From mattdm at mattdm.org  Sat May  1 04:19:15 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 1 May 2004 00:19:15 -0400
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083369058.3978.56.camel@localhost.localdomain>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083360223.15207.303.camel@cgf.boston.redhat.com>
	<1083369058.3978.56.camel@localhost.localdomain>
Message-ID: <20040501041915.GA18175@jadzia.bu.edu>

On Fri, Apr 30, 2004 at 04:50:59PM -0700, Per Bjornsson wrote:
> If the answer is "no", is it because of perceived destabilization or
> because it takes time from new development? If it is the latter, would
> it be possible for volunteer-packaged updates to be considered for
> inclusion as official updates? (I believe that the FC2 Gnome is very
> close to upstream, so it's likely that very little patch updating etc
> would have to be done - is that a correct assumption? I can see that for
> heavily patched packages would be more difficult for someone who is not
> the original packager to package a sane update.)

I think it's a bad idea to go down that road. Whole new Fedora Core releases
are planned to be quite frequent; within each one, the packages should be as
stable as possible.

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




From aoliva at redhat.com  Sat May  1 05:50:14 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 01 May 2004 02:50:14 -0300
Subject: Help Needed: Missing Obsoletes cause upgrade trouble
In-Reply-To: <1082745472.1687.1.camel@work.thl.home>
References: <4087119F.8010004@redhat.com>
	<20040423022256.7ccd6b34.fedora@wir-sind-cool.org>
	<20040423161330.2579149c.fedora@wir-sind-cool.org>
	<1082745472.1687.1.camel@work.thl.home>
Message-ID: <or4qr0lmqx.fsf@livre.redhat.lsd.ic.unicamp.br>

On Apr 23, 2004, Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> Am Fr, den 23.04.2004 schrieb Michael Schwendt um 16:13:
>> On Fri, 23 Apr 2004 02:22:56 +0200, Michael Schwendt wrote:
> [...]
>> >   alsa-driver ./. dev, MAKEDEV
>> >   alsa-lib, alsa-utils, all of alsa* because 1.0.4 > 1.0.3a!
>> 
>> Dangerous. In particular "alsa-driver", which contains many /dev files.

> What can I (as alsa-packager for fedora.us) do to solve this problem?
> Any hints?

IIRC the only conflict is with MAKEDEV.  How about getting your
alsa-driver to Require: the file provided by MAKEDEV, and split that
file out into a separate package, say alsa-driver-MAKEDEV?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From mark at weballistics.com  Sat May  1 09:06:22 2004
From: mark at weballistics.com (Mark Page)
Date: Sat, 01 May 2004 10:06:22 +0100
Subject: MySQL on FC1 and AMD64
In-Reply-To: <or4qr0lmqx.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <4087119F.8010004@redhat.com>
	<20040423022256.7ccd6b34.fedora@wir-sind-cool.org>
	<20040423161330.2579149c.fedora@wir-sind-cool.org>
	<1082745472.1687.1.camel@work.thl.home>
	<or4qr0lmqx.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <1083402382.25672.21.camel@dev.weballistics.co.uk>

Hi,

has anyone successfully installed the MySQL AMD64 rpms from
www.mysql.com on Core1, specifically for version 4.0.18 or 4.1.1.? 

Regards, -Mark.


I get the following errors;

[root at prod1 mark]# rpm -i MySQL-server-4.1.1-1.x86_64.rpm
warning: MySQL-server-4.1.1-1.x86_64.rpm: V3 DSA signature: NOKEY, key
ID 5072e1f5
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this
binary
or one of the libraries it was linked against is corrupt, improperly
built,
or misconfigured. This error can also be caused by malfunctioning
hardware.
We will try our best to scrape up some info that will hopefully help
diagnose
the problem, but since we have already crashed, something is definitely
wrong
and this may fail.

key_buffer_size=0
read_buffer_size=131072
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
= 217599 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
...
...




From buildsys at redhat.com  Sat May  1 11:31:44 2004
From: buildsys at redhat.com (Build System)
Date: Sat, 1 May 2004 07:31:44 -0400
Subject: rawhide report: 20040501 changes
Message-ID: <200405011131.i41BViM14349@porkchop.devel.redhat.com>

 

 
Updated Packages:

SysVinit-2.85-25
----------------
* Thu Apr 29 2004 Bill Nottingham <notting at redhat.com> 2.85-25

- fix build warning on make install (#121977)
- umount the SELinux filesystem on disabling it

anaconda-9.93-0.20040430011915
------------------------------
* Fri Apr 30 2004 Anaconda team <bugzilla at redhat.com>

- built new version from CVS

* Fri Apr 30 2004 Jeremy Katz <katzj at redhat.com>

- Update description, remove prereq on stuff that was only needed 
  for reconfig mode

* Tue Feb 24 2004 Jeremy Katz <katzj at redhat.com>

- buildrequire libselinux-devel


booty-0.36-1
------------
* Fri Apr 30 2004 Jeremy Katz <katzj at redhat.com> - 0.36-1

- some xfs fixes (#117968)

busybox-1.00.pre8-3
-------------------
* Wed Apr 21 2004 Karsten Hopp <karsten at redhat.de> 1.00.pre8-3 

- fix LS_COLOR in anaconda patch

exim-4.32-2
-----------
* Fri Apr 30 2004 David Woodhouse <dwmw2 at redhat.com> 4.32-2

- Enable IPv6 support, Cyrus saslauthd support, iconv.

gnome-applets-2.6.0-4
---------------------
* Thu Apr 29 2004 Karsten Hopp <karsten at redhat.de> 1:2.6.0-4

- fix error during update on s390(x) due to missing battery applet

gtkam-0.1.11-2
--------------
* Fri Apr 30 2004 Tim Waugh <twaugh at redhat.com> 0.1.11-2

- Only ship one desktop file (bug #121858).

kudzu-1.1.58-1
--------------
* Thu Apr 29 2004 Jeremy Katz <katzj at redhat.com> - 1.1.58-1

- fix libkudzu_loader for ppc

ltrace-0.3.32-2
---------------
* Thu Apr 22 2004 Jakub Jelinek <jakub at redhat.com> 0.3.32-2

- fix demangling

* Thu Apr 22 2004 Jakub Jelinek <jakub at redhat.com> 0.3.32-1

- update to 0.3.32
  - fix dict.c assertion (#114359)
  - x86_64 support
- rewrite elf.[ch] using libelf
- don't rely on st_value of SHN_UNDEF symbols in binaries,
  instead walk .rel{,a}.plt and compute the addresses (#115299)
- fix x86-64 support
- some ltrace.conf additions
- some format string printing fixes

mc-4.6.0-15
-----------
* Fri Apr 16 2004 Jakub Jelinek <jakub at redhat.com> 4.6.0-15

- don't use mmap if st_size doesn't fit into size_t
- fix one missed match_normal -> match_regex

* Fri Apr 16 2004 Jakub Jelinek <jakub at redhat.com> 4.6.0-14

- avoid buffer overflows in mcedit Replace function

* Wed Apr 14 2004 Jakub Jelinek <jakub at redhat.com> 4.6.0-13

- perl scripting fix


perl-Net-DNS-0.45-3
-------------------
* Thu Apr 29 2004 Chip Turner <cturner at redhat.com> 0.45-3

- fix bug 122039 -- add filter-depends.sh to remove Win32 deps

policy-1.11.2-21
----------------
* Wed Apr 28 2004 Dan Walsh <dwalsh at redhat.com> 1.11.2-21

- Add macros for userhelper

* Fri Apr 23 2004 Dan Walsh <dwalsh at redhat.com> 1.11.2-19

- Merge in Russell's Changes

* Thu Apr 22 2004 Dan Walsh <dwalsh at redhat.com> 1.11.2-18

- Allow rw of usb devices
- Check if /selinux is mounted before reload


rpmdb-fedora-1.92-0.20040501
----------------------------

screen-4.0.2-2
--------------
* Wed Apr 28 2004 Daniel Reed <djr at redhat.com> 4.0.2-2

- Add patch -logname to correct #121875

switchdesk-4.0.3-1
------------------
* Fri Apr 30 2004 Than Ngo <than at redhat.com> 4.0.3-1

- fix a invalid syntax bug in python script #121840, #121813
- update translations

system-config-bind-2.0.2-5
--------------------------
* Wed Apr 28 2004 Dan Walsh <dwalsh at redhat.com> 2.0.1-5

- Fix ns_value entry

xfce4-panel-4.0.5-2
-------------------
* Mon Apr 26 2004 Than Ngo <than at redhat.com> 4.0.5-2

- Change more defaults for fedora, use startup notification
  by default, remove "-splash" option from mozilla launcher. Thanks to Olivier Fourdan
- Patch to avoid crash at startup under some rare circumstances
- Change defaults for fedora




From fedora at wir-sind-cool.org  Sat May  1 11:45:40 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sat, 1 May 2004 13:45:40 +0200
Subject: Help Needed: Missing Obsoletes cause upgrade trouble
In-Reply-To: <or4qr0lmqx.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <4087119F.8010004@redhat.com>
	<20040423022256.7ccd6b34.fedora@wir-sind-cool.org>
	<20040423161330.2579149c.fedora@wir-sind-cool.org>
	<1082745472.1687.1.camel@work.thl.home>
	<or4qr0lmqx.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <20040501134540.648b0965.fedora@wir-sind-cool.org>

On 01 May 2004 02:50:14 -0300, Alexandre Oliva wrote:

> On Apr 23, 2004, Thorsten Leemhuis <fedora at leemhuis.xxx> wrote:
> 
> > Am Fr, den 23.04.2004 schrieb Michael Schwendt um 16:13:
> >> On Fri, 23 Apr 2004 02:22:56 +0200, Michael Schwendt wrote:
> > [...]
> >> >   alsa-driver ./. dev, MAKEDEV
> >> >   alsa-lib, alsa-utils, all of alsa* because 1.0.4 > 1.0.3a!
> >> 
> >> Dangerous. In particular "alsa-driver", which contains many /dev files.
> 
> > What can I (as alsa-packager for fedora.us) do to solve this problem?
> > Any hints?
> 
> IIRC the only conflict is with MAKEDEV.  How about getting your
> alsa-driver to Require: the file provided by MAKEDEV, and split that
> file out into a separate package, say alsa-driver-MAKEDEV?

After analyzing the conflict in detail, an obvious suggestion [posted
off-list] has been to simply copy the conflicting file from MAKEDEV and
include it in the alsa-driver package, too. That would get rid of the
conflict.




From smoogen at lanl.gov  Sat May  1 15:54:25 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Sat, 1 May 2004 09:54:25 -0600 (MDT)
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <20040501041915.GA18175@jadzia.bu.edu>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083360223.15207.303.camel@cgf.boston.redhat.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<20040501041915.GA18175@jadzia.bu.edu>
Message-ID: <Pine.LNX.4.58.0405010954030.7229@smoogen1.lanl.gov>

On Sat, 1 May 2004, Matthew Miller wrote:

>On Fri, Apr 30, 2004 at 04:50:59PM -0700, Per Bjornsson wrote:
>> If the answer is "no", is it because of perceived destabilization or
>> because it takes time from new development? If it is the latter, would
>> it be possible for volunteer-packaged updates to be considered for
>> inclusion as official updates? (I believe that the FC2 Gnome is very
>> close to upstream, so it's likely that very little patch updating etc
>> would have to be done - is that a correct assumption? I can see that for
>> heavily patched packages would be more difficult for someone who is not
>> the original packager to package a sane update.)
>
>I think it's a bad idea to go down that road. Whole new Fedora Core releases
>are planned to be quite frequent; within each one, the packages should be as
>stable as possible.

I think that people who want 2.6.1 can make the packages and put them in 
fedora.us for cooking.


-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From ByteEnable at austin.rr.com  Sat May  1 18:17:18 2004
From: ByteEnable at austin.rr.com (ByteEnable)
Date: Sat, 1 May 2004 13:17:18 -0500
Subject: Compiling digikam I get -lselinux lib errors with Test3
Message-ID: <200405011317.18398.ByteEnable@austin.rr.com>

Compiling digikam gives me -lselinux ld errors.

Byte




From chabotc at 4-ice.com  Sat May  1 18:47:45 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Sat, 01 May 2004 20:47:45 +0200
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <Pine.LNX.4.58.0405010954030.7229@smoogen1.lanl.gov>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>	<1083360223.15207.303.camel@cgf.boston.redhat.com>	<1083369058.3978.56.camel@localhost.localdomain>	<20040501041915.GA18175@jadzia.bu.edu>
	<Pine.LNX.4.58.0405010954030.7229@smoogen1.lanl.gov>
Message-ID: <4093F0D1.1030903@4-ice.com>

Oh while building gnome 2.6.1 packages (for my own use really, process 
is easy enough, update .spec and download new .tar.bz2's) i noticed that 
the current fedora gnome 2.6.0 already has a lot of patches downported 
from 2.6.1 (and a few of the 2.6.1 patches actually come from fedora 
development)

The difference between 'fedora gnome 2.6.0' and 'gnome 2.6.1' isnt as 
big as you would/might think.

    -- Chris

Stephen Smoogen wrote:

>On Sat, 1 May 2004, Matthew Miller wrote:
>
>  
>
>>On Fri, Apr 30, 2004 at 04:50:59PM -0700, Per Bjornsson wrote:
>>    
>>
>>>If the answer is "no", is it because of perceived destabilization or
>>>because it takes time from new development? If it is the latter, would
>>>it be possible for volunteer-packaged updates to be considered for
>>>inclusion as official updates? (I believe that the FC2 Gnome is very
>>>close to upstream, so it's likely that very little patch updating etc
>>>would have to be done - is that a correct assumption? I can see that for
>>>heavily patched packages would be more difficult for someone who is not
>>>the original packager to package a sane update.)
>>>      
>>>
>>I think it's a bad idea to go down that road. Whole new Fedora Core releases
>>are planned to be quite frequent; within each one, the packages should be as
>>stable as possible.
>>    
>>
>
>I think that people who want 2.6.1 can make the packages and put them in 
>fedora.us for cooking.
>
>
>  
>




From smoogen at lanl.gov  Sat May  1 19:25:37 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Sat, 1 May 2004 13:25:37 -0600 (MDT)
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <4093F0D1.1030903@4-ice.com>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083360223.15207.303.camel@cgf.boston.redhat.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<20040501041915.GA18175@jadzia.bu.edu>
	<Pine.LNX.4.58.0405010954030.7229@smoogen1.lanl.gov>
	<4093F0D1.1030903@4-ice.com>
Message-ID: <Pine.LNX.4.58.0405011324350.7229@smoogen1.lanl.gov>

On Sat, 1 May 2004, Chris Chabot wrote:

>Oh while building gnome 2.6.1 packages (for my own use really, process 
>is easy enough, update .spec and download new .tar.bz2's) i noticed that 
>the current fedora gnome 2.6.0 already has a lot of patches downported 
>from 2.6.1 (and a few of the 2.6.1 patches actually come from fedora 
>development)
>
>The difference between 'fedora gnome 2.6.0' and 'gnome 2.6.1' isnt as 
>big as you would/might think.
>

The big difference is usually translations and similar items that have 
to be redone when version numbers change. Sometimes it is something 
small.. sometimes it is something ugly.


-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From rdieter at math.unl.edu  Sat May  1 22:35:02 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sat, 01 May 2004 17:35:02 -0500
Subject: Compiling digikam I get -lselinux lib errors with Test3
In-Reply-To: <200405011317.18398.ByteEnable@austin.rr.com>
References: <200405011317.18398.ByteEnable@austin.rr.com>
Message-ID: <40942616.5020007@math.unl.edu>

ByteEnable wrote:
> Compiling digikam gives me -lselinux ld errors.

It would help if you gave more details (like the *exact* error you receive).

Though, for the record, it compiled fine for me.

Perhaps you need libselinux-devel to be installed.

-- Rex




From helios82 at optushome.com.au  Sat May  1 23:28:36 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Sun, 02 May 2004 09:28:36 +1000
Subject: Compiling digikam I get -lselinux lib errors with Test3
In-Reply-To: <200405011317.18398.ByteEnable@austin.rr.com>
References: <200405011317.18398.ByteEnable@austin.rr.com>
Message-ID: <1083454116.3572.22.camel@fc1>

On Sun, 2004-05-02 at 04:17, ByteEnable wrote:
> Compiling digikam gives me -lselinux ld errors.
> 
> Byte

See this for a fix:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121764

Regards,
-Matt
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 

-------------- 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/20040502/2419e1fc/attachment.sig>

From dennis at ausil.us  Sun May  2 00:37:22 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Sun, 2 May 2004 10:37:22 +1000
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
Message-ID: <200405021037.22538.dennis@ausil.us>

Recently the version of libgcrypt was increased  to 1.1.94  as a result of 
this newpg would not build against the newer libgcrypt  i sent an email to 
gcrypt-devel list and this is what i got back 

<quote>
Don't build newpg at all. ?It has been superseded by gnupg-1.9.x .

You would need an old libgcrypt < 1.1.42 to build it. ?The configure
sscript was not able to detect newer versions with a changed API. 
</quote>

we have a problem here seems we no longer need newpg  but we need things it 
provides  for gpgme gpgme03 cryptplug  gpa  kgpg (which doesnt complain so 
much  just says its not there)   to get these things it provides  we need to 
go to the newer gnupg  or we need to revert back to the older libgcrypt.

being so late in the cycle i dont know which would be best.  so i thought id 
ask before filling a bug against something.  it does need to be fixed before 
final is out  as people will complain if they cant decrypt email in kmail or 
mutt gpa doesnt work  etc. i think we should probably go back to the old 
version of libgcrypt

Dennis




From aleksey at nogin.org  Sun May  2 01:33:53 2004
From: aleksey at nogin.org (Aleksey Nogin)
Date: Sat, 01 May 2004 18:33:53 -0700
Subject: "headers" directory is missing from Raw Hide?
Message-ID: <40945001.5080909@nogin.org>

http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386 
is suddenly missing its "headers" directory (but does include 
directories rpmdbbuild.6390 and compsbuild.6390 that, I am guessing, 
should not be there). What's going on?

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907




From notting at redhat.com  Sun May  2 02:53:05 2004
From: notting at redhat.com (Bill Nottingham)
Date: Sat, 1 May 2004 22:53:05 -0400
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <200405021037.22538.dennis@ausil.us>
References: <200405021037.22538.dennis@ausil.us>
Message-ID: <20040502025305.GE13958@nostromo.devel.redhat.com>

Dennis Gilmore (dennis at ausil.us) said: 
> Recently the version of libgcrypt was increased  to 1.1.94  as a result of 
> this newpg would not build against the newer libgcrypt  i sent an email to 
> gcrypt-devel list and this is what i got back 
> 
> <quote>
> Don't build newpg at all. ?It has been superseded by gnupg-1.9.x .
> 
> You would need an old libgcrypt < 1.1.42 to build it. ?The configure
> sscript was not able to detect newer versions with a changed API. 
> </quote>
> 
> we have a problem here seems we no longer need newpg  but we need things it 
> provides  for gpgme gpgme03 cryptplug  gpa  kgpg (which doesnt complain so 
> much  just says its not there)   to get these things it provides  we need to 
> go to the newer gnupg  or we need to revert back to the older libgcrypt.
> 
> being so late in the cycle i dont know which would be best.  so i thought id 
> ask before filling a bug against something.  it does need to be fixed before 
> final is out  as people will complain if they cant decrypt email in kmail or 
> mutt gpa doesnt work  etc. i think we should probably go back to the old 
> version of libgcrypt

For a third-party package we don't ship? It's probably not going to
happen at this point. Note that, for example, mutt with gnupg will
work pretty much the same as it normally does in core - it doesn't
require libgcrypt. 

libgcrypt was updated for a package we do ship (cryptsetup for dm-crypt).

Bill




From notting at redhat.com  Sun May  2 02:53:29 2004
From: notting at redhat.com (Bill Nottingham)
Date: Sat, 1 May 2004 22:53:29 -0400
Subject: "headers" directory is missing from Raw Hide?
In-Reply-To: <40945001.5080909@nogin.org>
References: <40945001.5080909@nogin.org>
Message-ID: <20040502025329.GF13958@nostromo.devel.redhat.com>

Aleksey Nogin (aleksey at nogin.org) said: 
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386 
> is suddenly missing its "headers" directory (but does include 
> directories rpmdbbuild.6390 and compsbuild.6390 that, I am guessing, 
> should not be there). What's going on?

Tree build failure. Undiagnosed as of yet.

Bill




From aoliva at redhat.com  Sun May  2 02:56:53 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 01 May 2004 23:56:53 -0300
Subject: Module ohci1394 not found
In-Reply-To: <1083186496.5085.85.camel@roadrash.rdu.redhat.com>
References: <1083185485.2241.3.camel@localhost.localdomain>
	<1083186496.5085.85.camel@roadrash.rdu.redhat.com>
Message-ID: <orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>

On Apr 28, 2004, Chris Kloiber <ckloiber at ckloiber.com> wrote:

> FireWire is currently busted in the latest kernel trees. IIRC it
> compiles but explodes wonderfully on insertion, taking the whole system
> and half the of the South East USA seacoast with it into oblivion. It
> will likely be turned on again when it works.

Which probably means it won't make it to FC2 final.  I plan on
offering some work-arounds for Firewire users, sort of like I did for
FC1.  My plan is to take the Firewire code that shipped with kernel
2.6.3, since that has worked quite reliably for me.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From ByteEnable at austin.rr.com  Sun May  2 03:11:30 2004
From: ByteEnable at austin.rr.com (ByteEnable)
Date: Sat, 1 May 2004 22:11:30 -0500
Subject: Compiling digikam I get -lselinux lib errors with Test3
In-Reply-To: <40942616.5020007@math.unl.edu>
References: <200405011317.18398.ByteEnable@austin.rr.com>
	<40942616.5020007@math.unl.edu>
Message-ID: <200405012211.30352.ByteEnable@austin.rr.com>

On Saturday 01 May 2004 17:35, Rex Dieter wrote:
> ByteEnable wrote:
> > Compiling digikam gives me -lselinux ld errors.
>
> It would help if you gave more details (like the *exact* error you
> receive).
>
> Though, for the record, it compiled fine for me.
>
> Perhaps you need libselinux-devel to be installed.
>
> -- Rex

Yeah I probably did.  What I did do at the time was a quick search for selinux 
and selinux-devel and found none, so I just removed the -lselinux dep from 
the two .la files that they were in.

Byte




From katzj at redhat.com  Sun May  2 03:30:21 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 01 May 2004 23:30:21 -0400
Subject: Compiling digikam I get -lselinux lib errors with Test3
In-Reply-To: <200405012211.30352.ByteEnable@austin.rr.com>
References: <200405011317.18398.ByteEnable@austin.rr.com>
	<40942616.5020007@math.unl.edu>
	<200405012211.30352.ByteEnable@austin.rr.com>
Message-ID: <1083468620.11602.5.camel@rivendell.local.net>

On Sat, 2004-05-01 at 22:11 -0500, ByteEnable wrote:
> On Saturday 01 May 2004 17:35, Rex Dieter wrote:
> > ByteEnable wrote:
> > > Compiling digikam gives me -lselinux ld errors.
> >
> > It would help if you gave more details (like the *exact* error you
> > receive).
> >
> > Though, for the record, it compiled fine for me.
> >
> > Perhaps you need libselinux-devel to be installed.
> Yeah I probably did.  What I did do at the time was a quick search for selinux 
> and selinux-devel and found none, so I just removed the -lselinux dep from 
> the two .la files that they were in.

Which .la files?  Whatever library it is that actually needed libselinux
should probably get a dependency added in its -devel subpackage.

Jeremy




From helios82 at optushome.com.au  Sun May  2 04:06:08 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Sun, 02 May 2004 14:06:08 +1000
Subject: problems and questions with Red Hat Bugzilla
Message-ID: <1083470767.3432.44.camel@fc1>

Hello,

Trying to go to http://bugzilla.redhat.com/bugzilla/easy_enter_bug.cgi
produces a software error:
"data/versioncache did not return a true value at globals.pl line 692."
Anyone else seeing this? I sent an email to bugzilla-owner at redhat.com
about it. This would go to David Lawrence no?

Also, I'd like to be able to "watch" new bug reports w/o having to
manually CC: myself to individual reports. I tried entering package
owner names (notting at redhat.com, katzj at redhat.com etc.) into the input
field at the following page, but this has no effect.
http://bugzilla.redhat.com/bugzilla/userprefs.cgi - in the "Email"
section. Is there a way to setup my preferences to automatically be
emailed other people's new bug reports the same as is the case for my
own? Or is this an RFE that I should file against bugzilla? 

Regards,
-Matt
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 

-------------- 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/20040502/1911b2b7/attachment.sig>

From dennis at ausil.us  Sun May  2 03:43:58 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Sun, 2 May 2004 13:43:58 +1000
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <20040502025305.GE13958@nostromo.devel.redhat.com>
References: <200405021037.22538.dennis@ausil.us>
	<20040502025305.GE13958@nostromo.devel.redhat.com>
Message-ID: <200405021343.58132.dennis@ausil.us>

Once upon a time Sunday 02 May 2004 12:53 pm, Bill Nottingham wrote:
> Dennis Gilmore (dennis at ausil.us) said:

>
> For a third-party package we don't ship? It's probably not going to
> happen at this point. Note that, for example, mutt with gnupg will
> work pretty much the same as it normally does in core - it doesn't
> require libgcrypt.
>
> libgcrypt was updated for a package we do ship (cryptsetup for dm-crypt).
>
> Bill

well fedora.us has quite a few packages that do require it  ie  gpgme gpgme03 
cryptplug.   mutt needs gpgme03  kmail uses cryptplug which needs gpgme03 so 
you are breaking packages in fedora.us and saying too bad  not good,  
consideration has to be taken  to packages in extras  and it seems  its not.   
so it leaves us to upping gnupg  to a version that is considered alpha to 
support the extras tree or does that not come into consideration?

So far the fedora project  seems to be  Red Hat doing what it wants  with 
slightly more input from others but no real effort to open the project up.  
for a while now ive been starting to get a bad taste in my mouth about the 
whole thing  and more and more it seems to be justified. 

Dennis




From buildsys at redhat.com  Sun May  2 04:30:00 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 2 May 2004 00:30:00 -0400
Subject: rawhide report: 20040501 changes
Message-ID: <200405020430.i424U0C10148@porkchop.devel.redhat.com>




From notting at redhat.com  Sun May  2 05:00:56 2004
From: notting at redhat.com (Bill Nottingham)
Date: Sun, 2 May 2004 01:00:56 -0400
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <200405021343.58132.dennis@ausil.us>
References: <200405021037.22538.dennis@ausil.us>
	<20040502025305.GE13958@nostromo.devel.redhat.com>
	<200405021343.58132.dennis@ausil.us>
Message-ID: <20040502050056.GB14821@nostromo.devel.redhat.com>

Dennis Gilmore (dennis at ausil.us) said: 
> > For a third-party package we don't ship? It's probably not going to
> > happen at this point. Note that, for example, mutt with gnupg will
> > work pretty much the same as it normally does in core - it doesn't
> > require libgcrypt.
> >
> > libgcrypt was updated for a package we do ship (cryptsetup for dm-crypt).
> 
> well fedora.us has quite a few packages that do require it  ie  gpgme gpgme03 
> cryptplug.   mutt needs gpgme03

mutt doesn't use gpgme at all without adding external patches and
rebuilding first.
Ergo, not a concern for Core or Extras, only Alternatives.

> kmail uses cryptplug which needs gpgme03 so 
> you are breaking packages in fedora.us and saying too bad  not good

gpgme03 actually builds without newpg just fine, and therefore
doesn't depend on libgcrypt. I assume you've built it that way
explicitly for S/MIME?.

> consideration has to be taken  to packages in extras  and it seems  its not.

TBH, it's the first time I've heard of this conclict. In some cases,
it is impossible to test against the entirety of fedora.us, especially
when it's not all even built for FC2.

> so it leaves us to upping gnupg  to a version that is considered alpha to 
> support the extras tree or does that not come into consideration?

Thats *a* alternative (fedora.us is shipping 'alpha' gpgme, anyway), but
not a good one. Carrying around a libgcrypt1 compat library certainly
seems much simpler, and would be trivial to package.

> So far the fedora project  seems to be  Red Hat doing what it wants  with 
> slightly more input from others but no real effort to open the project up.  

Yes, exactly! We want to ram everything down your throat. MUWHAHAHAHA.
WE WILL BREAK YOUR SOFTWARE AND CRUSH YOU, YOU INSIGNIFICANT WORM! 
Next step, looting, pillaging, and rampaging.

We're just trying to add functionality requested by our users.

Bill




From ByteEnable at austin.rr.com  Sun May  2 05:13:05 2004
From: ByteEnable at austin.rr.com (ByteEnable)
Date: Sun, 2 May 2004 00:13:05 -0500
Subject: Compiling digikam I get -lselinux lib errors with Test3
In-Reply-To: <1083468620.11602.5.camel@rivendell.local.net>
References: <200405011317.18398.ByteEnable@austin.rr.com>
	<200405012211.30352.ByteEnable@austin.rr.com>
	<1083468620.11602.5.camel@rivendell.local.net>
Message-ID: <200405020013.05655.ByteEnable@austin.rr.com>

On Saturday 01 May 2004 22:30, Jeremy Katz wrote:
> On Sat, 2004-05-01 at 22:11 -0500, ByteEnable wrote:
> > On Saturday 01 May 2004 17:35, Rex Dieter wrote:
> > > ByteEnable wrote:
> > > > Compiling digikam gives me -lselinux ld errors.
> > >
> > > It would help if you gave more details (like the *exact* error you
> > > receive).
> > >
> > > Though, for the record, it compiled fine for me.
> > >
> > > Perhaps you need libselinux-devel to be installed.
> >
> > Yeah I probably did.  What I did do at the time was a quick search for
> > selinux and selinux-devel and found none, so I just removed the -lselinux
> > dep from the two .la files that they were in.
>
> Which .la files?  Whatever library it is that actually needed libselinux
> should probably get a dependency added in its -devel subpackage.
>
> Jeremy

libfam.la
librpmbuild.la
librpm.la

Byte




From dennis at ausil.us  Sun May  2 05:18:09 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Sun, 2 May 2004 15:18:09 +1000
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <20040502050056.GB14821@nostromo.devel.redhat.com>
References: <200405021037.22538.dennis@ausil.us>
	<200405021343.58132.dennis@ausil.us>
	<20040502050056.GB14821@nostromo.devel.redhat.com>
Message-ID: <200405021518.09927.dennis@ausil.us>

Once upon a time Sunday 02 May 2004 3:00 pm, Bill Nottingham wrote:
> Dennis Gilmore (dennis at ausil.us) said:


> > kmail uses cryptplug which needs gpgme03 so
> > you are breaking packages in fedora.us and saying too bad  not good
>
> gpgme03 actually builds without newpg just fine, and therefore
> doesn't depend on libgcrypt. I assume you've built it that way
> explicitly for S/MIME?.

yes  both gpgme and gpgme03 are built with s/MIME support in fedora.us 

Dennis




From notting at redhat.com  Sun May  2 05:29:40 2004
From: notting at redhat.com (Bill Nottingham)
Date: Sun, 2 May 2004 01:29:40 -0400
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <200405021518.09927.dennis@ausil.us>
References: <200405021037.22538.dennis@ausil.us>
	<200405021343.58132.dennis@ausil.us>
	<20040502050056.GB14821@nostromo.devel.redhat.com>
	<200405021518.09927.dennis@ausil.us>
Message-ID: <20040502052940.GA1032@nostromo.devel.redhat.com>

Dennis Gilmore (dennis at ausil.us) said: 
> > > kmail uses cryptplug which needs gpgme03 so
> > > you are breaking packages in fedora.us and saying too bad  not good
> >
> > gpgme03 actually builds without newpg just fine, and therefore
> > doesn't depend on libgcrypt. I assume you've built it that way
> > explicitly for S/MIME?.
> 
> yes  both gpgme and gpgme03 are built with s/MIME support in fedora.us 

So, the package that comes down to breaking is newpg, correct?

libgcrypt actually will get upgraded again, to 1.2.0. It's the Right
Thing To Do, as it's the first official stable release that they've
done; even the previous 1.1.12 (or whatever) series wasn't deemed
as such by then. So it's really the version we should be shipping, and
we do have an app that uses it.

In the short term, yes, we should probably have a libgcrypt1 package
in extras. In the long term, core should move to gnupg-2.0, and some
of this will go away. (In fact, just the fact that there's gpgme03
and gpgme package shows problems... everything should really be using
one interface.)

Bill




From dennis at ausil.us  Sun May  2 05:38:43 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Sun, 2 May 2004 15:38:43 +1000
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <20040502052940.GA1032@nostromo.devel.redhat.com>
References: <200405021037.22538.dennis@ausil.us>
	<200405021518.09927.dennis@ausil.us>
	<20040502052940.GA1032@nostromo.devel.redhat.com>
Message-ID: <200405021538.43398.dennis@ausil.us>

Once upon a time Sunday 02 May 2004 3:29 pm, Bill Nottingham wrote:
> Dennis Gilmore (dennis at ausil.us) said:
> > > > kmail uses cryptplug which needs gpgme03 so
> > > > you are breaking packages in fedora.us and saying too bad  not good
> > >
> > > gpgme03 actually builds without newpg just fine, and therefore
> > > doesn't depend on libgcrypt. I assume you've built it that way
> > > explicitly for S/MIME?.
> >
> > yes  both gpgme and gpgme03 are built with s/MIME support in fedora.us
>
> So, the package that comes down to breaking is newpg, correct?

yes newpg wont build at present.  and yes i saw  they said that 1.2.0 was the 
first stable release it seems that the whole gnupg project has a weird mix of 
dependacies  stable software relying on unstable and alpha software

> libgcrypt actually will get upgraded again, to 1.2.0. It's the Right
> Thing To Do, as it's the first official stable release that they've
> done; even the previous 1.1.12 (or whatever) series wasn't deemed
> as such by then. So it's really the version we should be shipping, and
> we do have an app that uses it.

ill work on a libgcrypt1 package in the intrim  solution.  using gnupg2 would 
reslove most if not all of the problems 

> In the short term, yes, we should probably have a libgcrypt1 package
> in extras. In the long term, core should move to gnupg-2.0, and some
> of this will go away. (In fact, just the fact that there's gpgme03
> and gpgme package shows problems... everything should really be using
> one interface.)

they seem to update some things and not others.  it seems in a much bigger 
mess that pwlib and openh323 

Dennis




From skvidal at phy.duke.edu  Sun May  2 06:05:44 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 02 May 2004 02:05:44 -0400
Subject: fedora core 3 goals.
Message-ID: <1083477944.3244.8.camel@binkley>

Hi,
 I was wondering what the distribution, community and infrastructure
goals are for fedora core 3. 
 
Will CVS be opened up?
Will extras be named extras?
Will selinux be on the hit-list again?
Will the webpage be more interesting/dynamic?
What's the timeline look like?
Will there be any time dedicated to just infrastructure/community
development and a general hold is put on the distro devel?
Any plans for build system work to come back to the fore?

Maybe right after the release of fc2 would be a good time for a 'state
of the fedora' message from the project leader?
Maybe sooner?

-sv





From buildsys at redhat.com  Sun May  2 06:42:53 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 2 May 2004 02:42:53 -0400
Subject: rawhide report: 20040502 changes
Message-ID: <200405020642.i426gr514812@porkchop.devel.redhat.com>

 

 
Updated Packages:

rpmdb-fedora-1.92-0.20040502
----------------------------




From buildsys at redhat.com  Sun May  2 10:56:42 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 2 May 2004 06:56:42 -0400
Subject: rawhide report: 20040502 changes
Message-ID: <200405021056.i42AugG05613@porkchop.devel.redhat.com>

 

 
Updated Packages:





From dragoran at feuerpokemon.de  Sun May  2 11:07:47 2004
From: dragoran at feuerpokemon.de (dragoran)
Date: Sun, 02 May 2004 13:07:47 +0200
Subject: fedora core 3 goals.
In-Reply-To: <1083477944.3244.8.camel@binkley>
References: <1083477944.3244.8.camel@binkley>
Message-ID: <4094D683.2070302@feuerpokemon.de>

seth vidal schrieb:

>Hi,
> I was wondering what the distribution, community and infrastructure
>goals are for fedora core 3. 
> 
>Will CVS be opened up?
>Will extras be named extras?
>Will selinux be on the hit-list again?
>Will the webpage be more interesting/dynamic?
>What's the timeline look like?
>Will there be any time dedicated to just infrastructure/community
>development and a general hold is put on the distro devel?
>Any plans for build system work to come back to the fore?
>
>Maybe right after the release of fc2 would be a good time for a 'state
>of the fedora' message from the project leader?
>Maybe sooner?
>
>-sv
>
>
>
>  
>
I have read that selinux will be in RHEL4 so it will be also in fc3




From ville.skytta at iki.fi  Sun May  2 11:51:13 2004
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Sun, 02 May 2004 14:51:13 +0300
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <200405021538.43398.dennis@ausil.us>
References: <200405021037.22538.dennis@ausil.us>
	<200405021518.09927.dennis@ausil.us>
	<20040502052940.GA1032@nostromo.devel.redhat.com>
	<200405021538.43398.dennis@ausil.us>
Message-ID: <1083498673.5261.495.camel@bobcat.mine.nu>

On Sun, 2004-05-02 at 08:38, Dennis Gilmore wrote:
> Once upon a time Sunday 02 May 2004 3:29 pm, Bill Nottingham wrote:
>
> > So, the package that comes down to breaking is newpg, correct?

Yes.

> ill work on a libgcrypt1 package in the intrim  solution.  using gnupg2 would 
> reslove most if not all of the problems 

As long as gnupg2 (when it's time) will have "Obsoletes: newpg", I
believe we can find a clean solution by packaging libgcrypt1 and
changing gpgme and gpgme03 to require %{_bindir}/gpgsm instead of newpg.




From dennis at ausil.us  Sun May  2 12:51:53 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Sun, 2 May 2004 22:51:53 +1000
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <1083498673.5261.495.camel@bobcat.mine.nu>
References: <200405021037.22538.dennis@ausil.us>
	<200405021538.43398.dennis@ausil.us>
	<1083498673.5261.495.camel@bobcat.mine.nu>
Message-ID: <200405022251.53292.dennis@ausil.us>

Once upon a time Sunday 02 May 2004 9:51 pm, Ville Skytt? wrote:
> On Sun, 2004-05-02 at 08:38, Dennis Gilmore wrote:
> > Once upon a time Sunday 02 May 2004 3:29 pm, Bill Nottingham wrote:
> > > So, the package that comes down to breaking is newpg, correct?
>
> Yes.
>
> > ill work on a libgcrypt1 package in the intrim  solution.  using gnupg2
> > would reslove most if not all of the problems
>
> As long as gnupg2 (when it's time) will have "Obsoletes: newpg", I
> believe we can find a clean solution by packaging libgcrypt1 and
> changing gpgme and gpgme03 to require %{_bindir}/gpgsm instead of newpg.

should we just package a gnupg2 package now?  can it be done cleanly to have 2 
versions of gnupg on the system at once?  we will need to file a bug against 
gnupg i guess to try and make sure that when it gets to gnupg2  that we have 
the Obsoletes: newpg in it.


Dennis




From helios82 at optushome.com.au  Sun May  2 13:32:03 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Sun, 02 May 2004 23:32:03 +1000
Subject: problems and questions with Red Hat Bugzilla
In-Reply-To: <1083470767.3432.44.camel@fc1>
References: <1083470767.3432.44.camel@fc1>
Message-ID: <1083504723.8820.2.camel@fc1>

On Sun, 2004-05-02 at 14:06, Matt Hansen wrote:

Well the Bugzilla error I was getting has cleared up. As for the other
half of my post, I haven't found any way to do this yet. Maybe it's not
possible?

Regards,
-Matt
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 

-------------- 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/20040502/abae09bd/attachment.sig>

From helios82 at optushome.com.au  Sun May  2 13:33:50 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Sun, 02 May 2004 23:33:50 +1000
Subject: rawhide report: 20040502 changes
In-Reply-To: <200405021056.i42AugG05613@porkchop.devel.redhat.com>
References: <200405021056.i42AugG05613@porkchop.devel.redhat.com>
Message-ID: <1083504830.8820.5.camel@fc1>

On Sun, 2004-05-02 at 20:56, Build System wrote:
>  
> 
> Updated Packages:

Something funny going on with the Build System it seems. Well, it is a
Sunday...

-Matt
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 





From casimiro_barreto at uol.com.br  Sun May  2 14:55:16 2004
From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto)
Date: Sun, 02 May 2004 11:55:16 -0300
Subject: fedora core 3 goals.
In-Reply-To: <4094D683.2070302@feuerpokemon.de>
References: <1083477944.3244.8.camel@binkley>
	<4094D683.2070302@feuerpokemon.de>
Message-ID: <40950BD4.2090007@uol.com.br>

dragoran escreveu:

> seth vidal schrieb:
>
>> Hi,
>> I was wondering what the distribution, community and infrastructure
>> goals are for fedora core 3.
>> Will CVS be opened up?
>> Will extras be named extras?
>> Will selinux be on the hit-list again?
>> Will the webpage be more interesting/dynamic?
>> What's the timeline look like?
>> Will there be any time dedicated to just infrastructure/community
>> development and a general hold is put on the distro devel?
>> Any plans for build system work to come back to the fore?
>>
>> Maybe right after the release of fc2 would be a good time for a 'state
>> of the fedora' message from the project leader?
>> Maybe sooner?
>>
>> -sv
>>
>>
>>
>>  
>>
> I have read that selinux will be in RHEL4 so it will be also in fc3
>
>
Before enabling SELINUX, it is mandatory:

a) To widespread usefull user documentation, so people concerned with 
other subjects (like multimedia, etc) don't get stuck with permissions 
and related subjects. The first issue of SELINUX in FC2 was quite a 
mess, since users not familiar to security just got problems even to 
login...

b) Standard policies must allow common users at least to login for the 
first time without having to understand how selinux works.

Best regards,

Casimiro




From swan at shockfrosted.org  Sun May  2 14:33:26 2004
From: swan at shockfrosted.org (Stefan Schwandter)
Date: Sun, 02 May 2004 16:33:26 +0200
Subject: Epiphany
Message-ID: <1083508405.4679.1.camel@chello213047005199.301.13.tuwien.teleweb.at>

Hello,


is an update of Epiphany to 1.2.* planned for FC2? It seems that a
couple of bugfixes went in since 1.1.12.


regards, Stefan




From shfukuzawa at jcom.home.ne.jp  Sun May  2 15:45:59 2004
From: shfukuzawa at jcom.home.ne.jp (Shun Fukuzawa)
Date: Mon, 03 May 2004 00:45:59 +0900
Subject: mozilla on fedora core 2 
Message-ID: <409517B7.6020002@jcom.home.ne.jp>

Hi, this is Shun Fukuzawa.

Although fedora core 2 test 3 in Japanese is installed on my PC ,
Mozilla(1.6)'s menu is in English. But Japanese localized Mozilla is
already released.

Will Mozilla on fedora core 2 be localized for Japanese? Or not?




From makgab at freemail.hu  Sun May  2 19:01:28 2004
From: makgab at freemail.hu (MG)
Date: Sun, 02 May 2004 21:01:28 +0200
Subject: Quanta cpu usage in FC1...
Message-ID: <40954588.5020508@freemail.hu>


Hi!

I use the Fedora Core 1.
The quanta cpu usage is 100% and I cannot use it this time. :(
Why sould I do with quanta?

Bye!
G.







From wtogami at redhat.com  Sun May  2 20:25:34 2004
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 02 May 2004 10:25:34 -1000
Subject: [Fwd: URGENT: Naming conflict in Cyrus-IMAP 2.2 vs. leafnode 1.9]
Message-ID: <4095593E.6000500@redhat.com>

-------- Original Message --------
Subject: URGENT: Naming conflict in Cyrus-IMAP 2.2 vs. leafnode 1.9
Resent-Date: Sun, 2 May 2004 16:17:42 +0200
Resent-From: Michael Schwendt <fedora at wir-sind-cool.org>
Resent-To: warren at togami.com
Date: Sun, 2 May 2004 16:11:28 +0200
From: Matthias Andree <matthias.andree at gmx.de>
To: info-cyrus AT lists.andrew.cmu.edu, wcw+andrew2 AT cmu.edu,
cyrus-bugs AT andrew.cmu.edu, rjs3+cyrus AT andrew.cmu.edu
CC: rh0212ms AT arcor.de, fedora AT zuhause-local.de, ume AT freebsd.org

Dear sirs,

it has come to my attention today that version 2.2.3 of the Cyrus-IMAPd
package (announced 2004-01-15) has added a program and manual page
named "fetchnews" that were not present in previous official releases of
Cyrus-IMAPd such as 2.1.16 (2003-11-20).

I am the current maintainer of the "leafnode" NNTP package[1]
that has been using a program and manual page named "fetchnews" since
the release of leafnode 1.9.3 on 1999-07-15 under the aegis of the
previous maintainer, Cornelius Krasel.[2]

This naming conflict triggered a bug report against Fedora Linux, see
https://bugzilla.fedora.us/show_bug.cgi?id=1445 -- and I expect that
more naming conflicts show up as more distributors upgrade their
cyrus-imapd packages to 2.2. FreeBSD also has conflicting names in the
ports collection.

As leafnode 1.9 has been using the "fetchnews" name for almost five
years to date and has also been shipping with various distributions for
years, among them major and established ones such as Debian GNU/Linux,
FreeBSD, Mandrake Linux, NetBSD, OpenBSD and SuSE Linux, it appears
difficult to change the name in the middle of a leafnode stable series;
doing so would break existing configurations in those distributions, for
numerous users.

Given that Cyrus-IMAPd 2.2.3 has been released only this January, and
has not yet been adopted by all distributions (most are still shipping
Cyrus-IMAPd 2.1.N), renaming fetchnews to cyr_fetchnews would have
little impact _now_ but be a major inconvenience later.

Note that distributors HAVE TO take action, and to avoid every
distributor using their own name, causing confusion among our users,
let's address this from the top level.

Could you change your fetchnews program's name to cyr_fetchnews or
similar? I am offering to rename leafnode's fetchnews to something else
(leafnode-fetchnews, ln_fetchnews, to be determined) in the next major
version of leafnode, leafnode-2.0.0 (probably 2nd half 2004) in return.

I have marked the Subject "URGENT" because Fedora has scheduled a code
freeze for May 7th (next Friday), I'd hope that we can resolve the
problem before then.

Thank you in advance; I'm looking forward to hearing from you.

Yours sincerely,
Matthias Andree

------------
[1] http://leafnode.sourceforge.net/

[2] The oldest public leafnode release that I am aware of is
     leafnode-1.0.1, released 1996-11-04 by Arnd Gulbrandsen, Trolltech,
     Oslo, NO.




From rdieter at math.unl.edu  Sun May  2 20:28:59 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 2 May 2004 15:28:59 -0500 (CDT)
Subject: Compiling digikam I get -lselinux lib errors with Test3
In-Reply-To: <200405020013.05655.ByteEnable@austin.rr.com>
References: <200405011317.18398.ByteEnable@austin.rr.com>
	<200405012211.30352.ByteEnable@austin.rr.com>
	<1083468620.11602.5.camel@rivendell.local.net>
	<200405020013.05655.ByteEnable@austin.rr.com>
Message-ID: <Pine.LNX.4.58.0405021526320.7510@math.unl.edu>

On Sun, 2 May 2004, ByteEnable wrote:

> > Which .la files?  Whatever library it is that actually needed libselinux
> > should probably get a dependency added in its -devel subpackage.
> >
> > Jeremy
> 
> libfam.la
> librpmbuild.la
> librpm.la

I would argue that a better fix would be to modify the packages above to 
strip all references of libselinux from their .la files or possibly  
remove the .la files altogether (if they're not absolutely needed)

-- Rex




From wtogami at redhat.com  Sun May  2 21:25:12 2004
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 02 May 2004 11:25:12 -1000
Subject: gaim x86-64 broken protocols
Message-ID: <40956738.5070506@redhat.com>

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

gaim-0.77-3's yahoo authentication is broken on x86-64, but it works on 
ppc32 and i386.  We need your help in finding the fix for this within 
the next 2-3 days.  Additionally the Novell Groupwise and Zephyr 
protocols are also broken on x86-64, but they are of lower priority to 
our userbase.

http://cvs.sourceforge.net/viewcvs.py/gaim/gaim/src/protocols/yahoo/yahoo.c
http://cvs.sourceforge.net/viewcvs.py/gaim/gaim/src/protocols/yahoo/yahoo_auth.c

These are the two relevant source files.

Please notify us in #gaim and this mailing list thread if you have 
solved the problem.

Warren Togami
wtogami at redhat.com




From wrrhdev at riede.org  Sun May  2 21:32:43 2004
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 2 May 2004 17:32:43 -0400
Subject: sg (scsi generic) module missing
In-Reply-To: <20040412204955.GB723@devserv.devel.redhat.com> (from
	alan@redhat.com on Mon, Apr 12, 2004 at 16:49:55 -0400)
References: <20040412204032.GE1556856@hiwaay.net>
	<20040412204955.GB723@devserv.devel.redhat.com>
Message-ID: <20040502213243.GM28387@serve.riede.org>

On 2004.04.12 16:49, Alan Cox wrote:
> On Mon, Apr 12, 2004 at 03:40:32PM -0500, Chris Adams wrote:
> > > > module.  It was there in ./2.6.4-1.300, it's missing in 305.
> > > > What happened to it?
> > > 
> > > it's deprecated
> > 
> > How do I control my tape library robot?  AFAIK that is only controlled
> > via sg (the other SCSI modules ignore tape robots).
> 
> Use 2.4 or rebuild the kernel. Ditto with ide-scsi, both are needed for
> real world hardware. Oh and file a bug, and if it closed re-open it until
> you get a working answer.

FC2T3 is still missing the ide-scsi module! And filing a bug doesn't work :-(
I've had one in bugzilla since February 28, and no reaction whatsoever from
the Red Hat kernel packagers...

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

Why not compile ide-scsi? Why inconvenience owners of tape drives that need it?
Put it in unsupported for all I care, but compile it, _please_.

Willem Riede.




From tibbs at math.uh.edu  Sun May  2 21:44:48 2004
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 02 May 2004 16:44:48 -0500
Subject: gaim x86-64 broken protocols
In-Reply-To: <40956738.5070506@redhat.com>
References: <40956738.5070506@redhat.com>
Message-ID: <ufa8ygafqr3.fsf@epithumia.math.uh.edu>

>>>>> "WT" == Warren Togami <wtogami at redhat.com> writes:

WT> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122221
WT> gaim-0.77-3's yahoo authentication is broken on x86-64, but it
WT> works on ppc32 and i386.  We need your help in finding the fix for
WT> this within the next 2-3 days.

I have a dual Opteron machine running FC2T3, but no ability to work on
this.  If someone needs a temporary account for testing, please let me
know.

 - J<




From alan at redhat.com  Sun May  2 22:26:59 2004
From: alan at redhat.com (Alan Cox)
Date: Sun, 2 May 2004 18:26:59 -0400
Subject: sg (scsi generic) module missing
In-Reply-To: <20040502213243.GM28387@serve.riede.org>
References: <20040412204032.GE1556856@hiwaay.net>
	<20040412204955.GB723@devserv.devel.redhat.com>
	<20040502213243.GM28387@serve.riede.org>
Message-ID: <20040502222659.GC5327@devserv.devel.redhat.com>

On Sun, May 02, 2004 at 05:32:43PM -0400, Willem Riede wrote:
> FC2T3 is still missing the ide-scsi module! And filing a bug doesn't work :-(
> I've had one in bugzilla since February 28, and no reaction whatsoever from
> the Red Hat kernel packagers...
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117095
> 
> Why not compile ide-scsi? Why inconvenience owners of tape drives that need it?

And IDE multi-changers

> Put it in unsupported for all I care, but compile it, _please_.

Unfortunately Arjan and Dave are out of range of my torture kit so all I
can do is bitch at them as well (and if need be release rival kernel rpms
which would be a pita to have to do)




From Axel.Thimm at ATrpms.net  Sun May  2 22:48:47 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Mon, 3 May 2004 00:48:47 +0200
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <200405021037.22538.dennis@ausil.us>
References: <200405021037.22538.dennis@ausil.us>
Message-ID: <20040502224847.GA11942@neu.nirvana>

On Sun, May 02, 2004 at 10:37:22AM +1000, Dennis Gilmore wrote:
> Recently the version of libgcrypt was increased  to 1.1.94  as a result of 
> this newpg would not build against the newer libgcrypt

newpg has been flagged as obsoleted by the authors in favour of
gnupg2. You can get working copies of gnupg/gnupg2, gpgme, libgcrypt,
libassuan, libksba at ATrpms.net for FC1 back to RH7.3. FC2 will also
be supported when it gets released.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040503/17b32b4f/attachment.sig>

From casimiro_barreto at uol.com.br  Sun May  2 23:22:58 2004
From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto)
Date: Sun, 02 May 2004 20:22:58 -0300
Subject: sg (scsi generic) module missing
In-Reply-To: <20040502222659.GC5327@devserv.devel.redhat.com>
References: <20040412204032.GE1556856@hiwaay.net>	<20040412204955.GB723@devserv.devel.redhat.com>	<20040502213243.GM28387@serve.riede.org>
	<20040502222659.GC5327@devserv.devel.redhat.com>
Message-ID: <409582D2.4070000@uol.com.br>

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

About what's being discussed, I just ponder that failing to work
correctly with common devices (usb-storage, etc) is a fair good way of
killing a distribution. Ok, that's a will to make everything work with
certain device drivers (like make scsi disks work with sr_mod
(/dev/sr*) and (/dev/scd*)) but it is also very important to have in
mind that, until it is done and working fine, the "deprecated" devices
and modules and functions and whatsoever must still work in good shape.

The mainstream kernel 2.6.6-rc3-bk3 works with /dev/sg*. There are
bugs, but the user is still able to deal with them and get job done.
The fact that mainstream and FC2T3 differs in matters of functionality
raises the fear that such incompatibilities grow bigger in the future
and portability and interoperability among distributions (FC, SuSe,
Conectiva, Slackware, etc...) become a subject of concern. That would
be bloody sucking.

Regards,

Casimiro
Alan Cox Public key for 0x68FA52A33F440F2D:

| On Sun, May 02, 2004 at 05:32:43PM -0400, Willem Riede wrote:
|
|> FC2T3 is still missing the ide-scsi module! And filing a bug
|> doesn't work :-( I've had one in bugzilla since February 28, and
|> no reaction whatsoever from the Red Hat kernel packagers...
|>
|> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117095
|>
|> Why not compile ide-scsi? Why inconvenience owners of tape drives
|> that need it?
|
|
| And IDE multi-changers
|
|> Put it in unsupported for all I care, but compile it, _please_.
|
|
| Unfortunately Arjan and Dave are out of range of my torture kit so
| all I can do is bitch at them as well (and if need be release rival
| kernel rpms which would be a pita to have to do)
|
|
Public key for 0x68FA52A33F440F2D
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.4 (GNU/Linux)

mQGiBEAQK2cRBAC5dUcZbPeatM8tsmhIdfSOq2OMwXNM4eU4m7gARXml0iyaV3hs
vNN9CP8JMdkuB2CohAasxf8zZ28OmSKG9QuUj5PNbRPk/HSj/yKzPB6yedHBNssq
ajjJN19hoOB/YNCrXPecnUjJnTvQfgbC0CTNzM3zXfn8KNDpSa5kgZ6oZwCg3ZNx
eKpHbKAwkkasK1nLW3r5M80D/iY0eB1BqIsL2vCFufb8W2wIX/NEBxLa5vf1uxI9
aFXTmGeUuRHvIQHlAiJDdXi/MP1tf/pQdM8nDIxd5BegfkaTDkSJf4m+K13wsEoM
sDHx1uiQduQytSUjLcqVN7CueNWNrC7azaBHzFQgbpM0xL4rY/h4DvQg+X3h4qVg
etToA/47CkSeltJALUom+17PEa3DP0fkIuSQu6H6YKbkNkfUFup2N2kSAThqYf5d
aXjvehsN8GsgQAjOWyk3W+FbD+s/DQkLydiRL9STLXjY9NalkfVIhrn2a4djVYjW
pakHC+x0RiV23nlRWzQ73QljyKDlSWsVB3KdijuOeo3Yb5XjhrRDQ2FzaW1pcm8g
ZGUgQWxtZWlkYSBCYXJyZXRvIChQZXNzb2FsKSA8Y2FzaW1pcm9fYmFycmV0b0B1
b2wuY29tLmJyPohfBBMRAgAfBQJAECtnBQkAnjQABAsHAwIDFQIDAxYCAQIeAQIX
gAAKCRBo+lKjP0QPLUMwAJ0fNhBH5wWGVappX8wdB8tuwkVSkACgqL/CG+84UgZF
ATFBG7d2wkjVSNe5Ag0EQBArghAIAOwWVTsFepybl0mCSHoOF0vlcB0IlCywvBo3
nYLG6zUo8IUQpXg5R8YxBfXvsSpSK83QQElZmyB25gQm1BvEpdUMGs+VmfBddqfx
SH69k0W/rWuwQ90Auk3mQDk38CB/rT/Hem3vZkiGoT8vPxWuCO5UJm+Y36Gg6tJr
JdELhtAAC8aDpFx+T5Ye0lTh00F2dca8cR+gf7S/lZseWutvZGvziqTEvC8cTzmb
af2x23o/RwAsy5wz1ljxh6iF59YeJsclNsQ0tBiRnXphqzcOPBorVUIF4EHS9sb+
tt7FhkhkSSDm2A9/veoIZmy81P2IniwAta1bEsz0EQsUSExhyiMAAwUIAIRADBcW
DskFNLYrY4KRNmL192pOgRH6BQEw8n+mrn2uuRGCR6ZnoDm3v5/nbRLMBwHZQxLP
EciYkPG9gTx/I74mQcgitqCCYiI2UzTaz/BbAMCIqrWyzGYav9sjaJtd0ko2eOZx
TU53pw50dwV9bW+xnh9a1x8x1Qoj1bnOyhESOJ4THGFhnjeMON+DhU2N+eyax9Md
jRUtxOJB6z7RVjELn6islKpEzH/1wKrqOFkL7BEr+3m2mjm8sBBs1gC3u+sNbgGB
Ebv5sGBsMX4+LbBIh4aw+fanzHZhVSAjSgVl7RH7bgF6YqAKAfKB1EpRwTW3FTqH
LMeUz8mQtbt8IpCITAQYEQIADAUCQBArggUJAJ40AAAKCRBo+lKjP0QPLZL/AJwJ
OSAyi5Zi8OmeL7iuNeHAeY2AUwCgn9LHEbusFl2KXWHnlFHya8WTyGE=
=aaqn
- -----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAlYLRaPpSoz9EDy0RAjy+AJ0SR+KqXqu+OY8TIr+u78kciEXHTwCgxbAJ
dFnzYtRVp2xDTp0Zxn5iAgE=
=Gh8i
-----END PGP SIGNATURE-----




From davej at redhat.com  Mon May  3 00:08:20 2004
From: davej at redhat.com (Dave Jones)
Date: Mon, 03 May 2004 01:08:20 +0100
Subject: sg (scsi generic) module missing
In-Reply-To: <20040502222659.GC5327@devserv.devel.redhat.com>
References: <20040412204032.GE1556856@hiwaay.net>
	<20040412204955.GB723@devserv.devel.redhat.com>
	<20040502213243.GM28387@serve.riede.org>
	<20040502222659.GC5327@devserv.devel.redhat.com>
Message-ID: <1083542900.6469.1.camel@delerium.codemonkey.org.uk>

On Sun, 2004-05-02 at 23:26, Alan Cox wrote:
> On Sun, May 02, 2004 at 05:32:43PM -0400, Willem Riede wrote:
> > FC2T3 is still missing the ide-scsi module! And filing a bug doesn't work :-(
> > I've had one in bugzilla since February 28, and no reaction whatsoever from
> > the Red Hat kernel packagers...
> > 
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117095
> > 
> > Why not compile ide-scsi? Why inconvenience owners of tape drives that need it?
> 
> And IDE multi-changers
> 
> > Put it in unsupported for all I care, but compile it, _please_.
> 
> Unfortunately Arjan and Dave are out of range of my torture kit so all I
> can do is bitch at them as well (and if need be release rival kernel rpms
> which would be a pita to have to do)

Odd. I thought we had come to a compromise on this which went along
the lines of..

	if device is an IDE CD drive
		print "use /dev/hd? directly"
		abort
	else
		passthrough to usual ide-scsi foo.

Arjan ?

	Dave





From notting at redhat.com  Mon May  3 00:47:54 2004
From: notting at redhat.com (Bill Nottingham)
Date: Sun, 2 May 2004 20:47:54 -0400
Subject: fedora core 3 goals.
In-Reply-To: <40950BD4.2090007@uol.com.br>
References: <1083477944.3244.8.camel@binkley>
	<4094D683.2070302@feuerpokemon.de> <40950BD4.2090007@uol.com.br>
Message-ID: <20040503004754.GB24383@nostromo.devel.redhat.com>

Casimiro de Almeida Barreto (casimiro_barreto at uol.com.br) said: 
> b) Standard policies must allow common users at least to login for the 
> first time without having to understand how selinux works.

This should work now no matter what... anything else is a bug. :)

Bill




From alan at redhat.com  Mon May  3 00:49:41 2004
From: alan at redhat.com (Alan Cox)
Date: Sun, 2 May 2004 20:49:41 -0400
Subject: sg (scsi generic) module missing
In-Reply-To: <1083542900.6469.1.camel@delerium.codemonkey.org.uk>
References: <20040412204032.GE1556856@hiwaay.net>
	<20040412204955.GB723@devserv.devel.redhat.com>
	<20040502213243.GM28387@serve.riede.org>
	<20040502222659.GC5327@devserv.devel.redhat.com>
	<1083542900.6469.1.camel@delerium.codemonkey.org.uk>
Message-ID: <20040503004941.GA23618@devserv.devel.redhat.com>

On Mon, May 03, 2004 at 01:08:20AM +0100, Dave Jones wrote:
> Odd. I thought we had come to a compromise on this which went along
> the lines of..
> 
> 	if device is an IDE CD drive
> 		print "use /dev/hd? directly"
> 		abort
> 	else
> 		passthrough to usual ide-scsi foo.

Multichangers are special, although even the nakamichi 5x IDE is pretty
rare and its users know about ide-scsi hand setup 8)




From aoliva at redhat.com  Mon May  3 02:05:30 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 02 May 2004 23:05:30 -0300
Subject: fedora core 3 goals.
In-Reply-To: <20040503004754.GB24383@nostromo.devel.redhat.com>
References: <1083477944.3244.8.camel@binkley>
	<4094D683.2070302@feuerpokemon.de> <40950BD4.2090007@uol.com.br>
	<20040503004754.GB24383@nostromo.devel.redhat.com>
Message-ID: <orzn8qs1sl.fsf@livre.redhat.lsd.ic.unicamp.br>

On May  2, 2004, Bill Nottingham <notting at redhat.com> wrote:

> Casimiro de Almeida Barreto (casimiro_barreto at uol.com.br) said: 
>> b) Standard policies must allow common users at least to login for the 
>> first time without having to understand how selinux works.

> This should work now no matter what... anything else is a bug. :)

You mean with SELinux disabled, or with enforcing enabled?  Last I
tried, I still couldn't ssh into a box as myself using publickey auth
because ssh wouldn't follow /home -> /l/home due to some SELinux
access error, even though everything under /l/home was labeled
properly.  I filed this problem in bugzilla.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From wrrhdev at riede.org  Mon May  3 02:15:18 2004
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 2 May 2004 22:15:18 -0400
Subject: sg (scsi generic) module missing
In-Reply-To: <1083542900.6469.1.camel@delerium.codemonkey.org.uk> (from
	davej@redhat.com on Sun, May 02, 2004 at 20:08:20 -0400)
References: <20040412204032.GE1556856@hiwaay.net>
	<20040412204955.GB723@devserv.devel.redhat.com>
	<20040502213243.GM28387@serve.riede.org>
	<20040502222659.GC5327@devserv.devel.redhat.com>
	<1083542900.6469.1.camel@delerium.codemonkey.org.uk>
Message-ID: <20040503021518.GQ28387@serve.riede.org>

On 2004.05.02 20:08, Dave Jones wrote:
> On Sun, 2004-05-02 at 23:26, Alan Cox wrote:
> > On Sun, May 02, 2004 at 05:32:43PM -0400, Willem Riede wrote:
> > > FC2T3 is still missing the ide-scsi module! And filing a bug doesn't work :-(
> > > I've had one in bugzilla since February 28, and no reaction whatsoever from
> > > the Red Hat kernel packagers...
> > > 
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117095
> > > 
> > > Why not compile ide-scsi? Why inconvenience owners of tape drives that need it?
> > 
> > And IDE multi-changers
> > 
> > > Put it in unsupported for all I care, but compile it, _please_.
> > 
> > Unfortunately Arjan and Dave are out of range of my torture kit so all I
> > can do is bitch at them as well (and if need be release rival kernel rpms
> > which would be a pita to have to do)
> 
> Odd. I thought we had come to a compromise on this which went along
> the lines of..
> 
> 	if device is an IDE CD drive
> 		print "use /dev/hd? directly"
> 		abort
> 	else
> 		passthrough to usual ide-scsi foo.

That is consistent with what I proposed both on linux-kernel/scsi and in my 
bugzilla entry. But as ide-scsi is not compiled, that logic is moot...

[root at fallguy root]# grep BLK_DEV_IDESCSI /usr/src/l*/configs/*
/usr/src/linux-2.6.5-1.327/configs/kernel-2.6.5-i586.config:# CONFIG_BLK_DEV_IDESCSI is not set
/usr/src/linux-2.6.5-1.327/configs/kernel-2.6.5-i586-smp.config:# CONFIG_BLK_DEV_IDESCSI is not set
/usr/src/linux-2.6.5-1.327/configs/kernel-2.6.5-i686.config:# CONFIG_BLK_DEV_IDESCSI is not set
/usr/src/linux-2.6.5-1.327/configs/kernel-2.6.5-i686-smp.config:# CONFIG_BLK_DEV_IDESCSI is not set

Regards, Willem Riede.




From arjanv at redhat.com  Mon May  3 07:50:21 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Mon, 03 May 2004 09:50:21 +0200
Subject: sg (scsi generic) module missing
In-Reply-To: <409582D2.4070000@uol.com.br>
References: <20040412204032.GE1556856@hiwaay.net>
	<20040412204955.GB723@devserv.devel.redhat.com>
	<20040502213243.GM28387@serve.riede.org>
	<20040502222659.GC5327@devserv.devel.redhat.com>
	<409582D2.4070000@uol.com.br>
Message-ID: <1083570621.3843.1.camel@laptop.fenrus.com>

On Mon, 2004-05-03 at 01:22, Casimiro de Almeida Barreto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> About what's being discussed, I just ponder that failing to work
> correctly with common devices (usb-storage, etc) is a fair good way of
> killing a distribution.

the usb-storage bug is fixed in kernel 349 (see
http://people.redhat.com). Actually it's worked around. cdrecord has a
bug where it doesn't check a return value and interprets an error value
as 255 sectors-io-size. Which is/was invalid for usb storage. SG just
silently ignores the fact that that is an invalid value for usb storage
and continues, at the risk of breaking the burn. As I said fixed in 349
by making usb-storage also grok 255 sector sized IO's.

-------------- 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/20040503/635e9539/attachment.sig>

From robert at it4texas.com  Mon May  3 11:03:10 2004
From: robert at it4texas.com (Robert Trembath)
Date: Mon, 03 May 2004 06:03:10 -0500
Subject: Problems with Core 2 test 3 install
Message-ID: <409626EE.6070008@it4texas.com>

Just installed Fedora Core 2 test 3 and have had a couple of issues, 
some I was able to resolve others not. The hardware used to test is a 
Dell Lattitude c840 laptop:

Intel P4 2.0ghz
512MB RAM
32MB Nvidia Geforce 4 video
20GB HD
3com 10/100 NIC & built-in Wireless 802.11b Minicard
1600x1200 resolution screen

Here are the immediate problems and what fixed some of them:

   1. X11 did not configure properly and only gave me a choice of
      800x600 and 640x480. Opon examination of the config file I foumd
      the settings to be correct for everything but the resolution and
      the vert and horiz rates were commentout in the monitor section.
      Adding the additional resolutions and uncommenting the rates
      enables X11 to function properly again.
   2. When booting I am always to kicked into the detail mode by the
      IA32 microcode update. Unresolved.
   3. PCMCIA does not detect my sockets or cards, thus no wireless.
      Unresolved.

All the above work perfectly in Core 1 but not in 2. Any help on 
resolving my PCMCIA problem would be great. Great job by the way , it 
looks to be really coming around for Core 2.

-- 
____________________________________
Robert Trembath
VP - Business & Technical Development

IT4Texas, LLC.
Houston, TX, USA
e| robert at it4texas.com
p| 832.722.7142





From buildsys at redhat.com  Mon May  3 11:06:30 2004
From: buildsys at redhat.com (Build System)
Date: Mon, 3 May 2004 07:06:30 -0400
Subject: rawhide report: 20040503 changes
Message-ID: <200405031106.i43B6UE13153@porkchop.devel.redhat.com>

 

 
Updated Packages:

rpmdb-fedora-1.92-0.20040503
----------------------------




From aoliva at redhat.com  Mon May  3 11:34:52 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 03 May 2004 08:34:52 -0300
Subject: Problems with Core 2 test 3 install
In-Reply-To: <409626EE.6070008@it4texas.com>
References: <409626EE.6070008@it4texas.com>
Message-ID: <ory8o9eobn.fsf@free.redhat.lsd.ic.unicamp.br>

On May  3, 2004, Robert Trembath <robert at it4texas.com> wrote:

>    3. PCMCIA does not detect my sockets or cards, thus no wireless.
>       Unresolved.

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

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From mr700 at globalnet.bg  Mon May  3 12:29:38 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Mon, 3 May 2004 15:29:38 +0300
Subject: sg (scsi generic) module missing
In-Reply-To: <20040502213243.GM28387@serve.riede.org>
References: <20040412204032.GE1556856@hiwaay.net>
	<20040412204955.GB723@devserv.devel.redhat.com>
	<20040502213243.GM28387@serve.riede.org>
Message-ID: <200405031529.38061@-mr700>

On Monday 03 May 2004 00:32, Willem Riede wrote:
...
> 
> Why not compile ide-scsi? Why inconvenience owners of tape drives that need it?
> Put it in unsupported for all I care, but compile it, _please_.
> 
    I have problems burning CDs, count one more please from me.

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79




From arjanv at redhat.com  Mon May  3 12:45:35 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Mon, 03 May 2004 14:45:35 +0200
Subject: sg (scsi generic) module missing
In-Reply-To: <200405031529.38061@-mr700>
References: <20040412204032.GE1556856@hiwaay.net>
	<20040412204955.GB723@devserv.devel.redhat.com>
	<20040502213243.GM28387@serve.riede.org>  <200405031529.38061@-mr700>
Message-ID: <1083588334.3843.3.camel@laptop.fenrus.com>

On Mon, 2004-05-03 at 14:29, Doncho N. Gunchev wrote:
> On Monday 03 May 2004 00:32, Willem Riede wrote:
> ...
> > 
> > Why not compile ide-scsi? Why inconvenience owners of tape drives that need it?
> > Put it in unsupported for all I care, but compile it, _please_.
> > 
>     I have problems burning CDs, count one more please from me.

I'm sorry but without details about what is broken that is really not
helpful. 
-------------- 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/20040503/46a1e04c/attachment.sig>

From richardl at redhat.com  Mon May  3 13:01:03 2004
From: richardl at redhat.com (Richard Li)
Date: Mon, 03 May 2004 09:01:03 -0400
Subject: fedora core 3 goals.
In-Reply-To: <1083477944.3244.8.camel@binkley>
References: <1083477944.3244.8.camel@binkley>
Message-ID: <4096428F.4050603@redhat.com>

Here's my take on the situation. Please note that I'm not a decision 
maker of any sort with Fedora and that nothing I say should be taken as 
official...

seth vidal wrote:

>Hi,
> I was wondering what the distribution, community and infrastructure
>goals are for fedora core 3. 
> 
>Will CVS be opened up?
>  
>
We want to open up CVS as soon as possible. Turns out that setting up a 
build system for FC that is open to outside contributors is non-trivial. 
For example, we need a system for preventing security-embargoed patches 
from appearing in the public tree until the embargo is lifted.

Anyway, Gafton, who is a hard-core 3l33t hax0r d00d, has been working 
hard on this problem with others.

>Will selinux be on the hit-list again?
>  
>
I believe whether or not SELinux will be enabled by default is a 
decision we will not be making until we have a better sense of its 
stability in FC3. (So if you want it on, madly test FC2 with SELinux! :-).

>Will there be any time dedicated to just infrastructure/community
>development and a general hold is put on the distro devel?
>  
>
We have a dedicated team in place, but their first priority (I believe) 
is the opening up of CVS.

>Maybe right after the release of fc2 would be a good time for a 'state
>of the fedora' message from the project leader?
>Maybe sooner?
>  
>
Agreed.

Richard




From skvidal at phy.duke.edu  Mon May  3 14:11:49 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 03 May 2004 10:11:49 -0400
Subject: fedora core 3 goals.
In-Reply-To: <4096428F.4050603@redhat.com>
References: <1083477944.3244.8.camel@binkley>  <4096428F.4050603@redhat.com>
Message-ID: <1083593509.22400.2.camel@binkley>

> >Will CVS be opened up?
> >  
> >
> We want to open up CVS as soon as possible. Turns out that setting up a 
> build system for FC that is open to outside contributors is non-trivial. 
> For example, we need a system for preventing security-embargoed patches 
> from appearing in the public tree until the embargo is lifted.
> 
> Anyway, Gafton, who is a hard-core 3l33t hax0r d00d, has been working 
> hard on this problem with others.

It's interesting, but everyone I've talked to tells me what gafton is
thinking. However, gafton never speaks himself. It's also somewhat
telling that the only people who know what the details are of things
happen to work for red hat. 


> We have a dedicated team in place, but their first priority (I believe) 
> is the opening up of CVS.

who is on this dedicated team? What's their agenda look like? Where is
it discussed?


> >Maybe right after the release of fc2 would be a good time for a 'state
> >of the fedora' message from the project leader?
> >Maybe sooner?
> >  
> >
> Agreed.

-sv





From jspaleta at gmail.com  Mon May  3 14:17:36 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 3 May 2004 10:17:36 -0400
Subject: fedora core 3 goals.
In-Reply-To: <1083593509.22400.2.camel@binkley>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
Message-ID: <2B70B12F.43734BB0@mail.gmail.com>

On Mon, 03 May 2004 10:11:49 -0400, seth vidal <skvidal at phy.duke.edu> wrote:
> 
> who is on this dedicated team? What's their agenda look like? Where is
> it discussed?


Dedicated team?  I doubt if such a team exists it will be a dedicated one.
More like who are the team of people who have 3 too many irons in the
fire, who clearly don't have enough time for yet another "important"
task


-jef"monday morning=super jaded"spaleta




From alan at redhat.com  Mon May  3 14:29:30 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 3 May 2004 10:29:30 -0400
Subject: fedora core 3 goals.
In-Reply-To: <1083593509.22400.2.camel@binkley>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
Message-ID: <20040503142930.GA1556@devserv.devel.redhat.com>

On Mon, May 03, 2004 at 10:11:49AM -0400, seth vidal wrote:
> It's interesting, but everyone I've talked to tells me what gafton is
> thinking. However, gafton never speaks himself. It's also somewhat
> telling that the only people who know what the details are of things
> happen to work for red hat. 

Cristian isn't the worlds most talkative person. He is however one of the
Red Hat fellows and is working very hard on all sorts of logistical crap
that is needed for external CVS: power, bandwidth, rack assignments, 
delivery dates. etc.

Most of these kind of details involve things like Red Hat internal
infrastructure details, arrangements with partners and the like which are
not terribly open-sourceable.

Alan




From skvidal at phy.duke.edu  Mon May  3 14:33:09 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 03 May 2004 10:33:09 -0400
Subject: fedora core 3 goals.
In-Reply-To: <20040503142930.GA1556@devserv.devel.redhat.com>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
Message-ID: <1083594789.22400.6.camel@binkley>

> Cristian isn't the worlds most talkative person. He is however one of the
> Red Hat fellows and is working very hard on all sorts of logistical crap
> that is needed for external CVS: power, bandwidth, rack assignments, 
> delivery dates. etc.

so we should not expect the project leader to talk to the people he is
supposed to be leading ABOUT the thing their being lead for?

> Most of these kind of details involve things like Red Hat internal
> infrastructure details, arrangements with partners and the like which are
> not terribly open-sourceable.

So the gist of this is:
"Take what you get and shut up, we can't tell you anyway."

I'm enjoying this whole more open red hat linux distribution more and
more everyday.

-sv





From richardl at redhat.com  Mon May  3 14:46:59 2004
From: richardl at redhat.com (Richard Li)
Date: Mon, 03 May 2004 10:46:59 -0400
Subject: fedora core 3 goals.
In-Reply-To: <1083594789.22400.6.camel@binkley>
References: <1083477944.3244.8.camel@binkley>
	<4096428F.4050603@redhat.com>	<1083593509.22400.2.camel@binkley>	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley>
Message-ID: <40965B63.1010601@redhat.com>

seth vidal wrote:

>So the gist of this is:
>"Take what you get and shut up, we can't tell you anyway."
>  
>
I haven't read anything from anyone that says to "shut up". In fact, 
I've read quite the opposite. cf 
https://listman.redhat.com/archives/fedora-devel-list/2004-April/msg00756.html 
("Actually, keep it and tell me what we can do to fix it."), for example.

Richard




From dhollis at davehollis.com  Mon May  3 14:54:13 2004
From: dhollis at davehollis.com (David T Hollis)
Date: Mon, 03 May 2004 10:54:13 -0400
Subject: Module ohci1394 not found
In-Reply-To: <orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <1083185485.2241.3.camel@localhost.localdomain>
	<1083186496.5085.85.camel@roadrash.rdu.redhat.com>
	<orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <1083596053.4603.4.camel@dhollis-lnx.kpmg.com>

On Sat, 2004-05-01 at 23:56 -0300, Alexandre Oliva wrote:
> On Apr 28, 2004, Chris Kloiber <ckloiber at ckloiber.com> wrote:
> 
> > FireWire is currently busted in the latest kernel trees. IIRC it
> > compiles but explodes wonderfully on insertion, taking the whole system
> > and half the of the South East USA seacoast with it into oblivion. It
> > will likely be turned on again when it works.
> 
> Which probably means it won't make it to FC2 final.  I plan on
> offering some work-arounds for Firewire users, sort of like I did for
> FC1.  My plan is to take the Firewire code that shipped with kernel
> 2.6.3, since that has worked quite reliably for me.
> 

For what it's worth, I was able to build and load the firewire modules
against 2.6.5-1.347.  I used the latest ieee1394 branch from subversion
using the attached Makefile.  I have not actually tested connecting any
firewire devices but my experience with other recent kernels was that
loading ohci1394 spewed out a bunch of stack dumps.

-- 
David T Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: text/x-makefile
Size: 1298 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040503/dfef22bb/attachment.bin>

From skvidal at phy.duke.edu  Mon May  3 14:55:21 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 03 May 2004 10:55:21 -0400
Subject: fedora core 3 goals.
In-Reply-To: <40965B63.1010601@redhat.com>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley>  <40965B63.1010601@redhat.com>
Message-ID: <1083596121.22400.12.camel@binkley>

> I haven't read anything from anyone that says to "shut up". In fact, 
> I've read quite the opposite. cf 
> https://listman.redhat.com/archives/fedora-devel-list/2004-April/msg00756.html 
> ("Actually, keep it and tell me what we can do to fix it."), for example.

Except that suggestions were given, ideas were presented and we've heard
NOTHING from either gafton or hogan since the WorldWide meeting.

what now?
-sv





From jkeating at j2solutions.net  Mon May  3 15:00:09 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 3 May 2004 08:00:09 -0700
Subject: fedora core 3 goals.
In-Reply-To: <40965B63.1010601@redhat.com>
References: <1083477944.3244.8.camel@binkley>
	<1083594789.22400.6.camel@binkley> <40965B63.1010601@redhat.com>
Message-ID: <200405030800.13949.jkeating@j2solutions.net>

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

On Monday 03 May 2004 07:46, Richard Li wrote:
> I haven't read anything from anyone that says to "shut up". In fact,
> I've read quite the opposite. cf
> https://listman.redhat.com/archives/fedora-devel-list/2004-April/msg0
>0756.html ("Actually, keep it and tell me what we can do to fix it."),
> for example.

But the point is that we're spinning our wheels out here w/ no idea of 
which direction to go.  We need direction, goals, ideas, thoughts, 
something.  We all hear that "everybody is terribly busy".  Busy doing 
what?  We never hear specifics, only vague ideas of what people are 
busy doing.  If this is supposed to be an open process, we should know 
what they are busy doing, not just waiting for product to be pushed for 
that week of non-busy where everything can be talked about that needs 
to be done, but nothing will be done before the next "busy blank-wall" 
session starts in.

- -- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key          
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAll594v2HLvE71NURAqXmAKDC4vaTBSuagtu2aKxK5BDb2NgcqACgki0V
mkNSXiQHZKUilcBkp9B1RuA=
=MSiV
-----END PGP SIGNATURE-----




From jhogan at redhat.com  Mon May  3 15:18:28 2004
From: jhogan at redhat.com (Jeremy Hogan)
Date: Mon, 03 May 2004 11:18:28 -0400
Subject: fedora core 3 goals.
In-Reply-To: <1083593509.22400.2.camel@binkley>
References: <1083477944.3244.8.camel@binkley>  <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
Message-ID: <1083597508.3243.39.camel@dhcp55-224.rdu.redhat.com>

> Except that suggestions were given, ideas were presented and 
> we'veheard NOTHING from either gafton or hogan since the WorldWide meeting. 

Cristian is en route (now or very soon) to co-lo to build the needed
systems for CVS.

The feedback I took to the meeting was all known issues, and the net
result was an explanation of the hold-ups:

-hw and bandwidth became a moving target due to co-lo and related
migrations to and from RH offices
-the build system is full of NDA stuff, embargoed security errata, etc.
and is not easily replicated or easily open to outside use

And discussion of some options:

-we could go ahead right now, with select contributors and not be able
to scale much further, or fix all the problems at once
-we discussed ways to encourage more RH interaction on public lists
(signal to noise ratio high at times)
-we need to deal with NDA and embargoed issues
-we will be posting what we feel are the features and goals of FC3 and
inviting feedback (this week)
-we should be talking about external leadership 

As mentioned, FC2 release is a good time to resolve this.

--jeremy




From dragoran at feuerpokemon.de  Mon May  3 15:31:14 2004
From: dragoran at feuerpokemon.de (dragoran)
Date: Mon, 03 May 2004 17:31:14 +0200
Subject: fedora core 3 goals.
In-Reply-To: <1083594789.22400.6.camel@binkley>
References: <1083477944.3244.8.camel@binkley>
	<4096428F.4050603@redhat.com>	<1083593509.22400.2.camel@binkley>	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley>
Message-ID: <409665C2.6020405@feuerpokemon.de>

seth vidal schrieb:

>>Cristian isn't the worlds most talkative person. He is however one of the
>>Red Hat fellows and is working very hard on all sorts of logistical crap
>>that is needed for external CVS: power, bandwidth, rack assignments, 
>>delivery dates. etc.
>>    
>>
>
>so we should not expect the project leader to talk to the people he is
>supposed to be leading ABOUT the thing their being lead for?
>
>  
>
>>Most of these kind of details involve things like Red Hat internal
>>infrastructure details, arrangements with partners and the like which are
>>not terribly open-sourceable.
>>    
>>
>
>So the gist of this is:
>"Take what you get and shut up, we can't tell you anyway."
>
>I'm enjoying this whole more open red hat linux distribution more and
>more everyday.
>
>-sv
>
>
>
>  
>
is there any project leader?
if yes who?




From smoogen at lanl.gov  Mon May  3 15:32:22 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Mon, 03 May 2004 09:32:22 -0600
Subject: fedora core 3 goals.
In-Reply-To: <1083594789.22400.6.camel@binkley>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley>
Message-ID: <1083598340.10985.57.camel@smoogen3.lanl.gov>

On Mon, 2004-05-03 at 08:33, seth vidal wrote:
> > Cristian isn't the worlds most talkative person. He is however one of the
> > Red Hat fellows and is working very hard on all sorts of logistical crap
> > that is needed for external CVS: power, bandwidth, rack assignments, 
> > delivery dates. etc.
> 
> so we should not expect the project leader to talk to the people he is
> supposed to be leading ABOUT the thing their being lead for?
> 
> > Most of these kind of details involve things like Red Hat internal
> > infrastructure details, arrangements with partners and the like which are
> > not terribly open-sourceable.
> 
> So the gist of this is:
> "Take what you get and shut up, we can't tell you anyway."
> 
> I'm enjoying this whole more open red hat linux distribution more and
> more everyday.
> 

Ok for your benefit I will give you the logs of a day at Red Hat. Just
change the dates, and some of the names, and it should fill in for
Fedora.

Day XXX:
 Got into work. Read emails about how much everyone thinks Red Hat
sucks.. some on lists, most personal. Wrote up a reply.. decided that
getting the company sued for references to potential imbreeding was not
a good idea.
 Called vendor about rackspace. The space is available but the bandwidth
available is not what asked for. Called second vendor because this is
the third time some switch-a-roo has happened.
 Got call from Murch to see him. Find out that racks from vendor were
shipped, dropped, shipped, and dropped. They say it was given to them
that way and we need to call vendor.
 Had meeting with developers on where software was at. Lots of bugs that
have shown up again in new ways.
 Had meeting with marketing on where we were at. Sub-products are
delayed.
 Eat krispy kreme doughnuts for lunch.
 Had phone call with second vendor on colocation. Marketing says it
would be a win-win.. where have I heard that one before <see last week
and the week before logs>.
 Global support has a bug in software package XXX. Last worked on it in
2002 but the new maintainer is out sick.. 
 Opened a new can of instant coffee to munch on.
 Rack vendor says that they shipped the rack in a good shape and that
the shipping company is to blame (and we didnt use parcelfarce)<<see log
from 2 months ago>>.
 Phone call with Pacific collegues about bug in software package Y.
Turns out we need to talk to the maintainer in the Philipines. Call wife
to tell her I will be late (again).
 Meeting with legal and hr about email sent out last week about
'usefulness of sales-twits.' Comparing them to dung beetles was uncalled
for and offensive. Go back to computer to write apology.
 Write up apology and see that a ton more emails about how stupid RH is
and we should just use Debian. Delete mailbox to save time.
 Eat krispy kremes and week old chinese for dinner.
 Philipines calls and says they sent the patch earlier in the day and
did I get it. Go look in mailbox. Hit head on table, repeat.
 Look over options for the evening:
   Listen to developers whinge about life
     (and the debate of arch, cvs, svs or bitkeeper)
   Read mails about whinging about life.
   Fix CVS
   Quit in disgust
Code for 3 hours on CVS. See I missed an email from legal about issues
on copyrights, trademarks, sec regulations, huh what.. damn 2 am. Go
home.

[switch dealing with code to dealing with Perl webpages/ftp servers and
this happened more times than i would like to remember.]

> -sv
-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From skvidal at phy.duke.edu  Mon May  3 15:32:45 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 03 May 2004 11:32:45 -0400
Subject: fedora core 3 goals.
In-Reply-To: <409665C2.6020405@feuerpokemon.de>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley> <409665C2.6020405@feuerpokemon.de>
Message-ID: <1083598365.22400.24.camel@binkley>

> >
> >  
> >
> is there any project leader?
> if yes who?
> 

Cristian Gafton.

-sv





From sopwith at redhat.com  Mon May  3 15:42:43 2004
From: sopwith at redhat.com (Elliot Lee)
Date: Mon, 3 May 2004 11:42:43 -0400 (EDT)
Subject: FC2 final freeze warning!
Message-ID: <Pine.LNX.4.58.0405031132490.31004@devserv.devel.redhat.com>

The final freeze starts on May 7. You should plan to have all your
packages built by May 6 close-of-business. We're already in freeze-ish
mode - the difference will be that only critical bug fixes go in after the
hard freeze.

It's the home stretch - almost done!
-- Elliot
I keep committing atrocities in an attempt to learn from my mistakes.




From smoogen at lanl.gov  Mon May  3 15:50:02 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Mon, 03 May 2004 09:50:02 -0600
Subject: fedora core 3 goals.
In-Reply-To: <1083597508.3243.39.camel@dhcp55-224.rdu.redhat.com>
References: <1083477944.3244.8.camel@binkley>  <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<1083597508.3243.39.camel@dhcp55-224.rdu.redhat.com>
Message-ID: <1083599400.10985.66.camel@smoogen3.lanl.gov>

On Mon, 2004-05-03 at 09:18, Jeremy Hogan wrote:
> > Except that suggestions were given, ideas were presented and 
> > we'veheard NOTHING from either gafton or hogan since the WorldWide meeting. 
> 
> Cristian is en route (now or very soon) to co-lo to build the needed
> systems for CVS.
> 
> The feedback I took to the meeting was all known issues, and the net
> result was an explanation of the hold-ups:
> 
> -hw and bandwidth became a moving target due to co-lo and related
> migrations to and from RH offices
> -the build system is full of NDA stuff, embargoed security errata, etc.
> and is not easily replicated or easily open to outside use
> 
> And discussion of some options:
> 
> -we could go ahead right now, with select contributors and not be able
> to scale much further, or fix all the problems at once

Go for the small number of contributors right now and then have people
work on the fix all problems at once. This waiting for the cathederal to
be built has shortened peoples tempers the most

> -we discussed ways to encourage more RH interaction on public lists
> (signal to noise ratio high at times)

Get 2-3 dedicated email monkeys. Hire from local student bodies on
work-study. Hell, hire me back and I will ... [sorry lost my head there
for a second.]

> -we need to deal with NDA and embargoed issues

Take sopwiths build system 2 code from some old backup and use that. It
is probably not scalable, etc, but might be a good first pass. [In my
day we used to ship crap.. and we liked it. Now everyone wants to have
high standards.]

> -we will be posting what we feel are the features and goals of FC3 and
> inviting feedback (this week)

I think what a lot of people are feeling that they are missing is a
conversation. Gafton isnt a email/irc guy but got things done and people
doing things when they were in a 400 meter range of his language. Get
someone who can talk to people via email/irc to front for him.

> -we should be talking about external leadership 

There was a list of things that Bill Nottingham and Elliot asked for
earlier this year that would be helpful for the project. Could someone
post which ones are still needed?

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From jkeating at j2solutions.net  Mon May  3 15:59:07 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 3 May 2004 08:59:07 -0700
Subject: fedora core 3 goals.
In-Reply-To: <409665C2.6020405@feuerpokemon.de>
References: <1083477944.3244.8.camel@binkley>
	<1083594789.22400.6.camel@binkley>
	<409665C2.6020405@feuerpokemon.de>
Message-ID: <200405030859.10457.jkeating@j2solutions.net>

On Monday 03 May 2004 08:31, dragoran wrote:
> is there any project leader?
> if yes who?

The fact that this had to be asked and wasn't readily visible is a good 
sign that something is broken.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040503/bb330665/attachment.sig>

From jkeating at j2solutions.net  Mon May  3 16:06:31 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 3 May 2004 09:06:31 -0700
Subject: fedora core 3 goals.
In-Reply-To: <1083597508.3243.39.camel@dhcp55-224.rdu.redhat.com>
References: <1083477944.3244.8.camel@binkley>
	<1083593509.22400.2.camel@binkley>
	<1083597508.3243.39.camel@dhcp55-224.rdu.redhat.com>
Message-ID: <200405030906.31982.jkeating@j2solutions.net>

On Monday 03 May 2004 08:18, Jeremy Hogan wrote:
> And discussion of some options:
>
> -we could go ahead right now, with select contributors and not be
> able to scale much further, or fix all the problems at once
> -we discussed ways to encourage more RH interaction on public lists
> (signal to noise ratio high at times)
> -we need to deal with NDA and embargoed issues
> -we will be posting what we feel are the features and goals of FC3
> and inviting feedback (this week)
> -we should be talking about external leadership
>
> As mentioned, FC2 release is a good time to resolve this.

Were any solutions discussed for these, or was it another meeting where 
problems were identified but no progress was made?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040503/f3acd47a/attachment.sig>

From jkt at redhat.com  Mon May  3 17:57:27 2004
From: jkt at redhat.com (Jay Turner)
Date: Mon, 3 May 2004 13:57:27 -0400
Subject: fedora core 3 goals.
In-Reply-To: <1083596121.22400.12.camel@binkley>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley> <40965B63.1010601@redhat.com>
	<1083596121.22400.12.camel@binkley>
Message-ID: <20040503175727.GR25028@redhat.com>

On Mon, May 03, 2004 at 10:55:21AM -0400, seth vidal wrote:
> > I haven't read anything from anyone that says to "shut up". In fact, 
> > I've read quite the opposite. cf 
> > https://listman.redhat.com/archives/fedora-devel-list/2004-April/msg00756.html 
> > ("Actually, keep it and tell me what we can do to fix it."), for example.
> 
> Except that suggestions were given, ideas were presented and we've heard
> NOTHING from either gafton or hogan since the WorldWide meeting.
> 
> what now?

You wait a little while longer :-)  Stuff is happening.  We're sorry that
it's taking a little more time that was originally hoped for, but resources
are being devoted and the fruit of their labor will be obvious shortly.
Instead of complaining about what hasn't happened, let's start talking
about what needs to happen with the direction of the project . . . or
maybe some testing and patch submission.  The WW wide ended less than a
week ago, and while this is Red Hat, that's still not a lot of time.

- jkt

-- 
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*
Jay Turner, QA Technical Lead      jkt at redhat.com             Red Hat, Inc. 

        Reality is merely an illusion, albeit a very persistent one.
                                                   - Albert Einstein




From laroche at redhat.com  Mon May  3 19:02:02 2004
From: laroche at redhat.com (Florian La Roche)
Date: Mon, 3 May 2004 21:02:02 +0200
Subject: fedora core 3 goals.
In-Reply-To: <4094D683.2070302@feuerpokemon.de>
References: <1083477944.3244.8.camel@binkley>
	<4094D683.2070302@feuerpokemon.de>
Message-ID: <20040503190202.GA17389@dudweiler.stuttgart.redhat.com>

> I have read that selinux will be in RHEL4 so it will be also in fc3

SELinux is already part of FC2. We currently discuss more radical
changes for the policy files, but overall the basic SELinux technology
is in the kernel and all relevant user level apps.

greetings,

Florian La Roche




From fedora at wir-sind-cool.org  Mon May  3 19:10:30 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Mon, 3 May 2004 21:10:30 +0200
Subject: [Fwd: URGENT: Naming conflict in Cyrus-IMAP 2.2 vs. leafnode
 1.9]
In-Reply-To: <4095593E.6000500@redhat.com>
References: <4095593E.6000500@redhat.com>
Message-ID: <20040503211030.3e1b0ee0.fedora@wir-sind-cool.org>

Some voices:

  From: Henrique de Moraes Holschuh <hmh AT debian.org>
  Date: Mon, 3 May 2004 15:52:53 -0300

  Debian has been renaming any potential offenders (reconstruct, master,
  etc) by prefixing them with "cyr" for a VERY long time now.  I will do
  so for Cyrus 2.2 as well, for every potential offender that has not a
  "cyr" or "cyr_" prefix already...

[...]

  From: Rob Siemborski <rjs3 AT andrew.cmu.edu>
  Date: Mon, 3 May 2004 11:04:32 -0400 (EDT)

  I don't know what we can do in the next 4 days that will solve the
  problem for Fedora.  Even if we were to release a new version that
  corrected the problem in that time (unlikely), I highly doubt they'd be
  willing to adopt it just to change the name.

  For what its worth, our experience in the past has been that package
  mantainers have delt with conflicts like this on their own (in several
  cases, for example, "deliver" has been renamed to "cyrdeliver", and
  there is also a conflict with the name of the postfix "master" process
  -- not to mention "imapd" which conflicts fairly directly with the UW
  server) quite successfully.  I don't see why this is significantly any
  different (especially when it can be delt with, minimally, in the way
  that FreeBSD does).

  Changing the binary name in our release causes all of our users to have
  to fix their systems to reference the new name when they upgrade.  This
  is not something I take lightly, and would strongly prefer not to do.

  I appreciate the problems with the namespace conflict, but if we were to
  do this for all of our binaries every time a conflict was discovered, I
  suspect we would quickly go mad.  FWIW, I'm perfectly fine with Fedora
  changing the Cyrus fetchnews to cyrfetchnews in order to fix their
  namespace conflict.

  Beyond that, I'm not sure what I can do that can help before May 7 anyway.

[...]




From alan at redhat.com  Mon May  3 19:25:51 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 3 May 2004 15:25:51 -0400
Subject: fedora core 3 goals
In-Reply-To: <409665C2.6020405@feuerpokemon.de>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley>
	<409665C2.6020405@feuerpokemon.de>
Message-ID: <20040503192551.GB10919@devserv.devel.redhat.com>

On Mon, May 03, 2004 at 05:31:14PM +0200, dragoran wrote:
> is there any project leader?

Cristian volunteered a huge amount of his time and effort to get the
CVS stuff up and running and to look after Fedora for now

> if yes who?

Well thats a perfectly good Fedora 3 goals question.




From mattdm at mattdm.org  Mon May  3 19:54:01 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 3 May 2004 15:54:01 -0400
Subject: fedora core 3 goals.
In-Reply-To: <200405030800.13949.jkeating@j2solutions.net>
References: <1083477944.3244.8.camel@binkley>
	<1083594789.22400.6.camel@binkley> <40965B63.1010601@redhat.com>
	<200405030800.13949.jkeating@j2solutions.net>
Message-ID: <20040503195401.GA18470@jadzia.bu.edu>

On Mon, May 03, 2004 at 08:00:09AM -0700, Jesse Keating wrote:
> But the point is that we're spinning our wheels out here w/ no idea of 
> which direction to go.  We need direction, goals, ideas, thoughts, 
> something.  We all hear that "everybody is terribly busy".  Busy doing 
> what?  We never hear specifics, only vague ideas of what people are 

Well, busy working on the FC2 release. I agree things could be made more
open, and thinking about it now is good (or else it will never happen), but
maybe in between that release and the start of the next one is the real time
to focus on these issues.

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




From mattdm at mattdm.org  Mon May  3 19:56:18 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 3 May 2004 15:56:18 -0400
Subject: fedora core 3 goals.
In-Reply-To: <1083598340.10985.57.camel@smoogen3.lanl.gov>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley>
	<1083598340.10985.57.camel@smoogen3.lanl.gov>
Message-ID: <20040503195618.GB18470@jadzia.bu.edu>

On Mon, May 03, 2004 at 09:32:22AM -0600, Stephen Smoogen wrote:
> Ok for your benefit I will give you the logs of a day at Red Hat. Just
> change the dates, and some of the names, and it should fill in for
> Fedora.
[snip]
>  Eat krispy kreme doughnuts for lunch.
[snip]
>  Eat krispy kremes and week old chinese for dinner.
[snip]

Well, that sounds like an alright day, then.


:)


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




From notting at redhat.com  Mon May  3 20:41:39 2004
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 3 May 2004 16:41:39 -0400
Subject: FC2 final freeze warning!
In-Reply-To: <Pine.LNX.4.58.0405031132490.31004@devserv.devel.redhat.com>
References: <Pine.LNX.4.58.0405031132490.31004@devserv.devel.redhat.com>
Message-ID: <20040503204139.GA1151@nostromo.devel.redhat.com>

Elliot Lee (sopwith at redhat.com) said: 
> The final freeze starts on May 7. You should plan to have all your
> packages built by May 6 close-of-business. We're already in freeze-ish
> mode - the difference will be that only critical bug fixes go in after the
> hard freeze.
> 
> It's the home stretch - almost done!

And here's your bug status update of the day.

2004-05-03
Severity	Total	Closed		Need Testing
BLOCKER		437	294 ( 67.28 %)	56 ( 19.05 %)
TARGET		206	76 ( 36.89 %)	8 ( 10.53 %)
Overall		643	370 ( 57.54 %)	64 ( 17.00 %)

2004-04-16
Severity	Total	Closed		Need Testing
BLOCKER		413	250 ( 60.53 %)	52 ( 20.80 %)
TARGET		202	66 ( 32.67 %)	10 ( 15.15 %)
Overall		615	316 ( 51.38 %)	62 ( 19.00 %)

(For the uninitiated - this is pulled from the FC2Blocker and FC2Target
dependencies. 'Needs Testing' means the bug is in 'Modified' state.)

Bill




From jmorris at redhat.com  Mon May  3 20:56:50 2004
From: jmorris at redhat.com (James Morris)
Date: Mon, 3 May 2004 16:56:50 -0400 (EDT)
Subject: fedora core 3 goals.
In-Reply-To: <1083598340.10985.57.camel@smoogen3.lanl.gov>
Message-ID: <Xine.LNX.4.44.0405031646494.4559-100000@thoron.boston.redhat.com>

On Mon, 3 May 2004, Stephen Smoogen wrote:

> Code for 3 hours on CVS. See I missed an email from legal about issues
> on copyrights, trademarks, sec regulations, huh what.. damn 2 am. Go
> home.

CVS? 2am?  Sheer luxury.  Back in my day we didn't even have computers.  
We had to do programming with pencil and paper.  (If we were lucky enough
to have those, if not, we'd have to write in the dirt with a finger,
assuming there was any dirt left after dinner of course).


- James
-- 
James Morris
<jmorris at redhat.com>





From jkeating at j2solutions.net  Mon May  3 20:55:55 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 3 May 2004 13:55:55 -0700
Subject: fedora core 3 goals.
In-Reply-To: <20040503195401.GA18470@jadzia.bu.edu>
References: <1083477944.3244.8.camel@binkley>
	<200405030800.13949.jkeating@j2solutions.net>
	<20040503195401.GA18470@jadzia.bu.edu>
Message-ID: <200405031355.56011.jkeating@j2solutions.net>

On Monday 03 May 2004 12:54, Matthew Miller wrote:
> Well, busy working on the FC2 release. I agree things could be made
> more open, and thinking about it now is good (or else it will never
> happen), but maybe in between that release and the start of the next
> one is the real time to focus on these issues.

Yeah, a lot can get done in 3 days.... (:

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040503/6a895eb9/attachment.sig>

From alan at clueserver.org  Mon May  3 21:05:23 2004
From: alan at clueserver.org (alan)
Date: Mon, 3 May 2004 14:05:23 -0700 (PDT)
Subject: fedora core 3 goals.
In-Reply-To: <Xine.LNX.4.44.0405031646494.4559-100000@thoron.boston.redhat.com>
Message-ID: <Pine.LNX.4.44.0405031402240.20943-100000@ebersisk.clueserver.org>

On Mon, 3 May 2004, James Morris wrote:

> On Mon, 3 May 2004, Stephen Smoogen wrote:
> 
> > Code for 3 hours on CVS. See I missed an email from legal about issues
> > on copyrights, trademarks, sec regulations, huh what.. damn 2 am. Go
> > home.
> 
> CVS? 2am?  Sheer luxury.  Back in my day we didn't even have computers.  
> We had to do programming with pencil and paper.  (If we were lucky enough
> to have those, if not, we'd have to write in the dirt with a finger,
> assuming there was any dirt left after dinner of course).

That was too easy! In may day we had to make our punchcards from buffalo 
hides.  (Usually while they were still on the buffalo.)  And we only had 
stone tools that we made by biting until they were sharp.

And our paper tape was made with real tapeworms!

And we were greatful!





From sdhmis at sheratondover.com  Mon May  3 21:13:13 2004
From: sdhmis at sheratondover.com (Kenneth Benson)
Date: Mon, 3 May 2004 17:13:13 -0400 
Subject: fedora core 3 goals.
Message-ID: <E464EB52A756C148A8F6CDD01B8584151C6E72@2k00893a.sheratondover.net>

Try it with pterodactyl wings. =P

-----Original Message-----
From: alan [mailto:alan at clueserver.org]
Sent: Monday, May 03, 2004 5:05 PM
To: Development discussions related to Fedora Core
Subject: Re: fedora core 3 goals.


On Mon, 3 May 2004, James Morris wrote:

> On Mon, 3 May 2004, Stephen Smoogen wrote:
> 
> > Code for 3 hours on CVS. See I missed an email from legal about issues
> > on copyrights, trademarks, sec regulations, huh what.. damn 2 am. Go
> > home.
> 
> CVS? 2am?  Sheer luxury.  Back in my day we didn't even have computers.  
> We had to do programming with pencil and paper.  (If we were lucky enough
> to have those, if not, we'd have to write in the dirt with a finger,
> assuming there was any dirt left after dinner of course).

That was too easy! In may day we had to make our punchcards from buffalo 
hides.  (Usually while they were still on the buffalo.)  And we only had 
stone tools that we made by biting until they were sharp.

And our paper tape was made with real tapeworms!

And we were greatful!



-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://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/20040503/fb9a85a6/attachment.htm>

From gafton at redhat.com  Mon May  3 22:54:15 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Mon, 3 May 2004 18:54:15 -0400 (EDT)
Subject: fedora core 3 goals.
In-Reply-To: <1083593509.22400.2.camel@binkley>
References: <1083477944.3244.8.camel@binkley>  <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
Message-ID: <Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>

On Mon, 3 May 2004, seth vidal wrote:

> It's interesting, but everyone I've talked to tells me what gafton is
> thinking. However, gafton never speaks himself. It's also somewhat
> telling that the only people who know what the details are of things
> happen to work for red hat. 

There is a very obvious reason why that is happening. Most of the things
that I am working on now are fixing issues inside Red Hat, and for that I 
do need first and foremost the help and assistance of the Red Hat folks.

> who is on this dedicated team? What's their agenda look like? Where is
> it discussed?

Currently on this team we have Warren (whom you know) and Elliot (whom you 
also know). The agenda is putting in place the tools required to engage 
eager folks such as yourself to contribute directly to the project. As our 
#1 issue is the (re)organization of the internal Red Hat development 
process, it is not surprizing that this has been treated as an internal 
issue.

I hate telling people to wait a bit more, but for now that'll have to do.
A lot of folks are working their tails off to get this thing done 
correctly and at some point in the future this will make for a very 
entertaining read. For now, this is just the way things are.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "There are two kinds of people who never amount to much: those who 
   cannot do what they are told, and those who can do nothing else."
        --Cyrus Curtis




From gafton at redhat.com  Mon May  3 22:56:53 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Mon, 3 May 2004 18:56:53 -0400 (EDT)
Subject: fedora core 3 goals.
In-Reply-To: <2B70B12F.43734BB0@mail.gmail.com>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley> <2B70B12F.43734BB0@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0405031855310.2478@alien.devel.redhat.com>

On Mon, 3 May 2004, Jeff Spaleta wrote:

> Dedicated team?  I doubt if such a team exists it will be a dedicated one.

Well, you can keep your doubts for yourself then, because such a team does 
exist and this team is working hard at getting stuff done. FULL TIME.

> More like who are the team of people who have 3 too many irons in the
> fire, who clearly don't have enough time for yet another "important"
> task

That's cute. Off-mark, but cute.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "There are two kinds of people who never amount to much: those who 
   cannot do what they are told, and those who can do nothing else."
        --Cyrus Curtis




From gafton at redhat.com  Mon May  3 22:58:42 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Mon, 3 May 2004 18:58:42 -0400 (EDT)
Subject: fedora core 3 goals.
In-Reply-To: <1083596121.22400.12.camel@binkley>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley>  <40965B63.1010601@redhat.com>
	<1083596121.22400.12.camel@binkley>
Message-ID: <Pine.LNX.4.58.0405031857410.2478@alien.devel.redhat.com>

On Mon, 3 May 2004, seth vidal wrote:

> Except that suggestions were given, ideas were presented and we've heard
> NOTHING from either gafton or hogan since the WorldWide meeting.

You do realize that the WW meeting has been over for a little over a 
weekend, don't you?

Cristian
--
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "There are two kinds of people who never amount to much: those who 
   cannot do what they are told, and those who can do nothing else."
        --Cyrus Curtis




From ottohaliburton at comcast.net  Mon May  3 23:00:10 2004
From: ottohaliburton at comcast.net (Otto Haliburton)
Date: Mon, 3 May 2004 18:00:10 -0500
Subject: Upgrade RH9 --> FC....
In-Reply-To: <Pine.LNX.4.58.0405031855310.2478@alien.devel.redhat.com>
Message-ID: <006e01c43162$634d41a0$1e090018@C515816A>

Is it possible to upgrade RH9 to FCx without having to start from scratch.
If not is this not a future project for the Fedora Core project.





From gafton at redhat.com  Mon May  3 23:04:05 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Mon, 3 May 2004 19:04:05 -0400 (EDT)
Subject: fedora core 3 goals.
In-Reply-To: <200405030906.31982.jkeating@j2solutions.net>
References: <1083477944.3244.8.camel@binkley>
	<1083593509.22400.2.camel@binkley>
	<1083597508.3243.39.camel@dhcp55-224.rdu.redhat.com>
	<200405030906.31982.jkeating@j2solutions.net>
Message-ID: <Pine.LNX.4.58.0405031903180.2478@alien.devel.redhat.com>

On Mon, 3 May 2004, Jesse Keating wrote:

> Were any solutions discussed for these, or was it another meeting where 
> problems were identified but no progress was made?

Yes, we need to finish what we started in terms of infrastructure that 
engages external folks.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "There are two kinds of people who never amount to much: those who 
   cannot do what they are told, and those who can do nothing else."
        --Cyrus Curtis




From markmc at redhat.com  Mon May  3 23:03:15 2004
From: markmc at redhat.com (Mark McLoughlin)
Date: Tue, 04 May 2004 00:03:15 +0100
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083369058.3978.56.camel@localhost.localdomain>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083360223.15207.303.camel@cgf.boston.redhat.com>
	<1083369058.3978.56.camel@localhost.localdomain>
Message-ID: <1083625394.5813.6.camel@laptop>

Hi,

On Sat, 2004-05-01 at 00:50, Per Bjornsson wrote:
> On Fri, 2004-04-30 at 14:23, Alexander Larsson wrote:
> > On Tue, 2004-04-20 at 16:36, David Wagoner wrote:
> > > I was reading the Gnome release schedule and saw that
> > > Gnome 2.6.1 is going to be released very soon with a
> > > lot of bug fixes, some new translations and a few
> > > performance improvements and was curious if it is
> > > going to make it into FC2 or if a patched version of
> > > Gnome 2.6.0 will be used.
> > 
> > It'll likely be 2.6.0 + some patches from cvs since we're frozen by now.
> 
> Since the stable Gnome release series really seem pretty regression-safe
> (well, at least that's my impression of how the Gnome project is
> managed), would it be possible to get releases in the stable series as
> updates for FC2 even if they don't make it into the original release?
> 
> If the answer is "no", is it because of perceived destabilization or
> because it takes time from new development?

	Its about potential destabilisation, yes. Every code change, no matter
how trivial it may seem, brings with it the risk of introducing
regressions or weird side effects. Therefore, at this stage in the
release cycle its good practise to weigh up the benefit each code change
brings versus the potential for introducing other bugs.

	Mass updating all of GNOME to 2.6.1 sounds like it should be safe, but
each change in that update has a risk associated with it. The fun thing
about risks is that they are cumulative so the chances are that
something somewhere would break with the update and we have no way of
anticipating how bad the breakage might be. Really, the best strategy at
this point is just to backport important fixes.

	Don't get me wrong, as many of us are the upstream maintainers we'd
love to see us update to the latest packages, but doing so would not be
exercising the appropriate risk management.

Cheers,
Mark.




From ottohaliburton at comcast.net  Mon May  3 23:05:31 2004
From: ottohaliburton at comcast.net (Otto Haliburton)
Date: Mon, 3 May 2004 18:05:31 -0500
Subject: Upgrade RH9 --> FC....
In-Reply-To: <006e01c43162$634d41a0$1e090018@C515816A>
Message-ID: <006f01c43163$22a860c0$1e090018@C515816A>



> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-
> bounces at redhat.com] On Behalf Of Otto Haliburton
> Sent: Monday, May 03, 2004 6:00 PM
> To: 'Development discussions related to Fedora Core'
> Subject: Upgrade RH9 --> FC....
> 
> Is it possible to upgrade RH9 to FCx without having to start from scratch.
> If not is this not a future project for the Fedora Core project.
> 
> 
Let's take it one step further RHx to FCx





From alan at redhat.com  Mon May  3 23:08:50 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 3 May 2004 19:08:50 -0400
Subject: Upgrade RH9 --> FC....
In-Reply-To: <006e01c43162$634d41a0$1e090018@C515816A>
References: <Pine.LNX.4.58.0405031855310.2478@alien.devel.redhat.com>
	<006e01c43162$634d41a0$1e090018@C515816A>
Message-ID: <20040503230850.GO31653@devserv.devel.redhat.com>

On Mon, May 03, 2004 at 06:00:10PM -0500, Otto Haliburton wrote:
> Is it possible to upgrade RH9 to FCx without having to start from scratch.
> If not is this not a future project for the Fedora Core project.

Just stick an FC1 CD in an RH9 box and hit "upgrade"




From mike at netlyncs.com  Mon May  3 23:10:39 2004
From: mike at netlyncs.com (Mike Chambers)
Date: Mon, 03 May 2004 18:10:39 -0500
Subject: fedora core 3 goals.
In-Reply-To: <Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
References: <1083477944.3244.8.camel@binkley>  <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
Message-ID: <1083625839.1720.10.camel@scrappy.netlyncs.com>

On Mon, 2004-05-03 at 17:54, Cristian Gafton wrote:

> Currently on this team we have Warren (whom you know) and Elliot (whom you 
> also know). The agenda is putting in place the tools required to engage 
> eager folks such as yourself to contribute directly to the project. As our 
> #1 issue is the (re)organization of the internal Red Hat development 
> process, it is not surprizing that this has been treated as an internal 
> issue.

Thanks Cristian for chiming in even if only a few words here and there. 
I think everyone needs to just chill out a bit and give this thing time
to get setup/going.  No one ever gave a date on when this should happen,
or maybe even realized how long/difficult it might be to get this thing
up and going.  I'm sure they are working hard at getting this internally
setup/reorganized on how they previously setup each release, so that
they can then get the public side setup so we all can contribute and
still not cause problems on the legal/NDA/etc. end at the same time.

I think Red Hat went out on a limb and went ahead and told everyone what
was going to happen with changing to Fedora and letting us in on how
this thing will work in general.  They didn't even have to do that and
just continue working as they were until it was all ready then made the
switch/announcement.  We are already helping even more than before, so
let's take things one step at a time.  Keep helping recommend what you
can during all this and continue to track bugs and such and wait until
we get the green light then we can see where we are in the scheme of
things.

(Now, upon saying all of that, maybe it might help if there was a list
or something that some Red Hat folks and few external folks can
talk/discuss what is going on and needs to get it going so that it's an
easy transition to the contribution side of things and such?  Such as
external folks used to submitting packages/fixes/bugs/code via cvs or
however on major projects and their experiences on what they went
through to make it easier?  Maybe a private list or something? *shrug*)

Anyway, patiently await things myself to see what happens and how it all
turns out.

(Oh yea, did I cheese eat enough yet to get my @redhat.com addy yet?
LOL)

-- 
Mike Chambers
Madisonville, KY

"It's only funny until someone gets hurt...Then it's hilarious!"




From strange at nsk.no-ip.org  Mon May  3 23:10:59 2004
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Tue, 4 May 2004 00:10:59 +0100
Subject: gaim x86-64 broken protocols
In-Reply-To: <ufa8ygafqr3.fsf@epithumia.math.uh.edu>;
	from tibbs@math.uh.edu on Sun, May 02, 2004 at 04:44:48PM -0500
References: <40956738.5070506@redhat.com>
	<ufa8ygafqr3.fsf@epithumia.math.uh.edu>
Message-ID: <20040504001059.A30404@nsk.no-ip.org>

On Sun, May 02, 2004 at 04:44:48PM -0500, Jason L Tibbitts III wrote:
> >>>>> "WT" == Warren Togami <wtogami at redhat.com> writes:
> 
> WT> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122221
> WT> gaim-0.77-3's yahoo authentication is broken on x86-64, but it
> WT> works on ppc32 and i386.  We need your help in finding the fix for
> WT> this within the next 2-3 days.
> 
> I have a dual Opteron machine running FC2T3, but no ability to work on
> this.  If someone needs a temporary account for testing, please let me
> know.

I'll get a few hours to try and debug this tomorrow and the day after, but
not an Opteron. If the bug and the offer still stand, page me, please.

Regards,
Luciano Rocha

-- 
Consciousness: that annoying time between naps.




From jkeating at j2solutions.net  Mon May  3 23:08:18 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 3 May 2004 16:08:18 -0700
Subject: fedora core 3 goals.
In-Reply-To: <Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
References: <1083477944.3244.8.camel@binkley>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
Message-ID: <200405031608.21555.jkeating@j2solutions.net>

On Monday 03 May 2004 15:54, Cristian Gafton wrote:
> Currently on this team we have Warren (whom you know) and Elliot
> (whom you also know). The agenda is putting in place the tools
> required to engage eager folks such as yourself to contribute
> directly to the project. As our #1 issue is the (re)organization of
> the internal Red Hat development process, it is not surprizing that
> this has been treated as an internal issue.
>
> I hate telling people to wait a bit more, but for now that'll have to
> do. A lot of folks are working their tails off to get this thing done
> correctly and at some point in the future this will make for a very
> entertaining read. For now, this is just the way things are.

Thank you very much for a peek at whats going on.  I among many 
appreciate it.  Please do keep up the efforts (:

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040503/6484fd30/attachment.sig>

From ottohaliburton at comcast.net  Mon May  3 23:13:49 2004
From: ottohaliburton at comcast.net (Otto Haliburton)
Date: Mon, 3 May 2004 18:13:49 -0500
Subject: Upgrade RH9 --> FC....
In-Reply-To: <20040503230850.GO31653@devserv.devel.redhat.com>
Message-ID: <007301c43164$4d1aa920$1e090018@C515816A>



> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-
> bounces at redhat.com] On Behalf Of Alan Cox
> Sent: Monday, May 03, 2004 6:09 PM
> To: Development discussions related to Fedora Core
> Subject: Re: Upgrade RH9 --> FC....
> 
> On Mon, May 03, 2004 at 06:00:10PM -0500, Otto Haliburton wrote:
> > Is it possible to upgrade RH9 to FCx without having to start from
> scratch.
> > If not is this not a future project for the Fedora Core project.
> 
> Just stick an FC1 CD in an RH9 box and hit "upgrade"
> 
> 
> --
Great, I was afraid that would not be the case and there would need to be
future development.





From skvidal at phy.duke.edu  Mon May  3 23:32:01 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 03 May 2004 19:32:01 -0400
Subject: fedora core 3 goals.
In-Reply-To: <1083598340.10985.57.camel@smoogen3.lanl.gov>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley>
	<1083598340.10985.57.camel@smoogen3.lanl.gov>
Message-ID: <1083627120.25635.10.camel@binkley>


> Ok for your benefit I will give you the logs of a day at Red Hat. Just
> change the dates, and some of the names, and it should fill in for
> Fedora.

I wanted to fill you in on my average day, too. Just to make sure we're
on a similar page.

1. get up, scroll through fedora-*-list see what's going on
2. do admin mail for work
3. go to office
4. hop on the irc cabal, ask what the status is on things, specifically
if anyone has heard what's up for cvs and for external infrastructure
5. hear nothing, go back to divining from tea leaves what's going on.
6. do the rest of my job all day and hope that I can guess the
directions and motives that red hat will take toward their open project,
fedora.

I've done this, more or less, for the better part of 2 months. We did it
before gafton came on too. It's not new.

We all work hard, we all do our jobs, some of us are trying to help with
fedora outside of our jobs, too, so please, I understand red hat
employees have stress, but they don't have the patent on it.

I, and others, are asking for communication.

-sv







From skvidal at phy.duke.edu  Mon May  3 23:34:04 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 03 May 2004 19:34:04 -0400
Subject: fedora core 3 goals.
In-Reply-To: <20040503175727.GR25028@redhat.com>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley> <40965B63.1010601@redhat.com>
	<1083596121.22400.12.camel@binkley> <20040503175727.GR25028@redhat.com>
Message-ID: <1083627243.25635.13.camel@binkley>


> You wait a little while longer :-)  Stuff is happening.  We're sorry that
> it's taking a little more time that was originally hoped for, but resources
> are being devoted and the fruit of their labor will be obvious shortly.
> Instead of complaining about what hasn't happened, let's start talking
> about what needs to happen with the direction of the project . . .

I originally just asked what was happening and what needs to happen.
That is all I've ever asked for, communication. How do you talk about
directions without having some input from the leadership as to what
directions things should take.

IT's not like I just started asking about this today. It's been going on
for months.

I'm glad there has finally been some comments from gafton today, it's a
shame this thread was required to make it happen.

-sv





From skvidal at phy.duke.edu  Mon May  3 23:41:11 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 03 May 2004 19:41:11 -0400
Subject: fedora core 3 goals.
In-Reply-To: <Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
References: <1083477944.3244.8.camel@binkley>  <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
Message-ID: <1083627671.25635.20.camel@binkley>


> There is a very obvious reason why that is happening. Most of the things
> that I am working on now are fixing issues inside Red Hat, and for that I 
> do need first and foremost the help and assistance of the Red Hat folks.
> 
So we can't even hear that it's occurring? I'm not asking for input
necessarily. I am asking for knowledge of what is happening. Just
knowing that there are problems with embargoed packages or knowing that
there are legal issues with non-employee contributions, this is valuable
information. This makes people realize what it is you're doing.

Just communicate. Look back through every message I've posted on this
subject. They're all the same point - Talk to us: where us == people
interested in helping with fedora development. If you don't want to talk
on a list, talk in a blog, if you don't want to talk in a blog, tell
Colin Charles and he can post it to the fedora weekly news. But tell us
things. If you've ever been a manager or have ever been managed you know
what a status report is.

Send them, every week, every two weeks, let the people who want to be
involved in this open source community/project know what's up, what
you're doing.


> Currently on this team we have Warren (whom you know) and Elliot (whom you 
> also know). The agenda is putting in place the tools required to engage 
> eager folks such as yourself to contribute directly to the project. As our 
> #1 issue is the (re)organization of the internal Red Hat development 
> process, it is not surprizing that this has been treated as an internal 
> issue.

Why not hear about this before today? Is there any part of this that is
protected in some way? 

> I hate telling people to wait a bit more, but for now that'll have to do.
> A lot of folks are working their tails off to get this thing done 
> correctly and at some point in the future this will make for a very 
> entertaining read. For now, this is just the way things are.

telling people to wait a bit more can get frustrating. However, not as
frustrating as people asking 'what's up' and getting silence for months
on end.

-sv





From skvidal at phy.duke.edu  Mon May  3 23:43:26 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 03 May 2004 19:43:26 -0400
Subject: fedora core 3 goals.
In-Reply-To: <1083625839.1720.10.camel@scrappy.netlyncs.com>
References: <1083477944.3244.8.camel@binkley>  <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
	<1083625839.1720.10.camel@scrappy.netlyncs.com>
Message-ID: <1083627806.25635.24.camel@binkley>


> (Now, upon saying all of that, maybe it might help if there was a list
> or something that some Red Hat folks and few external folks can
> talk/discuss what is going on and needs to get it going so that it's an
> easy transition to the contribution side of things and such?  Such as
> external folks used to submitting packages/fixes/bugs/code via cvs or
> however on major projects and their experiences on what they went
> through to make it easier?  Maybe a private list or something? *shrug*)
> 
> Anyway, patiently await things myself to see what happens and how it all
> turns out.


There are already cabals(what you just suggested) involving various
folks. The cabals are where you're hearing most of the heat coming from.
They've not gotten any answers at all for months, despite asking.

Ask Michael Johnson to comment on the cabals and what happened right
before he left. Look at the lists, this isn't the first time people have
asked these questions, this is just the loudest time.

-sv





From skvidal at phy.duke.edu  Mon May  3 23:43:59 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 03 May 2004 19:43:59 -0400
Subject: fedora core 3 goals.
In-Reply-To: <200405031608.21555.jkeating@j2solutions.net>
References: <1083477944.3244.8.camel@binkley>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
	<200405031608.21555.jkeating@j2solutions.net>
Message-ID: <1083627838.25635.25.camel@binkley>


> Thank you very much for a peek at whats going on.  I among many 
> appreciate it.  Please do keep up the efforts (:
> 

I'm glad to finally hear it too. It's a shame all this heat had to be
brought in order to hear it though.

-sv





From skvidal at phy.duke.edu  Mon May  3 23:44:41 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 03 May 2004 19:44:41 -0400
Subject: fedora core 3 goals.
In-Reply-To: <Pine.LNX.4.58.0405031857410.2478@alien.devel.redhat.com>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley>  <40965B63.1010601@redhat.com>
	<1083596121.22400.12.camel@binkley>
	<Pine.LNX.4.58.0405031857410.2478@alien.devel.redhat.com>
Message-ID: <1083627880.25635.27.camel@binkley>

On Mon, 2004-05-03 at 18:58 -0400, Cristian Gafton wrote:
> On Mon, 3 May 2004, seth vidal wrote:
> 
> > Except that suggestions were given, ideas were presented and we've heard
> > NOTHING from either gafton or hogan since the WorldWide meeting.
> 
> You do realize that the WW meeting has been over for a little over a 
> weekend, don't you?

Yep, and I also realize I've been asking what's been going on for a
little over 3 months.

-sv





From jspaleta at gmail.com  Mon May  3 23:50:49 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 3 May 2004 19:50:49 -0400
Subject: fedora core 3 goals.
In-Reply-To: <Pine.LNX.4.58.0405031855310.2478@alien.devel.redhat.com>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley> <2B70B12F.43734BB0@mail.gmail.com>
	<Pine.LNX.4.58.0405031855310.2478@alien.devel.redhat.com>
Message-ID: <2D0C44D9.3F5D174@mail.gmail.com>

On Mon, 3 May 2004 18:56:53 -0400 (EDT), Cristian Gafton
<gafton at redhat.com> wrote:
> Well, you can keep your doubts for yourself then, because such a team 
> does exist and this team is working hard at getting stuff done. FULL TIME.

My comment was meant in jest , but i thank you for the update or the
reminder depending on whether i'm suppose to publicly know this
already.

> > More like who are the team of people who have 3 too many irons in the
> > fire, who clearly don't have enough time for yet another "important"
> > task
> That's cute. Off-mark, but cute.

Thank you for telling my concern over people like Warren trying to do
way to much is misplaced and that situation has been corrected.  It's
definitely not good when key people are feeling burned out and
overwhelmed, its good to know its no longer true. From now on I'll
stop trying to rationalize that work on many things is bogged down
because there is a skilled manpower limit.


As for keeping my doubts to myself, I'll do that on one condition.
I'll do that if the fedora leadership is to prepared to state that Red
Hat's internal house is not in order enough to be ready to accept
community into the process. If Fedora leadership wants the community
to walk away from this for a month...fine...tell us that. I'd much
rather walk away if my help is not yet needed, than to keep watching
euthusiastic people walk into a process they think is open to the
community to find there are significant barriers to entry. And I'm not
naive, i know its a big chore to move from a very close knit private
process to an open one. But Fedora isn't ready to start accepting some
community invovlement and to assign roles to community leaders.. lets
just come out and say it.... we are burning a lot of bridges right now
and it might be best if Red Hat backed up a step, focused on getting
its house in order privately... and then re-engaging with community
when Red Hat is ready.  Fedora project is going to be a complicated
dance between community and Red Hat, and it doesn't help that Red
Hat's shoes seem to be untied. If we sit out the first song, while Red
Hat ties it shoes, it wont be so bad and it will be for more
comfortable than having both the community and Red Hat trying over
some loose strings all night long.

-jef




From icon at linux.duke.edu  Tue May  4 00:33:58 2004
From: icon at linux.duke.edu (Konstantin Ryabitsev)
Date: Mon, 03 May 2004 20:33:58 -0400
Subject: fedora core 3 goals.
In-Reply-To: <1083625839.1720.10.camel@scrappy.netlyncs.com>
References: <1083477944.3244.8.camel@binkley>
	<4096428F.4050603@redhat.com>	<1083593509.22400.2.camel@binkley>	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
	<1083625839.1720.10.camel@scrappy.netlyncs.com>
Message-ID: <4096E4F6.1030904@linux.duke.edu>

Mike Chambers wrote:
> I think Red Hat went out on a limb and went ahead and told everyone what
> was going to happen with changing to Fedora and letting us in on how
> this thing will work in general.

Let me, err, relay how things are looking from outside of RH in the 
format everyone will understand...

--- BEGIN IRC LOG ---
      <rh_pr> We are announcing Red Hat Project! A community-based
              distribution!
  <oss_crowd> rh_pr: Neat.
     <rh_dev> rh_pr: Uh... I'm not ready.
            * rh_pr is away: promoting rhel
  <oss_crowd> rh_dev: what do we do?
     <rh_dev> oss_crowd: I'm not sure.
   <rh_legal> rh_dev: don't do anything until I say it's ok.
  <oss_crowd> rh_dev: what can we do to help with Red Hat Project?
     <rh_dev> oss_crowd: uh... file bugs and help test things.
  <oss_crowd> rh_dev: didn't we always do that?
   <rh_sales> hey, all, if you really want a stable system, don't use
              fedora project. It will eat your brane. Buy RHEL instead.
     <rh_dev> rh_sales: stfu
          --- rh_pr removes voice from rh_sales
  <fedora_us> hey, all, check out our neat community-driven system for
              red hat development
  <oss_crowd> fedora_us: ooooh!
      <rh_pr> fedora_us: I like your name
          --- fedora_rh joined the channel
   <rh_legal> much better
      <rh_pr> We are announcing Fedora Project! A community-driven
              distribution!
  <oss_crowd> rh_pr: Neat!
            * fedora_rh waves
  <fedora_us> I'm not dead yet.
  <fedora_rh> fedora_us: don't confuse things.
  <fedora_us> fedora_rh: does this mean we're merging?
  <fedora_rh> fedora_us: maybe
   <rh_legal> fedora_rh: don't do anything until I say it's ok.
          --- fedora_us joined #limbo
  <oss_crowd> fedora_rh: so, what can we do to help?
  <fedora_rh> oss_crowd: uh... file bugs and help test things.
  <oss_crowd> sigh... didn't we always do that?
  <fedora_rh> oss_crowd: I know, let's all go in the circle and say our
              names.
            * oss_crowd goes in the circle and says their names. This
              lasts several months.
  <fedora_rh> So, there will be the following features in the next
              release of Fedora Core.
  <oss_crowd> Uh... Hold on. Who gets to decide?
   <rh_sales> We do. That stuff will be neato for RHEL-4.
  <oss_crowd> MMkay, then. When do _we_ get to suggest things?
  <fedora_rh> oss_crowd: feel free to talk among yourselves.
            * oss_crowd talks among themselves about new features.
  <fedora_rh> btw, feature X will be disabled in the release.
            * oss_crowd glares at fedora_rh
  <oss_crowd> fedora_rh: nice of you to tell us while we were sitting
              here talking.
     <rh_dev> oss_crowd: sorry, it's just not happening.
  <oss_crowd> rh_dev: when do we get to decide what's happening?
     <rh_dev> oss_crowd: Dunno, I'll ask rh_legal
   <rh_legal> rh_dev: ugh, /msg me
   <rh_sales> rh_dev: let's not do anything rash here.
            * fedora_us gets tired of sitting in #limbo
  <oss_crowd> fedora_rh: I want to see more of the "community" part of
              the whole "community-based" thing
  <oss_crowd> rh_dev: how about at least a publicly accessible CVS/SVN
              tree?
     <rh_dev> oss_crowd: Yeah, that would be cool.
  <oss_crowd> rh_dev: finally, some movement. When is that going to be
              up?
            * rh_dev is away: talking to rh_legal
            * oss_crowd tries to occupy themselves and do things like
              fedoranews and fedorapeople.
  <oss_crowd> Uh... ping?
  <fedora_uh> oss_crowd: what's up?
  <oss_crowd> fedora_rh: We're feeling kinda useless. What exactly is our
              role, again?
  <fedora_rh> oss_crowd: well, it would be really helpful if you could
              test some things and file the bugs.
  <oss_crowd> fedora_rh: ugh. We ALWAYS did that.
            * oss_crowd begins to wonder what exactly is the purpose of
              fedora_rh
  <fedora_rh> oss_crowd: it's the open-development, proving-grounds for
              new technology component of Red Hat, as opposed to RHEL.
   <rh_sales> Told ya it'll eat your brane.
          --- rh_pr kicks rh_sales from the channel (you're a dolt)
  <oss_crowd> fedora_rh: so, let me get this straight. Effectively, you
              want us to download the packages you release, test things,
              file bugs, and submit patches.
  <fedora_rh> oss_crowd: Sure, why not?
  <oss_crowd> ...but when it comes to things like features, direction of
              the project, and which software to include in the
              distribution, it's the decision of Red Hat?
            * fedora_rh is away: I AM RH
  <fedora_us> I'm still not dead.
  <oss_crowd> fedora_rh: How is that different from how things were
              before the whole "publicly-supported distribution" thing?
  <oss_crowd> rh_dev: where is that long-promised public CVS/SVN repo?
     <rh_dev> dunno, talk to fedora_rh
  <fedora_rh> oss_crowd: look, such things don't happen in a week, ok?
  <oss_crowd> IT'S BEEN A YEAR!
          --- rh_sales joined the channel
   <rh_sales> EAT YOUR BRAAAAAANE.
  <oss_crowd> /mode +b rh_sales
          --- You're not ops in here.
  <oss_crowd> figures
--- END IRC LOG ---

Cheers,
-- 
Konstantin ("Icon") Ryabitsev
Duke Physics Systems Admin, RHCE
I am looking for a job in Canada!
http://linux.duke.edu/~icon/cajob.ptml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040503/3853d241/attachment.sig>

From alan at clueserver.org  Tue May  4 00:38:55 2004
From: alan at clueserver.org (alan)
Date: Mon, 3 May 2004 17:38:55 -0700 (PDT)
Subject: fedora core 3 goals.
In-Reply-To: <4096E4F6.1030904@linux.duke.edu>
Message-ID: <Pine.LNX.4.44.0405031736490.23754-100000@ebersisk.clueserver.org>

On Mon, 3 May 2004, Konstantin Ryabitsev wrote:

> Mike Chambers wrote:
> > I think Red Hat went out on a limb and went ahead and told everyone what
> > was going to happen with changing to Fedora and letting us in on how
> > this thing will work in general.
> 
> Let me, err, relay how things are looking from outside of RH in the 
> format everyone will understand...

[irc log snipped]

That is the best description of the process so far.

Fedora development resembles more of a "clique" than a "community".





From gafton at redhat.com  Tue May  4 01:25:56 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Mon, 3 May 2004 21:25:56 -0400 (EDT)
Subject: fedora core 3 goals.
In-Reply-To: <1083625839.1720.10.camel@scrappy.netlyncs.com>
References: <1083477944.3244.8.camel@binkley>  <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
	<1083625839.1720.10.camel@scrappy.netlyncs.com>
Message-ID: <Pine.LNX.4.58.0405032117320.2478@alien.devel.redhat.com>

On Mon, 3 May 2004, Mike Chambers wrote:

> (Now, upon saying all of that, maybe it might help if there was a list
> or something that some Red Hat folks and few external folks can
> talk/discuss what is going on and needs to get it going so that it's an
> easy transition to the contribution side of things and such?  Such as
> external folks used to submitting packages/fixes/bugs/code via cvs or
> however on major projects and their experiences on what they went
> through to make it easier?  Maybe a private list or something? *shrug*)

Yes, such a list is coming. For lack of a better word, it is a list meant 
for the stakeholders of the entire process. The list archives will be 
public, but membership will be limited to folks with commit access as a 
way of keeping things on track and focused on various tasks that need to 
be performed.

I will seed the initial list with selected members of the Red Hat 
development team and the fedora.us members. Until we get more 
sophisticated about things, the membership criteria will be direct 
ownership of a "good chunk" of Fedora packages. The exact definition of a 
"good chunk" will rest with me for a while, again until this will get 
figured out better.

A proposal which I favor would be to have the discussions of this smaller 
list cross-posted here, so other interested parties can spawn follow-up 
threads that might or might not have a direct relevance to the work done 
by the package maintainers.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "There are two kinds of people who never amount to much: those who 
   cannot do what they are told, and those who can do nothing else."
        --Cyrus Curtis




From gafton at redhat.com  Tue May  4 01:27:11 2004
From: gafton at redhat.com (Cristian Gafton)
Date: Mon, 3 May 2004 21:27:11 -0400 (EDT)
Subject: fedora core 3 goals.
In-Reply-To: <1083625839.1720.10.camel@scrappy.netlyncs.com>
References: <1083477944.3244.8.camel@binkley>  <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
	<1083625839.1720.10.camel@scrappy.netlyncs.com>
Message-ID: <Pine.LNX.4.58.0405032126070.2478@alien.devel.redhat.com>

On Mon, 3 May 2004, Mike Chambers wrote:

> (Oh yea, did I cheese eat enough yet to get my @redhat.com addy yet?
> LOL)

Speaking of which, there are development and release engineering positions 
open at Red Hat currently. If you're willing to move to RDU, you should 
send along a resume for review if you want to...

Cristian
--
----------------------------------------------------------------------
Cristian Gafton     --     gafton at redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "There are two kinds of people who never amount to much: those who 
   cannot do what they are told, and those who can do nothing else."
        --Cyrus Curtis




From jurgen at botz.org  Tue May  4 02:57:00 2004
From: jurgen at botz.org (Jurgen Botz)
Date: Mon, 03 May 2004 19:57:00 -0700
Subject: sg (scsi generic) module missing
In-Reply-To: <1083570621.3843.1.camel@laptop.fenrus.com>
References: <20040412204032.GE1556856@hiwaay.net>	<20040412204955.GB723@devserv.devel.redhat.com>	<20040502213243.GM28387@serve.riede.org>	<20040502222659.GC5327@devserv.devel.redhat.com>	<409582D2.4070000@uol.com.br>
	<1083570621.3843.1.camel@laptop.fenrus.com>
Message-ID: <4097067C.7050800@botz.org>

Arjan van de Ven wrote:
> the usb-storage bug is fixed in kernel 349 (see
> http://people.redhat.com). Actually it's worked around. cdrecord has a
> bug where it doesn't check a return value and interprets an error value
> as 255 sectors-io-size. Which is/was invalid for usb storage. SG just
> silently ignores the fact that that is an invalid value for usb storage
> and continues, at the risk of breaking the burn. As I said fixed in 349
> by making usb-storage also grok 255 sector sized IO's.

I don't know about cdrecord, but grip and cdparanoia are still broken
with 349 and my USB CD-RW drive.  I still get:

   Error trying to open /dev/sg0 exclusively (No such device or 
address). retrying in 1 second

  ...and failure to rip any tracks.

Also, 349 seems to ignore "selinux=0" argument?

:j




From pryce at ucla.edu  Tue May  4 04:49:23 2004
From: pryce at ucla.edu (Paul Rigor)
Date: Mon, 03 May 2004 21:49:23 -0700
Subject: Upgrade RH9 --> FC....
In-Reply-To: <006e01c43162$634d41a0$1e090018@C515816A>
References: <Pine.LNX.4.58.0405031855310.2478@alien.devel.redhat.com>
	<006e01c43162$634d41a0$1e090018@C515816A>
Message-ID: <6.0.0.22.2.20040503214815.01fe9b30@mail.ucla.edu>

check out yum and its repositories... a nice tool is apt w/ synaptic as a 
frontend... easily customizable...

maybe someone else has a better idea =]

goodluck,
paul

At 04:00 PM 5/3/2004, you wrote:
>Is it possible to upgrade RH9 to FCx without having to start from scratch.
>If not is this not a future project for the Fedora Core project.
>
>
>
>--
>fedora-devel-list mailing list
>fedora-devel-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-devel-list

_________
Paul Rigor
pryce at ucla.edu
Go Bruins! 




From mike at netlyncs.com  Tue May  4 04:59:05 2004
From: mike at netlyncs.com (Mike Chambers)
Date: Mon, 03 May 2004 23:59:05 -0500
Subject: fedora core 3 goals.
In-Reply-To: <Pine.LNX.4.58.0405032126070.2478@alien.devel.redhat.com>
References: <1083477944.3244.8.camel@binkley>  <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
	<1083625839.1720.10.camel@scrappy.netlyncs.com>
	<Pine.LNX.4.58.0405032126070.2478@alien.devel.redhat.com>
Message-ID: <1083646745.2208.4.camel@scrappy.netlyncs.com>

On Mon, 2004-05-03 at 20:27, Cristian Gafton wrote:
> On Mon, 3 May 2004, Mike Chambers wrote:
> 
> > (Oh yea, did I cheese eat enough yet to get my @redhat.com addy yet?
> > LOL)
> 
> Speaking of which, there are development and release engineering positions 
> open at Red Hat currently. If you're willing to move to RDU, you should 
> send along a resume for review if you want to...

Hehe, well I wouldn't know about moving (all about doing anything to
better myself though), but I would if the right Job came along.  But,
seems I am not qualified for most/all of those jobs (unless the Q/A one
that I saw is mainly a gopher this type thing).

Guess  you could say I was just joking around, but sure wish I had the
education to help me.  (hrm, well I did do Help Desk for 3 or so years
for Allstate LOL).

-- 
Mike Chambers
Madisonville, KY

"It's only funny until someone gets hurt...Then it's hilarious!"




From dennis at ausil.us  Tue May  4 05:07:52 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 4 May 2004 15:07:52 +1000
Subject: fedora core 3 goals.
In-Reply-To: <1083646745.2208.4.camel@scrappy.netlyncs.com>
References: <1083477944.3244.8.camel@binkley>
	<Pine.LNX.4.58.0405032126070.2478@alien.devel.redhat.com>
	<1083646745.2208.4.camel@scrappy.netlyncs.com>
Message-ID: <200405041507.53126.dennis@ausil.us>

Once upon a time Tuesday 04 May 2004 2:59 pm, Mike Chambers wrote:
> On Mon, 2004-05-03 at 20:27, Cristian Gafton wrote:
> > On Mon, 3 May 2004, Mike Chambers wrote:
> > > (Oh yea, did I cheese eat enough yet to get my @redhat.com addy yet?
> > > LOL)
> >
> > Speaking of which, there are development and release engineering
> > positions open at Red Hat currently. If you're willing to move to RDU,
> > you should send along a resume for review if you want to...
>
> Hehe, well I wouldn't know about moving (all about doing anything to
> better myself though), but I would if the right Job came along.  But,
> seems I am not qualified for most/all of those jobs (unless the Q/A one
> that I saw is mainly a gopher this type thing).
>
> Guess  you could say I was just joking around, but sure wish I had the
> education to help me.  (hrm, well I did do Help Desk for 3 or so years
> for Allstate LOL).

Speaking of Jobs,  I'm currently in the process of moving from Australia to 
Chicago  so the systems Administrator position in Boston would be nice.  when 
moving 20,000 miles whats a couple of thousand more? Just wish i could apply  
damn waiting on visa's to come through (Need to be eligible to work in US 
before i can apply).  But employment offers in Illinois are welcome.

Dennis




From wtogami at redhat.com  Tue May  4 05:14:59 2004
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 03 May 2004 19:14:59 -1000
Subject: gaim x86-64 broken protocols
In-Reply-To: <40956738.5070506@redhat.com>
References: <40956738.5070506@redhat.com>
Message-ID: <409726D3.1010101@redhat.com>

Warren Togami wrote:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122221
> 
> gaim-0.77-3's yahoo authentication is broken on x86-64, but it works on 
> ppc32 and i386.  We need your help in finding the fix for this within 
> the next 2-3 days.  Additionally the Novell Groupwise and Zephyr 
> protocols are also broken on x86-64, but they are of lower priority to 
> our userbase.
> 
> http://cvs.sourceforge.net/viewcvs.py/gaim/gaim/src/protocols/yahoo/yahoo.c
> http://cvs.sourceforge.net/viewcvs.py/gaim/gaim/src/protocols/yahoo/yahoo_auth.c 
> 
> 
> These are the two relevant source files.
> 
> Please notify us in #gaim and this mailing list thread if you have 
> solved the problem.
> 

Upstream gaim believes Zephyr actually works on x86-64, but Novell 
Groupwise and Yahoo remain broken.  I will do a final rebuild of gaim 
early May 6th that will either disable these protocols on x86-64, or 
patch them if a fix is found before this deadline.

Warren Togami
wtogami at redhat.com




From pryce at ucla.edu  Tue May  4 07:03:41 2004
From: pryce at ucla.edu (Paul Rigor)
Date: Tue, 04 May 2004 00:03:41 -0700
Subject: Upgrade RH9 --> FC....
In-Reply-To: <20040503230850.GO31653@devserv.devel.redhat.com>
References: <Pine.LNX.4.58.0405031855310.2478@alien.devel.redhat.com>
	<006e01c43162$634d41a0$1e090018@C515816A>
	<20040503230850.GO31653@devserv.devel.redhat.com>
Message-ID: <6.0.0.22.2.20040504000311.01e6d460@mail.ucla.edu>

Becareful about lib dependencies... You might have to recompile custom apps...

Good luck!

At 04:08 PM 5/3/2004, you wrote:
>On Mon, May 03, 2004 at 06:00:10PM -0500, Otto Haliburton wrote:
> > Is it possible to upgrade RH9 to FCx without having to start from scratch.
> > If not is this not a future project for the Fedora Core project.
>
>Just stick an FC1 CD in an RH9 box and hit "upgrade"
>
>
>--
>fedora-devel-list mailing list
>fedora-devel-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-devel-list

_________
Paul Rigor
pryce at ucla.edu
Go Bruins! 




From thomas at apestaart.org  Tue May  4 07:57:20 2004
From: thomas at apestaart.org (Thomas Vander Stichele)
Date: Tue, 04 May 2004 09:57:20 +0200
Subject: fedora core 3 goals.
In-Reply-To: <4096E4F6.1030904@linux.duke.edu>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
	<1083625839.1720.10.camel@scrappy.netlyncs.com>
	<4096E4F6.1030904@linux.duke.edu>
Message-ID: <1083657440.24972.25.camel@otto.amantes>

On Tue, 2004-05-04 at 02:33, Konstantin Ryabitsev wrote:
> Mike Chambers wrote:
> > I think Red Hat went out on a limb and went ahead and told everyone what
> > was going to happen with changing to Fedora and letting us in on how
> > this thing will work in general.
> 
> Let me, err, relay how things are looking from outside of RH in the 
> format everyone will understand...

(snip)

Haha, that's precious ! :) I snorted up my corn flakes while reading
this this morning.  And, from the outside, this is indeed what it looks
like.  I know I end up making fun of myself by finding this mail funny,
but that, combined with the realization that the truth is in fact
funnier than what one could come up with on his/her own, makes me ready
for another year of wondering what the hell is going on and when
something is going to be clear.

Fedora, year 2 - you guys aren't rid of us yet :)  What, you'd think
we'd switch to debian if you held out long enough ?

Thanks, Konstantin :) I'll be smiling all day long.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
What am I still to you ?
Some thief who stole from you ?
Or some fool drama queen whose chances were few
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/





From mr700 at globalnet.bg  Tue May  4 08:04:40 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Tue, 4 May 2004 11:04:40 +0300
Subject: sg (scsi generic) module missing
In-Reply-To: <1083588334.3843.3.camel@laptop.fenrus.com>
References: <20040412204032.GE1556856@hiwaay.net> <200405031529.38061@-mr700>
	<1083588334.3843.3.camel@laptop.fenrus.com>
Message-ID: <200405041104.40666@-mr700>

On Monday 03 May 2004 15:45, Arjan van de Ven wrote:
> On Mon, 2004-05-03 at 14:29, Doncho N. Gunchev wrote:
> > On Monday 03 May 2004 00:32, Willem Riede wrote:
> > ...
> > > 
> > > Why not compile ide-scsi? Why inconvenience owners of tape drives that need it?
> > > Put it in unsupported for all I care, but compile it, _please_.
> > > 
> >     I have problems burning CDs, count one more please from me.
> 
> I'm sorry but without details about what is broken that is really not
> helpful. 
> 
    True, one of the CD-Writers I have access to - 'HL-DT-ST - CD-RW GCE-8525B' (LG)
worked just fine when my bittorrent finished downloading FC2t3. With all previous
2.6 kernels starting from FC1 I had no luck. I had one minute delay (no activity at
all) with them and cdrecord was failing to write the 'lead-in'. I'll test is more
tonight and if there are problems I'll report them. I still wonder about ide-scsi.
    BTW: my 128MB flash works too, kudzu just did not add entry in /etc/fstab as
it used to do with FC1... and thanks for the response.

-- 
Kind regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79




From wtogami at redhat.com  Tue May  4 09:05:00 2004
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 03 May 2004 23:05:00 -1000
Subject: gaim x86-64 broken protocols
In-Reply-To: <409726D3.1010101@redhat.com>
References: <40956738.5070506@redhat.com> <409726D3.1010101@redhat.com>
Message-ID: <40975CBC.4070803@redhat.com>

Woo!  marv and grim in #gaim found the problem in the src/sha.* 
implementation of the sha1 digest algorithm.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122221
http://people.redhat.com/wtogami/temp/

Please test the gaim-0.77-4 builds here, which should fix yahoo
authentication on x86-64.  Please test it for an extended period of
time on i386 and ppc too to make sure we did not break anything by
accident.

Warren Togami
wtogami at redhat.com




From Bernd.Bartmann at sohanet.de  Tue May  4 09:07:42 2004
From: Bernd.Bartmann at sohanet.de (Bernd Bartmann)
Date: Tue, 04 May 2004 11:07:42 +0200
Subject: Several FC1 update announcements are still missing
Message-ID: <40975D5E.6080602@sohanet.de>

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

Hi,

I noticed that there are several already available FC1 updates which are
not officially announced yet:

cvs-1.11.15-1
mc-4.6.0-14.10
neon-0.24.5-1
postfix-2.0.16-1

Best regards.

- --
Dipl.-Ing. (FH) Bernd Bartmann <Bernd.Bartmann at sohanet.de>
I.S. Security and Network Engineer
SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin
Fon: +49 30 214783-44 / Fax: +49 30 214783-46

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAl11ekQuIaHu84cIRAim+AJ9QZieWlexNKYv5Qp7I7Gjs2srw0gCgorMY
es8mqJThvd58kxdx+Hr6GM4=
=M7bQ
-----END PGP SIGNATURE-----




From arjanv at redhat.com  Tue May  4 09:17:04 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Tue, 04 May 2004 11:17:04 +0200
Subject: Several FC1 update announcements are still missing
In-Reply-To: <40975D5E.6080602@sohanet.de>
References: <40975D5E.6080602@sohanet.de>
Message-ID: <1083662224.3844.4.camel@laptop.fenrus.com>

On Tue, 2004-05-04 at 11:07, Bernd Bartmann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I noticed that there are several already available FC1 updates which are
> not officially announced yet:
> 
> cvs-1.11.15-1
> mc-4.6.0-14.10
> neon-0.24.5-1
> postfix-2.0.16-1

There seems to be a problem with the mailinglist somehow, our IS/IT guys
were investigating yesterday but apparently not with full success yet.
At least for mc I know jakub tried at least 4 times to get the announce
out but somehow it gets eaten somewhere.
-------------- 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/20040504/0f78d2f8/attachment.sig>

From pmmm at rnl.ist.utl.pt  Tue May  4 09:24:35 2004
From: pmmm at rnl.ist.utl.pt (Pedro Morais)
Date: Tue, 4 May 2004 10:24:35 +0100
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083625394.5813.6.camel@laptop>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
Message-ID: <200405041024.35271.pmmm@rnl.ist.utl.pt>

Em Ter?a, 4 de Maio de 2004 00:03, Mark McLoughlin escreveu:
>         Its about potential destabilisation, yes. Every code change, no
> matter how trivial it may seem, brings with it the risk of introducing
> regressions or weird side effects. Therefore, at this stage in the
> release cycle its good practise to weigh up the benefit each code change
> brings versus the potential for introducing other bugs.

As much as I want Fedora to have great localizations, and the portuguese 
localization would probably benefict from the 2.6.0 -> 2.6.1 upgrade, I still 
remember this:

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

Enabling the translation of mouse types names between the last beta and final 
release of RHL9 (what trouble can than cause?) had the side effect of making 
anaconda crash for several languages.

	Pedro Morais




From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Tue May  4 09:53:15 2004
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Tue, 4 May 2004 11:53:15 +0200
Subject: Module ohci1394 not found
In-Reply-To: <orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <1083185485.2241.3.camel@localhost.localdomain>
	<1083186496.5085.85.camel@roadrash.rdu.redhat.com>
	<orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <20040504115315.16eac80a@localhost>

Alexandre Oliva wrote :

> On Apr 28, 2004, Chris Kloiber <ckloiber at ckloiber.com> wrote:
> 
> > FireWire is currently busted in the latest kernel trees. IIRC it
> > compiles but explodes wonderfully on insertion, taking the whole system
> > and half the of the South East USA seacoast with it into oblivion. It
> > will likely be turned on again when it works.
> 
> Which probably means it won't make it to FC2 final.  I plan on
> offering some work-arounds for Firewire users, sort of like I did for
> FC1.  My plan is to take the Firewire code that shipped with kernel
> 2.6.3, since that has worked quite reliably for me.

Eeek!!! Disable FireWire in the final release!? I hope you were joking, and
that whatever working version that existed last will be forward ported
since FireWire seems nearly vital to me.

I personally use it _very_ often to connect an external hard drive, as well
as my MiniDV camcorder with dvgrab/kino, and I'm pretty sure I'm not the
only one.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1.92 (FC2 Test 3) - Linux kernel 2.6.5-1.327
Load : 1.06 1.15 1.14




From jorton at redhat.com  Tue May  4 10:11:00 2004
From: jorton at redhat.com (Joe Orton)
Date: Tue, 4 May 2004 11:11:00 +0100
Subject: Several FC1 update announcements are still missing
In-Reply-To: <1083662224.3844.4.camel@laptop.fenrus.com>
References: <40975D5E.6080602@sohanet.de>
	<1083662224.3844.4.camel@laptop.fenrus.com>
Message-ID: <20040504101100.GA18247@redhat.com>

On Tue, May 04, 2004 at 11:17:04AM +0200, Arjan van de Ven wrote:
> On Tue, 2004-05-04 at 11:07, Bernd Bartmann wrote:
> > I noticed that there are several already available FC1 updates which are
> > not officially announced yet:
> > 
> > cvs-1.11.15-1
> > mc-4.6.0-14.10
> > neon-0.24.5-1
> > postfix-2.0.16-1
> 
> There seems to be a problem with the mailinglist somehow, our IS/IT guys
> were investigating yesterday but apparently not with full success yet.
> At least for mc I know jakub tried at least 4 times to get the announce
> out but somehow it gets eaten somewhere.

Likewise for the neon announcement.

joe




From lorenzo at reality.it  Tue May  4 10:12:25 2004
From: lorenzo at reality.it (Lorenzo Luconi Trombacchi)
Date: Tue, 04 May 2004 12:12:25 +0200
Subject: Module ohci1394 not found
In-Reply-To: <20040504115315.16eac80a@localhost>
References: <1083185485.2241.3.camel@localhost.localdomain>	<1083186496.5085.85.camel@roadrash.rdu.redhat.com>	<orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040504115315.16eac80a@localhost>
Message-ID: <40976C89.3020102@reality.it>

Matthias Saou wrote:

>Eeek!!! Disable FireWire in the final release!? I hope you were joking, and
>that whatever working version that existed last will be forward ported
>since FireWire seems nearly vital to me.
>
>I personally use it _very_ often to connect an external hard drive, as well
>as my MiniDV camcorder with dvgrab/kino, and I'm pretty sure I'm not the
>only one.
>  
>

You aren't alone! Without firewire support FC2 becomes useless for many 
users.

Lorenzo

>Matthias
>
>  
>




From ijuma82 at f2s.com  Tue May  4 10:36:00 2004
From: ijuma82 at f2s.com (Ismael Juma)
Date: Tue, 04 May 2004 11:36:00 +0100
Subject: Module ohci1394 not found
In-Reply-To: <1083596053.4603.4.camel@dhollis-lnx.kpmg.com>
References: <1083185485.2241.3.camel@localhost.localdomain>	<1083186496.5085.85.camel@roadrash.rdu.redhat.com>	<orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1083596053.4603.4.camel@dhollis-lnx.kpmg.com>
Message-ID: <40977210.7010604@f2s.com>

David T Hollis wrote:

> For what it's worth, I was able to build and load the firewire modules
> against 2.6.5-1.347.  I used the latest ieee1394 branch from subversion
> using the attached Makefile.  I have not actually tested connecting any
> firewire devices but my experience with other recent kernels was that
> loading ohci1394 spewed out a bunch of stack dumps.

The ieee1394 branch from subversion was merged into one of the recent 
mainline kernels (I think it was between 2.6.6-rc2 and 2.6.6-rc3). I 
have been using vanilla 2.6.6-rc3 with firewire enabled and I have had 
no problems whatsoever. My maxtor external hard drive works as well as 
my internal one.

So I guess that for people that really require firewire capability, 
compiling their own kernels might be necessary (as it is for people who 
want Nvidia binary drivers or NTFS to work - I happen to need the three 
of them ;)).

Cheers,
Ismael




From barryn at pobox.com  Tue May  4 11:24:59 2004
From: barryn at pobox.com (Barry K. Nathan)
Date: Tue, 4 May 2004 04:24:59 -0700
Subject: Module ohci1394 not found
In-Reply-To: <40977210.7010604@f2s.com>
References: <1083185485.2241.3.camel@localhost.localdomain>
	<1083186496.5085.85.camel@roadrash.rdu.redhat.com>
	<orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1083596053.4603.4.camel@dhollis-lnx.kpmg.com>
	<40977210.7010604@f2s.com>
Message-ID: <20040504112459.GA4353@ip68-4-98-123.oc.oc.cox.net>

On Tue, May 04, 2004 at 11:36:00AM +0100, Ismael Juma wrote:
> The ieee1394 branch from subversion was merged into one of the recent 
> mainline kernels (I think it was between 2.6.6-rc2 and 2.6.6-rc3). I 
> have been using vanilla 2.6.6-rc3 with firewire enabled and I have had 
> no problems whatsoever. My maxtor external hard drive works as well as 
> my internal one.

FWIW, I'm running 2.6.5-rc3-bk5 on a Mandrake 10 system and FireWire
is working perfectly with two DVD+RW drives. In contrast, 2.6.5's
FireWire completely explodes (it doesn't take the whole system down, but
it spews tons of messages and is completely useless.) Both of those are
mainline, BTW.

Since the latest posted arjanv kernel (2.6.5-1.349) is based on
2.6.6-rc3-bk, it should have the ieee1394 update and I would expect
it to work again. I don't know if I will have time to test this in
the next few days, however.

-Barry K. Nathan <barryn at pobox.com>




From stuart at terminus.co.uk  Tue May  4 12:20:06 2004
From: stuart at terminus.co.uk (Stuart Children)
Date: Tue, 04 May 2004 13:20:06 +0100
Subject: Self-introduction: Stuart Children
Message-ID: <40978A76.20608@terminus.co.uk>

Hi all

I'm now going to be spending some time actually working on some 
packages, so here's a proper introduction...

1. Full legal name:

    Stuart Children

2. Country, City

    UK, London

3. Profession or Student status

    IT Developer

4. Company or School

    Guardian Unlimited (http://www.guardian.co.uk/)

5. Your goals in the Fedora Project

    * Which packages do you want to see published?

    Right now I am working on packages for the enlightenment
    window manager. I also intend to get some useful Perl modules
    packaged up.

    * Do you want to do QA?

    Definitely for packages I have an interest in.

    * Anything else special?

    I have an interest in desktop integration work, though how much
    time I have available to code on this will vary.

6. Historical qualifications

    * What other projects have you worked on in the past?

    No major contributions to anything that big, but many small
    patches all over the shop from the Linux kernel to Perl modules.
    I am currently rewriting ppstats (a Perl script to create statistics
    from the log files of the distributed.net personal proxy).

    * What computer languages and other skills do you know?

    Recently I've mainly been using TCL, Perl, shell scripting, along
    with some Java, C, and JavaScript. I work a fair bit with XML,
    HTML/CSS, and databases.

    * Why should we trust you?

    Trust is built up over time. Read my public postings (here and
    elsewhere). Look at my code. Observe my contributions. Finally,
    come and meet me in person! [1]

7. GPG KEYID and fingerprint

   pub 1024D/C3D17B95 2000-02-21 Stuart Children <stuart at terminus.co.uk>
   Key fingerprint = 649E 13D0 A9B8 7F54 3505  98F0 B71D 36F9 C3D1 7B95
   sub 1024g/976DDBA8 2000-02-21


[1] Is anyone interested in a Fedora developers/contributors social 
gathering in central London? Nothing too formal, just put faces to 
names, drink some beer, enjoy the sun (once this rain clears up), chat 
about our favourite head gear, and perhaps some do some key signing?

Cheers

-- 
Stuart
http://terminus.co.uk/




From ijuma82 at f2s.com  Tue May  4 12:50:51 2004
From: ijuma82 at f2s.com (Ismael Juma)
Date: Tue, 04 May 2004 13:50:51 +0100
Subject: Module ohci1394 not found
In-Reply-To: <20040504112459.GA4353@ip68-4-98-123.oc.oc.cox.net>
References: <1083185485.2241.3.camel@localhost.localdomain>	<1083186496.5085.85.camel@roadrash.rdu.redhat.com>	<orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>	<1083596053.4603.4.camel@dhollis-lnx.kpmg.com>	<40977210.7010604@f2s.com>
	<20040504112459.GA4353@ip68-4-98-123.oc.oc.cox.net>
Message-ID: <409791AB.2050405@f2s.com>

Barry K. Nathan wrote:

> FWIW, I'm running 2.6.5-rc3-bk5 on a Mandrake 10 system and FireWire
> is working perfectly with two DVD+RW drives. In contrast, 2.6.5's
> FireWire completely explodes (it doesn't take the whole system down, but
> it spews tons of messages and is completely useless.) Both of those are
> mainline, BTW.
> 
> Since the latest posted arjanv kernel (2.6.5-1.349) is based on
> 2.6.6-rc3-bk, it should have the ieee1394 update and I would expect
> it to work again. I don't know if I will have time to test this in
> the next few days, however.

You're running 2.6.5-rc3-bk5? Or do you mean 2.6.6-rc3-bk5?

Cheers,
Ismael




From barryn at pobox.com  Tue May  4 13:49:24 2004
From: barryn at pobox.com (Barry K. Nathan)
Date: Tue, 4 May 2004 06:49:24 -0700
Subject: Module ohci1394 not found
In-Reply-To: <409791AB.2050405@f2s.com>
References: <1083185485.2241.3.camel@localhost.localdomain>
	<1083186496.5085.85.camel@roadrash.rdu.redhat.com>
	<orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1083596053.4603.4.camel@dhollis-lnx.kpmg.com>
	<40977210.7010604@f2s.com>
	<20040504112459.GA4353@ip68-4-98-123.oc.oc.cox.net>
	<409791AB.2050405@f2s.com>
Message-ID: <20040504134924.GB4353@ip68-4-98-123.oc.oc.cox.net>

On Tue, May 04, 2004 at 01:50:51PM +0100, Ismael Juma wrote:
> You're running 2.6.5-rc3-bk5? Or do you mean 2.6.6-rc3-bk5?

Yes, I meant 2.6.6-rc3-bk5, sorry about that!!

-Barry K. Nathan <barryn at pobox.com>




From markmc at redhat.com  Tue May  4 14:13:39 2004
From: markmc at redhat.com (Mark McLoughlin)
Date: Tue, 04 May 2004 15:13:39 +0100
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <200405041024.35271.pmmm@rnl.ist.utl.pt>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
Message-ID: <1083680018.5813.19.camel@laptop>

Hi,

On Tue, 2004-05-04 at 10:24, Pedro Morais wrote:
> Em Ter?a, 4 de Maio de 2004 00:03, Mark McLoughlin escreveu:
> >         Its about potential destabilisation, yes. Every code change, no
> > matter how trivial it may seem, brings with it the risk of introducing
> > regressions or weird side effects. Therefore, at this stage in the
> > release cycle its good practise to weigh up the benefit each code change
> > brings versus the potential for introducing other bugs.
> 
> As much as I want Fedora to have great localizations, and the portuguese 
> localization would probably benefict from the 2.6.0 -> 2.6.1 upgrade, I still 
> remember this:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87431
> 
> Enabling the translation of mouse types names between the last beta and final 
> release of RHL9 (what trouble can than cause?) had the side effect of making 
> anaconda crash for several languages.

	Backporting translations from upstream is probably a fairly reasonable
thing to do. But if we were to do that I'd like to have translation
teams for each language be responsible for that work.

	Just another item to put on the TODO list for when we have an external
CVS ...

Cheers,
Mark.




From riel at redhat.com  Tue May  4 15:39:21 2004
From: riel at redhat.com (Rik van Riel)
Date: Tue, 4 May 2004 11:39:21 -0400 (EDT)
Subject: fedora core 3 goals.
In-Reply-To: <1083627671.25635.20.camel@binkley>
Message-ID: <Pine.LNX.4.44.0405041138030.28770-100000@chimarrao.boston.redhat.com>

On Mon, 3 May 2004, seth vidal wrote:

> So we can't even hear that it's occurring? I'm not asking for input
> necessarily. I am asking for knowledge of what is happening. Just
> knowing that there are problems with embargoed packages or knowing that
> there are legal issues with non-employee contributions, this is valuable
> information. This makes people realize what it is you're doing.

A Fedora status report would be awesome, indeed...

Even if it's only a few lines of what Christian and his
team have been up to over the last 2 weeks.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan




From lercio at pbh.gov.br  Tue May  4 16:48:21 2004
From: lercio at pbh.gov.br (Lercio Teotonio Gontijo)
Date: Tue, 04 May 2004 13:48:21 -0300
Subject: FC2-test3 - installation errors
Message-ID: <4097C955.80003@pbh.gov.br>

Hello All,

I download iso FC2-test3 am try to test and I need report installation 
erros:

during networking installation I copy iso images to /Fedora (and export 
it via NFS)
and the message

"The Fedora Core installation tree in that directory does not seem to match
your boot media"

then I mount  any ISO imagens and copy all to same dir and same message 
apper.

Howto install FC2 on net???
Howto get FC2 disk 1.44Mb boot??

I report also "mouse PS2 2 buttoms" not detect and also my generic SVGA 
monitor

Need Help

Thanks

Sory my bad english  :-(





From buildsys at redhat.com  Tue May  4 16:49:18 2004
From: buildsys at redhat.com (Build System)
Date: Tue, 4 May 2004 12:49:18 -0400
Subject: rawhide report: 20040504 changes
Message-ID: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>

 

 
Updated Packages:

alsa-lib-1.0.3a-2
-----------------
* Mon May 03 2004 Colin Walters <walters at redhat.com> 1.0.3a-2

- Add patch to avoid assert()ing on errors

firstboot-1.3.13-1
------------------
* Mon May 03 2004 Brent Fox <bfox at redhat.com> 1.3.13-1

- fix Norwegian translation bug (bug #122206)

gdb-6.0post-0.20040223.19
-------------------------
* Mon May 03 2004 Jeff Johnston <jjohnstn at redhat.com>	0.20040223.19

- Add -u parameter to build ChangeLog patch.

* Mon May 03 2004 Jeff Johnston <jjohnstn at redhat.com>	0.20040223.18

- Update thread fix made for .6 release to FSF version.

* Thu Apr 22 2004 Elena Zannoni <ezannoni at redhat.com>	0.20040223.17

- Disable PIE again.


gnome-system-monitor-2.6.0-3
----------------------------
* Mon May 03 2004 Than Ngo <than at redhat.com> 2.6.0-3

- cleanup GNOME/KDE menu, only show in GNOME

hotplug-2004_04_01-1
--------------------
* Mon May 03 2004 Bill Nottingham <notting at redhat.com> 3:2004_04_01-1

- update to 2004-04-01 release, fixes #116638, #119161, #111956, #115277

kdeutils-3.2.2-2
----------------
* Sun May 02 2004 Than Ngo <than at redhat.com> 6:3.2.2-2

- fix "Extract here" for tar.gz, #122048
- don't show some KDE apps in GNOME, #117271

kernel-2.6.5-1.349
------------------
* Fri Apr 30 2004 Arjan van de Ven <arjanv at redhat.com>

- 2.6.6-rc3-bk1
- make amd64 boot again
- fix vm86-vs-4g4g interaction (Ingo)

* Thu Apr 22 2004 Arjan van de Ven <arjanv at redhat.com>

- 2.6.6-rc2

* Tue Apr 20 2004 Arjan van de Ven <arjanv at redhat.com>

- add the ext3 online resize patch


kernel-utils-2.4-9.1.130
------------------------
* Mon May 03 2004 Arjan van de Ven <arjanv at redhat.com>

- add fix for bug 120522

* Sun May 02 2004 Arjan van de Ven <arjanv at redhat.com>

- update smartmontools to prevent amd64 from segfaulting

* Sat Apr 17 2004 Arjan van de Ven <arjanv at redhat.com>

- make cpuspeed initscript honor locking


koffice-1.3-6
-------------
* Mon May 03 2004 Than Ngo <than at redhat.com> 1.3-6

- cleanup GNOME/KDE menu, add X-KDE-More in Categories
- add some fixes from CVS stable branch

libgcrypt-1.2.0-1
-----------------
* Sun May 02 2004 Bill Nottingham <notting at redhat.com> - 1.2.0-1

- update to official 1.2.0

libpng-1.2.2-22
---------------
* Mon May 03 2004 Matthias Clasen <mclasen at redhat.com> 2:1.2.2-22

- Redo the out-of-bounds fix in a slightly better way.

* Wed Apr 21 2004 Matthias Clasen <mclasen at redhat.com>

- Bump release number to disambiguate n-v-rs.

* Mon Apr 19 2004 Matthias Clasen <mclasen at redhat.com> 

- fix a possible out-of-bounds read in the error message 
  handler. #121229


libpng10-1.0.13-13
------------------
* Mon May 03 2004 MAtthias Clasen <mclasen at redhat.com> 1.0.13-13

- Redo the out-of-bounds fix in a slightly better way.

* Wed Apr 21 2004 Matthias Clasen <mclasen at redhat.com> 1.0.13-12

- Bump release number to disambiguate n-v-rs.

* Mon Apr 19 2004 Matthias Clasen <mclasen at redhat.com>

- fix a possible out-of-bounds read in the error message
  handler. #121229


mailcap-2.1.15-1
----------------
* Mon May 03 2004 Bill Nottingham <notting at redhat.com> 2.1.15-1

- xpdf/gv -> ggv (#118401)
- add application/x-bittorrent (#118752)

* Fri Jul 11 2003 Bill Nottingham <notting at redhat.com> 2.1.14-1

- add application/ogg and OpenOffice.org mime.types

* Fri Feb 07 2003 Bill Nottingham <notting at redhat.com> 2.1.13-1

- resync mime.types with apache
- clean out mailcap some


perl-XML-Twig-3.13-5
--------------------
* Mon May 03 2004 Chip Turner <cturner at redhat.com> 3.13-5

- bugzilla 122079, add dep filter to remove bad dependency

qt-3.3.2-1
----------
* Thu Apr 29 2004 Than Ngo <than at redhat.com> 3.3.2-1

- update to 3.3.2

rhythmbox-0.8.3-1
-----------------
* Sun May 02 2004 Colin Walters <walters at redhat.com> - 0.8.3-1

- Update to 0.8.3: fixes showstopper bug with internet radio

* Fri Apr 30 2004 Colin Walters <walters at redhat.com> - 0.8.2-1

- Update to 0.8.2
- Fix Source url
- Add smp_mflags
- Bump BuildRequires on gstreamer to 0.8.1

* Fri Apr 23 2004 Colin Walters <walters at redhat.com> - 0.8.1-2

- Uninstall GConf schemas on removal


rpmdb-fedora-1.92-0.20040504
----------------------------

rsync-2.6.2-0
-------------
* Fri Apr 30 2004 Jay Fenlason <fenlason at redhat.com> 2.6.2-0

- New upstream version to correct the problems with 2.6.1.
  This obsoletes all the patches to 2.6.1

* Thu Apr 29 2004 Jay Fenlason <fenlason at redhat.com> 2.6.1-1

- Rsync 2.6.1 final.
- Add a patch from Wayne Davison <wayned at samba.org> that fixes a
  use of uninitilized memory in the map_uid and map_gid functions.
- Add another patch from Wayne Davidson that fixes the -R option.
- Add a patch (extracted from a patch by Sami Farin
  <safari-rsync at safari.iki.fi>) to not ignore the return value
  of close().

samba-3.0.3-4
-------------
* Thu Apr 29 2004 Jay Fenlason <fenlason at redhat.com> 3.0.3-4

- Samba 3.0.3 released.

* Wed Apr 21 2004 jay Fenlason <fenlason at redhat.com> 3.0.3-3.rc1

- New upstream version
- updated spec file to make libsmbclient.so executable.  This closes
  bugzilla #121356

spamassassin-2.63-8
-------------------
* Sun May 02 2004 Ville Skytt?? <ville.skytta at iki.fi> - 2.63-8

- #122233
- Require perl(:MODULE_COMPAT_*).
- Use %{_mandir} and %{_initrddir}.
- Fix License tag and include License in docs.
- Backslashify multiline init script description.

sysklogd-1.4.1-16
-----------------
* Mon May 03 2004 Bill Nottingham <notting at redhat.com> 1.4.1rh-16

- add Owl patch for crunch_list function, fixes potential crashes (#120453)

system-config-display-1.0.14-1
------------------------------
* Fri Apr 30 2004 Brent Fox <bfox at redhat.com> 1.0.14-1

- do not write out extra XF86Config file during firstboot (bug #121729)

system-config-securitylevel-1.3.12-1
------------------------------------
* Fri Apr 30 2004 Brent Fox <bfox at redhat.com> 1.3.12-1

- turn off SELinux widgets for FC2 (bug #122046)

vsftpd-1.2.1-5
--------------
* Mon May 03 2004 Bill Nottingham <notting at redhat.com> 1.2.1-5

- fix all references to vsftpd.conf to be /etc/vsftpd/vsftpd.conf,
  including in the binary (#121199, #104075)




From jkeating at j2solutions.net  Tue May  4 16:50:10 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 4 May 2004 09:50:10 -0700
Subject: FC2-test3 - installation errors
In-Reply-To: <4097C955.80003@pbh.gov.br>
References: <4097C955.80003@pbh.gov.br>
Message-ID: <200405040950.10539.jkeating@j2solutions.net>

On Tuesday 04 May 2004 09:48, Lercio Teotonio Gontijo wrote:
> I download iso FC2-test3 am try to test and I need report
> installation erros:
>
> during networking installation I copy iso images to /Fedora (and
> export it via NFS)
> and the message
>
> "The Fedora Core installation tree in that directory does not seem to
> match your boot media"

What are you booting from?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040504/3de93b9a/attachment.sig>

From arjanv at redhat.com  Tue May  4 17:00:38 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Tue, 04 May 2004 19:00:38 +0200
Subject: rawhide report: 20040504 changes
In-Reply-To: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
References: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
Message-ID: <1083690038.3844.6.camel@laptop.fenrus.com>

On Tue, 2004-05-04 at 18:49, Build System wrote:

> kernel-2.6.5-1.349
> ------------------

I would like to ask everyone on this list to please test this kernel
hard; it has quite a few bugfixes but there always is the risk of
regressions; time to release is running out so please test!

-------------- 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/20040504/e5e57347/attachment.sig>

From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Tue May  4 17:04:38 2004
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Tue, 4 May 2004 19:04:38 +0200
Subject: rawhide report: 20040504 changes
In-Reply-To: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
References: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
Message-ID: <20040504190438.33960a6c@localhost>

Build System wrote :

> - Use %{_mandir} and %{_initrddir}.

Once again, as I never got any answers nor comments about this one :
Why is it _initrddir for /etc/rc.d/init.d??? It has nothing to do with the
initial ramdisk, which is (AFAIK) _the_ initrd.
Is it a typo of the person who introduced that macro into rpm, or...?

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1.92 (FC2 Test 3) - Linux kernel 2.6.5-1.327
Load : 0.39 0.41 0.54




From alan at redhat.com  Tue May  4 18:07:25 2004
From: alan at redhat.com (Alan Cox)
Date: Tue, 4 May 2004 14:07:25 -0400
Subject: Module ohci1394 not found
In-Reply-To: <20040504115315.16eac80a@localhost>
References: <1083185485.2241.3.camel@localhost.localdomain>
	<1083186496.5085.85.camel@roadrash.rdu.redhat.com>
	<orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040504115315.16eac80a@localhost>
Message-ID: <20040504180725.GA15185@devserv.devel.redhat.com>

On Tue, May 04, 2004 at 11:53:15AM +0200, Matthias Saou wrote:
> Eeek!!! Disable FireWire in the final release!? I hope you were joking, and
> that whatever working version that existed last will be forward ported
> since FireWire seems nearly vital to me.

The "working version" doesnt exist yet - thats much of the problem.

> I personally use it _very_ often to connect an external hard drive, as well
> as my MiniDV camcorder with dvgrab/kino, and I'm pretty sure I'm not the
> only one.

And there will be errata kernels in time




From dstewart at atl.lmco.com  Tue May  4 18:07:03 2004
From: dstewart at atl.lmco.com (Doug Stewart)
Date: Tue, 04 May 2004 14:07:03 -0400
Subject: fedora core 3 goals.
In-Reply-To: <4096E4F6.1030904@linux.duke.edu>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
	<1083625839.1720.10.camel@scrappy.netlyncs.com>
	<4096E4F6.1030904@linux.duke.edu>
Message-ID: <4097DBC7.80604@atl.lmco.com>

Konstantin Ryabitsev wrote:
> Mike Chambers wrote:
> 
>> I think Red Hat went out on a limb and went ahead and told everyone what
>> was going to happen with changing to Fedora and letting us in on how
>> this thing will work in general.
> 
> 
> Let me, err, relay how things are looking from outside of RH in the 
> format everyone will understand...

[SNIP]

Konstantine:
Hope you don't mind, but I posted a nicely html-ized and colorized 
version of that gem up on my weblog:
http://literalbarrage.org/blog/archives/2004/05/04/linux-geek-out-moment-of-the-day/

-- 
----------
Doug Stewart
Systems Administrator/Web Applications Developer
Lockheed Martin Advanced Technology Labs
(856)792-9844
dstewart at atl.lmco.com




From icon at linux.duke.edu  Tue May  4 18:20:02 2004
From: icon at linux.duke.edu (Konstantin Ryabitsev)
Date: Tue, 04 May 2004 14:20:02 -0400
Subject: fedora core 3 goals.
In-Reply-To: <4097DBC7.80604@atl.lmco.com>
References: <1083477944.3244.8.camel@binkley>
	<4096428F.4050603@redhat.com>	<1083593509.22400.2.camel@binkley>	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>	<1083625839.1720.10.camel@scrappy.netlyncs.com>	<4096E4F6.1030904@linux.duke.edu>
	<4097DBC7.80604@atl.lmco.com>
Message-ID: <4097DED2.5060103@linux.duke.edu>

Doug Stewart wrote:
> Konstantine:
> Hope you don't mind, but I posted a nicely html-ized and colorized 
> version of that gem up on my weblog:
> http://literalbarrage.org/blog/archives/2004/05/04/linux-geek-out-moment-of-the-day/ 

You people are having too much fun with this. :) I wrote it hoping it 
will lessen the tensions a little, and hopefully help carry across a few 
points. But if anyone feels like using it elsewhere, have a blast:

http://creativecommons.org/licenses/by/1.0/

:)

Cheers,
--icon




From alan at redhat.com  Tue May  4 18:20:28 2004
From: alan at redhat.com (Alan Cox)
Date: Tue, 4 May 2004 14:20:28 -0400
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083680018.5813.19.camel@laptop>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
Message-ID: <20040504182028.GC15185@devserv.devel.redhat.com>

On Tue, May 04, 2004 at 03:13:39PM +0100, Mark McLoughlin wrote:
> thing to do. But if we were to do that I'd like to have translation
> teams for each language be responsible for that work.
> 
> 	Just another item to put on the TODO list for when we have an external
> CVS ...

Any reason for not just pushing 2.6.1 at some point ?




From markmc at redhat.com  Tue May  4 18:38:50 2004
From: markmc at redhat.com (Mark McLoughlin)
Date: Tue, 04 May 2004 19:38:50 +0100
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <20040504182028.GC15185@devserv.devel.redhat.com>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
Message-ID: <1083695929.20962.33.camel@laptop>

Hey,

On Tue, 2004-05-04 at 19:20, Alan Cox wrote:
> On Tue, May 04, 2004 at 03:13:39PM +0100, Mark McLoughlin wrote:
> > thing to do. But if we were to do that I'd like to have translation
> > teams for each language be responsible for that work.
> > 
> > 	Just another item to put on the TODO list for when we have an external
> > CVS ...
> 
> Any reason for not just pushing 2.6.1 at some point ?

	Look back over the thread :-)

http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00090.html

	Basically, mass-updating to GNOME 2.6.1 at this point doesn't strike me
as a particularly good exercise in in risk management, no matter how
confident I am in GNOME's release process ...

Cheers,
Mark.




From cpedersen at c-note.dk  Tue May  4 18:46:21 2004
From: cpedersen at c-note.dk (Casper Pedersen)
Date: Tue, 04 May 2004 20:46:21 +0200
Subject: FC2-Test3 Xorg problems
Message-ID: <1083696381.28827.6.camel@tuxdsk.c-note.dk>

Hi,

It looks like there is a problem with firstboot/Xorg. I have a Sony E200
monitor which is DCC compliant (I think), but after firstboot I'm only
able to set it to 640x480 or 800x600 - Not 1280x1024..

In /etc/X11/xorg.conf the following lines where remarked out:

       HorizSync    30.0 - 85.0
       VertRefresh  48.0 - 120.0

After enabling them again, I was able to get 1280x1024.

Is this a bug?

Regards/Casper 


-- 
GPG Public key is available from: http://www.keyserver.net/
Fingerprint = 56ED 74A4 7B00 20E2 B493 0C1A 6B4E BF8F A086 FE57

-------------- 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/20040504/8acae2fd/attachment.sig>

From alan at redhat.com  Tue May  4 18:52:57 2004
From: alan at redhat.com (Alan Cox)
Date: Tue, 4 May 2004 14:52:57 -0400
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083695929.20962.33.camel@laptop>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
	<1083695929.20962.33.camel@laptop>
Message-ID: <20040504185257.GA15467@devserv.devel.redhat.com>

On Tue, May 04, 2004 at 07:38:50PM +0100, Mark McLoughlin wrote:
> > Any reason for not just pushing 2.6.1 at some point ?
> 
> 	Look back over the thread :-)
> 
> http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00090.html
> 
> 	Basically, mass-updating to GNOME 2.6.1 at this point doesn't strike me
> as a particularly good exercise in in risk management, no matter how
> confident I am in GNOME's release process ...


Sorry - I didnt mean for the FC2 release I meant some time after when they
have wandered through testing 




From j.rink at freenet.de  Tue May  4 06:15:13 2004
From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink)
Date: Tue, 4 May 2004 08:15:13 +0200
Subject: Minimal Instalation of Fedora
Message-ID: <20040504081513.2a607541.j.rink@freenet.de>

Hi,
as i remember correctly, there was such a discussion 5 or 6 month ago.
My goal is to have a kickstart installation or a anaconda installation
where i can select a minimal Installation. And when i wrote minimal i
mean minimal ;-)

Is there a project which is working on this problem? Is there a manual
where i can read more about the comps file (Where the rpm's are defined
for installation of workstation, server etc)

I am very glad about any hint.

Thanks

 Joern Rink

-- 
Nine (not 9)
Never trust a hippie




From strange at nsk.no-ip.org  Tue May  4 16:10:41 2004
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Tue, 4 May 2004 17:10:41 +0100
Subject: gaim x86-64 broken protocols
In-Reply-To: <40975CBC.4070803@redhat.com>;
	from wtogami@redhat.com on Mon, May 03, 2004 at 11:05:00PM -1000
References: <40956738.5070506@redhat.com> <409726D3.1010101@redhat.com>
	<40975CBC.4070803@redhat.com>
Message-ID: <20040504171041.A31508@nsk.no-ip.org>

On Mon, May 03, 2004 at 11:05:00PM -1000, Warren Togami wrote:
> Woo!  marv and grim in #gaim found the problem in the src/sha.* 
> implementation of the sha1 digest algorithm.
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122221
> http://people.redhat.com/wtogami/temp/
> 
> Please test the gaim-0.77-4 builds here, which should fix yahoo
> authentication on x86-64.  Please test it for an extended period of
> time on i386 and ppc too to make sure we did not break anything by
> accident.
> 
> Warren Togami
> wtogami at redhat.com

That version still has a bug in the irc module (not related to x86-64,
occurs in every arch).

For more informations, bug #947794 @ gaim.sf.net, #114870 on
bugzilla.redhat.com.

Please include the fix I attach.

Regards,
Luciano Rocha
-------------- next part --------------
diff -ur gaim-0.77.orig/src/protocols/irc/msgs.c gaim-0.77/src/protocols/irc/msgs.c
--- gaim-0.77.orig/src/protocols/irc/msgs.c	2004-03-30 18:44:40.000000000 +0100
+++ gaim-0.77/src/protocols/irc/msgs.c	2004-05-04 16:50:24.388180040 +0100
@@ -390,7 +390,8 @@
 	gaim_connection_set_state(gc, GAIM_CONNECTED);
 
 	irc_blist_timeout(irc);
-	irc->timer = gaim_timeout_add(45000, (GSourceFunc)irc_blist_timeout, (gpointer)irc);
+	if (!irc->timer) 
+		irc->timer = gaim_timeout_add(45000, (GSourceFunc)irc_blist_timeout, (gpointer)irc);
 }
 
 void irc_msg_nochan(struct irc_conn *irc, const char *name, const char *from, char **args)

From mark at harddata.com  Tue May  4 19:06:51 2004
From: mark at harddata.com (Mark Lane)
Date: Tue, 4 May 2004 13:06:51 -0600
Subject: FC2-Test3 Xorg problems
In-Reply-To: <1083696381.28827.6.camel@tuxdsk.c-note.dk>
References: <1083696381.28827.6.camel@tuxdsk.c-note.dk>
Message-ID: <200405041306.51731.mark@harddata.com>

On May 4, 2004 12:46 pm, Casper Pedersen <cpedersen at c-note.dk> wrote:
> Hi,
>
> It looks like there is a problem with firstboot/Xorg. I have a Sony E200
> monitor which is DCC compliant (I think), but after firstboot I'm only
> able to set it to 640x480 or 800x600 - Not 1280x1024..
>
> In /etc/X11/xorg.conf the following lines where remarked out:
>
>        HorizSync    30.0 - 85.0
>        VertRefresh  48.0 - 120.0
>
> After enabling them again, I was able to get 1280x1024.
>
> Is this a bug?

We have noticed a problem with dpms trying to auto determine the Sync and 
Refresh. You definitely need to hard code it in and the install doesn't do 
that.

regards,

-- 
Mark Lane, CET mailto:mark at harddata.com 
Hard Data Ltd. http://www.harddata.com 
T: 01-780-456-9771   F: 01-780-456-9772
11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3
--> Ask me about our Excellent 1U Systems! <--




From cpedersen at c-note.dk  Tue May  4 19:20:55 2004
From: cpedersen at c-note.dk (Casper Pedersen)
Date: Tue, 04 May 2004 21:20:55 +0200
Subject: FC2-Test3 Xorg problems
In-Reply-To: <200405041306.51731.mark@harddata.com>
References: <1083696381.28827.6.camel@tuxdsk.c-note.dk>
	<200405041306.51731.mark@harddata.com>
Message-ID: <1083698455.28827.27.camel@tuxdsk.c-note.dk>

Actually, the installation left the infomation there it was just
remarked out.

I'll file a bug against it.

Regards/Casper


On Tue, 2004-05-04 at 21:06, Mark Lane wrote:
> On May 4, 2004 12:46 pm, Casper Pedersen <cpedersen at c-note.dk> wrote:
> > Hi,
> >
> > It looks like there is a problem with firstboot/Xorg. I have a Sony E200
> > monitor which is DCC compliant (I think), but after firstboot I'm only
> > able to set it to 640x480 or 800x600 - Not 1280x1024..
> >
> > In /etc/X11/xorg.conf the following lines where remarked out:
> >
> >        HorizSync    30.0 - 85.0
> >        VertRefresh  48.0 - 120.0
> >
> > After enabling them again, I was able to get 1280x1024.
> >
> > Is this a bug?
> 
> We have noticed a problem with dpms trying to auto determine the Sync and 
> Refresh. You definitely need to hard code it in and the install doesn't do 
> that.
> 
> regards,
> 
> -- 
> Mark Lane, CET mailto:mark at harddata.com 
> Hard Data Ltd. http://www.harddata.com
> T: 01-780-456-9771   F: 01-780-456-9772
> 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3
> --> Ask me about our Excellent 1U Systems! <--
-- 
GPG Public key is available from: http://www.keyserver.net/
Fingerprint = 56ED 74A4 7B00 20E2 B493 0C1A 6B4E BF8F A086 FE57

-------------- 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/20040504/d1be4e9f/attachment.sig>

From rgorosito at comarb.gov.ar  Tue May  4 19:27:53 2004
From: rgorosito at comarb.gov.ar (Ricardo Gorosito)
Date: Tue, 04 May 2004 16:27:53 -0300
Subject: FC2-Test3 Xorg problems
In-Reply-To: <1083696381.28827.6.camel@tuxdsk.c-note.dk>
References: <1083696381.28827.6.camel@tuxdsk.c-note.dk>
Message-ID: <4097EEB9.5090707@comarb.gov.ar>

I has ACER View 34T (not DCC compliant) and have the same problem. 
Solved enabling remarked lines.
I was selected my monitor during install. I don't know if it is a bug in 
anaconda, system-config-display or firstboot

Ricardo.-

Casper Pedersen wrote:

>Hi,
>
>It looks like there is a problem with firstboot/Xorg. I have a Sony E200
>monitor which is DCC compliant (I think), but after firstboot I'm only
>able to set it to 640x480 or 800x600 - Not 1280x1024..
>
>In /etc/X11/xorg.conf the following lines where remarked out:
>
>       HorizSync    30.0 - 85.0
>       VertRefresh  48.0 - 120.0
>
>After enabling them again, I was able to get 1280x1024.
>
>Is this a bug?
>
>Regards/Casper 
>
>
>  
>




From fkooman at bromstraat.net  Tue May  4 19:32:25 2004
From: fkooman at bromstraat.net (F. Kooman)
Date: Tue, 04 May 2004 21:32:25 +0200
Subject: FC2-Test3 Xorg problems
In-Reply-To: <1083696381.28827.6.camel@tuxdsk.c-note.dk>
References: <1083696381.28827.6.camel@tuxdsk.c-note.dk>
Message-ID: <1083699144.3281.5.camel@localhost.localdomain>

Op di 04-05-2004, om 20:46 schreef Casper Pedersen:
> Is this a bug?


#121717
#120950

Gr,
Fran?ois






From ndbecker2 at verizon.net  Tue May  4 19:36:14 2004
From: ndbecker2 at verizon.net (Neal Becker)
Date: Tue, 4 May 2004 15:36:14 -0400
Subject: FC2-Test3 Xorg problems
In-Reply-To: <4097EEB9.5090707@comarb.gov.ar>
References: <1083696381.28827.6.camel@tuxdsk.c-note.dk>
	<4097EEB9.5090707@comarb.gov.ar>
Message-ID: <200405041536.14776.ndbecker2@verizon.net>

On Tuesday 04 May 2004 03:27 pm, Ricardo Gorosito wrote:
> I has ACER View 34T (not DCC compliant) and have the same problem.
> Solved enabling remarked lines.
> I was selected my monitor during install. I don't know if it is a bug in
> anaconda, system-config-display or firstboot
>
> Ricardo.-
>
> Casper Pedersen wrote:
> >Hi,
> >
> >It looks like there is a problem with firstboot/Xorg. I have a Sony E200
> >monitor which is DCC compliant (I think), but after firstboot I'm only
> >able to set it to 640x480 or 800x600 - Not 1280x1024..
> >
> >In /etc/X11/xorg.conf the following lines where remarked out:
> >
> >       HorizSync    30.0 - 85.0
> >       VertRefresh  48.0 - 120.0
> >
> >After enabling them again, I was able to get 1280x1024.
> >
> >Is this a bug?
> >

Same problem here with viewsonic p95f+ / GeForce FX 5900XT rev 161.

Must fix before release.




From markmc at redhat.com  Tue May  4 19:59:53 2004
From: markmc at redhat.com (Mark McLoughlin)
Date: Tue, 04 May 2004 20:59:53 +0100
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <20040504185257.GA15467@devserv.devel.redhat.com>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
	<1083695929.20962.33.camel@laptop>
	<20040504185257.GA15467@devserv.devel.redhat.com>
Message-ID: <1083700792.20962.39.camel@laptop>

On Tue, 2004-05-04 at 19:52, Alan Cox wrote:
> On Tue, May 04, 2004 at 07:38:50PM +0100, Mark McLoughlin wrote:
> > > Any reason for not just pushing 2.6.1 at some point ?
> > 
> > 	Look back over the thread :-)
> > 
> > http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00090.html
> > 
> > 	Basically, mass-updating to GNOME 2.6.1 at this point doesn't strike me
> > as a particularly good exercise in in risk management, no matter how
> > confident I am in GNOME's release process ...
> 
> 
> Sorry - I didnt mean for the FC2 release I meant some time after when they
> have wandered through testing 

	Yeah, I was mainly referring to post release too, although you could
probably figure out something whereby the mass-update gets a lot of
QA-ing before being pushed.

	I'd be all for it, but it would be a rather large amount of work given
the number packages involved and the relative little gain for doing it.
I guess its something that people could easily help out with so once we
have an external CVS we could certainly try and figure it out.

Cheers,
Mark.




From jspaleta at gmail.com  Tue May  4 20:12:56 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 4 May 2004 16:12:56 -0400
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083700792.20962.39.camel@laptop>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
	<1083695929.20962.33.camel@laptop>
	<20040504185257.GA15467@devserv.devel.redhat.com>
	<1083700792.20962.39.camel@laptop>
Message-ID: <31EF65B9.596D533C@mail.gmail.com>

On Tue, 04 May 2004 20:59:53 +0100, Mark McLoughlin <markmc at redhat.com> wrote:
>         Yeah, I was mainly referring to post release too, although you could
> probably figure out something whereby the mass-update gets a lot of
> QA-ing before being pushed.
> 
>         I'd be all for it, but it would be a rather large amount of work given
> the number packages involved and the relative little gain for doing it.
> I guess its something that people could easily help out with so once we
> have an external CVS we could certainly try and figure it out.


>From the sounds of things, this is an example of  something that
would fit into the scope of Fedora Alternatives and certainly not Fedora Extras.

http://fedora.redhat.com/participate/terminology.html

Which frankly, FA is very undefined and frought with inherent dangers
that Fedora Extras, being a place for addons, mostly doesn't have to
worry about. Issues like how to upgrade to a new FC release becomes
much much more complicated once FA walks out of the vapor. And I
haven't seen any noteworthy discussion how to keep FA sane and
consistent. There's no reason to think that their couldn't be 17
different versions of the same package, all with different compile
time options, sitting in FA for people to grab, can the update repo
tools handle that? I'm even sure anyone's mental canons have swung
around to even think about what Fedora Alternatives is actually going
to look like yet.

-jef




From wtogami at redhat.com  Tue May  4 20:17:13 2004
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 04 May 2004 10:17:13 -1000
Subject: gaim x86-64 broken protocols
In-Reply-To: <20040504171041.A31508@nsk.no-ip.org>
References: <40956738.5070506@redhat.com>
	<409726D3.1010101@redhat.com>	<40975CBC.4070803@redhat.com>
	<20040504171041.A31508@nsk.no-ip.org>
Message-ID: <4097FA49.7070300@redhat.com>

Luciano Miguel Ferreira Rocha wrote:
> On Mon, May 03, 2004 at 11:05:00PM -1000, Warren Togami wrote:
> 
>>Woo!  marv and grim in #gaim found the problem in the src/sha.* 
>>implementation of the sha1 digest algorithm.
>>
>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122221
>>http://people.redhat.com/wtogami/temp/
>>
>>Please test the gaim-0.77-4 builds here, which should fix yahoo
>>authentication on x86-64.  Please test it for an extended period of
>>time on i386 and ppc too to make sure we did not break anything by
>>accident.
>>
>>Warren Togami
>>wtogami at redhat.com
> 
> 
> That version still has a bug in the irc module (not related to x86-64,
> occurs in every arch).
> 
> For more informations, bug #947794 @ gaim.sf.net, #114870 on
> bugzilla.redhat.com.
> 

http://people.redhat.com/wtogami/temp/

Please test this on i386, x86-64 and ppc FC2.  Patched x86-64 and your 
IRC reconnnect fix, also changed the default profile a bit.

Warren Togami
wtogami at redhat.com




From kewley at cns.caltech.edu  Tue May  4 20:19:13 2004
From: kewley at cns.caltech.edu (David Kewley)
Date: Tue, 4 May 2004 13:19:13 -0700
Subject: rawhide report: 20040504 changes
In-Reply-To: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
References: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
Message-ID: <200405041319.13662.kewley@cns.caltech.edu>

Build System wrote on Tuesday 04 May 2004 09:49:
> kernel-2.6.5-1.349
> ------------------
> * Tue Apr 20 2004 Arjan van de Ven <arjanv at redhat.com>
> 
> - add the ext3 online resize patch

I take it this is stable?  I'd been considering XFS or JFS for a new 
fileserver mostly for online resize capability down the road.  But if ext3 
can do it stably already, that makes ext3 a strong contender too (it's the 
only journaling fs I've used up to now).

David




From makgab at freemail.hu  Tue May  4 20:36:19 2004
From: makgab at freemail.hu (MG)
Date: Tue, 04 May 2004 22:36:19 +0200
Subject: Quanta cpu usage in FC1...
Message-ID: <4097FEC3.1070605@freemail.hu>


Hi!

I use the Fedora Core 1.
The quanta cpu usage is 100% and I cannot use it this time. :(
Why sould I do with quanta?

Bye!
G.








From arjanv at redhat.com  Tue May  4 20:38:50 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Tue, 04 May 2004 22:38:50 +0200
Subject: rawhide report: 20040504 changes
In-Reply-To: <200405041319.13662.kewley@cns.caltech.edu>
References: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
	<200405041319.13662.kewley@cns.caltech.edu>
Message-ID: <1083703130.3844.8.camel@laptop.fenrus.com>

On Tue, 2004-05-04 at 22:19, David Kewley wrote:
> Build System wrote on Tuesday 04 May 2004 09:49:
> > kernel-2.6.5-1.349
> > ------------------
> > * Tue Apr 20 2004 Arjan van de Ven <arjanv at redhat.com>
> > 
> > - add the ext3 online resize patch
> 
> I take it this is stable?  I'd been considering XFS or JFS for a new 
> fileserver mostly for online resize capability down the road.  But if ext3 
> can do it stably already, that makes ext3 a strong contender too (it's the 
> only journaling fs I've used up to now).

the kernel side is, the fsck side is just about there
(meaning that if you get a power outage during the short window of
growing it might confuse a bit afaik)
-------------- 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/20040504/98adbe98/attachment.sig>

From feliciano.matias at free.fr  Tue May  4 21:04:39 2004
From: feliciano.matias at free.fr (Matias Feliciano)
Date: Tue, 04 May 2004 23:04:39 +0200
Subject: fedora core 3 goals.
In-Reply-To: <4096E4F6.1030904@linux.duke.edu>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<Pine.LNX.4.58.0405031846460.2478@alien.devel.redhat.com>
	<1083625839.1720.10.camel@scrappy.netlyncs.com>
	<4096E4F6.1030904@linux.duke.edu>
Message-ID: <1083704657.960.89.camel@localhost.localdomain>

Le mar 04/05/2004 ? 02:33, Konstantin Ryabitsev a ?crit :
[snip]

http://lwn.net/Articles/83360/




From smoogen at lanl.gov  Tue May  4 21:21:11 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Tue, 04 May 2004 15:21:11 -0600
Subject: fedora core 3 goals.
In-Reply-To: <1083627120.25635.10.camel@binkley>
References: <1083477944.3244.8.camel@binkley> <4096428F.4050603@redhat.com>
	<1083593509.22400.2.camel@binkley>
	<20040503142930.GA1556@devserv.devel.redhat.com>
	<1083594789.22400.6.camel@binkley>
	<1083598340.10985.57.camel@smoogen3.lanl.gov>
	<1083627120.25635.10.camel@binkley>
Message-ID: <1083705668.13625.24.camel@smoogen3.lanl.gov>

On Mon, 2004-05-03 at 17:32, seth vidal wrote:
> > Ok for your benefit I will give you the logs of a day at Red Hat. Just
> > change the dates, and some of the names, and it should fill in for
> > Fedora.
> 
> I wanted to fill you in on my average day, too. Just to make sure we're
> on a similar page.
> 

Sorry I was trying to get some humour into a black day all about. I am
as frustrated as others outside of RH about the lack of visual
progress... but hope to smile through it because there isnt much else I
can do until we either switch all to windows or the various internal RH
crap gets dealt with.


-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From wtogami at redhat.com  Tue May  4 21:41:02 2004
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 04 May 2004 11:41:02 -1000
Subject: Help Needed: Readahead Optimization Data
Message-ID: <40980DEE.30901@redhat.com>

We need your help in order to collect data for readahead service 
optimization.  Services readahead_early and readahead read files on a 
list into buffer memory in the background during system startup.  By 
optimizing both lists, we can make system bootup time faster and more 
efficient, with the goal of reaching the gdm login screen in the least 
amount of time.

We have provided a modified kernel below, and Markus Lidel has developed 
a simple tool and database to collect readahead statistical information. 
  We need a wide variety of data from different FC2 latest installations 
of desktop, workstation, and server profiles.  We also need data from 
both i686 and x86-64 users, as lib64 requires its own readahead lists 
due to different file locations.

Data collected in Markus' database will be used on Thursday to compile 
the readahead lists that will ship in FC2.

Readahead Data Submission Procedure
===================================
NOTE:
YOU MUST BE RUNNING FC2 LATEST.

1) Install this test kernel.
http://people.redhat.com/wtogami/temp/readahead/
Installing this kernel disables readahead and readahead_early services. 
It is IMPORTANT that these services are disabled during your readahead 
test boot or results will be wildly inaccurate.
You can be sure they are disabled with:
chkconfig readahead off
chkconfig readahead_early off

2) boot like you would normally, but don't touch the computer for 3 minutes.

3) Run this tool. http://www.shadowconnect.com/redhat/readahead/import.pl

4) Uninstall test kernel.
This step automatically enables both readahead and readahead_early services.

For Optional Offline Operation
------------------------------
If your FC2 latest + test kernel machine does not have an Internet 
connection, obtain a dmesg.txt file with the following command:

dmesg -s 524288 > dmesg.txt

Then transfer dmesg.txt to another computer with Internet.  With the 
dmesg.txt in the current directory, run the perl script.  The dmesg.txt 
will be transfered to the server.

Special thanks to Markus Lidel for working all day on preparing this 
easy data collection mechanism.

Warren Togami
wtogami at redhat.com




From aoliva at redhat.com  Wed May  5 04:24:00 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 05 May 2004 01:24:00 -0300
Subject: Module ohci1394 not found
In-Reply-To: <40977210.7010604@f2s.com>
References: <1083185485.2241.3.camel@localhost.localdomain>
	<1083186496.5085.85.camel@roadrash.rdu.redhat.com>
	<orn04rk03u.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1083596053.4603.4.camel@dhollis-lnx.kpmg.com>
	<40977210.7010604@f2s.com>
Message-ID: <orr7tzcxi7.fsf@livre.redhat.lsd.ic.unicamp.br>

On May  4, 2004, Ismael Juma <ijuma82 at f2s.com> wrote:

> I have been using vanilla 2.6.6-rc3 with firewire enabled and I have
> had no problems whatsoever.

I have tested the linux1394 SVN tree regularly with my LVM on RAID1 on
two external Firewire Maxtor hard drives, and every now and then I get
the whole firewire subsystem to die under high load.  Last I tried was
-r1206, which appears to still be the latest.  Problem is still the
same as the one I last (?) re-reported to the linux1394-devel list
about a month ago.  Unfortunately the archives at sf.net seem to only
go up to Apr 3 (?!?), so here's a link to an earlier version of the
same report:
http://sourceforge.net/mailarchive/message.php?msg_id=7605681

FWIW, some people have run into the problem with a single disk,
without LVM or RAID, so it's not that.  It's just more difficult to
trigger the problem then.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From hp at redhat.com  Wed May  5 04:46:27 2004
From: hp at redhat.com (Havoc Pennington)
Date: Wed, 05 May 2004 00:46:27 -0400
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083695929.20962.33.camel@laptop>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
	<1083695929.20962.33.camel@laptop>
Message-ID: <1083732387.2257.24.camel@localhost.localdomain>

On Tue, 2004-05-04 at 14:38, Mark McLoughlin wrote:
> Hey,
> 
> On Tue, 2004-05-04 at 19:20, Alan Cox wrote:
> > On Tue, May 04, 2004 at 03:13:39PM +0100, Mark McLoughlin wrote:
> > > thing to do. But if we were to do that I'd like to have translation
> > > teams for each language be responsible for that work.
> > > 
> > > 	Just another item to put on the TODO list for when we have an external
> > > CVS ...
> > 
> > Any reason for not just pushing 2.6.1 at some point ?
> 
> 	Look back over the thread :-)
> 
> http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00090.html
> 
> 	Basically, mass-updating to GNOME 2.6.1 at this point doesn't strike me
> as a particularly good exercise in in risk management, no matter how
> confident I am in GNOME's release process ...
> 

I think 2.6.1 would be fine post-FC2-release, just put it in staging
area for a bit and use it ourselves and if nothing horrible happens push
it out as an update. Probably not a good idea during the freeze though.
Basically, push 2.6.1 into Fedora when Fedora is in the same state that
GNOME was in when GNOME pushed 2.6.1 in GNOME.

I saw someone mention that we may have some packages that aren't up to
2.6.0 though (epiphany perhaps?), we should be sure to fix those by
Friday probably if there are any. Don't want to ship betas.

Havoc






From barryn at pobox.com  Wed May  5 05:20:14 2004
From: barryn at pobox.com (Barry K. Nathan)
Date: Tue, 4 May 2004 22:20:14 -0700
Subject: rawhide report: 20040504 changes
In-Reply-To: <1083690038.3844.6.camel@laptop.fenrus.com>
References: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
	<1083690038.3844.6.camel@laptop.fenrus.com>
Message-ID: <20040505052014.GC4353@ip68-4-98-123.oc.oc.cox.net>

On Tue, May 04, 2004 at 07:00:38PM +0200, Arjan van de Ven wrote:
> On Tue, 2004-05-04 at 18:49, Build System wrote:
> 
> > kernel-2.6.5-1.349
> > ------------------
> 
> I would like to ask everyone on this list to please test this kernel
> hard; it has quite a few bugfixes but there always is the risk of
> regressions; time to release is running out so please test!

I'll try to test it on FC devel later tonight. In the meantime, I've
tested 2.6.5-1.349 on RHEL 3WS and it works *very* well.

(I realize that's an unsupported configuration, but 2.6.5-1.34x works far
better on my test laptop than any 2.4 kernel, since it has working ACPI
and sound. ACPI in turn gives me LCD brightness control, battery meter,
SpeedStep, and tons of other stuff. 2.6.5-1.349 turns RHEL from a shiny
toy into something useful for production.)

BTW, recently I accidentally (long story...) found out on a production
box that 2.6.5-1.32x is *vastly* more stable on heavy NFS workloads than
2.4.22-1.2188.nptl. I haven't tested with a newer 2.6.5 kernel because,
as I said, it's a production box (right now it's running a 2.4.21-9.0.3.TL
(Tao Linux) kernel, which seems about as stable as 2.6.5-1.32x so far).

-Barry K. Nathan <barryn at pobox.com>




From wtogami at redhat.com  Wed May  5 05:21:59 2004
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 04 May 2004 19:21:59 -1000
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083732387.2257.24.camel@localhost.localdomain>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>	<1083369058.3978.56.camel@localhost.localdomain>	<1083625394.5813.6.camel@laptop>	<200405041024.35271.pmmm@rnl.ist.utl.pt>	<1083680018.5813.19.camel@laptop>	<20040504182028.GC15185@devserv.devel.redhat.com>	<1083695929.20962.33.camel@laptop>
	<1083732387.2257.24.camel@localhost.localdomain>
Message-ID: <409879F7.9010403@redhat.com>

Havoc Pennington wrote:
> I think 2.6.1 would be fine post-FC2-release, just put it in staging
> area for a bit and use it ourselves and if nothing horrible happens push
> it out as an update. Probably not a good idea during the freeze though.
> Basically, push 2.6.1 into Fedora when Fedora is in the same state that
> GNOME was in when GNOME pushed 2.6.1 in GNOME.
> 
> I saw someone mention that we may have some packages that aren't up to
> 2.6.0 though (epiphany perhaps?), we should be sure to fix those by
> Friday probably if there are any. Don't want to ship betas.
> 
> Havoc

Rawhide: epiphany-1.1.12-0

http://www.gnome.org/projects/epiphany/
Latest Stable: epiphany-1.2.4

If there are no objections I will go ahead and upgrade this probably 
tonight.  I wanted to modify epiphany slightly along with redhat-menus, 
htmlview and mozilla for the final Preferred Application behavior fix 
for FC2.

Ok?

Warren Togami
wtogami at redhat.com




From Axel.Thimm at ATrpms.net  Wed May  5 05:47:59 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 5 May 2004 07:47:59 +0200
Subject: _initrddir typo (was: rawhide report: 20040504 changes)
In-Reply-To: <20040504190438.33960a6c@localhost>
References: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
	<20040504190438.33960a6c@localhost>
Message-ID: <20040505054759.GA32592@neu.nirvana>

On Tue, May 04, 2004 at 07:04:38PM +0200, Matthias Saou wrote:
> Build System wrote :
> 
> > - Use %{_mandir} and %{_initrddir}.
> 
> Once again, as I never got any answers nor comments about this one :
> Why is it _initrddir for /etc/rc.d/init.d??? It has nothing to do with the
> initial ramdisk, which is (AFAIK) _the_ initrd.
> Is it a typo of the person who introduced that macro into rpm, or...?

It can only be a typo, the question is what should be do, continue
using the wrongly typed macro or introduce something new in parallel
(_initdir or _rcinitdir for instance), and have the old one being
deprecated?

I'd like the latter to happen, but since this is a cosmetic buglet and
only seen by people under the hood it will be considered low priority
by whoever would decide this.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040505/dc738d04/attachment.sig>

From rms at 1407.org  Wed May  5 08:32:01 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Wed, 05 May 2004 09:32:01 +0100
Subject: Linux 2.6.5-1.349 ignores selinux=0
In-Reply-To: <200405011131.i41BViM14349@porkchop.devel.redhat.com>
References: <200405011131.i41BViM14349@porkchop.devel.redhat.com>
Message-ID: <1083745921.1173.1.camel@roque>

I had to revert to 327 since 349 ignores selinux=0

I didn't try to add enforcing=0...

Rui
-------------- 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/20040505/f964c5dd/attachment.sig>

From dennis at ausil.us  Wed May  5 09:12:34 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Wed, 5 May 2004 19:12:34 +1000
Subject: Linux 2.6.5-1.349 ignores selinux=0
In-Reply-To: <1083745921.1173.1.camel@roque>
References: <200405011131.i41BViM14349@porkchop.devel.redhat.com>
	<1083745921.1173.1.camel@roque>
Message-ID: <200405051912.34727.dennis@ausil.us>

Once upon a time Wednesday 05 May 2004 6:32 pm, Rui Miguel Seabra wrote:
> I had to revert to 327 since 349 ignores selinux=0
>
> I didn't try to add enforcing=0...
>
> Rui
I fixed this for me by changing /etc/sysconfig/selinux to selinux=disabled it 
seems that in the mix there somewhere the kernel decided to ignore the 
selinux=0  if /etc/sysconfig/selinux  had enforcing  in

Dennis




From rms at 1407.org  Wed May  5 09:54:46 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Wed, 05 May 2004 10:54:46 +0100
Subject: Linux 2.6.5-1.349 ignores selinux=0
In-Reply-To: <200405051912.34727.dennis@ausil.us>
References: <200405011131.i41BViM14349@porkchop.devel.redhat.com>
	<1083745921.1173.1.camel@roque>  <200405051912.34727.dennis@ausil.us>
Message-ID: <1083750885.2546.5.camel@roque>

On Wed, 2004-05-05 at 19:12 +1000, Dennis Gilmore wrote:
> Once upon a time Wednesday 05 May 2004 6:32 pm, Rui Miguel Seabra wrote:
> > I had to revert to 327 since 349 ignores selinux=0
> >
> > I didn't try to add enforcing=0...
>
> I fixed this for me by changing /etc/sysconfig/selinux to selinux=disabled it 
> seems that in the mix there somewhere the kernel decided to ignore the 
> selinux=0  if /etc/sysconfig/selinux  had enforcing  in

That solved it. Thanks.

Rui
-------------- 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/20040505/d2b037ec/attachment.sig>

From mr700 at globalnet.bg  Wed May  5 10:46:25 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Wed, 5 May 2004 13:46:25 +0300
Subject: FC1/FC2 nedit and nc (netcat) conflict
Message-ID: <200405051346.25964@-mr700>

    I have two 'nc's with FC1 and FC2t3. Here's the rpm output:
<cut>
[pts/1:mr700 at fedora:~]# rpm -qf /usr/X11R6/bin/nc /usr/bin/nc
nedit-5.3-5
nc-1.10-19
</cut>
    This is a problem, at least for me. It was very surprising to type
'nc host port' and see:
<cut>
No servers available, start one (yes)?
</cut>
    Maybe /usr/bin/nc should be renamed to netcat or /usr/X11R6/bin/nc
should be renamed to neditc?

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79




From P at draigBrady.com  Wed May  5 11:53:04 2004
From: P at draigBrady.com (P at draigBrady.com)
Date: Wed, 05 May 2004 12:53:04 +0100
Subject: FC1/FC2 nedit and nc (netcat) conflict
In-Reply-To: <200405051346.25964@-mr700>
References: <200405051346.25964@-mr700>
Message-ID: <4098D5A0.1020608@draigBrady.com>

Doncho N. Gunchev wrote:
>     I have two 'nc's with FC1 and FC2t3. Here's the rpm output:
> <cut>
> [pts/1:mr700 at fedora:~]# rpm -qf /usr/X11R6/bin/nc /usr/bin/nc
> nedit-5.3-5
> nc-1.10-19
> </cut>
>     This is a problem, at least for me. It was very surprising to type
> 'nc host port' and see:
> <cut>
> No servers available, start one (yes)?
> </cut>
>     Maybe /usr/bin/nc should be renamed to netcat or /usr/X11R6/bin/nc
> should be renamed to neditc?

It's not the only one. Using fslint: http://www.pixelbeat.org/fslint
shows 2 more clashes like that:

/usr/bin/ex -> vim
/bin/ex -> vi
 

/usr/bin/kill
/bin/kill
 

/usr/X11R6/bin/nc
/usr/bin/nc

P?draig.




From s.mako at gmx.net  Wed May  5 12:45:18 2004
From: s.mako at gmx.net (Zoltan Kota)
Date: Wed, 5 May 2004 14:45:18 +0200 (CEST)
Subject: yum feature?!
Message-ID: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>

Hi,

It would be nice if yum indicated somehow during the
downloading/installation process, which repository the package
comes from (e.g. Fedora Core 1 - Base).
Using different repos like Base, updates, fedora.us extras... one could
see the origin of the package.

Zoltan




From skvidal at phy.duke.edu  Wed May  5 12:51:35 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 05 May 2004 08:51:35 -0400
Subject: yum feature?!
In-Reply-To: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
Message-ID: <1083761495.32622.0.camel@binkley>

On Wed, 2004-05-05 at 14:45 +0200, Zoltan Kota wrote:
> Hi,
> 
> It would be nice if yum indicated somehow during the
> downloading/installation process, which repository the package
> comes from (e.g. Fedora Core 1 - Base).
> Using different repos like Base, updates, fedora.us extras... one could
> see the origin of the package.

sounds reasonable.

-sv





From Nicolas.Mailhot at laPoste.net  Wed May  5 12:51:32 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 05 May 2004 14:51:32 +0200
Subject: yum feature?!
In-Reply-To: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
Message-ID: <1083761492.16132.1.camel@ulysse.olympe.o2t>

Le mer, 05/05/2004 ? 14:45 +0200, Zoltan Kota a ?crit :
> Hi,
> 
> It would be nice if yum indicated somehow during the
> downloading/installation process, which repository the package
> comes from (e.g. Fedora Core 1 - Base).
> Using different repos like Base, updates, fedora.us extras... one could
> see the origin of the package.

And what url it's pulling the file from...

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

From skvidal at phy.duke.edu  Wed May  5 12:53:57 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 05 May 2004 08:53:57 -0400
Subject: yum feature?!
In-Reply-To: <1083761492.16132.1.camel@ulysse.olympe.o2t>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
Message-ID: <1083761636.32622.2.camel@binkley>

On Wed, 2004-05-05 at 14:51 +0200, Nicolas Mailhot wrote:
> Le mer, 05/05/2004 ? 14:45 +0200, Zoltan Kota a ?crit :
> > Hi,
> > 
> > It would be nice if yum indicated somehow during the
> > downloading/installation process, which repository the package
> > comes from (e.g. Fedora Core 1 - Base).
> > Using different repos like Base, updates, fedora.us extras... one could
> > see the origin of the package.
> 
> And what url it's pulling the file from...
> 

we're getting a bit busy on the screen now, aren't we?

that's a lot of content to display. It'd become a scrollfest.

the url is visible in the higher debug modes anyway if you need it.

-sv





From Nicolas.Mailhot at laPoste.net  Wed May  5 13:07:19 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 05 May 2004 15:07:19 +0200
Subject: yum feature?!
In-Reply-To: <1083761636.32622.2.camel@binkley>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
	<1083761636.32622.2.camel@binkley>
Message-ID: <1083762439.16132.5.camel@ulysse.olympe.o2t>

Le mer, 05/05/2004 ? 08:53 -0400, seth vidal a ?crit :
> On Wed, 2004-05-05 at 14:51 +0200, Nicolas Mailhot wrote:
> > Le mer, 05/05/2004 ? 14:45 +0200, Zoltan Kota a ?crit :
> > > Hi,
> > > 
> > > It would be nice if yum indicated somehow during the
> > > downloading/installation process, which repository the package
> > > comes from (e.g. Fedora Core 1 - Base).
> > > Using different repos like Base, updates, fedora.us extras... one could
> > > see the origin of the package.
> > 
> > And what url it's pulling the file from...
> > 
> 
> we're getting a bit busy on the screen now, aren't we?
> 
> that's a lot of content to display. It'd become a scrollfest.

Well, apt does it and it's invaluable to detect mirrors which suddenly
stop working as fast as they used to.

Cheers,

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

From skvidal at phy.duke.edu  Wed May  5 13:12:56 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 05 May 2004 09:12:56 -0400
Subject: yum feature?!
In-Reply-To: <1083762439.16132.5.camel@ulysse.olympe.o2t>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
	<1083761636.32622.2.camel@binkley>
	<1083762439.16132.5.camel@ulysse.olympe.o2t>
Message-ID: <1083762775.32622.4.camel@binkley>


> Well, apt does it and it's invaluable to detect mirrors which suddenly
> stop working as fast as they used to.
> 

and I've always considered apt's output to be daunting to a new user.

-sv






From NOS at Utel.no  Wed May  5 13:20:32 2004
From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=)
Date: Wed, 05 May 2004 15:20:32 +0200
Subject: yum feature?!
In-Reply-To: <000801c432a3$16ab0020$14aaa8c0@utelsystems.local>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
	<1083761636.32622.2.camel@binkley>
	<1083762439.16132.5.camel@ulysse.olympe.o2t>
	<000801c432a3$16ab0020$14aaa8c0@utelsystems.local>
Message-ID: <1083763232.3658.1.camel@nos-rh.utelsystems.local>

On Wed, 2004-05-05 at 15:15, seth vidal wrote:
> > Well, apt does it and it's invaluable to detect mirrors which suddenly
> > stop working as fast as they used to.
> > 
> 
> and I've always considered apt's output to be daunting to a new user.
New users should never have to use apt  imho;) There should be a
GUI for this sort of thing, where it's perhaps a bit easier/cleaner
to display status info.





From jspaleta at gmail.com  Wed May  5 13:34:42 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 5 May 2004 09:34:42 -0400
Subject: yum feature?!
In-Reply-To: <1083762439.16132.5.camel@ulysse.olympe.o2t>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
	<1083761636.32622.2.camel@binkley>
	<1083762439.16132.5.camel@ulysse.olympe.o2t>
Message-ID: <35152F8D.7FD13683@mail.gmail.com>

On Wed, 05 May 2004 15:07:19 +0200, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> Well, apt does it and it's invaluable to detect mirrors which suddenly
> stop working as fast as they used to.

Let me suggest that saying application X does something as a reason to get
that feature implemented in application Y isn't how you go about negotiating
with a developer for a feature for application Y.  You need to address
the concern raised by the developer directly. In this case, the
concern was having so much information being scrolling by that its too
busy. You haven't addressed that concern.  All you have said here is
why you think this specific piece of information is important enough
to give it screen real-estate, you haven't address the concern that
perhaps there isn't enough real-estate to go around.

-jef




From Nicolas.Mailhot at laPoste.net  Wed May  5 13:51:05 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 05 May 2004 15:51:05 +0200
Subject: yum feature?!
In-Reply-To: <35152F8D.7FD13683@mail.gmail.com>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
	<1083761636.32622.2.camel@binkley>
	<1083762439.16132.5.camel@ulysse.olympe.o2t>
	<35152F8D.7FD13683@mail.gmail.com>
Message-ID: <1083765065.16506.11.camel@ulysse.olympe.o2t>

Le mer, 05/05/2004 ? 09:34 -0400, Jeff Spaleta a ?crit :
> On Wed, 05 May 2004 15:07:19 +0200, Nicolas Mailhot
> <nicolas.mailhot at laposte.net> wrote:
> > Well, apt does it and it's invaluable to detect mirrors which suddenly
> > stop working as fast as they used to.
> 
> Let me suggest that saying application X does something as a reason to get
> that feature implemented in application Y isn't how you go about negotiating
> with a developer for a feature for application Y.  

Well, I'm not asking to slavishly copy apt. I'm asking to add a feature
that I've found to be very useful when using apt. I'm sure Seth is smart
enough one can use the a* word without ending in /dev/null

> You need to address
> the concern raised by the developer directly. In this case, the
> concern was having so much information being scrolling by that its too
> busy.

I'm afraid even on a local network downloads are not so fast it's
scrolling madly. On a normal broadband link there is not much in yum to
show things are actually progressing and not stuck on a mirror.

Granted, some people might prefer a lighter reporting. But surely
putting this kind of info in debug is a bit of overkill, don't you
think ?

More than cryptic messages users hate stuff that seems stuck doing
nothing. All the daunting apt reporting at least shows magic is
currently happening. (and a lot of people do know how to interpret it
btw)

Cheers,

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

From brads at redhat.com  Wed May  5 11:18:29 2004
From: brads at redhat.com (Brad Smith)
Date: Wed, 05 May 2004 07:18:29 -0400
Subject: yum feature?!
In-Reply-To: <1083762775.32622.4.camel@binkley>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
	<1083761636.32622.2.camel@binkley>
	<1083762439.16132.5.camel@ulysse.olympe.o2t>
	<1083762775.32622.4.camel@binkley>
Message-ID: <1083755909.1521.1.camel@localhost.localdomain>

On Wed, 2004-05-05 at 09:12, seth vidal wrote:
> > Well, apt does it and it's invaluable to detect mirrors which suddenly
> > stop working as fast as they used to.
> > 
> 
> and I've always considered apt's output to be daunting to a new user.
> 
> -sv
> 
> 
> 

The traditional solution to a problem like that would be to include a
-v/--verbose option. Any reason not to do that?

--Brad




From brads at redhat.com  Wed May  5 11:19:23 2004
From: brads at redhat.com (Brad Smith)
Date: Wed, 05 May 2004 07:19:23 -0400
Subject: yum feature?!
In-Reply-To: <1083762775.32622.4.camel@binkley>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
	<1083761636.32622.2.camel@binkley>
	<1083762439.16132.5.camel@ulysse.olympe.o2t>
	<1083762775.32622.4.camel@binkley>
Message-ID: <1083755962.1521.3.camel@localhost.localdomain>

On Wed, 2004-05-05 at 09:12, seth vidal wrote:
> > Well, apt does it and it's invaluable to detect mirrors which suddenly
> > stop working as fast as they used to.
> > 
> 
> and I've always considered apt's output to be daunting to a new user.
> 
> -sv
> 
> 
> 

Sorry, just noticed that you already have a -d (debug) option. So same
suggestion, different option.

--Brad




From skvidal at phy.duke.edu  Wed May  5 14:20:11 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 05 May 2004 10:20:11 -0400
Subject: yum feature?!
In-Reply-To: <1083755962.1521.3.camel@localhost.localdomain>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
	<1083761636.32622.2.camel@binkley>
	<1083762439.16132.5.camel@ulysse.olympe.o2t>
	<1083762775.32622.4.camel@binkley>
	<1083755962.1521.3.camel@localhost.localdomain>
Message-ID: <1083766810.30445.15.camel@opus>


> Sorry, just noticed that you already have a -d (debug) option. So same
> suggestion, different option.
> 

Which is included

the debug levels
turn them up and you get more information.


-sv





From skvidal at phy.duke.edu  Wed May  5 14:21:44 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 05 May 2004 10:21:44 -0400
Subject: yum feature?!
In-Reply-To: <1083765065.16506.11.camel@ulysse.olympe.o2t>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
	<1083761636.32622.2.camel@binkley>
	<1083762439.16132.5.camel@ulysse.olympe.o2t>
	<35152F8D.7FD13683@mail.gmail.com>
	<1083765065.16506.11.camel@ulysse.olympe.o2t>
Message-ID: <1083766904.30445.18.camel@opus>


> Well, I'm not asking to slavishly copy apt. I'm asking to add a feature
> that I've found to be very useful when using apt. I'm sure Seth is smart
> enough one can use the a* word without ending in /dev/null

actually I have a mail filter - if any mail matches a* then it goes to 
/dev/null :) - fortunately that means I don't see much mail at all.
(whoops, I won't see this one either, I just said 'all') :)



> I'm afraid even on a local network downloads are not so fast it's
> scrolling madly. On a normal broadband link there is not much in yum to
> show things are actually progressing and not stuck on a mirror.

The progress bars on download aren't enough information? When a mirror
fails over it says it's executing the failover.

So I think there is some progress, but only when there's an error.


> Granted, some people might prefer a lighter reporting. But surely
> putting this kind of info in debug is a bit of overkill, don't you
> think ?

not really. The debug mode means the user can see the data that is more
beneficial to them.

> More than cryptic messages users hate stuff that seems stuck doing
> nothing. All the daunting apt reporting at least shows magic is
> currently happening. (and a lot of people do know how to interpret it
> btw)

I'm not sure when it is that yum gets stuck doing things and not
reporting any information. It might do this if you've set your
debuglevel below the default of 2 - but then that's the point of having
the lower debuglevels - their a quiet mode.

-sv






From dragoran at feuerpokemon.de  Wed May  5 14:36:10 2004
From: dragoran at feuerpokemon.de (dragoran)
Date: Wed, 05 May 2004 16:36:10 +0200
Subject: 3CDs instead of 4
Message-ID: <4098FBDA.5000306@feuerpokemon.de>

Is there any reason why there are 4 CDs for FC 2 ? It can be done in 3 
CDs (700MB Disk) .
This would save a disk and time for burning it.




From Nicolas.Mailhot at laPoste.net  Wed May  5 14:40:30 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 05 May 2004 16:40:30 +0200
Subject: yum feature?!
In-Reply-To: <1083766904.30445.18.camel@opus>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083761492.16132.1.camel@ulysse.olympe.o2t>
	<1083761636.32622.2.camel@binkley>
	<1083762439.16132.5.camel@ulysse.olympe.o2t>
	<35152F8D.7FD13683@mail.gmail.com>
	<1083765065.16506.11.camel@ulysse.olympe.o2t>
	<1083766904.30445.18.camel@opus>
Message-ID: <1083768030.16989.10.camel@ulysse.olympe.o2t>

Le mer, 05/05/2004 ? 10:21 -0400, seth vidal a ?crit :

> > I'm afraid even on a local network downloads are not so fast it's
> > scrolling madly. On a normal broadband link there is not much in yum to
> > show things are actually progressing and not stuck on a mirror.
> 
> The progress bars on download aren't enough information?

Well, with *big* rpms (openoffice.org comes to mind), no, it just takes
too long for the bar to change. A realtime download rate would help
there.

> When a mirror
> fails over it says it's executing the failover.

It's not always intuitive to correlate the slow download rate with the
fact a failover occurred 50 packages before - especially if yum is
running in a term one is only casually monitoring.

> > More than cryptic messages users hate stuff that seems stuck doing
> > nothing. All the daunting apt reporting at least shows magic is
> > currently happening. (and a lot of people do know how to interpret it
> > btw)
> 
> I'm not sure when it is that yum gets stuck doing things and not
> reporting any information.

It's not really stuck - it just has the appearance of being stuck, since
sometime nothing changes for a long time. Just like a stupid hourglass
cursor, having changing stuff gives the users the warm feeling something
is going on, even when the actual download rate is exactly the same as
if there were no reporting at all.

Cheers,

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

From jkeating at j2solutions.net  Wed May  5 15:01:33 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 5 May 2004 08:01:33 -0700
Subject: yum feature?!
In-Reply-To: <1083768030.16989.10.camel@ulysse.olympe.o2t>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083766904.30445.18.camel@opus>
	<1083768030.16989.10.camel@ulysse.olympe.o2t>
Message-ID: <200405050801.33465.jkeating@j2solutions.net>

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

On Wednesday 05 May 2004 07:40, Nicolas Mailhot wrote:
> Well, with *big* rpms (openoffice.org comes to mind), no, it just takes
> too long for the bar to change. A realtime download rate would help
> there.

Am I missing something here?  When yum is ran on the CLI, you get a REAL 
TIME download indicator for each header, and then again for each rpm it 
pulls down.  Once it's all pulled down, it quiets down a bit as it 
installs each rpm.  There isn't a hash line for the actual rpm 
installation (like there is w/ rpm -*vh) but thats already beyond the 
point of file downloads.

- -- 
Jesse Keating RHCE	(http://geek.j2solutions.net)
Fedora Legacy Team	(http://www.fedoralegacy.org)
GPG Public Key		(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAmQHN4v2HLvE71NURAiZMAKCR8pZ2WP6nm3VlEd7+f3ZGN3TuSwCfT2Qb
Cc6KO4Nzs08IZ29UFYgCQaY=
=eRGk
-----END PGP SIGNATURE-----




From Nicolas.Mailhot at laPoste.net  Wed May  5 15:14:51 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 05 May 2004 17:14:51 +0200
Subject: yum feature?!
In-Reply-To: <200405050801.33465.jkeating@j2solutions.net>
References: <Pine.LNX.4.44.0405051437520.275-100000@erna.mpibpc.gwdg.de>
	<1083766904.30445.18.camel@opus>
	<1083768030.16989.10.camel@ulysse.olympe.o2t>
	<200405050801.33465.jkeating@j2solutions.net>
Message-ID: <1083770091.17229.3.camel@ulysse.olympe.o2t>

Le mer, 05/05/2004 ? 08:01 -0700, Jesse Keating a ?crit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wednesday 05 May 2004 07:40, Nicolas Mailhot wrote:
> > Well, with *big* rpms (openoffice.org comes to mind), no, it just takes
> > too long for the bar to change. A realtime download rate would help
> > there.
> 
> Am I missing something here?  When yum is ran on the CLI, you get a REAL 
> TIME download indicator for each header, and then again for each rpm it 
> pulls down. 

It's not a rate, it's ETA + size + downloaded %

All of those won't move a lot for big downloads (or slow links, or both)
There is a reason why every app that downloads stuff also displays the
rate.

Cheers,

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

From dhollis at davehollis.com  Wed May  5 15:17:27 2004
From: dhollis at davehollis.com (David T Hollis)
Date: Wed, 05 May 2004 11:17:27 -0400
Subject: Linux 2.6.5-1.349 ignores selinux=0
In-Reply-To: <200405051912.34727.dennis@ausil.us>
References: <200405011131.i41BViM14349@porkchop.devel.redhat.com>
	<1083745921.1173.1.camel@roque>  <200405051912.34727.dennis@ausil.us>
Message-ID: <1083770247.3311.1.camel@dhollis-lnx.kpmg.com>

On Wed, 2004-05-05 at 19:12 +1000, Dennis Gilmore wrote:
> Once upon a time Wednesday 05 May 2004 6:32 pm, Rui Miguel Seabra wrote:
> > I had to revert to 327 since 349 ignores selinux=0
> >
> > I didn't try to add enforcing=0...
> >
> > Rui
> I fixed this for me by changing /etc/sysconfig/selinux to selinux=disabled it 
> seems that in the mix there somewhere the kernel decided to ignore the 
> selinux=0  if /etc/sysconfig/selinux  had enforcing  in
> 
> Dennis

Setting SELINUX=disabled in /etc/sysconfig/selinux worked for me as
well.  I didn't have an /etc/sysconfig/selinux file at all prior to
that.  It seems that the selinux parameter on the command line was
completely ignored.

-- 
David T Hollis <dhollis at davehollis.com>




From feliciano.matias at free.fr  Wed May  5 15:25:34 2004
From: feliciano.matias at free.fr (Matias Feliciano)
Date: Wed, 05 May 2004 17:25:34 +0200
Subject: 3CDs instead of 4
In-Reply-To: <4098FBDA.5000306@feuerpokemon.de>
References: <4098FBDA.5000306@feuerpokemon.de>
Message-ID: <1083770734.19442.17.camel@localhost.localdomain>

Le mer 05/05/2004 ? 16:36, dragoran a ?crit :
> Is there any reason why there are 4 CDs for FC 2 ? It can be done in 3 
> CDs (700MB Disk) .
> This would save a disk and time for burning it.
> 

-rw-rw-r--  2 fmatias fmatias 662472704 avr 21 17:23 FC2-test3-i386-disc1.iso
-rw-rw-r--  2 fmatias fmatias 668182528 avr 21 17:24 FC2-test3-i386-disc2.iso
-rw-rw-r--  2 fmatias fmatias 647518208 avr 21 17:26 FC2-test3-i386-disc3.iso
-rw-rw-r--  2 fmatias fmatias 240728064 avr 27 17:46 FC2-test3-i386-disc4.iso

$ bc
scale=3
(662472704+668182528+647518208+240728064)/(700*1024*1024)
3.023

No :-(




From nietzel at rhinobox.org  Wed May  5 15:27:53 2004
From: nietzel at rhinobox.org (Earle Robert Nietzel)
Date: Wed, 05 May 2004 17:27:53 +0200
Subject: FC2-Test3 Xorg problems
In-Reply-To: <200405041536.14776.ndbecker2@verizon.net>
References: <1083696381.28827.6.camel@tuxdsk.c-note.dk>
	<4097EEB9.5090707@comarb.gov.ar>
	<200405041536.14776.ndbecker2@verizon.net>
Message-ID: <1083770873.7628.1.camel@ws001.rhinobox.org>

On Tue, 2004-05-04 at 15:36 -0400, Neal Becker wrote:
> On Tuesday 04 May 2004 03:27 pm, Ricardo Gorosito wrote:
> > I has ACER View 34T (not DCC compliant) and have the same problem.
> > Solved enabling remarked lines.
> > I was selected my monitor during install. I don't know if it is a bug in
> > anaconda, system-config-display or firstboot
> >
> > Ricardo.-
> >
> > Casper Pedersen wrote:
> > >Hi,
> > >
> > >It looks like there is a problem with firstboot/Xorg. I have a Sony E200
> > >monitor which is DCC compliant (I think), but after firstboot I'm only
> > >able to set it to 640x480 or 800x600 - Not 1280x1024..
> > >
> > >In /etc/X11/xorg.conf the following lines where remarked out:
> > >
> > >       HorizSync    30.0 - 85.0
> > >       VertRefresh  48.0 - 120.0
> > >
> > >After enabling them again, I was able to get 1280x1024.
> > >
> > >Is this a bug?
> > >
> 
> Same problem here with viewsonic p95f+ / GeForce FX 5900XT rev 161.
> 
> Must fix before release.
> 

Just to put the stake in the coffin I can also confirm this on my laptop
ATI Mobility 9700, 17" wxga LCD.

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list




From mpeters at mac.com  Wed May  5 15:35:47 2004
From: mpeters at mac.com (Michael A. Peters)
Date: Wed, 05 May 2004 08:35:47 -0700
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <409879F7.9010403@redhat.com>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
	<1083695929.20962.33.camel@laptop>
	<1083732387.2257.24.camel@localhost.localdomain>
	<409879F7.9010403@redhat.com>
Message-ID: <1083771347.4068.76.camel@devel.mpeters.us>

On Tue, 2004-05-04 at 22:21, Warren Togami wrote:

>  I wanted to modify epiphany slightly along with redhat-menus, 
> htmlview and mozilla for the final Preferred Application behavior fix 
> for FC2.

Thank you !!

-- 
Cheap Linux CD's - http://mpeters.us/linux/




From strange at nsk.no-ip.org  Wed May  5 16:27:07 2004
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Wed, 5 May 2004 17:27:07 +0100
Subject: gaim x86-64 broken protocols
In-Reply-To: <4097FA49.7070300@redhat.com>;
	from wtogami@redhat.com on Tue, May 04, 2004 at 10:17:13AM -1000
References: <40956738.5070506@redhat.com> <409726D3.1010101@redhat.com>
	<40975CBC.4070803@redhat.com> <20040504171041.A31508@nsk.no-ip.org>
	<4097FA49.7070300@redhat.com>
Message-ID: <20040505172707.A25172@nsk.no-ip.org>

On Tue, May 04, 2004 at 10:17:13AM -1000, Warren Togami wrote:
> Luciano Miguel Ferreira Rocha wrote:
> > On Mon, May 03, 2004 at 11:05:00PM -1000, Warren Togami wrote:
> > 
> >>Woo!  marv and grim in #gaim found the problem in the src/sha.* 
> >>implementation of the sha1 digest algorithm.
> >>
> >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122221
> >>http://people.redhat.com/wtogami/temp/
> >>
> >>Please test the gaim-0.77-4 builds here, which should fix yahoo
> >>authentication on x86-64.  Please test it for an extended period of
> >>time on i386 and ppc too to make sure we did not break anything by
> >>accident.
> >>
> >>Warren Togami
> >>wtogami at redhat.com
> > 
> > 
> > That version still has a bug in the irc module (not related to x86-64,
> > occurs in every arch).
> > 
> > For more informations, bug #947794 @ gaim.sf.net, #114870 on
> > bugzilla.redhat.com.
> > 
> 
> http://people.redhat.com/wtogami/temp/
> 
> Please test this on i386, x86-64 and ppc FC2.  Patched x86-64 and your 
> IRC reconnnect fix, also changed the default profile a bit.
> 
> Warren Togami
> wtogami at redhat.com

Seems to work ok. The MSN plugin still doesn't show me the "invalid
username", but that's not a serious bug nor related to any of these bugs
or your changes.

Regards,
Luciano Rocha




From kmaraas at broadpark.no  Wed May  5 16:29:53 2004
From: kmaraas at broadpark.no (Kjartan Maraas)
Date: Wed, 05 May 2004 18:29:53 +0200
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <409879F7.9010403@redhat.com>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
	<1083695929.20962.33.camel@laptop>
	<1083732387.2257.24.camel@localhost.localdomain>
	<409879F7.9010403@redhat.com>
Message-ID: <1083774593.3883.2.camel@localhost.localdomain>

tir, 04.05.2004 kl. 19.21 -1000, skrev Warren Togami:
> Havoc Pennington wrote:
> > I think 2.6.1 would be fine post-FC2-release, just put it in staging
> > area for a bit and use it ourselves and if nothing horrible happens push
> > it out as an update. Probably not a good idea during the freeze though.
> > Basically, push 2.6.1 into Fedora when Fedora is in the same state that
> > GNOME was in when GNOME pushed 2.6.1 in GNOME.
> > 
> > I saw someone mention that we may have some packages that aren't up to
> > 2.6.0 though (epiphany perhaps?), we should be sure to fix those by
> > Friday probably if there are any. Don't want to ship betas.
> > 
> > Havoc
> 
> Rawhide: epiphany-1.1.12-0
> 
> http://www.gnome.org/projects/epiphany/
> Latest Stable: epiphany-1.2.4
> 

Actually, epiphany is at 1.2.5 as of yesterday.

- Planner/mrproject could go up to 0.11 also I think?
- libgtop in rawhide is at 2.5.2

And I hope to push 2.6.1 out this week assuming I get the last remaining
tarballs sorted out.

Cheers
Kjartan




From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Wed May  5 16:38:08 2004
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Wed, 5 May 2004 18:38:08 +0200
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083774593.3883.2.camel@localhost.localdomain>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
	<1083695929.20962.33.camel@laptop>
	<1083732387.2257.24.camel@localhost.localdomain>
	<409879F7.9010403@redhat.com>
	<1083774593.3883.2.camel@localhost.localdomain>
Message-ID: <20040505183808.01af7f4c@localhost>

Kjartan Maraas wrote :

> - Planner/mrproject could go up to 0.11 also I think?
> - libgtop in rawhide is at 2.5.2

>From the "Packages Removed" section of the RELEASE-NOTES :

     o libgtop -- No longer used by any Fedora Core application

Time to trash the archive if it's still there?

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1.92 (FC2 Test 3) - Linux kernel 2.6.5-1.349
Load : 0.13 0.20 0.40




From pryce at ucla.edu  Wed May  5 17:15:11 2004
From: pryce at ucla.edu (Paul Rigor)
Date: Wed, 05 May 2004 10:15:11 -0700
Subject: 3CDs instead of 4
In-Reply-To: <4098FBDA.5000306@feuerpokemon.de>
References: <4098FBDA.5000306@feuerpokemon.de>
Message-ID: <1083777311.12913.1.camel@DHGDell4>

Probably to accomodate for 650mb cds?

On Wed, 2004-05-05 at 07:36, dragoran wrote:

> Is there any reason why there are 4 CDs for FC 2 ? It can be done in 3 
> CDs (700MB Disk) .
> This would save a disk and time for burning it.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040505/bb3d61b2/attachment.htm>

From p.vandenberg at personainternet.com  Wed May  5 17:19:38 2004
From: p.vandenberg at personainternet.com (Paul Vandenberg)
Date: Wed, 5 May 2004 13:19:38 -0400 (EDT)
Subject: Epiphany Version
Message-ID: <46102.192.26.212.72.1083777578.squirrel@webmail.personainternet.com>

Hi,

It looks like FC2 is going to have a development snapshot of Epiphany,
version 1.1.12. Just curious, since the corresponding stable version
(1.2.x) was released before GNOME 2.6, why is FC2 not including the
appropriate stable version of Epiphany.

Thanks in advance.....Paul








From pyroman at ninjapanda.org  Wed May  5 17:28:35 2004
From: pyroman at ninjapanda.org (Pyroman[FO])
Date: Wed, 05 May 2004 13:28:35 -0400
Subject: k3b as default CD burner
Message-ID: <40992443.9010002@ninjapanda.org>

I was wondering why gtoaster was still the default cd burner with Fedora 
Core.  k3b is updated more often and much easier to use than gtoaster, 
IMO.  gtoaster hasn't been updated in a while.  Any specific reasons?

Allen Cook




From sopwith at redhat.com  Wed May  5 17:46:01 2004
From: sopwith at redhat.com (Elliot Lee)
Date: Wed, 5 May 2004 13:46:01 -0400 (EDT)
Subject: 3CDs instead of 4
In-Reply-To: <4098FBDA.5000306@feuerpokemon.de>
References: <4098FBDA.5000306@feuerpokemon.de>
Message-ID: <Pine.LNX.4.58.0405051339390.11960@devserv.devel.redhat.com>

On Wed, 5 May 2004, dragoran wrote:

> Is there any reason why there are 4 CDs for FC 2 ? It can be done in 3 
> CDs (700MB Disk).

We can't count on 700M disks being available. Releasing 700M .iso's has
been tried in the past (one of the RHL8 or RHL9 betas) and rejected.

-- Elliot
I keep committing atrocities in an attempt to learn from my mistakes.




From jkeating at j2solutions.net  Wed May  5 17:43:29 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 5 May 2004 10:43:29 -0700
Subject: k3b as default CD burner
In-Reply-To: <40992443.9010002@ninjapanda.org>
References: <40992443.9010002@ninjapanda.org>
Message-ID: <200405051043.29358.jkeating@j2solutions.net>

On Wednesday 05 May 2004 10:28, Pyroman[FO] wrote:
> I was wondering why gtoaster was still the default cd burner with
> Fedora Core.  k3b is updated more often and much easier to use than
> gtoaster, IMO.  gtoaster hasn't been updated in a while.  Any
> specific reasons?

The default desktop is gnome, gtoaster is a gnome app.  K3b is a QT/KDE 
app, and not necessiarly in the system with a default install.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040505/775bbb33/attachment.sig>

From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Wed May  5 17:52:08 2004
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Wed, 5 May 2004 19:52:08 +0200
Subject: Latest tree broke rpm?
Message-ID: <20040505195208.441a4f26@localhost>

Hi,

I just finished upgrading to today's development tree, and was surprised to
see yum bailing out when I tried to clean up the download archives :

[... complete yum upgrade ...]
Transaction(s) Complete
[dude at python2 dude]$ yum clean all
Traceback (most recent call last):
  File "/usr/bin/yum", line 22, in ?
    import yummain
  File "/usr/share/yum/yummain.py", line 22, in ?
    import clientStuff
  File "/usr/share/yum/clientStuff.py", line 18, in ?
    import rpm
ImportError: /lib/librt.so.1: symbol __librt_multiple_threads, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
[dude at python2 dude]$

And now I get this :

[dude at python2 dude]$ rpm -qa
rpm: relocation error: /lib/librt.so.1: symbol __librt_multiple_threads, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
[dude at python2 dude]$

I've just noticed the problem, now time to investigate some more...

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1.92 (FC2 Test 3) - Linux kernel 2.6.5-1.349
Load : 0.06 0.36 0.45




From skvidal at phy.duke.edu  Wed May  5 17:56:52 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 05 May 2004 13:56:52 -0400
Subject: Latest tree broke rpm?
In-Reply-To: <20040505195208.441a4f26@localhost>
References: <20040505195208.441a4f26@localhost>
Message-ID: <1083779812.30445.53.camel@opus>

On Wed, 2004-05-05 at 13:52, Matthias Saou wrote:
> Hi,
> 
> I just finished upgrading to today's development tree, and was surprised to
> see yum bailing out when I tried to clean up the download archives :
> 
> [... complete yum upgrade ...]
> Transaction(s) Complete
> [dude at python2 dude]$ yum clean all
> Traceback (most recent call last):
>   File "/usr/bin/yum", line 22, in ?
>     import yummain
>   File "/usr/share/yum/yummain.py", line 22, in ?
>     import clientStuff
>   File "/usr/share/yum/clientStuff.py", line 18, in ?
>     import rpm
> ImportError: /lib/librt.so.1: symbol __librt_multiple_threads, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
> [dude at python2 dude]$
> 
> And now I get this :
> 
> [dude at python2 dude]$ rpm -qa
> rpm: relocation error: /lib/librt.so.1: symbol __librt_multiple_threads, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
> [dude at python2 dude]$
> 
> I've just noticed the problem, now time to investigate some more...
> 

your glibc package got unhappy during the transition.

check back in the archives of fedora-devel or fedora-test - it's talked
about in there, iirc.

-sv







From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Wed May  5 17:58:53 2004
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Wed, 5 May 2004 19:58:53 +0200
Subject: Latest tree broke rpm?
In-Reply-To: <20040505195208.441a4f26@localhost>
References: <20040505195208.441a4f26@localhost>
Message-ID: <20040505195853.2e95e49c@localhost>

Matthias Saou wrote :

> And now I get this :
> 
> [dude at python2 dude]$ rpm -qa
> rpm: relocation error: /lib/librt.so.1: symbol __librt_multiple_threads, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
> [dude at python2 dude]$
> 
> I've just noticed the problem, now time to investigate some more...

Very quick followup : Running /sbin/ldconfig manually fixed the problem. This
could mean there is a missing call to it in some %post somewhere or that rpm
or yum ordered the package upgrade wrong.

Anyway, in case it can help find an eventual problem, here is what exactly
got upgraded right before the problem occurred :

Running test transaction:
/etc/security/selinux/file_contexts: No such file or directory
Test transaction complete, Success!
/etc/security/selinux/file_contexts: No such file or directory
warning: /etc/printcap created as /etc/printcap.rpmnew
setup 100 % done 1/51
glibc-common 100 % done 2/51
glibc 100 % done 3/51
Stopping sshd:[  OK  ]
Starting sshd:[  OK  ]
coreutils 100 % done 4/51
mozilla-nspr 100 % done 5/51
gnome-vfs2 100 % done 6/51
mozilla-nss 100 % done 7/51
gpm 100 % done 8/51
util-linux 100 % done 9/51
glibc-headers 100 % done 10/51
initscripts 100 % done 11/51
gaim 100 % done 12/51
mozilla 100 % done 13/51
sane-backends 100 % done 14/51
binutils 100 % done 15/51
boost 100 % done 16/51
nautilus-cd-burner 100 % done 17/51
kudzu-devel 100 % done 18/51
gnome-vfs2-smb 100 % done 19/51
kudzu 100 % done 20/51
nscd 100 % done 21/51
kernel 100 % done 22/51
gpm-devel 100 % done 23/51
glibc-devel 100 % done 24/51
usbutils 100 % done 25/51
gnome-vfs2-devel 100 % done 26/51
Completing update for binutils  - 27/51
Completing update for boost  - 28/51
Completing update for initscripts  - 29/51
Completing update for nautilus-cd-burner  - 30/51
Completing update for gpm  - 31/51
Completing update for util-linux  - 32/51
Completing update for sane-backends  - 33/51
Completing update for kudzu-devel  - 34/51
Completing update for gnome-vfs2-smb  - 35/51
Completing update for kudzu  - 36/51
Completing update for mozilla-nspr  - 37/51
Completing update for nscd  - 38/51
Completing update for gaim  - 39/51
Completing update for gpm-devel  - 40/51
Completing update for glibc-devel  - 41/51
Completing update for coreutils  - 42/51
Completing update for usbutils  - 43/51
Completing update for mozilla-nss  - 44/51
Completing update for glibc-common  - 45/51
Completing update for mozilla  - 46/51
Completing update for setup  - 47/51
Completing update for gnome-vfs2  - 48/51
Completing update for glibc  - 49/51
Completing update for glibc-headers  - 50/51
Completing update for gnome-vfs2-devel  - 51/51
Kernel Updated/Installed, checking for bootloader
Grub found - making this kernel the default

Could it be a problem with /usr/sbin/glibc_post_upgrade?

$ rpm -q --scripts glibc
postinstall program: /usr/sbin/glibc_post_upgrade
postuninstall program: /sbin/ldconfig

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1.92 (FC2 Test 3) - Linux kernel 2.6.5-1.349
Load : 0.58 0.47 0.47




From pyroman at ninjapanda.org  Wed May  5 17:59:34 2004
From: pyroman at ninjapanda.org (Pyroman[FO])
Date: Wed, 05 May 2004 13:59:34 -0400
Subject: k3b as default CD burner
In-Reply-To: <200405051043.29358.jkeating@j2solutions.net>
References: <40992443.9010002@ninjapanda.org>
	<200405051043.29358.jkeating@j2solutions.net>
Message-ID: <40992B86.2060905@ninjapanda.org>

I understand that, but why isn't it included in the default install as 
the default burner?  Are there any reasons other than "We don't like KDE"?

Allen Cook

Jesse Keating wrote:
> On Wednesday 05 May 2004 10:28, Pyroman[FO] wrote:
> 
>>I was wondering why gtoaster was still the default cd burner with
>>Fedora Core.  k3b is updated more often and much easier to use than
>>gtoaster, IMO.  gtoaster hasn't been updated in a while.  Any
>>specific reasons?
> 
> 
> The default desktop is gnome, gtoaster is a gnome app.  K3b is a QT/KDE 
> app, and not necessiarly in the system with a default install.
> 
> 




From skvidal at phy.duke.edu  Wed May  5 18:00:33 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 05 May 2004 14:00:33 -0400
Subject: Latest tree broke rpm?
In-Reply-To: <20040505195853.2e95e49c@localhost>
References: <20040505195208.441a4f26@localhost>
	<20040505195853.2e95e49c@localhost>
Message-ID: <1083780033.30445.57.camel@opus>


> Could it be a problem with /usr/sbin/glibc_post_upgrade?
> 
> $ rpm -q --scripts glibc
> postinstall program: /usr/sbin/glibc_post_upgrade
> postuninstall program: /sbin/ldconfig
> 

not a bad place to look.

-sv





From skvidal at phy.duke.edu  Wed May  5 18:01:55 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 05 May 2004 14:01:55 -0400
Subject: k3b as default CD burner
In-Reply-To: <40992B86.2060905@ninjapanda.org>
References: <40992443.9010002@ninjapanda.org>
	<200405051043.29358.jkeating@j2solutions.net>
	<40992B86.2060905@ninjapanda.org>
Message-ID: <1083780115.30445.60.camel@opus>

On Wed, 2004-05-05 at 13:59, Pyroman[FO] wrote:
> I understand that, but why isn't it included in the default install as 
> the default burner?  Are there any reasons other than "We don't like KDE"?
> 

to be brutally honest - k3b is great. It's a whole lot ahead of gtoaster
in terms of flexibility and obviousness of use.

I install it on my gnome systems b/c chances are I'll need the kde stuff
anyway.

It probably doesn't need to be in the gnome default for burning b/c
gnome has nautilus cd burning for a lot of tasks.

but k3b is darned nice.

-sv





From dcbw at redhat.com  Wed May  5 18:05:39 2004
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 05 May 2004 14:05:39 -0400
Subject: k3b as default CD burner
In-Reply-To: <40992B86.2060905@ninjapanda.org>
References: <40992443.9010002@ninjapanda.org>
	<200405051043.29358.jkeating@j2solutions.net>
	<40992B86.2060905@ninjapanda.org>
Message-ID: <1083780338.6350.4.camel@dcbw.boston.redhat.com>

If you don't choose to install KDE, then having k3b as the default will
drag along much of KDE anyway.  Same thing goes for people who choose
not to install GNOME, a single GNOME app would drag along most of GNOME
+ GTK.

Dan

On Wed, 2004-05-05 at 13:59 -0400, Pyroman[FO] wrote:
> I understand that, but why isn't it included in the default install as 
> the default burner?  Are there any reasons other than "We don't like KDE"?
> 
> Allen Cook
> 
> Jesse Keating wrote:
> > On Wednesday 05 May 2004 10:28, Pyroman[FO] wrote:
> > 
> >>I was wondering why gtoaster was still the default cd burner with
> >>Fedora Core.  k3b is updated more often and much easier to use than
> >>gtoaster, IMO.  gtoaster hasn't been updated in a while.  Any
> >>specific reasons?
> > 
> > 
> > The default desktop is gnome, gtoaster is a gnome app.  K3b is a QT/KDE 
> > app, and not necessiarly in the system with a default install.
> > 
> > 
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list




From earnson at gmail.com  Wed May  5 18:24:42 2004
From: earnson at gmail.com (Erik Arnson)
Date: Wed, 5 May 2004 13:24:42 -0500
Subject: 3CDs instead of 4
In-Reply-To: <Pine.LNX.4.58.0405051339390.11960@devserv.devel.redhat.com>
References: <4098FBDA.5000306@feuerpokemon.de>
	<Pine.LNX.4.58.0405051339390.11960@devserv.devel.redhat.com>
Message-ID: <DCC0BFA2.126ED11A@mail.gmail.com>

I haven't bought a 650MB CD-R in a long time.  I always make sure I've
got the 700MB CD-R.  I do agree on the idea of 700MB ISOs.  I don't
think a lot of people use 650MB CDs anymore.  I hate to toy with the
idea of downloading 4 ISOs one-after-another.  As time goes on the
requirements of disk space and the like of an OS increase.  With this,
you should also take into account people now have fast CD-RWs and most
people don't buy the 650MB CDs.

-Erik Arnson

On Wed, 5 May 2004 13:46:01 -0400 (EDT), Elliot Lee <sopwith at redhat.com> wrote:
> 
> On Wed, 5 May 2004, dragoran wrote:
> 
> > Is there any reason why there are 4 CDs for FC 2 ? It can be done in 3
> > CDs (700MB Disk).
> 
> We can't count on 700M disks being available. Releasing 700M .iso's has
> been tried in the past (one of the RHL8 or RHL9 betas) and rejected.
> 
> -- Elliot
> I keep committing atrocities in an attempt to learn from my mistakes.
> 
> 
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>




From aoliva at redhat.com  Wed May  5 18:42:15 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 05 May 2004 15:42:15 -0300
Subject: k3b as default CD burner
In-Reply-To: <40992443.9010002@ninjapanda.org>
References: <40992443.9010002@ninjapanda.org>
Message-ID: <or7jvqvhq0.fsf@free.redhat.lsd.ic.unicamp.br>

On May  5, 2004, "Pyroman[FO]" <pyroman at ninjapanda.org> wrote:

> I was wondering why gtoaster was still the default cd burner with
> Fedora Core.

Isn't nautilus-cd-burner the default cd burner?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From wtogami at redhat.com  Wed May  5 18:49:00 2004
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 05 May 2004 08:49:00 -1000
Subject: mailman testing needed
Message-ID: <4099371C.7070504@redhat.com>

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=105638#c12

Anyone using FC1 or FC2 mailman?  Please rebuild this SRPM and see if it 
works for you.  I tried to address the rpm -V and .py byte compile 
issue, but I am unable to quickly test this myself.  Be prepared to 
downgrade back to the previous mailman version with --oldpackage if this 
test has failed.

If this works, FC2 can finally fix this bug...

Warren Togami
wtogami at redhat.com




From jakub at redhat.com  Wed May  5 19:00:31 2004
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 5 May 2004 15:00:31 -0400
Subject: Latest tree broke rpm?
In-Reply-To: <1083780033.30445.57.camel@opus>
References: <20040505195208.441a4f26@localhost>
	<20040505195853.2e95e49c@localhost>
	<1083780033.30445.57.camel@opus>
Message-ID: <20040505190031.GC30909@devserv.devel.redhat.com>

On Wed, May 05, 2004 at 02:00:33PM -0400, seth vidal wrote:
> 
> > Could it be a problem with /usr/sbin/glibc_post_upgrade?
> > 
> > $ rpm -q --scripts glibc
> > postinstall program: /usr/sbin/glibc_post_upgrade
> > postuninstall program: /sbin/ldconfig
> > 
> 
> not a bad place to look.

glibc_post_upgrade is essentially:
/sbin/ldconfig || exit
/usr/sbin/iconvconfig || exit
/sbin/telinit || exit
/sbin/service sshd condrestart || exit
(but as it cannot assume /bin/sh and other programs being available,
it is statically linked proglet).

	Jakub




From smoogen at lanl.gov  Wed May  5 19:04:23 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Wed, 05 May 2004 13:04:23 -0600
Subject: 3CDs instead of 4
In-Reply-To: <DCC0BFA2.126ED11A@mail.gmail.com>
References: <4098FBDA.5000306@feuerpokemon.de>
	<Pine.LNX.4.58.0405051339390.11960@devserv.devel.redhat.com>
	<DCC0BFA2.126ED11A@mail.gmail.com>
Message-ID: <1083783861.16031.21.camel@smoogen3.lanl.gov>

On Wed, 2004-05-05 at 12:24, Erik Arnson wrote:
> I haven't bought a 650MB CD-R in a long time.  I always make sure I've
> got the 700MB CD-R.  I do agree on the idea of 700MB ISOs.  I don't
> think a lot of people use 650MB CDs anymore.  I hate to toy with the
> idea of downloading 4 ISOs one-after-another.  As time goes on the

In the past, there have been too many people who found that their
machine they wanted to run a 700 MB cdrom was only 650 or that it didnt
do 700 as well as it should. Then the mailing lists get filled with
howls of how RH is conspiring with hardware manufacturers to force
people to buy new computers.

I think it is a little late in the release cycle to make a possibly ugly
decision like this. I would suggest it be put in the FC3 cycle as one of
the changes (releases will be 700MB and DVD ISO).

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From jakub at redhat.com  Wed May  5 19:04:49 2004
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 5 May 2004 15:04:49 -0400
Subject: Latest tree broke rpm?
In-Reply-To: <20040505195853.2e95e49c@localhost>
References: <20040505195208.441a4f26@localhost>
	<20040505195853.2e95e49c@localhost>
Message-ID: <20040505190446.GD30909@devserv.devel.redhat.com>

On Wed, May 05, 2004 at 07:58:53PM +0200, Matthias Saou wrote:
> Matthias Saou wrote :
> 
> > And now I get this :
> > 
> > [dude at python2 dude]$ rpm -qa
> > rpm: relocation error: /lib/librt.so.1: symbol __librt_multiple_threads, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
> > [dude at python2 dude]$
> > 
> > I've just noticed the problem, now time to investigate some more...
> 
> Very quick followup : Running /sbin/ldconfig manually fixed the problem. This
> could mean there is a missing call to it in some %post somewhere or that rpm
> or yum ordered the package upgrade wrong.
> 
> Anyway, in case it can help find an eventual problem, here is what exactly
> got upgraded right before the problem occurred :
> 
> Running test transaction:
> /etc/security/selinux/file_contexts: No such file or directory
> Test transaction complete, Success!
> /etc/security/selinux/file_contexts: No such file or directory
> warning: /etc/printcap created as /etc/printcap.rpmnew
> setup 100 % done 1/51
> glibc-common 100 % done 2/51
> glibc 100 % done 3/51
> Stopping sshd:[  OK  ]
> Starting sshd:[  OK  ]

When this is printed, this means /sbin/ldconfig surely had to be run
successfully.
Do you have LD_ASSUME_KERNEL set in the environment?
Was the /lib/tls/librt.so.1 symlink missing immediately after yum install?

I upgraded my box with rpm -U directly and certainly did not see such
problems.

	Jakub




From buildsys at redhat.com  Wed May  5 19:30:30 2004
From: buildsys at redhat.com (Build System)
Date: Wed, 5 May 2004 15:30:30 -0400
Subject: rawhide report: 20040505 changes
Message-ID: <200405051930.i45JUUw15388@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-images-9.99-1
----------------------
* Tue May 04 2004 Jeremy Katz <katzj at redhat.com>

- add better scaled Fedora logo, keep old size for lowres

bcel-5.0-13
-----------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 5.0-13

- Rebuild with new compiler.

binutils-2.15.90.0.3-5
----------------------
* Tue May 04 2004 Jakub Jelinek <jakub at redhat.com> 2.15.90.0.3-5

- fix s390{,x} .{,b,p2}align handling
- ppc/ppc64 testsuite fix

* Mon May 03 2004 Jakub Jelinek <jakub at redhat.com> 2.15.90.0.3-4

- -z relro ppc/ppc64/ia64 fixes
- change x86-64 .plt symbol st_size handling to match ia32
- prettify objdump -d output

* Tue Apr 20 2004 Jakub Jelinek <jakub at redhat.com> 2.15.90.0.3-3

- several SPARC fixes


boost-1.31.0-6
--------------
* Mon May 03 2004 Benjamin Kosnik <bkoz at redhat.com> 

- (#121630: gcc34 patch needed)

commons-beanutils-1.6.1-13
--------------------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.6.1-13

- Rebuild with new compiler.

commons-collections-2.1-12
--------------------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 2.1-12

- Rebuild with new compiler.

commons-dbcp-1.1-3
------------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.1-3

- Rebuild with new compiler.

commons-digester-1.4.1-13
-------------------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.4.1-13

- Rebuild with new compiler.

commons-fileupload-1.0-8
------------------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.0-8

- Rebuild with new compiler.

commons-logging-1.0.2-15
------------------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.0.2-15

- Rebuild with new compiler.

commons-pool-1.1-3
------------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.1-3

- Rebuild with new compiler.

coreutils-5.2.1-7
-----------------
* Tue May 04 2004 Tim Waugh <twaugh at redhat.com> 5.2.1-7

- Fix join -t (bug #122435).

cproto-4.7c-1
-------------
* Tue May 04 2004 Bill Nottingham <notting at redhat.com> 4.7c-1

- update to 4.7c (#54814)

cup-v10k-13
-----------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> v10k-13

- Rebuild with new compiler.

festival-1.4.2-22
-----------------
* Tue May 04 2004 Jonathan Blandford <jrb at redhat.com> 1.4.2-21

- Remove the spanish voices until we get clarification on the license

gaim-0.77-6
-----------
* Tue May 04 2004 Warren Togami <wtogami at redhat.com> 0.77-6

- CVS backport 118: x86-64 yahoo auth fix
               119: Copy/paste fixes for UCS-2 encoded selection
               120: IRC reconnect segfault fix
- remove relnot.so plugin because it is unusable in FC
- Default enable logging and history.so plugin
          enable autoreconnect plugin
- Fix Gnome Default url handler

glibc-2.3.3-24
--------------
* Tue May 04 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-24

- update from CVS
  - define S_ISSOCK in -D_XOPEN_SOURCE=600 and S_I[FS]SOCK
    plus F_[SG]ETOWN also in -D_XOPEN_SOURCE=500 (both
    included already in XNS5)
  - reorder dlopen checks, so that dlopening ET_REL objects
    complains about != ET_DYN != ET_EXEC, not about phentsize
    (#121606)
  - fix strpbrk macro for GCC 3.4+ (BZ #130)
  - fix <sys/sysctl.h> (BZ #140)
  - sched_[gs]etaffinity documentation fix (BZ #131)
  - fix sparc64 build (BZ #139)
  - change linuxthreads back to use non-cancellable writes
    to manager pipes etc.
  - fix sem_timedwait return value in linuxthreads (BZ #133)
  - ia64 unnecessary PLT relocs removal

* Thu Apr 22 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-23

- update from CVS
  - fix *scanf
  - fix shm_unlink, sem_unlink and mq_unlink errno values
  - avoid memory leaks in error
  - execstack fixes on s390

* Mon Apr 19 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-22

- update from CVS
  - mq and timer fixes
- rebuilt with binutils >= 2.15.90.0.3-2 to fix IA-64 statically
  linked binaries
- fix linuxthreads librt.so on s390{,x}, so it is no longer DT_TEXTREL


gnome-vfs2-2.6.0-7
------------------
* Tue May 04 2004 Dan Williams <dcbw at redhat.com> 2.6.0-7

- Update to desktop-file-utils 0.6
- Implement monitoring to detect addition/deletion of .desktop files
- Fix RH #118553, crash when reading symlink that points to
    nothing in libmenu.so VFS backend

gnuchess-5.07-3
---------------
* Tue May 04 2004 Karsten Hopp <karsten at redhat.de> 5.07-3 

- update and rebuild book.dat to fix #122431

gpm-1.20.1-48
-------------
* Tue May 04 2004 Adrian Havill <havill at redhat.com> 1.20.1-48

- restore gpmopen() NULL check that was removed with the
  evdev superpatch (#118554)

gv-3.5.8-25
-----------
* Tue May 04 2004 Bill Nottingham <notting at redhat.com> 3.5.8-25

- fix desktop file (#120190)

initscripts-7.51-1
------------------
* Tue May 04 2004 Bill Nottingham <notting at redhat.com> 7.51-1

- get rid of LVM error when no volumes are defined (#121197)
- fix selinux short-circuit test (#121143, <michal at harddata.com>)
- /dev/mapper/control is a special file, check it accordingly (#121963)
- support ETHTOOL_OPTS on bonding slaves (#119430, <hrunting at texas.net>)
- handle multiple spaces correctly in rc.sysinit, network-functions
  (#118583, <pallas at kadan.cz>)
- cleanup fd leaks, mem leaks, other bogosities
  (#119987, <linux_4ever at yahoo.com>)
- rc.d/init.d/network: remove ipv6 bogosity (#114128)
- translation updates

jaf-20030319-4
--------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 20030319-4

- Rebuild with new compiler.

jakarta-regexp-1.2-15
---------------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.2-15

- Rebuild with new compiler.

javamail-20031006-4
-------------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 20031006-4

- Rebuild with new compiler.

jed-0.99.16-4
-------------
* Tue May 04 2004 Bill Nottingham <notting at redhat.com> 0.99.16-4

- remove info page (#115826)

junit-3.8.1-4
-------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 3.8.1-4

- Rebuild with new compiler.

kdeadmin-3.2.2-2
----------------
* Tue May 04 2004 Than Ngo <than at redhat.com> 7:3.2.2-2

- cleanup GNOME/KDE menu

kdebase-3.2.2-4
---------------
* Tue May 04 2004 Than Ngo <than at redhat.com> 3.2.2-4

- cleanup GNOME/KDE Menu, added OnlyShowIn=KDE

kernel-2.6.5-1.350
------------------
* Tue May 04 2004 Arjan van de Ven <arjanv at redhat.com>

- work around i810/i830 DRM issue

kudzu-1.1.59-1
--------------
* Mon May 03 2004 Bill Nottingham <notting at redhat.com> - 1.1.59-1

- shut up modprobe (#120410)
- re-enable the mouse config code (#121139, #121487)

mozilla-1.6-4
-------------
* Tue May 04 2004 Christopher Aillon <caillon at redhat.com> 37:1.6-4

- Added patch to no longer block port 1080
- Added patch to fix the DNS cache
- Added patch to correctly get the avail screen size
- Added patches to make x-remote aware of profiles, programs and usernames

nautilus-cd-burner-2.6.0-2
--------------------------
* Tue May 04 2004 Alex Larsson <alexl at redhat.com> 2.6.0-2

- Open the right help file (#121476)

rpmdb-fedora-1.92-0.20040505
----------------------------

sane-backends-1.0.13-6
----------------------
* Tue May 04 2004 Tim Waugh <twaugh at redhat.com> 1.0.13-6

- Ship libusb.usermap (from sane-backends-1.0.14) and a pam_console-aware
  libusbscanner script.
- Fix epson.conf for Epson Perfection 2400 (bug #122328).

servletapi-2.3-4
----------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 2.3-4

- Rebuild with new compiler.

setup-2.5.32-1
--------------
* Tue May 04 2004 Bill Nottingham <notting at redhat.com> 2.5.32-1

- set MAIL in csh.cshrc (#115376)
- fix inputrc check in csh.login (#115073)

* Mon Jan 26 2004 Bill Nottingham <notting at redhat.com> 2.5.31-1

- move /etc/aliases here

* Mon Dec 08 2003 Bill Nottingham <notting at redhat.com> 2.5.30-1

- remove stty `tput kbs` section (#91357)


usbutils-0.11-4
---------------
* Tue May 04 2004 Bill Nottingham <notting at redhat.com> 0.11-4

- add patch from USB maintainer to fix various brokenness (#115694, <david-b at pacbell.net>)

util-linux-2.12-18
------------------
* Tue May 04 2004 Elliot Lee <sopwith at redhat.com> 2.12-18

- Fix #122448 (autofs issues)

* Fri Apr 23 2004 Elliot Lee <sopwith at redhat.com> 2.12-17

- Fix #119157 by editing the patch
- Add patch145 to fix #119986

* Fri Apr 16 2004 Elliot Lee <sopwith at redhat.com> 2.12-16

- Fix #118803


xalan-j-2.4.1-14
----------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 2.4.1-14

- Rebuild with new compiler.

xerces-j-2.2.1-16
-----------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 2.2.1-16

- Rebuild with new compiler.




From alan at redhat.com  Wed May  5 19:33:44 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 5 May 2004 15:33:44 -0400
Subject: k3b as default CD burner
In-Reply-To: <or7jvqvhq0.fsf@free.redhat.lsd.ic.unicamp.br>
References: <40992443.9010002@ninjapanda.org>
	<or7jvqvhq0.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <20040505193344.GA14970@devserv.devel.redhat.com>

On Wed, May 05, 2004 at 03:42:15PM -0300, Alexandre Oliva wrote:
> On May  5, 2004, "Pyroman[FO]" <pyroman at ninjapanda.org> wrote:
> > I was wondering why gtoaster was still the default cd burner with
> > Fedora Core.
> Isn't nautilus-cd-burner the default cd burner?

It burns CD's - its not a CD burning application, and there is a definite
difference between the two roles. 




From pertusus at free.fr  Wed May  5 21:39:31 2004
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 5 May 2004 23:39:31 +0200
Subject: rawhide report: 20040504 changes
In-Reply-To: <1083690038.3844.6.camel@laptop.fenrus.com>
References: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
	<1083690038.3844.6.camel@laptop.fenrus.com>
Message-ID: <20040505213931.GA4147@free.fr>

> regressions; time to release is running out so please test!

It fixes the issue about not being able to compile module as non root for me

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

Pat




From jakub at redhat.com  Wed May  5 21:55:18 2004
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 5 May 2004 17:55:18 -0400
Subject: Latest tree broke rpm?
In-Reply-To: <20040505190446.GD30909@devserv.devel.redhat.com>
References: <20040505195208.441a4f26@localhost>
	<20040505195853.2e95e49c@localhost>
	<20040505190446.GD30909@devserv.devel.redhat.com>
Message-ID: <20040505215517.GF30909@devserv.devel.redhat.com>

> When this is printed, this means /sbin/ldconfig surely had to be run
> successfully.

Actually, I found out what's going on.
If you are unlucky and /sbin/ldconfig run in glibc_post_upgrade (from
glibc's %post) is the last /sbin/ldconfig run during the update,
then at the point when that /sbin/ldconfig is run, files from both
new glibc and old glibc might still exist in the filesystem.
Particularly there might be still /lib/tls/librtkaio-2.3.3.so
(from glibc-2.3.3-20 or earlier) and /lib/tls/librt-2.3.3.so (from
glibc-2.3.3-24 (well, -21 or later, the rpm currently being installed)).
The libraries have the same SONAME (that's because they provide the same
ABI, librt.so.1) but different filename (librtkaio uses kernel aio,
librt is pure userland implementation).
Unfortunately librtkaio is the one picked by ldconfig, so librt.so.1
stays pointing to librtkaio-2.3.3.so.  Some time after glibc %post ends
rpm removes /lib/tls/librtkaio-2.3.3.so (as it is present just in the old
package) and there is a stale symlink.

If you are lucky and some other package's %post runs ldconfig after the
librtkaio-2.3.3.so file is removed (or if you are upgrading already
from glibc which did not have that file), everything is fine.

Guess I'll need to add some more ugly hacks into glibc_post_upgrade :(.

FYI, librtkaio has been removed for FC2, because 2.6.x kernel AIO support
is in a bad shape and insufficient for POSIX AIO on top of it.

	Jakub




From twanger at bluetwanger.de  Wed May  5 21:55:24 2004
From: twanger at bluetwanger.de (Markus Bertheau)
Date: Wed, 05 May 2004 23:55:24 +0200
Subject: rawhide report: 20040504 changes
In-Reply-To: <1083690038.3844.6.camel@laptop.fenrus.com>
References: <200405041649.i44GnIY32121@porkchop.devel.redhat.com>
	<1083690038.3844.6.camel@laptop.fenrus.com>
Message-ID: <1083794123.2395.2.camel@yarrow.bertheau.de>

? ???, 04.05.2004, ? 19:00, Arjan van de Ven ?????:
> On Tue, 2004-05-04 at 18:49, Build System wrote:
> 
> > kernel-2.6.5-1.349
> > ------------------
> 
> I would like to ask everyone on this list to please test this kernel
> hard; it has quite a few bugfixes but there always is the risk of
> regressions; time to release is running out so please test!
> 

The new version doesn't fix the acpi boot crash on asus notebooks

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

Btw, are older kernel version available to test somewhere?

________________________________________________________________________
????? 

-- 
Markus Bertheau <twanger at bluetwanger.de>




From tim at niemueller.de  Wed May  5 21:57:46 2004
From: tim at niemueller.de (Tim Niemueller)
Date: Wed, 05 May 2004 23:57:46 +0200
Subject: Problem on package installation
Message-ID: <4099635A.60009@niemueller.de>

Hi there.

Finally I found the time to upgrade my FC1 box to FC2t3 (I should 
mention that this has been a RH8 box with Ximian and RH 9 before) via 
"apt-get dist-upgrade". This worked pretty good until some Gnome 
packages where about to be installed:

On some packages I got error message about missing DTD for some help 
files as it seemed that oasis-open.org has been done (or maybe still 
is). The installation took awfully long then since it was waiting for 
the timeout on each file. I ended up in adding www.oasis-open.org to my 
hosts file to point to a local webserver with an immediate 404...

An example error message looks like:

error : Unknown IO error
/usr/share/gnome/help/gedit/zh_TW/gedit.xml:9: I/O warning : failed to 
load external entity 
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
]>
   ^
/usr/share/gnome/help/gedit/zh_TW/gedit.xml:908: parser error : Entity 
'tilde' not defined

The first lines appear once per file. The latter line once per entity in 
that file -> very often. It clutters the screen and takes a loot of time.

The packages I know of that have this problem (the installation ran 
unattended and I did not see all packages) are:

gnome-media (very long)
gnome-applets (also very long)
gedit
file-roller

I looked at the gedit spec and I assume the scrollkeeper is causing the 
problems here...

First I thought this should be done at compile time but as it seems this 
updates the search database and the like? Maybe then it would be a good 
idea to install a local copy of the DTDs needed to avoid such problems.

	Tim

-- 
     Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
  Imagination is more important than knowledge. (Albert Einstein)




From mattwhiteley at gmail.com  Wed May  5 22:35:05 2004
From: mattwhiteley at gmail.com (matt whiteley)
Date: Wed, 5 May 2004 15:35:05 -0700
Subject: boot.iso && dhcp
Message-ID: <25E05478.734D4B00@mail.gmail.com>

I install my test machine most every day from the devel tree. I know
this is not an approved method of using the test release but it works
for me, and I am interested in seeing the differences in anaconda etc.

The last two days booting from the boot.iso in the devel tree, my
machine is not asking for dhcp properly. I have a dlink 530tx+ network
card that it loads the module and finds an eth0. My dhcp server logs
have no mention of it asking for an address. After a timeout it
reports "pump told us: no DHCP reply received."

Since this is only happening with the boot.iso from 5/4 and 5/5 which
is when the kernel revs 349 and 350 were introduced I thought this may
be a kernel issue. I saw nothing in bugzilla that was applicable, but
thought I would try here first.

thanks,

--
matt whiteley <mattwhiteley at gmail.com>




From helios82 at optushome.com.au  Wed May  5 22:56:21 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Thu, 06 May 2004 08:56:21 +1000
Subject: k3b as default CD burner
In-Reply-To: <40992443.9010002@ninjapanda.org>
References: <40992443.9010002@ninjapanda.org>
Message-ID: <1083797781.3468.48.camel@fc1>

On Thu, 2004-05-06 at 03:28, Pyroman[FO] wrote:
> I was wondering why gtoaster was still the default cd burner with Fedora 
> Core.  k3b is updated more often and much easier to use than gtoaster, 
> IMO.  gtoaster hasn't been updated in a while.  Any specific reasons?

According to the FC2 test3 release notes, gtoaster has been removed for
FC2:

"gtoaster ??? Equivalent functionality present in nautilus-cd-burner"

Equivalent functionality!? As Alan just pointed out, it's not as
full-featured as a CD-burning app. So the only other GNOME app on offer
is X-CD-Roast I believe, but I prefer K3b over all of them.
nautilus-cd-burner is really simple to use, but it can't do everything
such as burn an audio CD if you feed it mp3s/oggs.

Regards,
-Matt
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 

-------------- 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/20040506/f98e9a91/attachment.sig>

From helios82 at optushome.com.au  Wed May  5 23:25:15 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Thu, 06 May 2004 09:25:15 +1000
Subject: mailman testing needed
In-Reply-To: <4099371C.7070504@redhat.com>
References: <4099371C.7070504@redhat.com>
Message-ID: <1083799514.3468.50.camel@fc1>

On Thu, 2004-05-06 at 04:49, Warren Togami wrote:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=105638#c12
> 
> Anyone using FC1 or FC2 mailman?  Please rebuild this SRPM and see if it 
> works for you.  I tried to address the rpm -V and .py byte compile 
> issue, but I am unable to quickly test this myself.  Be prepared to 
> downgrade back to the previous mailman version with --oldpackage if this 
> test has failed.
> 
> If this works, FC2 can finally fix this bug...

Warren, I just upgraded and tested this and all seems fixed. I've
attached a comment to the bug.

Regards,
-Matt
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 

-------------- 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/20040506/2abc5fdf/attachment.sig>

From kmaraas at broadpark.no  Wed May  5 23:40:22 2004
From: kmaraas at broadpark.no (Kjartan Maraas)
Date: Thu, 06 May 2004 01:40:22 +0200
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <20040505183808.01af7f4c@localhost>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
	<1083695929.20962.33.camel@laptop>
	<1083732387.2257.24.camel@localhost.localdomain>
	<409879F7.9010403@redhat.com>
	<1083774593.3883.2.camel@localhost.localdomain>
	<20040505183808.01af7f4c@localhost>
Message-ID: <1083800422.3883.4.camel@localhost.localdomain>

ons, 05.05.2004 kl. 18.38 +0200, skrev Matthias Saou:
> Kjartan Maraas wrote :
> 
> > - Planner/mrproject could go up to 0.11 also I think?
> > - libgtop in rawhide is at 2.5.2
> 
> >From the "Packages Removed" section of the RELEASE-NOTES :
> 
>      o libgtop -- No longer used by any Fedora Core application
> 
It's used by both gnome-system-monitor and gnome-applets AFAIK.

Cheers
Kjartan




From perbj at stanford.edu  Thu May  6 01:05:08 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Wed, 05 May 2004 18:05:08 -0700
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083800422.3883.4.camel@localhost.localdomain>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
	<1083695929.20962.33.camel@laptop>
	<1083732387.2257.24.camel@localhost.localdomain>
	<409879F7.9010403@redhat.com>
	<1083774593.3883.2.camel@localhost.localdomain>
	<20040505183808.01af7f4c@localhost>
	<1083800422.3883.4.camel@localhost.localdomain>
Message-ID: <1083805508.17791.55.camel@beechnut.Stanford.EDU>

On Wed, 2004-05-05 at 16:40, Kjartan Maraas wrote:
> ons, 05.05.2004 kl. 18.38 +0200, skrev Matthias Saou:
> > Kjartan Maraas wrote :
> > 
> > > - Planner/mrproject could go up to 0.11 also I think?
> > > - libgtop in rawhide is at 2.5.2
> > 
> > >From the "Packages Removed" section of the RELEASE-NOTES :
> > 
> >      o libgtop -- No longer used by any Fedora Core application
> > 
> It's used by both gnome-system-monitor and gnome-applets AFAIK.

I don't have an FC2 install handy right now, but on FC1 the current
version was packaged as libgtop2 so that both 1.x and 2.x were parallel
installable. gnome-system-monitor certainly works for me on FC2 tests to
I'd wager libgtop2 is still around...

/Per

-- 
Per Bjornsson
Ph.D. Candidate, Dept. of Applied Physics, Stanford University




From helios82 at optushome.com.au  Thu May  6 01:10:14 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Thu, 06 May 2004 11:10:14 +1000
Subject: Gnome 2.6.1 and FC2
In-Reply-To: <1083805508.17791.55.camel@beechnut.Stanford.EDU>
References: <20040420203602.90502.qmail@web40411.mail.yahoo.com>
	<1083369058.3978.56.camel@localhost.localdomain>
	<1083625394.5813.6.camel@laptop>
	<200405041024.35271.pmmm@rnl.ist.utl.pt>
	<1083680018.5813.19.camel@laptop>
	<20040504182028.GC15185@devserv.devel.redhat.com>
	<1083695929.20962.33.camel@laptop>
	<1083732387.2257.24.camel@localhost.localdomain>
	<409879F7.9010403@redhat.com>
	<1083774593.3883.2.camel@localhost.localdomain>
	<20040505183808.01af7f4c@localhost>
	<1083800422.3883.4.camel@localhost.localdomain>
	<1083805508.17791.55.camel@beechnut.Stanford.EDU>
Message-ID: <1083805814.1292.6.camel@fc1>

On Thu, 2004-05-06 at 11:05, Per Bjornsson wrote:
> On Wed, 2004-05-05 at 16:40, Kjartan Maraas wrote:
> > ons, 05.05.2004 kl. 18.38 +0200, skrev Matthias Saou:
> > > Kjartan Maraas wrote :
> > > 
> > > > - Planner/mrproject could go up to 0.11 also I think?
> > > > - libgtop in rawhide is at 2.5.2
> > > 
> > > >From the "Packages Removed" section of the RELEASE-NOTES :
> > > 
> > >      o libgtop -- No longer used by any Fedora Core application
> > > 
> > It's used by both gnome-system-monitor and gnome-applets AFAIK.
> 
> I don't have an FC2 install handy right now, but on FC1 the current
> version was packaged as libgtop2 so that both 1.x and 2.x were parallel
> installable. gnome-system-monitor certainly works for me on FC2 tests to
> I'd wager libgtop2 is still around...

Yep, this is correct. However I think it would make sense to rename
libgtop2 back to libgtop now that the ver1 library package is to be
expunged?

Regards,
-Matt
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 

-------------- 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/20040506/c98c8afe/attachment.sig>

From mdunkle3 at comcast.net  Thu May  6 01:46:59 2004
From: mdunkle3 at comcast.net (Matthew L. Dunkle)
Date: Wed, 05 May 2004 20:46:59 -0500
Subject: kernel low-latency follow up question
Message-ID: <1083808019.4763.14.camel@pcp01533809pcs.huntsv01.al.comcast.net>

I understand now that instability concerns were responsible for the
decision to remove the kernel low-latency patch beginning with the 2179
fedora core 1 release.  And thank you for those explanations.

However, I would like to suggest that for many of us this is an
important patch, and there is actually no need to remove it altogether. 
This patch used to be equipped with a proc filesystem / sysctl control
parameter, allowing the patch to be integrated into the kernel, and
disabled by default.  This would relieve the instability problems for
the general populous, but allow users such as myself to easily enable
the patch on systems where it is still needed.

Yes, I know I could re-install the patch myself, but given the other
changes that redhat routinely makes to the kernel, I have found it
extremely difficult in the past to pick up the patch files and install
them as is.  We use the redhat distribution where I work, and it is very
difficult at best to get "non-standard" patches installed by system
administration personnel into their system installation procedures,
especially patches that I have had to re-tailor by hand.

Thank you,
Matt Dunkle




From d_bradsh at bellsouth.net  Thu May  6 01:58:31 2004
From: d_bradsh at bellsouth.net (d_bradsh at bellsouth.net)
Date: Wed, 5 May 2004 21:58:31 -0400
Subject: yum and strange happenings.
Message-ID: <20040506015831.ZFGG11640.imf23aec.mail.bellsouth.net@mail.bellsouth.net>

Hey there you all.
I just updated from yesterdays updates to todays, and yum is acting strangly. First of all, Yum is working, but my screen scrolls continuously while the updates are being downloaded. I just wanted to know if this is a *new feature*, or something else. I asked around on #fedora, and no one would answer, so i assume no one knew. Thanks

Dusty-- resident idiot.




From katzj at redhat.com  Thu May  6 03:42:19 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 05 May 2004 23:42:19 -0400
Subject: boot.iso && dhcp
In-Reply-To: <25E05478.734D4B00@mail.gmail.com>
References: <25E05478.734D4B00@mail.gmail.com>
Message-ID: <1083814939.2110.5.camel@bree.local.net>

On Wed, 2004-05-05 at 15:35 -0700, matt whiteley wrote:
> Since this is only happening with the boot.iso from 5/4 and 5/5 which
> is when the kernel revs 349 and 350 were introduced I thought this may
> be a kernel issue. I saw nothing in bugzilla that was applicable, but
> thought I would try here first.

It's the return of an older kernel bug...
http://bugzilla.redhat.com/bugzilla/114092

Jeremy




From sharuzzaman at ezrs.com  Thu May  6 03:53:27 2004
From: sharuzzaman at ezrs.com (Sharuzzaman Ahmat Raslan)
Date: Thu, 06 May 2004 11:53:27 +0800
Subject: Embedded Fedora - soon?
Message-ID: <4099B6B7.8070801@ezrs.com>

http://www.linuxdevices.com/news/NS4819874726.html

Seems like Red Hat is going into embedded. Any plan for Fedora?

-----
Sharuzzaman Ahmat Raslan




From fedora at andrewfarris.com  Thu May  6 04:32:34 2004
From: fedora at andrewfarris.com (Andrew Farris)
Date: Wed, 05 May 2004 21:32:34 -0700
Subject: k3b as default CD burner
In-Reply-To: <1083780115.30445.60.camel@opus>
References: <40992443.9010002@ninjapanda.org>
	<200405051043.29358.jkeating@j2solutions.net>
	<40992B86.2060905@ninjapanda.org>  <1083780115.30445.60.camel@opus>
Message-ID: <1083817953.2076.8.camel@CirithUngol>

On Wed, 2004-05-05 at 14:01 -0400, seth vidal wrote:
> On Wed, 2004-05-05 at 13:59, Pyroman[FO] wrote:
> > I understand that, but why isn't it included in the default install as 
> > the default burner?  Are there any reasons other than "We don't like KDE"?
> > 
> 
> to be brutally honest - k3b is great. It's a whole lot ahead of gtoaster
> in terms of flexibility and obviousness of use.
> 
> I install it on my gnome systems b/c chances are I'll need the kde stuff
> anyway.
> 
> It probably doesn't need to be in the gnome default for burning b/c
> gnome has nautilus cd burning for a lot of tasks.
> 
> but k3b is darned nice.
> 
> -sv

IMO gtoaster is far behind k3b and xcdroast in capabilities, it's dated
and removing it is a good thing.  However, making k3b the default for a
gnome only install is no good, and neither is doing the other way
around.  I would like to see k3b and xcdroast used respectively for kde
and gnome only setups as default.  Nautilus cd burning is almost as
useless as Windows XP Explorer integrated cd burning... its a nice
feature to point at and say 'ooh looky there'.

When burning a cd it is usually worthwhile to do so with a well featured
and configurable app.  Using nautilus builtin burning should be the
option for the 'I know this is simple and don't mind all defaults
operation' situations.

-- 
Andrew Farris, CPE senior (California Polytechnic State University, SLO)
fedora at andrewfarris.com :: lmorgul on irc.freenode.net
"The only thing necessary for the triumph of evil is for good men
to do nothing." (Edmond Burke)




From skvidal at phy.duke.edu  Thu May  6 06:16:56 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 06 May 2004 02:16:56 -0400
Subject: python and x86_64 problem
Message-ID: <1083824215.2554.18.camel@binkley>

Hi,
 Troubleshooting this bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122304

I found something that could be a problem on x86_64 for python:

try this on x86_64:
foo='www.redhat.com'
foo.encode("idna")
depending on your encoding that's set you'll get either the correct:
www.redhat.com
or
www.redhat..om

we look on line 6 of 
/usr/lib64/python2.3/encodings/idna.py at:
dots = re.compile(u"[\u002E\u3002\uFF0E\uFF61]")

that works great on x86 - so a little further down on line 153 you see:

labels = dots.split(input)

the input in this question is like the url above.

so try this bit of code on your own x86_64 python 2.3.3 system:

import re
dots = re.compile(u"[\u002E\u3002\uFF0E\uFF61]")
foo = 'www.redhat.com'
labels = dots.split(foo)

print labels

you'll find it is:
Hi,
 Troubleshooting this bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122304

I found something that could be a problem on x86_64 for python:

try this on x86_64:
foo='www.redhat.com'
foo.encode("idna")
depending on your encoding that's set you'll get either the correct:
www.redhat.com
or
www.redhat..om

we look on line 6 of 
/usr/lib64/python2.3/encodings/idna.py at:
dots = re.compile(u"[\u002E\u3002\uFF0E\uFF61]")

that works great on x86 - so a little further down on line 153 you see:

labels = dots.split(input)

the input in this question is like the url above.

so try this bit of code on your own x86_64 python 2.3.3 system:

import re
dots = re.compile(u"[\u002E\u3002\uFF0E\uFF61]")
foo = 'www.redhat.com'
labels = dots.split(foo)

print labels

you'll find it is:
['www.redhat.', 'om']

while on x86 it is:

['www', 'redhat', 'com']

which is correct - 3 label sections from rfc 3490

so I went looking for the problem a little bit and found in _sre.c
    #if defined(MS_WIN64) || defined(__LP64__) || defined(_LP64)
        /* require smaller recursion limit for a number of 64-bit platforms:
         * Win64 (MS_WIN64), Linux64 (__LP64__), Monterey (64-bit AIX) (_LP64)
         */
        /* FIXME: maybe the limit should be 40000 / sizeof(void*) ? */
        #define USE_RECURSION_LIMIT 7500



I'm wondering if that FIXME is accurate - I've not tested the change yet
but it seems like a potential problem for regexes like this - or more to
the point anything using the HTTPHandler in python.

Can someone more experienced at python _sre internals take a look at
this?

This will most likely effect up2date, yum, and many network-interacting
python applications using http.
Thanks
-sv





From skvidal at phy.duke.edu  Thu May  6 06:38:02 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 06 May 2004 02:38:02 -0400
Subject: python and x86_64 problem
In-Reply-To: <1083824215.2554.18.camel@binkley>
References: <1083824215.2554.18.camel@binkley>
Message-ID: <1083825482.2554.20.camel@binkley>

On Thu, 2004-05-06 at 02:16 -0400, seth vidal wrote:
> Hi,
>  Troubleshooting this bug:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122304
> 
> I found something that could be a problem on x86_64 for python:
> 

<snip>
already filed in python's bugtracker

http://sourceforge.net/tracker/index.php?func=detail&aid=931848&group_id=5470&atid=105470

-sv





From de_lupus at hotmail.com  Thu May  6 09:34:52 2004
From: de_lupus at hotmail.com (Kristof Vansant)
Date: Thu, 06 May 2004 09:34:52 +0000
Subject: project to get desktop items to follow HIG so it can get included
	in FC3 
Message-ID: <BAY15-F132PEwr5Kk640000f195@hotmail.com>

I was thinking: if we just put all the package there Name=, GenericName=, 
Comment= lines
(only the english version) on a wiki and let people add a better name, 
genericname, etc following the HIG.

http://developer.gnome.org/projects/gup/hig/1.0/desktop-integration.html

After 2 months the best one's are selected. Then people can start 
translating it to there language.
After 3 months after the freezing date. So after there translated. The 
results are put in .desktop files and send to the maintainers.
With maintainers I mean the programme and the package maintainers.
This will let other distro's also profit from this effort.

example: send gimp.desktop to gimp fedora and gimp

Wiki example:

xchat.desktop
original:
Name=IRC Client
GenericName=IRC Client
Comment=X-Chat

lupus:
Name=X-Chat IRC Client
GenericName=IRC Client
Comment=For chatting on IRC

PS: if everything goes to plan the new desktop files can be in FC3

Lupus (Kristof Vansant Belgium)

_________________________________________________________________
Vraag van de week: Welk soort project zou jij financieel ondersteunen? 
http://www.msn.be/microsoft/potential/default.asp




From mitr at volny.cz  Thu May  6 09:44:33 2004
From: mitr at volny.cz (Miloslav Trmac)
Date: Thu, 6 May 2004 11:44:33 +0200
Subject: project to get desktop items to follow HIG so it can get
	included in FC3
In-Reply-To: <BAY15-F132PEwr5Kk640000f195@hotmail.com>
References: <BAY15-F132PEwr5Kk640000f195@hotmail.com>
Message-ID: <20040506094432.GC7749@chrys.ms.mff.cuni.cz>

On Thu, May 06, 2004 at 09:34:52AM +0000, Kristof Vansant wrote:
> After 3 months after the freezing date. So after there translated. The 
> results are put in .desktop files and send to the maintainers.
Most of the GNOME packages should already use a internationalization mechanism
(intltool) upstream; if they are not using it, they should. Maintaining
desktop file translations separately is error-prone and the translations
will probably get stale (new translators are very likely not to notice
that they need to update the desktop file, and manual adding of the
translations puts a burden on the maintaner).

I don't know how KDE does it, but the desktop files come translated
from upstream too :)
	Mirek




From rms at 1407.org  Thu May  6 10:01:23 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Thu, 06 May 2004 11:01:23 +0100
Subject: project to get desktop items to follow HIG so it can get
	included in FC3
In-Reply-To: <BAY15-F132PEwr5Kk640000f195@hotmail.com>
References: <BAY15-F132PEwr5Kk640000f195@hotmail.com>
Message-ID: <1083837683.3822.17.camel@roque>

On Thu, 2004-05-06 at 09:34 +0000, Kristof Vansant wrote:
> xchat.desktop
> original:
> Name=IRC Client
> GenericName=IRC Client
> Comment=X-Chat
> 
> lupus:
> Name=X-Chat IRC Client
> GenericName=IRC Client
> Comment=For chatting on IRC

It is absurd that you shouldn't put X-Chat or lupus into Name=

Likewise, it is absurd if these fields are not handled like they should.

On my FC2t3+updates, I have the following info on Evolution:

Name=Evolution Email
GenericName=
Comment=Send email and manage your schedule

Shouldn't this be:
Name=Evolution
GenericName=Email
Comment=Send email and manage your schedule

???

It should. And it should display something debatable like:

   Name GenericName
   Comment

But if fields have names, then these names have meanings, right? :)
The meanings should be respected, and fix the software if needed, but
don't invert the meanings on account of software bugs as if that is the
solution. Fix the bugs.

Rui
-------------- 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/20040506/66ed9b01/attachment.sig>

From mitr at volny.cz  Thu May  6 10:27:25 2004
From: mitr at volny.cz (Miloslav Trmac)
Date: Thu, 6 May 2004 12:27:25 +0200
Subject: project to get desktop items to follow HIG so it can get
	included in FC3
In-Reply-To: <1083837683.3822.17.camel@roque>
References: <BAY15-F132PEwr5Kk640000f195@hotmail.com>
	<1083837683.3822.17.camel@roque>
Message-ID: <20040506102724.GA8316@chrys.ms.mff.cuni.cz>

On Thu, May 06, 2004 at 11:01:23AM +0100, Rui Miguel Seabra wrote:
> On Thu, 2004-05-06 at 09:34 +0000, Kristof Vansant wrote:
> Likewise, it is absurd if these fields are not handled like they should.
> 
> On my FC2t3+updates, I have the following info on Evolution:
> 
> Name=Evolution Email
> GenericName=
> Comment=Send email and manage your schedule
> 
> Shouldn't this be:
> Name=Evolution
> GenericName=Email
> Comment=Send email and manage your schedule
No. http://developer.gnome.org/projects/gup/hig/1.0/desktop-integration.html#menu-item-names

> And it should display something debatable like:
> 
>    Name GenericName
>    Comment
See http://lists.gnome.org/archives/desktop-devel-list/2002-August/msg00000.html
and the followups.

> But if fields have names, then these names have meanings, right? :)
Yes, but not necessarily the "obvious" meanings. 

The current menu spec does not mention this issue at all, maybe it's
time to add something there. But that discussion belongs on xdg-list,
or whatever it is called now.
	Mirek




From huw-l at moving-picture.com  Thu May  6 11:46:32 2004
From: huw-l at moving-picture.com (Huw Lynes)
Date: Thu, 6 May 2004 12:46:32 +0100
Subject: Kernel RPM question: What if...
In-Reply-To: <1082134762.16566.1.camel@delerium.codemonkey.org.uk>
References: <4080043E.1050008@db.com>
	<1082133189.9600.4.camel@laptop.fenrus.com>
	<200404161239.44017.czar@czarc.net>
	<1082134762.16566.1.camel@delerium.codemonkey.org.uk>
Message-ID: <20040506124632.2e3dbf60.huw-l@moving-picture.com>

On Fri, 16 Apr 2004 17:59:23 +0100
Dave Jones <davej at redhat.com> wrote:

> On Fri, 2004-04-16 at 17:39, Gene C. wrote:
> > On Friday 16 April 2004 12:33, Arjan van de Ven wrote:
> > > you can try the
> > 
> > I have been getting sudden system freezes on a dual athlon system with FC1
> > 
> > since FC1 came up.  When it happens, it is painful.  It usually occurs
> > when I am trying to run the umount command (although it may also have
> > occured for mount).
> 
> The umount bug should be fixed in the 2179 kernel.
> It seemed that the low-latency patch caused that problem.


Yep 2179 seems to have fixed that.

-- 
| Huw Lynes               | The Moving Picture Company  |
| System Administrator    | 127 Wardour Street          |
|.........................| London, W1F 0NL             | 





From rms at 1407.org  Thu May  6 12:24:24 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Thu, 06 May 2004 13:24:24 +0100
Subject: project to get desktop items to follow HIG so it can get
	included in FC3
In-Reply-To: <20040506102724.GA8316@chrys.ms.mff.cuni.cz>
References: <BAY15-F132PEwr5Kk640000f195@hotmail.com>
	<1083837683.3822.17.camel@roque>
	<20040506102724.GA8316@chrys.ms.mff.cuni.cz>
Message-ID: <1083846264.3822.49.camel@roque>

On Thu, 2004-05-06 at 12:27 +0200, Miloslav Trmac wrote:
> On Thu, May 06, 2004 at 11:01:23AM +0100, Rui Miguel Seabra wrote:
> > On Thu, 2004-05-06 at 09:34 +0000, Kristof Vansant wrote:
> > Likewise, it is absurd if these fields are not handled like they should

From alan at redhat.com  Thu May  6 14:00:08 2004
From: alan at redhat.com (Alan Cox)
Date: Thu, 6 May 2004 10:00:08 -0400
Subject: Embedded Fedora - soon?
In-Reply-To: <4099B6B7.8070801@ezrs.com>
References: <4099B6B7.8070801@ezrs.com>
Message-ID: <20040506140008.GD8828@devserv.devel.redhat.com>

On Thu, May 06, 2004 at 11:53:27AM +0800, Sharuzzaman Ahmat Raslan wrote:
> http://www.linuxdevices.com/news/NS4819874726.html
> 
> Seems like Red Hat is going into embedded. Any plan for Fedora?

Perhaps we should get the CVS running first but at that point the question
becomes "anyone want to ?"

Alan




From buildsys at redhat.com  Thu May  6 15:16:02 2004
From: buildsys at redhat.com (Build System)
Date: Thu, 6 May 2004 11:16:02 -0400
Subject: rawhide report: 20040506 changes
Message-ID: <200405061516.i46FG2L02734@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-9.93-0.20040504202210
------------------------------
* Tue May 04 2004 Anaconda team <bugzilla at redhat.com>

- built new version from CVS

* Fri Apr 30 2004 Jeremy Katz <katzj at redhat.com>

- Update description, remove prereq on stuff that was only needed 
  for reconfig mode

* Tue Feb 24 2004 Jeremy Katz <katzj at redhat.com>

- buildrequire libselinux-devel


anaconda-images-10-1
--------------------

ant-1.5.2-26
------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.5.2-26

- Rebuild with new compiler.

at-3.1.8-53
-----------
* Tue May 04 2004 Dan Walsh <dwalsh at redhat.com> - 3.1.8-53

- Add fileentrypoint check

control-center-2.6.1-3
----------------------
* Wed May 05 2004 Warren Togami <wtogami at redhat.com> 1:2.6.1-3

- workaround "evolution-1.6" bug, always point at /usr/bin/evolution
- Preferred Applications should be visible from KDE

cyrus-imapd-2.2.3-10
--------------------
* Wed May 05 2004 Justin M. Forbes <64bit_fedora at comcast.net> 2.2.3-10

- fix init for lib64 systems (#119438)
- rename fetchnews to cyrfetchnews to avoid namespace conflicts with leafnode
- replace fetchnews with cyrfetchnews in man pages
- replace master with cyrus-master in man pages

desktop-printing-0.1.10-26
--------------------------
* Wed May 05 2004 Tim Waugh <twaugh at redhat.com> 0.1.10-26

- Don't poll cupsd; rely on D-BUS for notifications.  This prevents cups
  generating never-ending useless log messages.

fedora-logos-1.1.24-1
---------------------
* Wed May 05 2004 Jeremy Katz <katzj at redhat.com> - 1.1.24-1

- newer grub image for fc2

hpoj-0.91-7
-----------
* Wed May 05 2004 Tim Waugh <twaugh at redhat.com> 0.91-7

- Fix up security contexts (bug #120054).

hwdata-0.118-1
--------------
* Wed May 05 2004 Jeremy Katz <katzj at redhat.com> - 0.118-1

- add a wireless card (#122064)
- and a monitor (#121696)

initscripts-7.52-1
------------------
* Tue May 04 2004 Bill Nottingham <notting at redhat.com> 7.52-1

- ipv4 addresses are ints, not longs (#122479)

kdemultimedia-3.2.2-2
---------------------
* Wed May 05 2004 Than Ngo <than at redhat.com> 6:3.2.2-2

- cleanup KDE/GNOME menu
- add obsolete juk

kernel-2.6.5-1.351
------------------
* Wed May 05 2004 Arjan van de Ven <arjanv at redhat.com>

- fix bug 122504
- convert b44 to ethtool ops (jgarzik)
- make IDE do a cache-flush on shutdown (me/Alan)

kudzu-1.1.60-1
--------------
* Wed May 05 2004 Jeremy Katz <katzj at redhat.com> 1.1.60-1

- fix checking of modules loaded which have a - in their name as 
  /proc/modules will contain an _ instead (#121955, #120289, #120360)

lha-1.14i-14
------------
* Wed May 05 2004 Than Ngo <than at redhat.com> 1.14i-14

- fix security vulnerabilities, CAN-2004-0234, CAN-2004-0235

libgsf-1.9.0-1
--------------
* Wed May 05 2004 Caolan McNamara <caolanm at redhat.com> 1.9.0-1

* upgrade to 1.9.0 to get crash fixes

libselinux-1.11.4-1
-------------------
* Wed May 05 2004 Dan Walsh <dwalsh at redhat.com> 1.11.4-1

- Update with latest from NSA

mailman-2.1.4-4
---------------
* Tue May 04 2004 Warren Togami <wtogami at redhat.com> 3:2.1.4-4

- #105638 fix bytecompile and rpm -V
- postun /etc/postfix/aliases fix
- clean uninstall (no more empty dirs)
- #115378 RedirectMatch syntax fix

modutils-2.4.26-16
------------------
* Wed May 05 2004 Bill Nottingham <notting at redhat.com> 2.4.26-16

- fix sound restoring on module load when done via OSS compat

mozilla-1.6-5
-------------
* Wed May 05 2004 Warren Togami <wtogami at redhat.com> 37:1.6-5

- Preferred Application supporting hack

mx4j-1.1.1-9
------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.1.1-9

- Rebuild with new compiler.

policycoreutils-1.11-1
----------------------
* Wed May 05 2004 Dan Walsh <dwalsh at redhat.com> 1.11-1

- update to match NSA

* Wed Apr 28 2004 Dan Walsh <dwalsh at redhat.com> 1.10-4

- Log fixfiles to the /tmp directory

rpmdb-fedora-1.92-0.20040506
----------------------------

setup-2.5.33-1
--------------
* Wed May 05 2004 Nalin Dahyabhai <nalin at redhat.com> 2.5.33-1

- fix syntax error in csh.cshrc

xfsprogs-2.6.13-1
-----------------
* Wed May 05 2004 Jeremy Katz <katzj at redhat.com> - 2.6.13-1

- update to 2.6.13 per request of upstream
- fixes mount by label of xfs on former raid partition (#122043)

xscreensaver-4.14-5
-------------------
* Wed May 05 2004 Bill Nottingham <notting at redhat.com> 4.14-5

- config tweaks




From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Thu May  6 16:04:41 2004
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Thu, 6 May 2004 18:04:41 +0200
Subject: Latest tree broke rpm?
In-Reply-To: <20040505215517.GF30909@devserv.devel.redhat.com>
References: <20040505195208.441a4f26@localhost>
	<20040505195853.2e95e49c@localhost>
	<20040505190446.GD30909@devserv.devel.redhat.com>
	<20040505215517.GF30909@devserv.devel.redhat.com>
Message-ID: <20040506180441.188568f8@localhost>

Jakub Jelinek wrote :

> > When this is printed, this means /sbin/ldconfig surely had to be run
> > successfully.
> 
> Actually, I found out what's going on.
> If you are unlucky and /sbin/ldconfig run in glibc_post_upgrade (from
> glibc's %post) is the last /sbin/ldconfig run during the update,
> then at the point when that /sbin/ldconfig is run, files from both
> new glibc and old glibc might still exist in the filesystem.
> Particularly there might be still /lib/tls/librtkaio-2.3.3.so
> (from glibc-2.3.3-20 or earlier) and /lib/tls/librt-2.3.3.so (from
> glibc-2.3.3-24 (well, -21 or later, the rpm currently being installed)).
> The libraries have the same SONAME (that's because they provide the same
> ABI, librt.so.1) but different filename (librtkaio uses kernel aio,
> librt is pure userland implementation).
> Unfortunately librtkaio is the one picked by ldconfig, so librt.so.1
> stays pointing to librtkaio-2.3.3.so.  Some time after glibc %post ends
> rpm removes /lib/tls/librtkaio-2.3.3.so (as it is present just in the old
> package) and there is a stale symlink.
> 
> If you are lucky and some other package's %post runs ldconfig after the
> librtkaio-2.3.3.so file is removed (or if you are upgrading already
> from glibc which did not have that file), everything is fine.
> 
> Guess I'll need to add some more ugly hacks into glibc_post_upgrade :(.
> 
> FYI, librtkaio has been removed for FC2, because 2.6.x kernel AIO support
> is in a bad shape and insufficient for POSIX AIO on top of it.

Thanks a lot for tracking this down and giving such a detailed
explanation about the problem!

I think such glibc knowledge would be useful to track down something
funny that has been seen when trying to run a FC1 chroot on a FC2 test
host... can't point to the discussion as sf.net lists seem to have
stopped archiving, though :-(
Basically all applications in the FC1 root segfault, and this doesn't
happen with FC2test or RHLx roots and is reproducible. If it rings a
bell, pointers are welcome ;-)

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1.92 (FC2 Test 3) - Linux kernel 2.6.5-1.350
Load : 0.49 0.53 0.45




From dax at gurulabs.com  Thu May  6 16:21:33 2004
From: dax at gurulabs.com (Dax Kelson)
Date: Thu, 06 May 2004 10:21:33 -0600
Subject: Force IDE flush on shutdown
Message-ID: <1083860493.3736.4.camel@mentor.gurulabs.com>


heh

I noticed that on FCT3 every time I rebooted, my ext3 journal was being
replayed.

I guess this was the problem?

-- 
Dax Kelson




From arjanv at redhat.com  Thu May  6 16:22:37 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 06 May 2004 18:22:37 +0200
Subject: Force IDE flush on shutdown
In-Reply-To: <1083860493.3736.4.camel@mentor.gurulabs.com>
References: <1083860493.3736.4.camel@mentor.gurulabs.com>
Message-ID: <1083860557.3844.9.camel@laptop.fenrus.com>

On Thu, 2004-05-06 at 18:21, Dax Kelson wrote:
> heh
> 
> I noticed that on FCT3 every time I rebooted, my ext3 journal was being
> replayed.
> 
> I guess this was the problem?

run the 353 kernel from http://people.redhat.com/arjanv/2.6 and let me
know ;)

-------------- 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/20040506/3a63e2b5/attachment.sig>

From czar at czarc.net  Thu May  6 16:39:29 2004
From: czar at czarc.net (Gene C.)
Date: Thu, 6 May 2004 12:39:29 -0400
Subject: rawhide report: 20040506 changes
In-Reply-To: <200405061516.i46FG2L02734@porkchop.devel.redhat.com>
References: <200405061516.i46FG2L02734@porkchop.devel.redhat.com>
Message-ID: <200405061239.29492.czar@czarc.net>

On Thursday 06 May 2004 11:16, Build System wrote:
> kernel-2.6.5-1.351
> ------------------
> * Wed May 05 2004 Arjan van de Ven <arjanv at redhat.com>
>
> - fix bug 122504
> - convert b44 to ethtool ops (jgarzik)
> - make IDE do a cache-flush on shutdown (me/Alan)

Caution ... this causes problems (cache-flush I believe) on x86_64 ... see 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122648
-- 
Gene




From czar at czarc.net  Thu May  6 16:50:06 2004
From: czar at czarc.net (Gene C.)
Date: Thu, 6 May 2004 12:50:06 -0400
Subject: Force IDE flush on shutdown
In-Reply-To: <1083860557.3844.9.camel@laptop.fenrus.com>
References: <1083860493.3736.4.camel@mentor.gurulabs.com>
	<1083860557.3844.9.camel@laptop.fenrus.com>
Message-ID: <200405061250.06137.czar@czarc.net>

On Thursday 06 May 2004 12:22, Arjan van de Ven wrote:
> run the 353 kernel from http://people.redhat.com/arjanv/2.6 and let me
> know ;)

There is no 353 although there is 352.

Will this address https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122648
-- 
Gene




From arjanv at redhat.com  Thu May  6 16:51:14 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 06 May 2004 18:51:14 +0200
Subject: rawhide report: 20040506 changes
In-Reply-To: <200405061239.29492.czar@czarc.net>
References: <200405061516.i46FG2L02734@porkchop.devel.redhat.com>
	<200405061239.29492.czar@czarc.net>
Message-ID: <1083862274.3844.11.camel@laptop.fenrus.com>

On Thu, 2004-05-06 at 18:39, Gene C. wrote:
> On Thursday 06 May 2004 11:16, Build System wrote:
> > kernel-2.6.5-1.351
> > ------------------
> > * Wed May 05 2004 Arjan van de Ven <arjanv at redhat.com>
> >
> > - fix bug 122504
> > - convert b44 to ethtool ops (jgarzik)
> > - make IDE do a cache-flush on shutdown (me/Alan)
> 
> Caution ... this causes problems

well they cause spewage, problems might be overstated ;)
-------------- 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/20040506/3c3acd50/attachment.sig>

From czar at czarc.net  Thu May  6 17:00:16 2004
From: czar at czarc.net (Gene C.)
Date: Thu, 6 May 2004 13:00:16 -0400
Subject: rawhide report: 20040506 changes
In-Reply-To: <1083862274.3844.11.camel@laptop.fenrus.com>
References: <200405061516.i46FG2L02734@porkchop.devel.redhat.com>
	<200405061239.29492.czar@czarc.net>
	<1083862274.3844.11.camel@laptop.fenrus.com>
Message-ID: <200405061300.16987.czar@czarc.net>

On Thursday 06 May 2004 12:51, Arjan van de Ven wrote:
> On Thu, 2004-05-06 at 18:39, Gene C. wrote:
> > On Thursday 06 May 2004 11:16, Build System wrote:
> > > kernel-2.6.5-1.351
> > > ------------------
> > > * Wed May 05 2004 Arjan van de Ven <arjanv at redhat.com>
> > >
> > > - fix bug 122504
> > > - convert b44 to ethtool ops (jgarzik)
> > > - make IDE do a cache-flush on shutdown (me/Alan)
> >
> > Caution ... this causes problems
>
> well they cause spewage, problems might be overstated ;)

Does this mean that inspite of the messages, everything is really OK?

If this goes into the final I would expect lots of bugzilla reports.  Messages 
like those which occurred on my x86_64 system (but not on a dual processor 
i686 system) will not indicate "no problems" to most users.
-- 
Gene




From arjanv at redhat.com  Thu May  6 17:13:59 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 06 May 2004 19:13:59 +0200
Subject: rawhide report: 20040506 changes
In-Reply-To: <200405061300.16987.czar@czarc.net>
References: <200405061516.i46FG2L02734@porkchop.devel.redhat.com>
	<200405061239.29492.czar@czarc.net>
	<1083862274.3844.11.camel@laptop.fenrus.com>
	<200405061300.16987.czar@czarc.net>
Message-ID: <1083863639.3844.14.camel@laptop.fenrus.com>

On Thu, 2004-05-06 at 19:00, Gene C. wrote:
> On Thursday 06 May 2004 12:51, Arjan van de Ven wrote:
> > On Thu, 2004-05-06 at 18:39, Gene C. wrote:
> > > On Thursday 06 May 2004 11:16, Build System wrote:
> > > > kernel-2.6.5-1.351
> > > > ------------------
> > > > * Wed May 05 2004 Arjan van de Ven <arjanv at redhat.com>
> > > >
> > > > - fix bug 122504
> > > > - convert b44 to ethtool ops (jgarzik)
> > > > - make IDE do a cache-flush on shutdown (me/Alan)
> > >
> > > Caution ... this causes problems
> >
> > well they cause spewage, problems might be overstated ;)
> 
> Does this mean that inspite of the messages, everything is really OK?
> 
> If this goes into the final I would expect lots of bugzilla reports.  Messages 
> like those which occurred on my x86_64 system (but not on a dual processor 
> i686 system) will not indicate "no problems" to most users.

can you check with hdparm if the writeback cache is on in your disk ?
-------------- 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/20040506/b077c018/attachment.sig>

From alan at redhat.com  Thu May  6 17:44:09 2004
From: alan at redhat.com (Alan Cox)
Date: Thu, 6 May 2004 13:44:09 -0400
Subject: Force IDE flush on shutdown
In-Reply-To: <1083860493.3736.4.camel@mentor.gurulabs.com>
References: <1083860493.3736.4.camel@mentor.gurulabs.com>
Message-ID: <20040506174409.GA25558@devserv.devel.redhat.com>

On Thu, May 06, 2004 at 10:21:33AM -0600, Dax Kelson wrote:
> I noticed that on FCT3 every time I rebooted, my ext3 journal was being
> replayed.
> 
> I guess this was the problem?

On some disks the result is more evil the log is written back so looks good
but other stuff like bitmap blocks are not. 

But yes thats probably the flush bug (update btw it seems that SATA also
has it)




From arjanv at redhat.com  Thu May  6 19:43:17 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 06 May 2004 21:43:17 +0200
Subject: rawhide report: 20040506 changes
In-Reply-To: <200405061300.16987.czar@czarc.net>
References: <200405061516.i46FG2L02734@porkchop.devel.redhat.com>
	<200405061239.29492.czar@czarc.net>
	<1083862274.3844.11.camel@laptop.fenrus.com>
	<200405061300.16987.czar@czarc.net>
Message-ID: <1083872597.3844.23.camel@laptop.fenrus.com>


> the final I would expect lots of bugzilla reports.  Messages 
> like those which occurred on my x86_64 system (but not on a dual processor 
> i686 system) will not indicate "no problems" to most users.
> -- 
> Gene

can we please get a cat /proc/ide/hda/identify for this drive ?
-------------- 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/20040506/e4e8e3ac/attachment.sig>

From havill at redhat.com  Thu May  6 19:51:54 2004
From: havill at redhat.com (Adrian Havill)
Date: Thu, 06 May 2004 15:51:54 -0400
Subject: mozilla [jaJP langpack] on fedora core 2
Message-ID: <409A975A.3060401@redhat.com>

>
>
>Although fedora core 2 test 3 in Japanese is installed on my PC ,
>Mozilla(1.6)'s menu is in English. But Japanese localized Mozilla is
>already released.
>  
>
Thanks for pointing this out. I've informed the maintainer of the 1.6
mozilla.gr.jp language pack link.

>Will Mozilla on fedora core 2 be localized for Japanese? Or not?
>
It's late to notice something like this, but hopefully it'll get in
before the freeze.

Next time, please file a bug in bugzilla.




From arjanv at redhat.com  Thu May  6 21:21:56 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 6 May 2004 23:21:56 +0200
Subject: kernel testing request
Message-ID: <20040506212156.GB10775@devserv.devel.redhat.com>

Hi,

We're chasing that IDE dmesg spew bug hard and we have a test kernel with
what we think will fix it. I would like to ask the people who got the IDE
errors in kernel 351/352 to please test kernel 353 from
http://people.redhat.com/arjanv/2.6
and report to me or in bug 122648 if the errors have gone away.
If they haven't I'd like to get the output of cat /proc/ide/hda/identify
(assuming hda is the disk in question) for futher investigation.

Thanks,
   Arjan van de Ven

-------------- 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/20040506/1689142a/attachment.sig>

From akabi at speakeasy.net  Thu May  6 21:36:16 2004
From: akabi at speakeasy.net (ne...)
Date: Thu, 6 May 2004 17:36:16 -0400 (EDT)
Subject: Force IDE flush on shutdown
In-Reply-To: <200405061250.06137.czar@czarc.net>
References: <1083860493.3736.4.camel@mentor.gurulabs.com>
	<1083860557.3844.9.camel@laptop.fenrus.com>
	<200405061250.06137.czar@czarc.net>
Message-ID: <Pine.LNX.4.53.0405061735420.995@mach1.guhvies.org>

On May 6, 2004 at 12:50, Gene C. in a soothing rage wrote:

>On Thursday 06 May 2004 12:22, Arjan van de Ven wrote:
>> run the 353 kernel from http://people.redhat.com/arjanv/2.6 and let me
>> know ;)
>
>There is no 353 although there is 352.
There is now. Please look again.

N.Emile...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Switch to: http://www.speakeasy.net/refer/190653
If your mother knew what you're doing, she'd probably hang her head and cry.
 17:35:42  up 47 days,  6:08,  3 users,  load average: 0.00, 0.00, 0.00




From shfukuzawa at jcom.home.ne.jp  Thu May  6 20:52:22 2004
From: shfukuzawa at jcom.home.ne.jp (Shun Fukuzawa)
Date: Fri, 07 May 2004 05:52:22 +0900
Subject: mozilla [jaJP langpack] on fedora core 2
In-Reply-To: <409A975A.3060401@redhat.com>
References: <409A975A.3060401@redhat.com>
Message-ID: <409AA586.4020808@jcom.home.ne.jp>

Thanks for your responce.

Adrian Havill wrote:
>>
>>Although fedora core 2 test 3 in Japanese is installed on my PC ,
>>Mozilla(1.6)'s menu is in English. But Japanese localized Mozilla is
>>already released.
>> 
>>
> 
> Thanks for pointing this out. I've informed the maintainer of the 1.6
> mozilla.gr.jp language pack link.
> 
Thanks.

But tar.gz fromat localized mozilla is in below link.
http://www.mozilla.org/releases/#1.6

> 
>>Will Mozilla on fedora core 2 be localized for Japanese? Or not?
>>
> 
> It's late to notice something like this, but hopefully it'll get in
> before the freeze.
> 
O.K.

> Next time, please file a bug in bugzilla.
> 
O.K. Thanks.




From czar at czarc.net  Thu May  6 22:34:00 2004
From: czar at czarc.net (Gene C.)
Date: Thu, 6 May 2004 18:34:00 -0400
Subject: kernel testing request
In-Reply-To: <20040506212156.GB10775@devserv.devel.redhat.com>
References: <20040506212156.GB10775@devserv.devel.redhat.com>
Message-ID: <200405061834.00773.czar@czarc.net>

On Thursday 06 May 2004 17:21, Arjan van de Ven wrote:
> We're chasing that IDE dmesg spew bug hard and we have a test kernel with
> what we think will fix it. I would like to ask the people who got the IDE
> errors in kernel 351/352 to please test kernel 353 from
> http://people.redhat.com/arjanv/2.6
> and report to me or in bug 122648 if the errors have gone away.
> If they haven't I'd like to get the output of cat /proc/ide/hda/identify
> (assuming hda is the disk in question) for futher investigation.

OK, with kernel 353 the error messages are gone for /dev/hda (regular ide) but 
I still got an error for the /dev/hde SATA drive.  The info is posted to 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122648
-- 
Gene




From czar at czarc.net  Thu May  6 22:09:42 2004
From: czar at czarc.net (Gene C.)
Date: Thu, 6 May 2004 18:09:42 -0400
Subject: rawhide report: 20040506 changes
In-Reply-To: <1083872597.3844.23.camel@laptop.fenrus.com>
References: <200405061516.i46FG2L02734@porkchop.devel.redhat.com>
	<200405061300.16987.czar@czarc.net>
	<1083872597.3844.23.camel@laptop.fenrus.com>
Message-ID: <200405061809.42563.czar@czarc.net>

On Thursday 06 May 2004 15:43, Arjan van de Ven wrote:
> > the final I would expect lots of bugzilla reports.  Messages
> > like those which occurred on my x86_64 system (but not on a dual
> > processor i686 system) will not indicate "no problems" to most users.
> > --
> > Gene
>
> can we please get a cat /proc/ide/hda/identify for this drive ?

The information has been posted to 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122648
-- 
Gene




From naoki at valuecommerce.com  Fri May  7 01:25:41 2004
From: naoki at valuecommerce.com (Naoki)
Date: Fri, 07 May 2004 10:25:41 +0900
Subject: Test 3 bugs.
Message-ID: <409AE595.60607@valuecommerce.com>

ACPI on most laptops kernel panics.
NVidia driver locks up on exiting X windows ( display corruption and 
then hang).
X error on startup (not fatal, press a button ok but still ugly).

People know about these and I can forget them?




From nathanr at nathanr.net  Thu May  6 22:26:31 2004
From: nathanr at nathanr.net (Nathan Robertson)
Date: Fri, 7 May 2004 08:26:31 +1000
Subject: rawhide report: 20040506 changes
In-Reply-To: <200405061516.i46FG2L02734@porkchop.devel.redhat.com>
References: <200405061516.i46FG2L02734@porkchop.devel.redhat.com>
Message-ID: <6CC62F5C-9FAC-11D8-B01E-000D935221F2@nathanr.net>

On 07/05/2004, at 1:16 AM, Build System wrote:

> ant-1.5.2-26
> ------------
> * Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.5.2-26
>
> - Rebuild with new compiler.

Hmm. This seems a bit old. Ant 1.6 has been out for a while now (1.6.1 
is the latest), and I've been using at work without problems since the 
1.6 beta stage. We even shipped it with our product, and customers 
haven't complained about there being issues with it.

I think the last version of 1.5 was 1.5.4 (from memory, their website 
and download section only mention 1.6.1 now), so if my memory serves me 
right, this isn't even the latest 1.5 build.

Nathan.




From naoki at valuecommerce.com  Fri May  7 01:55:24 2004
From: naoki at valuecommerce.com (Naoki)
Date: Fri, 07 May 2004 10:55:24 +0900
Subject: Test 3 bugs.
In-Reply-To: <409AE595.60607@valuecommerce.com>
References: <409AE595.60607@valuecommerce.com>
Message-ID: <409AEC8C.6080804@valuecommerce.com>

Also, shifting through gnome terminal tabs with CTRL-PGUP/PGDN causes a 
"~5" to be written to the terminal if you try and over step the bounds 
on either side.

Naoki wrote:

> ACPI on most laptops kernel panics.
> NVidia driver locks up on exiting X windows ( display corruption and 
> then hang).
> X error on startup (not fatal, press a button ok but still ugly).
>
> People know about these and I can forget them?
>
>




From smoogen at lanl.gov  Fri May  7 02:16:16 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Thu, 6 May 2004 20:16:16 -0600 (MDT)
Subject: Embedded Fedora - soon?
In-Reply-To: <20040506140008.GD8828@devserv.devel.redhat.com>
References: <4099B6B7.8070801@ezrs.com>
	<20040506140008.GD8828@devserv.devel.redhat.com>
Message-ID: <Pine.LNX.4.58.0405062015390.24701@smoogen1.lanl.gov>

On Thu, 6 May 2004, Alan Cox wrote:

>On Thu, May 06, 2004 at 11:53:27AM +0800, Sharuzzaman Ahmat Raslan wrote:
>> http://www.linuxdevices.com/news/NS4819874726.html
>> 
>> Seems like Red Hat is going into embedded. Any plan for Fedora?
>
>Perhaps we should get the CVS running first but at that point the question
>becomes "anyone want to ?"
>

I can see a use for it.. but I would say there are a ton of things that 
need to be done before the various fedora ports begin.

>Alan
>
>
>

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From fedora at andrewfarris.com  Fri May  7 03:22:55 2004
From: fedora at andrewfarris.com (Andrew Farris)
Date: Thu, 06 May 2004 20:22:55 -0700
Subject: Test 3 bugs.
In-Reply-To: <409AE595.60607@valuecommerce.com>
References: <409AE595.60607@valuecommerce.com>
Message-ID: <1083900174.11121.8.camel@CirithUngol>

On Fri, 2004-05-07 at 10:25 +0900, Naoki wrote:
> ACPI on most laptops kernel panics.

'most' is impossible to make meaningful.  Which kernel is being used..
what is being used with acpi, what the exact hardware is, and the kernel
panic are necessary pieces of information.  When you do gather that,
search Bugzilla for similar issues...

> NVidia driver locks up on exiting X windows ( display corruption and 
> then hang).

Not a Fedora problem, an nVIDIA problem -- they know about it but
posting to www.nvnews.net linux forum wouldn't hurt.  Again, details
(video bios / card model, driver being used / agp chipset and modo
specs..)

> X error on startup (not fatal, press a button ok but still ugly).

If you are referring to something similar to: "Error activating XKB
configuration." then it is known and fixed.
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120858

-- 
Andrew Farris, CPE senior (California Polytechnic State University, SLO)
fedora at andrewfarris.com :: lmorgul on irc.freenode.net
"The only thing necessary for the triumph of evil is for good men
to do nothing." (Edmond Burke)




From wtogami at redhat.com  Fri May  7 04:51:40 2004
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 06 May 2004 18:51:40 -1000
Subject: Test 3 bugs.
In-Reply-To: <409AE595.60607@valuecommerce.com>
References: <409AE595.60607@valuecommerce.com>
Message-ID: <409B15DC.3060008@redhat.com>

Naoki wrote:
> ACPI on most laptops kernel panics.
> NVidia driver locks up on exiting X windows ( display corruption and 
> then hang).
> X error on startup (not fatal, press a button ok but still ugly).
> 
> People know about these and I can forget them?
> 
> 

All of these issues are improper for discussion in fedora-devel-list. 
Please use fedora-test-list for support issues like this.  And always 
search lists before asking, because all of those issues have been 
discussed at length on fedora-test-list.

fedora-devel-list is for developer discussion, mainly implementation of 
fixes, not complaining about problems.

Warren Togami
wtogami at redhat.com




From wtogami at redhat.com  Fri May  7 07:30:54 2004
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 06 May 2004 21:30:54 -1000
Subject: I2O kudzu + anaconda Status
Message-ID: <409B3B2E.2050708@redhat.com>

Test results from I2O installation... failure.

I rebuilt my own tree with rawhide + modified kudzu + grub + lvm2. 
Booted x86_64 boot.iso.

<jeremy> warren_laptop: I haven't moved them yet... still staring at 
anaconda.  but going cross-eyed, so think I'll move them and just finish 
looking at anaconda in the morning
<jeremy> you'll get told that there are no hard drives in the loader, 
but then if you continue, you should see them in disk druid

Anaconda says there are no hard drives in the loader, and when I go to 
Disk Druid it says this fatal message, "An error has ocurred - no valid 
devices were found on which to create new file systems.  Please check 
your hardware for the cause of this problem."

In ALT-F2, kudzu-probe displays this among the devices:

Scanning for SCSI Controllers
	Device Distributed tech|SmartRAID V Controller:
	    Desc:	Distributed Tech|SmartRAID V Controller
	    Driver:	dpt_i2o
	    Device:	None

kudzu still knows about the old 2.4 kernel dpt_i2o driver, while in this 
kernel we are using i2o_block.  I suspect kudzu or hwdata needs 
changing, and kudzu needs more changing to work properly here.  I am 
working more on this again in several hours after I fix a few xorg-x11 
upgrade issues.

Warren Togami
wtogami at redhat.com




From rhl-devel-list at lnx.ro  Fri May  7 08:19:58 2004
From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu)
Date: Fri, 07 May 2004 11:19:58 +0300
Subject: I2O kudzu + anaconda Status
In-Reply-To: <409B3B2E.2050708@redhat.com>
References: <409B3B2E.2050708@redhat.com>
Message-ID: <1083917999.7802.4.camel@localhost.localdomain>

On Thu, 2004-05-06 at 21:30 -1000, Warren Togami wrote:
> kudzu still knows about the old 2.4 kernel dpt_i2o driver, while in this 
> kernel we are using i2o_block.  I suspect kudzu or hwdata needs 
> changing, and kudzu needs more changing to work properly here.  I am 
> working more on this again in several hours after I fix a few xorg-x11 
> upgrade issues.


Will it work for update ?
As in up2date -u kernel, and the install script to
change /etc/modprobe.conf.

Is there any doc for the i2o block driver?
I was being misguided and I put i2o_scsi instead of dpt_i2o in
modprobe.conf and it failed on me. Should it work with i2o_block ?

-- 
Cioby





From wtogami at redhat.com  Fri May  7 08:53:26 2004
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 06 May 2004 22:53:26 -1000
Subject: I2O kudzu + anaconda Status
In-Reply-To: <1083917999.7802.4.camel@localhost.localdomain>
References: <409B3B2E.2050708@redhat.com>
	<1083917999.7802.4.camel@localhost.localdomain>
Message-ID: <409B4E86.5080409@redhat.com>

Dumitru Ciobarcianu wrote:
> On Thu, 2004-05-06 at 21:30 -1000, Warren Togami wrote:
> 
>>kudzu still knows about the old 2.4 kernel dpt_i2o driver, while in this 
>>kernel we are using i2o_block.  I suspect kudzu or hwdata needs 
>>changing, and kudzu needs more changing to work properly here.  I am 
>>working more on this again in several hours after I fix a few xorg-x11 
>>upgrade issues.
> 
> 
> 
> Will it work for update ?
> As in up2date -u kernel, and the install script to
> change /etc/modprobe.conf.

Other changes in your config will be needed because your block devices 
change from /dev/sd* to /dev/i2o/hd*.

> 
> Is there any doc for the i2o block driver?
> I was being misguided and I put i2o_scsi instead of dpt_i2o in
> modprobe.conf and it failed on me. Should it work with i2o_block ?
> 

i2o_scsi is almost never used because it is for accessing disks 
directly.  i2o_block is used for accessing the logical block devices of 
your I2O RAID controller.  If you have disabled RAID arrays, then these 
block devices become the individual disks.

Note that only 351 and later kernels are patched with Markus Lidel's 
newer fixes.  All previous kernels have severe problems if your RAID 
controller has more than a single logical array.

http://i2o.shadowconnect.com/
One more patch for i2o_proc available at Markus' I2O homepage, along 
with other information.

Warren Togami
wtogami at redhat.com




From rhl-devel-list at lnx.ro  Fri May  7 10:17:49 2004
From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu)
Date: Fri, 07 May 2004 13:17:49 +0300
Subject: I2O kudzu + anaconda Status
In-Reply-To: <409B4E86.5080409@redhat.com>
References: <409B3B2E.2050708@redhat.com>
	<1083917999.7802.4.camel@localhost.localdomain>
	<409B4E86.5080409@redhat.com>
Message-ID: <1083925069.21300.1.camel@localhost.localdomain>

On Thu, 2004-05-06 at 22:53 -1000, Warren Togami wrote:
> Other changes in your config will be needed because your block devices 
> change from /dev/sd* to /dev/i2o/hd*.


Shouldn't LABEL= take care of that ?

-- 
Cioby






From wtogami at redhat.com  Fri May  7 10:40:11 2004
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 07 May 2004 00:40:11 -1000
Subject: I2O kudzu + anaconda Status
In-Reply-To: <1083925069.21300.1.camel@localhost.localdomain>
References: <409B3B2E.2050708@redhat.com>	<1083917999.7802.4.camel@localhost.localdomain>	<409B4E86.5080409@redhat.com>
	<1083925069.21300.1.camel@localhost.localdomain>
Message-ID: <409B678B.1000105@redhat.com>

Dumitru Ciobarcianu wrote:
> On Thu, 2004-05-06 at 22:53 -1000, Warren Togami wrote:
> 
>>Other changes in your config will be needed because your block devices 
>>change from /dev/sd* to /dev/i2o/hd*.
> 
> 
> 
> Shouldn't LABEL= take care of that ?
> 

If the kernel can't see the device because the driver is not loaded, 
LABEL=  is not enough.  For this reason you would need to manually run 
mkinitrd to preload the right modules.

Warren




From phil at phil-anderson.com  Fri May  7 11:01:09 2004
From: phil at phil-anderson.com (Phil Anderson)
Date: Fri, 07 May 2004 21:01:09 +1000
Subject: dovecot default authentication change
Message-ID: <1083927669.3424.5.camel@hallucination.phil-anderson.com>

Hi,

I just upgraded my system from FC1 to Test 3, and it broke my dovecot
installation.  When I looked in the system log, it was immediately
obvious.  The default authentication in dovecot has changed from passwd
authentication to be postgres.

What is the reason for this?  The best thing that dovecot has going for
it is that it requires no setup, compared to cyrus-imap.  Now that this
default behaviour has changed, it changes this.

Is this intentional?  Or has it just been transfered from upstream?  In
which case, I think Fedora should have passwd authentication by default.

Any thoughts on this?

Phil




From wtogami at redhat.com  Fri May  7 11:32:09 2004
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 07 May 2004 01:32:09 -1000
Subject: dovecot default authentication change
In-Reply-To: <1083927669.3424.5.camel@hallucination.phil-anderson.com>
References: <1083927669.3424.5.camel@hallucination.phil-anderson.com>
Message-ID: <409B73B9.3040002@redhat.com>

Phil Anderson wrote:
> Hi,
> 
> I just upgraded my system from FC1 to Test 3, and it broke my dovecot
> installation.  When I looked in the system log, it was immediately
> obvious.  The default authentication in dovecot has changed from passwd
> authentication to be postgres.
> 
> What is the reason for this?  The best thing that dovecot has going for
> it is that it requires no setup, compared to cyrus-imap.  Now that this
> default behaviour has changed, it changes this.
> 
> Is this intentional?  Or has it just been transfered from upstream?  In
> which case, I think Fedora should have passwd authentication by default.
> 
> Any thoughts on this?
> 
> Phil
> 
> 

Good catch!  In reviewing the revision history it appears this came from 
upstream.  I am guessing this is totally not what we want shipping in 
Fedora as postgresql based authentication is far less common and more 
difficult to use than passwd.  I will see if I can fix this... already 
very close to absolute development freeze. =(

Warren




From buildsys at redhat.com  Fri May  7 12:48:41 2004
From: buildsys at redhat.com (Build System)
Date: Fri, 7 May 2004 08:48:41 -0400
Subject: rawhide report: 20040507 changes
Message-ID: <200405071248.i47Cmfx25945@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-10.0-1
---------------
* Thu May 06 2004 Anaconda team <bugzilla at redhat.com>

- built new version from CVS

* Fri Apr 30 2004 Jeremy Katz <katzj at redhat.com>

- Update description, remove prereq on stuff that was only needed 
  for reconfig mode

* Tue Feb 24 2004 Jeremy Katz <katzj at redhat.com>

- buildrequire libselinux-devel


boost-1.31.0-7
--------------
* Wed May 05 2004 Warren Togami <wtogami at redhat.com> 1.31.0-7

- missing Obsoletes boost-python

booty-0.38-1
------------
* Thu May 06 2004 Jeremy Katz <katzj at redhat.com> - 0.38-1

- remove ide-scsi from bootloader config on upgrade (#116622)

* Thu May 06 2004 Jeremy Katz <katzj at redhat.com> - 0.37-1

- clean up the xfs fix (#122606)
- altix boxes need relocatable (#120851)

cdrtools-2.01-0.a27.4
---------------------
* Thu May 06 2004 Harald Hoyer <harald at redhat.com> - 8:2.01-0.a27.4

- provide dvdrecord with a stub to cdrecord

commons-modeler-1.0-8
---------------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 1.0-8

- Rebuild with new compiler.

desktop-backgrounds-2.0-20
--------------------------
* Thu May 06 2004 Jeremy Katz <katzj at redhat.com> - 2.0-20

- background from Garrett for FC2

epiphany-1.2.4-1
----------------
* Wed May 05 2004 Warren Togami <wtogami at redhat.com> - 1.2.4-1

- update to 1.2.4 stable

evolution-1.4.6-2
-----------------
* Wed May 05 2004 Warren Togami <wtogami at redhat.com> 1.4.6-2

- link to evolution.desktop in redhat-menus

glibc-2.3.3-25
--------------
* Wed May 05 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-25

- update from CVS
- disable FUTEX_REQUEUE (work around #115349)
- mq for sparc/sparc64/ia64

gpm-1.20.1-49
-------------
* Tue May 04 2004 Adrian Havill <havill at redhat.com> 1.20.1-49

- remove superfluous "i die" msg (#121845)

grub-0.94-5
-----------
* Thu May 06 2004 Warren Togami <wtogami at redhat.com> - 0.94-5

- i2o patch from Markus Lidel

htmlview-3.0.0-4
----------------
* Wed May 05 2004 Warren Togami <wtogami at redhat.com> 3.00-4

- minor changes to htmlview
- add launchmail
- move redhat-email.desktop from evolution

httpd-2.0.49-4
--------------
* Thu May 06 2004 Joe Orton <jorton at redhat.com> 2.0.49-4

- make "noindex" page valid XHTML 1.1 (Pascal Volk, #122020)
- fix SEGV with no Listen directives (Michael Corcoran)
- mod_cgi: synch with 2.0 backport proposed upstream

initscripts-7.53-1
------------------
* Fri May 07 2004 Jeremy Katz <katzj at redhat.com> - 7.53-1

- little lvm tweak (#121963)

kdelibs-3.2.2-4
---------------
* Wed Apr 21 2004 Than Ngo <than at redhat.com> 3.2.2-4

- Implements the FreeDesktop System Tray Protocol, thanks to Harald Hoyer

kdepim-3.2.2-2
--------------
* Thu May 06 2004 Than Ngo <than at redhat.com> 6:3.2.2-2

- cleanup KDE/GNOME menu

kdesdk-3.2.2-2
--------------
* Wed May 05 2004 Than Ngo <than at redhat.com> 2:3.2.2-2

- cleanup KDE/GNOME menu

kdeutils-3.2.2-3
----------------
* Thu May 06 2004 Than Ngo <than at redhat.com> 6:3.2.2-3

- cleanup GNOME/KDE menu

kernel-2.6.5-1.352
------------------

kernel-2.6.5-1.353
------------------
* Thu May 06 2004 Arjan van de Ven <arjanv at redhat.com>

- some more ide cache flush fixes

kudzu-1.1.62-1
--------------
* Fri May 07 2004 Jeremy Katz <katzj at redhat.com> - 1.1.62-1

- add i2o probing code from Markus Lidel

* Thu May 06 2004 Karsten Hopp <karsten at redhat.com> 1.1.61-1

- fix QETH module name
- add HiperSockets 
- fix DASD detection

libgsf-1.9.0-2
--------------
* Thu May 06 2004 Dams <anvil[AT]livna.org> 1.9.0-2

- -devel now requires libgsf=version-release
- Added smp_mflags
- Fixed double included .so files

lvm2-2.00.15-2
--------------
* Thu May 06 2004 Warren Togami <wtogami at redhat.com> - 2.00.15-2

- i2o patch from Markus Lidel

metacity-2.8.1-2
----------------
* Thu May 06 2004 Havoc Pennington <hp at redhat.com> 2.8.1-2

- fix mangled Summary

* Thu May 06 2004 Havoc Pennington <hp at redhat.com> 2.8.1-1

- 2.8.1

mkinitrd-3.5.22-1
-----------------
* Thu May 06 2004 Jeremy Katz <katzj at redhat.com> - 3.5.22-1

- bump initrd size (#122325)

mozilla-1.6-6
-------------
* Wed May 05 2004 Warren Togami <wtogami at redhat.com> 37:1.6-6

- typo mozila.desktop fixed

ncurses-5.4-5
-------------
* Thu May 06 2004 Adrian Havill <havill at redhat.com> 5.4-5

- remove --with-gpm from configure, as it adds a pkg
  dependency (#122336) and causes too many problems vs its benefits

pan-0.14.2-7
------------
* Thu May 06 2004 Than Ngo <than at redhat.com> 1:0.14.2-7

- cleanup GNOME/KDE Menu

prelink-0.3.2-1
---------------
* Wed May 05 2004 Jakub Jelinek <jakub at redhat.com> 0.3.2-1

- fix cxx.c:68: find_cxx_sym: Assertive `n < ndeps' failed problem
  on 32-bit architectures (#118522)
- build prelink.cache into temporary file and atomically rename over
  (#121109)

qt-3.3.2-2
----------
* Tue May 04 2004 Than Ngo <than at redhat.com> 1:3.3.2-2

- fix broken symlink at qt document, bug #121652

redhat-menus-1.4.1-1
--------------------
* Fri May 07 2004 Than Ngo <than at redhat.com> 1.4.1-1

- release 1.4.1, add More submenu, fix Preferences/Others menu

* Wed May 05 2004 Warren Togami <wtogami at redhat.com> 1.4-2

- Temporary hacks for Preferred Browser launching in FC2

rpmdb-fedora-1.92-0.20040507
----------------------------

samba-3.0.3-5
-------------
* Tue May 04 2004 Jay Fenlason <fenlason at redhat.com> 3.0.3-5

- Patch to allow password changes from machines patched with
  Microsoft hotfix MS04-011.
- Include patches for https://bugzilla.samba.org/show_bug.cgi?id=1302
  and https://bugzilla.samba.org/show_bug.cgi?id=1309

setuptool-1.15-1
----------------
* Wed May 05 2004 Nalin Dahyabhai <nalin at redhat.com> 1.15-1

- prefer system-config-keyboard to kbdconfig (#122575)
- handle tools which require command-line arguments correctly

strace-4.5.3-1
--------------
* Fri Apr 16 2004 Roland McGrath <roland at redhat.com> 4.5.3-1

- new upstream version, mq_* calls (#120701), -p vs NPTL (#120462), more fixes (#118694, #120541, #118685)

* Tue Mar 02 2004 Elliot Lee <sopwith at redhat.com> 4.5.2-1.1

- rebuilt

* Mon Mar 01 2004 Roland McGrath <roland at redhat.com> 4.5.2-1

- new upstream version, sched_* calls (#116990), show core flag (#112117)


tomcat-4.1.27-13
----------------
* Tue May 04 2004 Gary Benson <gbenson at redhat.com> 4.1.27-13

- Rebuild with new compiler.

unixODBC-2.2.8-4
----------------
* Wed May 05 2004 Tom Lane <tgl at redhat.com> 2.2.8-4

- Add dependency to ensure kde subpackage stays in sync with main
  (needed because upstream moved odbctest from one pkg to the other,
  cf bug #122478)
- rebuilt

up2date-4.3.18-2
----------------
* Thu May 06 2004 Adrian Likins <alikins at redhat.com>

- point sources to new repo urls

* Thu May 06 2004 Warren Togami <wtogami at redhat.com>

- #69205 bytecompile for rpm -V

* Thu May 06 2004 Adrian Likins <alikins at redhat.com>

- fix #113773 from rbb at redhat.com (reset sigint
handler after rpm unsets it so ctrl-c works better)


yum-2.0.7-1
-----------
* Fri May 07 2004 Jeremy Katz <katzj at redhat.com> 2.0.7-1

- update to 2.0.7
- change config to point to final FC2 locations




From phil at phil-anderson.com  Fri May  7 13:55:38 2004
From: phil at phil-anderson.com (Phil Anderson)
Date: Fri, 07 May 2004 23:55:38 +1000
Subject: dovecot default authentication change
In-Reply-To: <1083927669.3424.5.camel@hallucination.phil-anderson.com>
References: <1083927669.3424.5.camel@hallucination.phil-anderson.com>
Message-ID: <1083938137.6691.2.camel@hallucination.phil-anderson.com>

On Fri, 2004-05-07 at 21:01, Phil Anderson wrote:
> I just upgraded my system from FC1 to Test 3, and it broke my dovecot
> installation.  When I looked in the system log, it was immediately
> obvious.  The default authentication in dovecot has changed from passwd
> authentication to be postgres.

Reported last week:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122212




From aleksey at nogin.org  Fri May  7 17:19:13 2004
From: aleksey at nogin.org (Aleksey Nogin)
Date: Fri, 07 May 2004 10:19:13 -0700
Subject: rawhide report: 20040507 changes
In-Reply-To: <200405071248.i47Cmfx25945@porkchop.devel.redhat.com>
References: <200405071248.i47Cmfx25945@porkchop.devel.redhat.com>
Message-ID: <409BC511.8010500@nogin.org>

On 07.05.2004 05:48, Build System wrote:

> cdrtools-2.01-0.a27.4
> ---------------------
> * Thu May 06 2004 Harald Hoyer <harald at redhat.com> - 8:2.01-0.a27.4
> 
> - provide dvdrecord with a stub to cdrecord

I am now getting:

file /usr/bin/dvdrecord from install of cdrecord-2.01-0.a27.4 conflicts 
with file from package dvdrecord-0.1.5-1
file /usr/share/man/man1/dvdrecord.1.gz from install of 
cdrecord-2.01-0.a27.4 conflicts with file from package dvdrecord-0.1.5-1

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907




From remco at rvt.com  Fri May  7 17:30:21 2004
From: remco at rvt.com (Remco Treffkorn)
Date: Fri, 7 May 2004 10:30:21 -0700
Subject: cdrom not a valid block device
Message-ID: <200405071030.21505.remco@rvt.com>


With kernel 327 and 351 (only ones I tried) I get the following when trying to 
mount /mnt/cdrom:

  mount: /dev/cdrom is not a valid block device

eject gives:

  eject: unable to open `/dev/hdc'

cat /proc/ide/hdc/driver: ide-default version 0.9.newide
cat /proc/ide/hdc/media: cdrom

On a PPC laptop with 351 it works!

cat /proc/ide/hdb/driver: ide-cdrom version 4.61

What determines which driver is beeing used? Is this in-kernel?

Cheers,
Remco
-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco at rvt.com   (831) 685-1201




From daryll at daryll.net  Fri May  7 17:37:54 2004
From: daryll at daryll.net (Daryll Strauss)
Date: Fri, 07 May 2004 10:37:54 -0700
Subject: Synaptic Touchpad
Message-ID: <1083951472.1756.10.camel@ninja2>


Mike,
	Any comments on the problems with the Synaptics touch pad on laptops?
Since it's common on a lot of laptops it's a step back from FC1 to FC2
right now. It's really painful to use in this state.

	Just to make sure I'm clear, the touch pad now jitters badly, no longer
supports taping for mouse clicks, and no longer supports the scroll
wheel area. These all worked under FC1 and no longer do. There's two or
three bugs files on the topic.

						- |Daryll


	




From rms at 1407.org  Fri May  7 18:06:35 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 07 May 2004 19:06:35 +0100
Subject: Synaptic Touchpad
In-Reply-To: <1083951472.1756.10.camel@ninja2>
References: <1083951472.1756.10.camel@ninja2>
Message-ID: <1083953194.2496.186.camel@roque>

On Fri, 2004-05-07 at 10:37 -0700, Daryll Strauss wrote:
> 	Any comments on the problems with the Synaptics touch pad on laptops?
> Since it's common on a lot of laptops it's a step back from FC1 to FC2
> right now. It's really painful to use in this state.
> 
> 	Just to make sure I'm clear, the touch pad now jitters badly, no longer
> supports taping for mouse clicks, and no longer supports the scroll
> wheel area. These all worked under FC1 and no longer do. There's two or
> three bugs files on the topic.

You need the synaptics driver (is it already in the distro?) and a good
configuration.

I currently have:

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "synaptics"
        Option      "Protocol" "auto-dev"
        Option      "Device" "/dev/input/mice"
        Option      "UpDownScrolling" "yes"
        Option      "EmulateMidButtonTime" "500"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "yes"
        Option      "SHMConfig" "no"
        Option      "BLCornerButton" "2"
EndSection

-------------- 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/20040507/33a11d20/attachment.sig>

From aleksey at nogin.org  Fri May  7 18:25:54 2004
From: aleksey at nogin.org (Aleksey Nogin)
Date: Fri, 07 May 2004 11:25:54 -0700
Subject: Synaptic Touchpad
In-Reply-To: <1083953194.2496.186.camel@roque>
References: <1083951472.1756.10.camel@ninja2> <1083953194.2496.186.camel@roque>
Message-ID: <409BD4B2.8070303@nogin.org>

On 07.05.2004 11:06, Rui Miguel Seabra wrote:

> You need the synaptics driver (is it already in the distro?)

It's not. At least not the X one (gpm does support the event driver now).

> and a good configuration.

That's another part of the problem - system-config-mouse needs to be 
updated. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116091

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907




From cra at WPI.EDU  Fri May  7 18:34:13 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Fri, 7 May 2004 14:34:13 -0400
Subject: rawhide report: 20040507 changes
In-Reply-To: <200405071248.i47Cmfx25945@porkchop.devel.redhat.com>
References: <200405071248.i47Cmfx25945@porkchop.devel.redhat.com>
Message-ID: <20040507183413.GZ17668@angus.ind.WPI.EDU>

On Fri, May 07, 2004 at 08:48:41AM -0400, Build System wrote:
> desktop-backgrounds-2.0-20
> --------------------------
> * Thu May 06 2004 Jeremy Katz <katzj at redhat.com> - 2.0-20
> 
> - background from Garrett for FC2

This package version is missing from download.fedora.redhat.com, but I
have headers in my local yum cache for it.  Did the version go
backwards from 2.0-20 to 2.0-19 at some point?




From wtogami at redhat.com  Fri May  7 20:19:56 2004
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 07 May 2004 10:19:56 -1000
Subject: rawhide report: 20040507 changes
In-Reply-To: <409BC511.8010500@nogin.org>
References: <200405071248.i47Cmfx25945@porkchop.devel.redhat.com>
	<409BC511.8010500@nogin.org>
Message-ID: <409BEF6C.2040800@redhat.com>

Aleksey Nogin wrote:
> On 07.05.2004 05:48, Build System wrote:
> 
>> cdrtools-2.01-0.a27.4
>> ---------------------
>> * Thu May 06 2004 Harald Hoyer <harald at redhat.com> - 8:2.01-0.a27.4
>>
>> - provide dvdrecord with a stub to cdrecord
> 
> 
> I am now getting:
> 
> file /usr/bin/dvdrecord from install of cdrecord-2.01-0.a27.4 conflicts 
> with file from package dvdrecord-0.1.5-1
> file /usr/share/man/man1/dvdrecord.1.gz from install of 
> cdrecord-2.01-0.a27.4 conflicts with file from package dvdrecord-0.1.5-1
> 

Doh... we tried to add a versioned Obsolete in order to get rid of the 
old FC1 dvdrecord package because it is no longer needed.  Only trouble 
is that I gave Harald the wrong version number!  My bad... we missed 
this chance because it was reverted almost immediately.

(Equivalent functionality has been rolled into cdrecord, and there are 
still the other dvd* packages.)




From wtogami at redhat.com  Fri May  7 20:21:41 2004
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 07 May 2004 10:21:41 -1000
Subject: dovecot default authentication change
In-Reply-To: <409B73B9.3040002@redhat.com>
References: <1083927669.3424.5.camel@hallucination.phil-anderson.com>
	<409B73B9.3040002@redhat.com>
Message-ID: <409BEFD5.4000407@redhat.com>

Warren Togami wrote:
> 
> Good catch!  In reviewing the revision history it appears this came from 
> upstream.  I am guessing this is totally not what we want shipping in 
> Fedora as postgresql based authentication is far less common and more 
> difficult to use than passwd.  I will see if I can fix this... already 
> very close to absolute development freeze. =(

Bad news, I missed the development freeze when I built this package, so 
unfortunately FC2 will ship with a non-functional by default dovecot. 
The FC2 update that fixes a few bugs and has a functional default config 
is in the pipe.  I may clean it up a bit more before releasing it later.

Warren




From vibol at khmer.cc  Sat May  8 00:59:45 2004
From: vibol at khmer.cc (Vibol Hou)
Date: Fri, 07 May 2004 17:59:45 -0700
Subject: Laptop screen not turning off in ACPI S1
Message-ID: <409C3101.6040702@khmer.cc>

When I issue an echo -n "1" > /proc/acpi/sleep, my laptop (Dell Lat 
C400) enters the state, but the laptop screen does not turn off.  Is 
there a way of getting the laptop screen to turn off in S1?

-Vibol




From aoliva at redhat.com  Sat May  8 03:12:22 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 08 May 2004 00:12:22 -0300
Subject: Laptop screen not turning off in ACPI S1
In-Reply-To: <409C3101.6040702@khmer.cc>
References: <409C3101.6040702@khmer.cc>
Message-ID: <or65b76295.fsf@livre.redhat.lsd.ic.unicamp.br>

On May  7, 2004, Vibol Hou <vibol at khmer.cc> wrote:

> When I issue an echo -n "1" > /proc/acpi/sleep, my laptop (Dell Lat
> C400) enters the state, but the laptop screen does not turn off.  Is
> there a way of getting the laptop screen to turn off in S1?

The ugly work around I found on my Dell Inspiron 8000 was to run:

sleep 5; echo ...

and then close the lid, such that the display is turned off.  Then,
when you enter the sleep state, it remains so.

Yeah, yuck :-/  But it works :-)

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From wrrhdev at riede.org  Sat May  8 13:38:29 2004
From: wrrhdev at riede.org (Willem Riede)
Date: Sat, 8 May 2004 09:38:29 -0400
Subject: STill no ide-scsi module (was: Re: sg (scsi generic) module missing)
In-Reply-To: <1083542900.6469.1.camel@delerium.codemonkey.org.uk> (from
	davej@redhat.com on Sun, May 02, 2004 at 20:08:20 -0400)
References: <20040412204032.GE1556856@hiwaay.net>
	<20040412204955.GB723@devserv.devel.redhat.com>
	<20040502213243.GM28387@serve.riede.org>
	<20040502222659.GC5327@devserv.devel.redhat.com>
	<1083542900.6469.1.camel@delerium.codemonkey.org.uk>
Message-ID: <20040508133829.GI28387@serve.riede.org>

On 2004.05.02 20:08, Dave Jones wrote:
> On Sun, 2004-05-02 at 23:26, Alan Cox wrote:
> > On Sun, May 02, 2004 at 05:32:43PM -0400, Willem Riede wrote:
> > > FC2T3 is still missing the ide-scsi module! And filing a bug doesn't work :-(
> > > I've had one in bugzilla since February 28, and no reaction whatsoever from
> > > the Red Hat kernel packagers...
> > > 
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117095
> > > 
> > > Why not compile ide-scsi? Why inconvenience owners of tape drives that need it?
> > 
> > And IDE multi-changers
> > 
> > > Put it in unsupported for all I care, but compile it, _please_.
> > 
> > Unfortunately Arjan and Dave are out of range of my torture kit so all I
> > can do is bitch at them as well (and if need be release rival kernel rpms
> > which would be a pita to have to do)
> 
> Odd. I thought we had come to a compromise on this which went along
> the lines of..
> 
> 	if device is an IDE CD drive
> 		print "use /dev/hd? directly"
> 		abort
> 	else
> 		passthrough to usual ide-scsi foo.
> 
> Arjan ?
> 
> 	Dave
> 
[root at fallguy root]# grep BLK_DEV_IDESCSI /usr/src/l*/configs/*
/usr/src/linux-2.6.5-1.351/configs/kernel-2.6.5-i586.config:# CONFIG_BLK_DEV_IDESCSI is not set
/usr/src/linux-2.6.5-1.351/configs/kernel-2.6.5-i586-smp.config:# CONFIG_BLK_DEV_IDESCSI is not set
/usr/src/linux-2.6.5-1.351/configs/kernel-2.6.5-i686.config:# CONFIG_BLK_DEV_IDESCSI is not set
/usr/src/linux-2.6.5-1.351/configs/kernel-2.6.5-i686-smp.config:# CONFIG_BLK_DEV_IDESCSI is not set

Ide-scsi is both stable and needed.

Sigh. Willem Riede.





From vibol at khmer.cc  Sat May  8 20:11:58 2004
From: vibol at khmer.cc (Vibol Hou)
Date: Sat, 08 May 2004 13:11:58 -0700
Subject: Laptop screen not turning off in ACPI S1
In-Reply-To: <or65b76295.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <409C3101.6040702@khmer.cc>
	<or65b76295.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <409D3F0E.4030002@khmer.cc>

Just out of curiousity, I was reviewing the kernel proper for the code 
that is executed as the system enters suspend and it appears to be 
allocating a VT and switching to it to display debug messages.  This 
appears to be causing my screen to switch back on since I have a script 
that shuts off my display when I initiate sleep mode (script found at: 
http://ltswww.epfl.ch/~dsanta/resources/dell-i8500-linux).  I modified 
the script to work with 2.6.

My question is; is it necessary for the kernel to do all this terminal 
switching?  I'm tempted to patch the kernel to remove the 
allocation/switching/debug code but I'd like to know if this was done 
for a reason (other than to output the debug messages).

-Vibol

Alexandre Oliva wrote:
> On May  7, 2004, Vibol Hou <vibol at khmer.cc> wrote:
> 
> 
>>When I issue an echo -n "1" > /proc/acpi/sleep, my laptop (Dell Lat
>>C400) enters the state, but the laptop screen does not turn off.  Is
>>there a way of getting the laptop screen to turn off in S1?
> 
> 
> The ugly work around I found on my Dell Inspiron 8000 was to run:
> 
> sleep 5; echo ...
> 
> and then close the lid, such that the display is turned off.  Then,
> when you enter the sleep state, it remains so.
> 
> Yeah, yuck :-/  But it works :-)
> 




From strange at nsk.no-ip.org  Sat May  8 20:45:49 2004
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Sat, 8 May 2004 21:45:49 +0100
Subject: Laptop screen not turning off in ACPI S1
In-Reply-To: <409D3F0E.4030002@khmer.cc>
References: <409C3101.6040702@khmer.cc>
	<or65b76295.fsf@livre.redhat.lsd.ic.unicamp.br>
	<409D3F0E.4030002@khmer.cc>
Message-ID: <20040508204549.GA6388@nsk.no-ip.org>

On Sat, May 08, 2004 at 01:11:58PM -0700, Vibol Hou wrote:
> Just out of curiousity, I was reviewing the kernel proper for the code 
> that is executed as the system enters suspend and it appears to be 
> allocating a VT and switching to it to display debug messages.  This 
> appears to be causing my screen to switch back on since I have a script 
> that shuts off my display when I initiate sleep mode (script found at: 
> http://ltswww.epfl.ch/~dsanta/resources/dell-i8500-linux).  I modified 
> the script to work with 2.6.
> 
> My question is; is it necessary for the kernel to do all this terminal 
> switching?  I'm tempted to patch the kernel to remove the 
> allocation/switching/debug code but I'd like to know if this was done 
> for a reason (other than to output the debug messages).

Terminal switching, yes, in most cases. Debug code, no, and I think it can
be turned off by writing to the proper file in /proc or suspending with
the proper flags. I don't recall which one and what, as  it changed a few
times. Maybe there's some documentation, or at least the kernel source.

Regards,
Luciano Rocha




From jurgen at botz.org  Sat May  8 23:15:48 2004
From: jurgen at botz.org (Jurgen Botz)
Date: Sat, 08 May 2004 16:15:48 -0700
Subject: CD ripping is broken on USB drives
Message-ID: <409D6A24.6050808@botz.org>

As best I can tell this isn't unique to me... but if anyone /can/
use cdparanoia or grip on a USB CD drive with kernel 327 or later,
please let us know.

The underlying cause, as I've reported before, seems to be that the
sg driver currently does not work with USB storage devices.  It worked
in 305, it doesn't in 327 onward (I don't have any kernels from in
between those available).  The symptom is that sg doesn't even see
the devices and doesn't report them when you load it.

Pardon the cross-posting, but I've reported this in bugzilla and on
the devel list before and there hasn't been any ack of this problem,
which I think it pretty critical... I know arjanv thinks sg should
die, but while some of its uses may be marginal, CD ripping is not...
I mean, is there anyone who /doesn't/ rip their audio CDs these days?
It would be pretty bad if FC2 couldn't rip on USB drives.

:j




From ckloiber at ckloiber.com  Sat May  8 23:53:55 2004
From: ckloiber at ckloiber.com (Chris Kloiber)
Date: Sun, 09 May 2004 07:53:55 +0800
Subject: k3b as default CD burner
In-Reply-To: <1083780115.30445.60.camel@opus>
References: <40992443.9010002@ninjapanda.org>
	<200405051043.29358.jkeating@j2solutions.net>
	<40992B86.2060905@ninjapanda.org>  <1083780115.30445.60.camel@opus>
Message-ID: <1084060434.11000.1.camel@galileo.ckloiber.com>

On Thu, 2004-05-06 at 02:01, seth vidal wrote:
> On Wed, 2004-05-05 at 13:59, Pyroman[FO] wrote:
> > I understand that, but why isn't it included in the default install as 
> > the default burner?  Are there any reasons other than "We don't like KDE"?
> > 
> 
> to be brutally honest - k3b is great. It's a whole lot ahead of gtoaster
> in terms of flexibility and obviousness of use.
> 
> I install it on my gnome systems b/c chances are I'll need the kde stuff
> anyway.
> 
> It probably doesn't need to be in the gnome default for burning b/c
> gnome has nautilus cd burning for a lot of tasks.
> 
> but k3b is darned nice.
> 
> -sv

Convince someone to fork a port to gtk2 and call it g3b. 

/me runs!

-- 
Chris Kloiber





From buildsys at redhat.com  Sat May  8 23:54:21 2004
From: buildsys at redhat.com (Build System)
Date: Sat, 8 May 2004 19:54:21 -0400
Subject: rawhide report: 20040508 changes
Message-ID: <200405082354.i48NsLU21142@porkchop.devel.redhat.com>

 

 
Updated Packages:

cdrtools-2.01-0.a27.3
---------------------
* Thu Apr 22 2004 Harald Hoyer <harald at redhat.com> - 8:2.01-0.a27.3

- fixed command line parsing, thx to Stephen Beahm (119906)

* Wed Apr 07 2004 Harald Hoyer <harald at redhat.com> - 8:2.01-0.a27.2

- added dvd patch from http://people.mandrakesoft.com/~warly/files/cdrtools/
- added note to manpage about configuration path change

* Tue Mar 02 2004 Elliot Lee <sopwith at redhat.com>

- rebuilt


dvdrtools-0.1.4-5
-----------------
* Fri Feb 13 2004 Elliot Lee <sopwith at redhat.com>

- rebuilt

* Thu Feb 05 2004 Harald Hoyer <harald at faro.stuttgart.redhat.com> - 0.1.4-4

- added ret.patch (113666)
- put autoconf changes in patch99

* Wed Jun 04 2003 Elliot Lee <sopwith at redhat.com>

- rebuilt


glibc-2.3.3-26
--------------
* Fri May 07 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-26

- update from CVS
  - fix <tgmath.h>
  - fix memory leaks in nis, getifaddrs, etc. caused by incorrect
    use of realloc
- remove /lib/{tls,i686}/librtkaio-2.3.[23].so in glibc_post_upgrade
  and rerun ldconfig if needed, otherwise after glibc upgrade librt.so.1
  might be a stale symlink

gnome-applets-2.6.0-5
---------------------
* Wed May 05 2004 Nils Philippsen <nphilipp at redhat.com> 1:2.6.0-5

- fix #120354 (mixer applet forgets channel settings)

kernel-2.6.5-1.356
------------------
* Fri May 07 2004 Arjan van de Ven <arjanv at redhat.com>

- more ide cache flush work

kernel-utils-2.4-9.1.131
------------------------
* Fri May 07 2004 Arjan van de Ven <arjanv at redhat.com>

- fix for bug 122677 (cpuspeed initscript borkage)

libtermcap-2.0.8-38
-------------------
* Fri May 07 2004 Tim Waugh <twaugh at redhat.com> 2.0.8-38

- Fix tgetent() (bug #116934).

policy-1.11.3-3
---------------
* Fri May 07 2004 Dan Walsh <dwalsh at redhat.com> 1.11.3-3

- Eliminate bind mounts from relabel

* Thu May 06 2004 Dan Walsh <dwalsh at redhat.com> 1.11.3-2

- Update to match NSA
- Allow syslog network logging
- Fix setfiles

* Wed Apr 28 2004 Dan Walsh <dwalsh at redhat.com> 1.11.2-21

- Add macros for userhelper


policycoreutils-1.11-2
----------------------
* Fri May 07 2004 Dan Walsh <dwalsh at redhat.com> 1.11-2

- Eliminate bind and context mounts

ppp-2.4.2-2
-----------
* Fri May 07 2004 Nils Philippsen <nphilipp at redhat.com> 2.4.2-2

- don't write to /etc (#118837)

* Wed Mar 10 2004 Nalin Dahyabhai <nalin at redhat.com> 2.4.2-1

- update to 2.4.2

python-2.3.3-6
--------------
* Fri May 07 2004 Mihai Ibanescu <misa at redhat.com> 2.3.3-6

- Correct fix for #122304 from upstream:
  http://sourceforge.net/tracker/?func=detail&atid=105470&aid=931848&group_id=5470

* Thu May 06 2004 Mihai Ibanescu <misa at redhat.com> 2.3.3-4

- Fix for bug #122304 : splitting the domain name fails on 64-bit arches
- Fix for bug #120879 : including Makefile into the main package

- Requires XFree86-devel instead of -libs (see bug #118442)

pyxf86config-0.3.18-2
---------------------
* Fri May 07 2004 Mike A. Harris <mharris at redhat.com> - 0.3.18-2

- Bumped release number and rebuilt unmodified in dist-fc2 to relink to new
  static libxf86config.a to pick up fix for (FC2BLOCKER #120950)

rpmdb-fedora-1.92-0.20040508
----------------------------

sane-backends-1.0.13-7
----------------------
* Fri May 07 2004 Tim Waugh <twaugh at redhat.com> 1.0.13-7

- Fix epson.conf for USB scanners (bug #122328).

subversion-1.0.2-1
------------------
* Mon Apr 19 2004 Joe Orton <jorton at redhat.com> 1.0.2-1

- update to 1.0.2

xemacs-sumo-20040202-4
----------------------
* Fri May 07 2004 Jens Petersen <petersen at redhat.com> - 20040202-4

- do not require xemacs, so that it is installable with xemacs-nox

xinitrc-3.40-1
--------------
* Fri May 07 2004 Mike A. Harris <mharris at redhat.com> 3.40-1

- Modified xinitrc and Xsession scripts to only source files with .sh
  extensions in /etc/X11/xinit/xinitrc.d/* so that backup files that are
  created when hand editing the scripts, aren't executed. (FC2BLOCKER

xorg-x11-6.7.0-2
----------------
* Sat May 08 2004 Mike A. Harris <mharris at redhat.com> 6.7.0-2

- Add -Wa,--noexecstack to AsCmd, in order to force all assembler files to
  use GNU stacks.  This was accomplished in an alternative way in our XFree86
  4.3.0 packaging via XFree86-4.3.0-redhat-exec-shield-GNU-stack.patch which
  patched every assembler file to add a .note.GNU-stack section, which is
  considered a superior solution, but our patch was non-portable to non-GNU
  systems.  This is a cleaner hack for now. (FC2BLOCKER #122708)
- Modified main rpm pre script to massage the X server config file(s) to
  remove XkbRules lines to help avoid (FC2BLOCKER #120858 and a zillion
  duplicates), and to ensure that the only active X server config file is
  xorg.conf (if any is present), and any other XFree86 4.x config files are
  renamed to .obsolete, which will help to minimize config file name confusion,
  and provide some sanity on upgrades, as all users will use xorg.conf by
  default regardless now. (FC2BLOCKER #122454)  (Fix based on patch from wtogami)

* Fri May 07 2004 Mike A. Harris <mharris at redhat.com> 6.7.0-1

- Added xorg-x11-6.7.0-libxf86config-monitor-freq-fix.patch to fix a problem
  caused by gratuitous upstream libxf86config changes which force the
  HorizSync and VertRefresh lines to always be written out to the config file
  in commented out form.  (FC2BLOCKER #120950, 122341, 122573, 122439, 122072,
  122461, 121946, 121717, others not yet duped)




From wtogami at redhat.com  Sat May  8 23:55:58 2004
From: wtogami at redhat.com (Warren Togami)
Date: Sat, 08 May 2004 13:55:58 -1000
Subject: rawhide custom compose syntax?
Message-ID: <409D738E.6040703@redhat.com>

#!/bin/bash

cd /usr/lib/anaconda-runtime
./genhdlist --productpath Fedora /home/stage/x86_64
PYTHONPATH=/usr/lib/anaconda /usr/lib/anaconda-runtime/pkgorder 
/home/stage/x86_64 x86_64 Fedora > /home/stage/x86_64/pkgorder.txt
./buildinstall --pkgorder /home/stage/x86_64/pkgorder.txt --version 1.93 
  --product "Fedora Core" --release yarrow --prodpath Fedora 
/home/stage/x86_64

I have been using the above syntax suggested by Justin Forbes in order 
to create my own modified rawhide trees while testing Anaconda.  It 
seems to create a working net installable tree, but the pkgorder is 
always messed up so the resulting installed system is unusable.  Anyone 
know what I am doing wrong?

Thanks,
Warren




From ckloiber at ckloiber.com  Sun May  9 00:17:01 2004
From: ckloiber at ckloiber.com (Chris Kloiber)
Date: Sun, 09 May 2004 08:17:01 +0800
Subject: /proc/ide/ firmware info for CD/DVD writers?
Message-ID: <1084061821.11000.17.camel@galileo.ckloiber.com>

With the older ide-scsi method of accessing cd and dvd writers, we
conveniently found our drive firmware version in /proc/scsi/scsi.
(Important info if you want to use 8x media in your 8x drive it seems. I
still have not seen a good burn at 8x.) I tried looking for it today in
/proc/ide/* without success. Is it elsewhere, or just MIA? How tough to
add it to either 'identity' or 'model', or add a new 'firmware' file?

-- 
Chris Kloiber





From buildsys at redhat.com  Sun May  9 13:17:52 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 9 May 2004 09:17:52 -0400
Subject: rawhide report: 20040509 changes
Message-ID: <200405091317.i49DHqi14953@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-10.0-3
---------------
* Fri May 07 2004 Anaconda team <bugzilla at redhat.com>

- built new version from CVS

* Fri Apr 30 2004 Jeremy Katz <katzj at redhat.com>

- Update description, remove prereq on stuff that was only needed 
  for reconfig mode

* Tue Feb 24 2004 Jeremy Katz <katzj at redhat.com>

- buildrequire libselinux-devel


anaconda-images-10-3
--------------------

dovecot-0.99.10.4-4
-------------------
* Fri May 07 2004 Warren Togami <wtogami at redhat.com> 0.99.10.4-4

- default auth config that is actually usable
- Timo Sirainen (author) suggested functionality fixes
  maildir, imap-fetch-body-section, customflags-fix

* Mon Feb 23 2004 Tim Waugh <twaugh at redhat.com>

- Use ':' instead of '.' as separator for chown.

exim-4.33-2
-----------
* Sat May 08 2004 David Woodhouse <dwmw2 at redhat.com> 4.33-2

- fix buffer overflow in header_syntax check

* Wed May 05 2004 David Woodhouse <dwmw2 at redhat.com> 4.33-1

- Update to Exim 4.33, exiscan-acl 4.33-20 to
  fix crashes both in exiscan-acl and Exim itself.

kernel-2.6.5-1.358
------------------
* Sat May 08 2004 Arjan van de Ven <arjanv at redhat.com>

- fix non-booting on Transmeta cpus (Peter Arvin)
- fix count leak in message queues

rhythmbox-0.8.3-3
-----------------
* Fri May 07 2004 Colin Walters <walters at redhat.com> - 0.8.3-3

- Apply tiny patch from 0.8 arch to fix GConf key used
  for initial sorting

* Fri May 07 2004 Colin Walters <walters at redhat.com> - 0.8.3-2

- Apply patch from 0.8 arch tree to fix a number of memleaks

rpmdb-fedora-1.92-0.20040509
----------------------------

unixODBC-2.2.8-5
----------------
* Sat May 08 2004 Tom Lane <tgl at redhat.com> 2.2.8-5

- Backpatch fix for double-free error from upstream devel sources.
- rebuilt




From wtogami at redhat.com  Sun May  9 13:36:02 2004
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 09 May 2004 03:36:02 -1000
Subject: dovecot default authentication change
In-Reply-To: <409BEFD5.4000407@redhat.com>
References: <1083927669.3424.5.camel@hallucination.phil-anderson.com>	<409B73B9.3040002@redhat.com>
	<409BEFD5.4000407@redhat.com>
Message-ID: <409E33C2.7030206@redhat.com>

Warren Togami wrote:
> Warren Togami wrote:
> 
>>
>> Good catch!  In reviewing the revision history it appears this came 
>> from upstream.  I am guessing this is totally not what we want 
>> shipping in Fedora as postgresql based authentication is far less 
>> common and more difficult to use than passwd.  I will see if I can fix 
>> this... already very close to absolute development freeze. =(
> 
> 
> Bad news, I missed the development freeze when I built this package, so 
> unfortunately FC2 will ship with a non-functional by default dovecot. 
> The FC2 update that fixes a few bugs and has a functional default config 
> is in the pipe.  I may clean it up a bit more before releasing it later.
> 

Hmm... the package magically appeared in rawhide.  I'm not complaining. =)

Warren




From jfontain at free.fr  Sun May  9 13:56:46 2004
From: jfontain at free.fr (Jean-Luc FONTAINE)
Date: Sun, 09 May 2004 15:56:46 +0200
Subject: fedora 1.92, tclx-8.3.5-2 bug?
Message-ID: <409E389E.6000703@free.fr>

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

$ tclsh
% package require Tclx
Can't find tclx.tcl in the following directories:
~  /usr/lib/tclX8.3
~  /usr/lib/tclX8.3
~  /usr/lib/tclX8.3
~  /tclX8.3/tcl/bin
~  /tclX8.3/tcl/bin
This probably means that TclX wasn't installed properly.

Note: this is using my own Tcl 8.4.6 shell, but I suspect it also
happens with the tcl rpm in the 1.92 distribution.


- --
Jean-Luc Fontaine
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAnjidkG/MMvcT1qQRAn9vAKCxuZXOqdfDQs+rhKe6vYhLgEHxRgCgsnNj
voLFJRFoNvKYyNFpmBmfkPg=
=Cmjh
-----END PGP SIGNATURE-----




From naoki at valuecommerce.com  Sun May  9 15:33:05 2004
From: naoki at valuecommerce.com (Naoki)
Date: Mon, 10 May 2004 00:33:05 +0900
Subject: Test 3 bugs.
In-Reply-To: <409B15DC.3060008@redhat.com>
References: <409AE595.60607@valuecommerce.com> <409B15DC.3060008@redhat.com>
Message-ID: <409E4F31.7040003@valuecommerce.com>


> All of these issues are improper for discussion in fedora-devel-list. 
> Please use fedora-test-list for support issues like this.  And always 
> search lists before asking, because all of those issues have been 
> discussed at length on fedora-test-list.


Ok, cheers.
-n.




From leonard at den.ottolander.nl  Sun May  9 15:35:31 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Sun, 09 May 2004 17:35:31 +0200
Subject: cup version drop "v"
Message-ID: <1084116930.4753.44.camel@athlon.localdomain>

Hi,

The use of a starting letter in the version of cup and cup-devel is
inconsistent with any other package in the distribution. This
exception is a pita when using scripts to sort rpms by version.

Could we please restrict letters in the version and release to be
positioned after one or more numbers?

Please change "cup-v10k-13" to "cup-10k-13".

See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122865

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From Fred.New at microlink.ee  Sun May  9 20:24:09 2004
From: Fred.New at microlink.ee (Fred New)
Date: Sun, 9 May 2004 23:24:09 +0300
Subject: rawhide report: 20040508 changes
Message-ID: <345764DCB65C0C4FACC44529DE273C180B52EF@eemail1.microlink.lan>

> kernel-2.6.5-1.356
> ------------------
> * Fri May 07 2004 Arjan van de Ven <arjanv at redhat.com>
>
> - more ide cache flush work

Is it intentional that my hard disk spins down during a reboot now
with kernels .356 and .358?

Fred


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2381 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040509/90265c4c/attachment.bin>

From alan at redhat.com  Sun May  9 20:44:52 2004
From: alan at redhat.com (Alan Cox)
Date: Sun, 9 May 2004 16:44:52 -0400
Subject: rawhide report: 20040508 changes
In-Reply-To: <345764DCB65C0C4FACC44529DE273C180B52EF@eemail1.microlink.lan>
References: <345764DCB65C0C4FACC44529DE273C180B52EF@eemail1.microlink.lan>
Message-ID: <20040509204452.GC27537@devserv.devel.redhat.com>

On Sun, May 09, 2004 at 11:24:09PM +0300, Fred New wrote:
> > - more ide cache flush work
> 
> Is it intentional that my hard disk spins down during a reboot now
> with kernels .356 and .358?

Some disks respond to the standbynow request by spinning down.




From barryn at pobox.com  Sun May  9 22:19:48 2004
From: barryn at pobox.com (Barry K. Nathan)
Date: Sun, 9 May 2004 15:19:48 -0700
Subject: cup version drop "v"
In-Reply-To: <1084116930.4753.44.camel@athlon.localdomain>
References: <1084116930.4753.44.camel@athlon.localdomain>
Message-ID: <20040509221948.GD4353@ip68-4-98-123.oc.oc.cox.net>

On Sun, May 09, 2004 at 05:35:31PM +0200, Leonard den Ottolander wrote:
> Please change "cup-v10k-13" to "cup-10k-13".
> 
> See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122865

As I just commented in that Bugzilla bug, it should be changed to
cup-0.10k-13, as 0.10k is the upstream version number.

-Barry K. Nathan <barryn at pobox.com>




From barryn at pobox.com  Mon May 10 02:16:12 2004
From: barryn at pobox.com (Barry K. Nathan)
Date: Sun, 9 May 2004 19:16:12 -0700
Subject: unofficial FC-devel installer boot floppies
Message-ID: <20040510021612.GE4353@ip68-4-98-123.oc.oc.cox.net>

I've created a set of unofficial, experimental FC-devel installer boot
floppies. They're available here:
http://math.uci.edu/~bnathan/linux/fc2-floppies-i386/

Right now I've posted floppies for rawhide (fc-devel) as of 2004-05-09.
There are three floppies. No matter what kind of install you are
performing, you need all 3 disks. It's currently very bare-bones; it
does not offer the user the option of adding command line arguments.

Go ahead and try these out if you're interested...


FWIW, here's where I obtained the various components I hacked together:

FreeDOS kernel & command.com: FreeDOS Beta9 pre-release5
cat.exe: dosemu-freedos-1.2.0-3mdk
loadlin: whatever ships in the dosutils directory with SuSE 9.0 FTP
syslinux, memdisk: syslinux-2.08-3 (from fc-devel)
vmlinuz, initrd: isolinux directory from fc-devel
autoexec.bat: I wrote it. I just realized I didn't think about what kind
of license to use for it -- oops. Any suggestions? Right now I'm leaning
toward GPL.

-Barry K. Nathan <barryn at pobox.com>

-------------- 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/20040509/a2a1b87e/attachment.sig>

From pmatilai at welho.com  Mon May 10 05:03:28 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Mon, 10 May 2004 08:03:28 +0300 (EEST)
Subject: cup version drop "v"
In-Reply-To: <1084116930.4753.44.camel@athlon.localdomain>
References: <1084116930.4753.44.camel@athlon.localdomain>
Message-ID: <Pine.LNX.4.58.0405100801360.24581@chip.laiskiainen.org>

On Sun, 9 May 2004, Leonard den Ottolander wrote:

> Hi,
> 
> The use of a starting letter in the version of cup and cup-devel is
> inconsistent with any other package in the distribution. This
> exception is a pita when using scripts to sort rpms by version.
> 
> Could we please restrict letters in the version and release to be
> positioned after one or more numbers?

Sorting rpm's without using rpm's own version comparison algorithm is 
guaranteed to break at some point, better use rpm-python bindings for such 
tasks.

Doesn't mean sticking to sane version numbers isn't a good thing, 'v10k' 
should indeed be sanitized anyway.

	- Panu -




From jurgen at botz.org  Mon May 10 06:37:35 2004
From: jurgen at botz.org (Jurgen Botz)
Date: Sun, 09 May 2004 23:37:35 -0700
Subject: CD ripping is broken on USB drives
In-Reply-To: <409D6A24.6050808@botz.org>
References: <409D6A24.6050808@botz.org>
Message-ID: <409F232F.9050505@botz.org>

Finally got a chance to test a stock linux kernel (latest from
bk as of this afternoon) and it works fine.  If I can find the
time I'll rebuild the kernel src RPM with various patches turned
off to see if I can figure out which of them breaks sg with USB.

:j




From arjanv at redhat.com  Mon May 10 07:04:39 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Mon, 10 May 2004 09:04:39 +0200
Subject: CD ripping is broken on USB drives
In-Reply-To: <409F232F.9050505@botz.org>
References: <409D6A24.6050808@botz.org>  <409F232F.9050505@botz.org>
Message-ID: <1084172679.4925.11.camel@laptop.fenrus.com>

On Mon, 2004-05-10 at 08:37, Jurgen Botz wrote:
> Finally got a chance to test a stock linux kernel (latest from
> bk as of this afternoon) and it works fine.  If I can find the
> time I'll rebuild the kernel src RPM with various patches turned
> off to see if I can figure out which of them breaks sg with USB.

But you don't need sg to rip from USB....
Yes I know I sound like a broken record.

-------------- 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/20040510/de2d1621/attachment.sig>

From buildsys at redhat.com  Mon May 10 11:26:12 2004
From: buildsys at redhat.com (Build System)
Date: Mon, 10 May 2004 07:26:12 -0400
Subject: rawhide report: 20040510 changes
Message-ID: <200405101126.i4ABQCG28153@porkchop.devel.redhat.com>

 

 
Updated Packages:

rpmdb-fedora-1.92-0.20040510
----------------------------




From robert at it4texas.com  Mon May 10 12:00:02 2004
From: robert at it4texas.com (Robert Trembath)
Date: Mon, 10 May 2004 07:00:02 -0500
Subject: A few issues
Message-ID: <409F6EC2.402@it4texas.com>

Morning everyone,

In Fedora Core Test 3, I am still experienced a few problems with 
various hardware, particularly xorg. The default config remarks out 
screen refresh rates and only makes 800x600 and 640x480 available. Also 
adding nvidia drivers that nvidia states supports 2.6.x kernels kills 
the kernel. I get a message while compiling the module that the kernel 
has been tainted and the system becones unusable. Also in system with 
builtin Intel 845 Video chipsets where it has been disabled in the bios, 
and a new AGP or PCI card has been added, I can manually configure X11 
for the new card  and complete the install, but when rebooting after 
installation, I get a kernel panic and the system is unusable.

The workaround for the PCMCIA problem is also still problematic compared 
to Fedora Core 1 where PCMCIA works very well. Thanks to those who 
pointed me to to the workaround. Curious why this problem still exists 
since it was originally found in test 1 and has been noted for some time 
as a bug. Not even the workaround has ended up in a release. Just curious!

Test systems
1) Dell Lattitude C840 Laptop w/P4 2.0gHz, 512 MB RAM, 20GB HD, Nvidia 
Geforce4 w/32MB, 1600x1200 display.
2) iWill XP4 P4 1.8gHz Box, 256MB RAM, 40GB HD, integrated Intel 845 
Video and i810 audio, and an Nvidia Geforce2 64MB PCI Video Card.

-- 
____________________________________
Robert Trembath
VP - Business & Technical Development

IT4Texas, LLC.
Houston, TX, USA
e| robert at it4texas.com
p| 832.722.7142





From ulrick2 at faith4miracle.org  Mon May 10 12:28:24 2004
From: ulrick2 at faith4miracle.org (Steven P. Ulrick)
Date: Mon, 10 May 2004 07:28:24 -0500
Subject: CD ripping is broken on USB drives
In-Reply-To: <1084172679.4925.11.camel@laptop.fenrus.com>
References: <409D6A24.6050808@botz.org> <409F232F.9050505@botz.org>
	<1084172679.4925.11.camel@laptop.fenrus.com>
Message-ID: <20040510072824.255a211c.ulrick2@faith4miracle.org>

On Mon, 10 May 2004 09:04:39 +0200
Arjan van de Ven <arjanv at redhat.com> wrote:

> On Mon, 2004-05-10 at 08:37, Jurgen Botz wrote:
> > Finally got a chance to test a stock linux kernel (latest from
> > bk as of this afternoon) and it works fine.  If I can find the
> > time I'll rebuild the kernel src RPM with various patches turned
> > off to see if I can figure out which of them breaks sg with USB.
> 
> But you don't need sg to rip from USB....
> Yes I know I sound like a broken record.

Hello, Everyone :)
I have been following this specific thread, and this general subject,
with great interest, since I have had the same problem and am interested
in it's solution.  First of all, here is some proof that the drive Does
exist: (I've uploaded a screenshot of the output of the "usbview"
command because I couldn't figure out how to copy and paste from the
"usbview" browser :)
http://www.faith4miracle.org/iomega-usbview.jpg


Here is the output of "cdrecord -scanbus":
Cdrecord-Clone 2.01a27-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004
J?rg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to
<warly at mandrakesoft.com>.
Note: The author of cdrecord should not be bothered with problems in
this version.
scsidev: 'ATA'
devname: 'ATA'
scsibus: -2 target: -2 lun: -2
Warning: Using badly designed ATAPI via /dev/hd* interface.
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.8'.
cdrecord: Warning: using inofficial libscg transport code version
(schily - Red Hat-scsi-linux-sg.c-1.80-RH '@(#)scsi-linux-sg.c      
1.80 04/03/08 Copyright 1997 J. Schilling').
scsibus0:
        0,0,0     0) *
cdrecord: Warning: controller returns wrong size for CD capabilities
page.
        0,1,0     1) 'E-IDE   ' 'CD-ROM 50X      ' '50  ' Removable
CD-ROM
        0,2,0     2) *
        0,3,0     3) *
        0,4,0     4) *
        0,5,0     5) *
        0,6,0     6) *
        0,7,0     7) *


Last night, I updated to the latest Rawhide (if I can still use that
term) kernel and I successfully burned a cd from an image that I had
made yesterday.  Problem is, when I tried to rip a cd this morning, this
is the output from "cdparanoia -v -d /dev/scd0 -B 1- TheJam.wav" that I
got (I have edited it greatly, because I think it would have kept going
if I hadn't stopped it):

cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty at xiph.org> and Xiphophorus

Report bugs to paranoia at xiph.org
http://www.xiph.org/paranoia/

Checking /dev/scd0 for cdrom...
	Testing /dev/scd0 for cooked ioctl() interface
		/dev/scd0 is not a cooked ioctl CDROM.
	Testing /dev/scd0 for SCSI interface
Error trying to open /dev/sg0 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sga exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg1 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sgb exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg2 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sgc exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg3 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sgd exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg4 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sge exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg5 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sgf exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg6 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sgg exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg7 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sgh exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg8 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sgi exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg9 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sgj exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg10 exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sgk exclusively (No such device or address). retrying in 1 second.
Error trying to open /dev/sg11 exclusively (No such device or address). retrying in 1 second.

I was logged in as root when I tried all of this.
I don't in any way deny the reality of your statement as contained in
the following quotation:

> But you don't need sg to rip from USB....
> Yes I know I sound like a broken record.

So I assume that I am probably doing something wrong.  The command that
I used to try to rip from the above mentioned Iomega external CDRW drive
is the same one that still works perfectly under Fedora Core 1.  To
clarify, I am running FC1 and FC2TR3 on the same box, with the same
Iomega drive plugged into the same USB2 port, ripping does work under
FC1, and it Does Not work under FC2TR3.

In closing, I truly believe that maybe I am doing something wrong, and
that maybe something has changed about the way I'm supposed to rip CD's
under FC2TR3.  If that is the case, I'd love to know what to do so I can
make it work :)

If I have left out any necessary information, please let me know.

Have a Great Day :)
Steven P. Ulrick

OOops, Just saw this at the beginning of the output of "cdrecord
-scanbus":

scsidev: 'ATA'
devname: 'ATA'
scsibus: -2 target: -2 lun: -2

For all I know, it might be meaningless, but I'm not an expert :)




From arjanv at redhat.com  Mon May 10 12:32:01 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Mon, 10 May 2004 14:32:01 +0200
Subject: CD ripping is broken on USB drives
In-Reply-To: <20040510072824.255a211c.ulrick2@faith4miracle.org>
References: <409D6A24.6050808@botz.org> <409F232F.9050505@botz.org>
	<1084172679.4925.11.camel@laptop.fenrus.com>
	<20040510072824.255a211c.ulrick2@faith4miracle.org>
Message-ID: <20040510123201.GA5296@devserv.devel.redhat.com>


On Mon, May 10, 2004 at 07:28:24AM -0500, Steven P. Ulrick wrote:
> On Mon, 10 May 2004 09:04:39 +0200
> Arjan van de Ven <arjanv at redhat.com> wrote:
> 
> > On Mon, 2004-05-10 at 08:37, Jurgen Botz wrote:
> > > Finally got a chance to test a stock linux kernel (latest from
> > > bk as of this afternoon) and it works fine.  If I can find the
> > > time I'll rebuild the kernel src RPM with various patches turned
> > > off to see if I can figure out which of them breaks sg with USB.
> > 
> > But you don't need sg to rip from USB....
> > Yes I know I sound like a broken record.
> 
> Hello, Everyone :)
> I have been following this specific thread, and this general subject,
> with great interest, since I have had the same problem and am interested
> in it's solution.  First of all, here is some proof that the drive Does
> exist: (I've uploaded a screenshot of the output of the "usbview"
> command because I couldn't figure out how to copy and paste from the
> "usbview" browser :)
> http://www.faith4miracle.org/iomega-usbview.jpg
> 
> 
> Here is the output of "cdrecord -scanbus":

don't do scanbus, why do you need scanbus ?
-------------- 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/20040510/55965385/attachment.sig>

From leonard at den.ottolander.nl  Mon May 10 14:01:03 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Mon, 10 May 2004 16:01:03 +0200
Subject: cup version drop "v"
In-Reply-To: <Pine.LNX.4.58.0405100801360.24581@chip.laiskiainen.org>
References: <1084116930.4753.44.camel@athlon.localdomain>
	<Pine.LNX.4.58.0405100801360.24581@chip.laiskiainen.org>
Message-ID: <1084197663.4753.36.camel@athlon.localdomain>

Hi Panu,

> > This
> > exception is a pita when using scripts to sort rpms by version.

> Sorting rpm's without using rpm's own version comparison algorithm is 
> guaranteed to break at some point, better use rpm-python bindings for such 
> tasks.

Actually my "sorting algorithm" is much easier: I'm sorting the
downloaded updates by date ;-) . I break the version of by splitting the
file name on the third dash from the end.

It's just that when picking the latest version of a package I check for
a digit after the package name as to avoid confusion between fe cup and
cup-devel. Versions starting with a letter break with this check.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From hmunoz at CODESI.COM  Mon May 10 14:42:32 2004
From: hmunoz at CODESI.COM (=?iso-8859-1?Q?Hugo_Mu=F1oz?=)
Date: Mon, 10 May 2004 09:42:32 -0500
Subject: RECOMPILE KERNEL
Message-ID: <8E989C0B7380C3468D3BDC11C4F9569A035417@srvcodesimn.CODESISA.COM>

Hi, my name is Hugo Mu?oz I'm having problems with FEDORA CORE 1 because the driver for the ohci1394 (firewire) doesn't work the computer freezes.... and occurs the same in the versions 9.0, 8.0 how can I recompile the kernel to ignore ohci1394

My computer is:

	Compaq HP nx9010 (LAPTOP)
	256 RAM
	40gb HD
	PIV 2.4 GHZ

And the problem is not only in my computer the same occurs in other computers laptops Of the same characteristics

I someone wise can help me






From rms at 1407.org  Mon May 10 14:55:05 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Mon, 10 May 2004 15:55:05 +0100
Subject: RECOMPILE KERNEL
In-Reply-To: <8E989C0B7380C3468D3BDC11C4F9569A035417@srvcodesimn.CODESISA.COM>
References: <8E989C0B7380C3468D3BDC11C4F9569A035417@srvcodesimn.CODESISA.COM>
Message-ID: <1084200905.6116.131.camel@roque>

Install with firewire=no in the install prompt!

If you go to tuxmobile.org there's links to a page with NX9010 info.

BTW, FC2t3 installed purrfectly in it without adding firewire=no (but
maybe that's because firewire is temporarily disabled).

Regards,

On Mon, 2004-05-10 at 09:42 -0500, Hugo Mu?oz wrote:
> Hi, my name is Hugo Mu?oz I'm having problems with FEDORA CORE 1 because the driver for the ohci1394 (firewire) doesn't work the computer freezes.... and occurs the same in the versions 9.0, 8.0 how can I recompile the kernel to ignore ohci1394
> 
> My computer is:
> 
> 	Compaq HP nx9010 (LAPTOP)
> 	256 RAM
> 	40gb HD
> 	PIV 2.4 GHZ
> 
> And the problem is not only in my computer the same occurs in other computers laptops Of the same characteristics
> 
> I someone wise can help me

-------------- 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/20040510/fb8249d9/attachment.sig>

From jurgen at botz.org  Mon May 10 15:05:14 2004
From: jurgen at botz.org (Jurgen Botz)
Date: Mon, 10 May 2004 08:05:14 -0700
Subject: CD ripping is broken on USB drives
In-Reply-To: <1084172679.4925.11.camel@laptop.fenrus.com>
References: <409D6A24.6050808@botz.org> <409F232F.9050505@botz.org>
	<1084172679.4925.11.camel@laptop.fenrus.com>
Message-ID: <409F9A2A.8070008@botz.org>

Arjan van de Ven wrote:
> But you don't need sg to rip from USB....
> Yes I know I sound like a broken record.

Not quite... you do not repeat yourself, but you rhyme
(apologies to Mark Twain).

Seriously, if you don't need sg to rip from USB, could
you PLEASE enlighten us as to how it's done??? Even if
I explicitly tell cdparanoia to used /dev/scd0 as both
the cdrom device and generic device it still tries to
open sg0...

   nova:/tmp$ cdparanoia -d /dev/scd0 -g /dev/scd0 1
   cdparanoia III release 9.8 (March 23, 2001)
   (C) 2001 Monty <monty at xiph.org> and Xiphophorus

   Report bugs to paranoia at xiph.org
   http://www.xiph.org/paranoia/

   Error trying to open /dev/scd0 exclusively (Read-only file system).
     retrying in 1 second.
   Error trying to open /dev/scd0 exclusively (Read-only file system).
     retrying in 1 second.
   ...

Is there a secret undocumented "don't use sg" flag?  Or
did you mean by "you don't need..." that someone ought
to fix the applications not to demand the sg device?  If
the later, I'll even volunteer to work on it, just bloody
say so!  (And of course it's too late for FC2, which means
that in any case I'm right and CD ripping is broken from
USB in FC2.)

:j




From arjanv at redhat.com  Mon May 10 15:08:47 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Mon, 10 May 2004 17:08:47 +0200
Subject: CD ripping is broken on USB drives
In-Reply-To: <409F9A2A.8070008@botz.org>
References: <409D6A24.6050808@botz.org> <409F232F.9050505@botz.org>
	<1084172679.4925.11.camel@laptop.fenrus.com>
	<409F9A2A.8070008@botz.org>
Message-ID: <20040510150846.GA13325@devserv.devel.redhat.com>

On Mon, May 10, 2004 at 08:05:14AM -0700, Jurgen Botz wrote:
> Arjan van de Ven wrote:
> >But you don't need sg to rip from USB....
> >Yes I know I sound like a broken record.
> 
> Not quite... you do not repeat yourself, but you rhyme
> (apologies to Mark Twain).
> 
> Seriously, if you don't need sg to rip from USB, could
> you PLEASE enlighten us as to how it's done??? Even if
> I explicitly tell cdparanoia to used /dev/scd0 as both
> the cdrom device and generic device it still tries to
> open sg0...
> 
>   nova:/tmp$ cdparanoia -d /dev/scd0 -g /dev/scd0 1
>   cdparanoia III release 9.8 (March 23, 2001)
>   (C) 2001 Monty <monty at xiph.org> and Xiphophorus
> 
>   Report bugs to paranoia at xiph.org
>   http://www.xiph.org/paranoia/
> 
>   Error trying to open /dev/scd0 exclusively (Read-only file system).
>     retrying in 1 second.

this means something has /dev/scd0 open already, for example magicdev or
nautilus or ...

-------------- 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/20040510/df92ae02/attachment.sig>

From jurgen at botz.org  Mon May 10 15:12:08 2004
From: jurgen at botz.org (Jurgen Botz)
Date: Mon, 10 May 2004 08:12:08 -0700
Subject: CD ripping is broken on USB drives
In-Reply-To: <409F9A2A.8070008@botz.org>
References: <409D6A24.6050808@botz.org> <409F232F.9050505@botz.org>
	<1084172679.4925.11.camel@laptop.fenrus.com>
	<409F9A2A.8070008@botz.org>
Message-ID: <409F9BC8.2070100@botz.org>

Jurgen Botz wrote:
> I explicitly tell cdparanoia to used /dev/scd0 as both
> the cdrom device and generic device it still tries to
> open sg0...
>[...] 
>   Error trying to open /dev/scd0 exclusively (Read-only file system).
>     retrying in 1 second.

I just noticed that the error message is not consistent with
what I said... in fact, if I just use "cdparaoia -g /dev/scd0"
then I get "Error trying to open /dev/sg0 exclusively (No such
device or address)", i.e. it seems to be ignoring my "-g" and
trying to open sg0 anyway.  If I specify both -d and -g I get
the above which is maybe even stranger.

In any case it doesn't work.

:j




From hutuworm at hz.cn  Mon May 10 15:15:01 2004
From: hutuworm at hz.cn (hutuworm)
Date: Mon, 10 May 2004 23:15:01 +0800
Subject: Which kernel will be integrated into Fedora Core 2 ?
Message-ID: <0HXI0089C6TOHE@inbound2.hz.gov.cn>

fedora-devel-list,

    Linus announced kernel 2.6.6 today, will it be integrated into Fedora Core 2 ?
I've found many valuable bug-fixes in the new release.

	http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.6


hutuworm

    





From jurgen at botz.org  Mon May 10 15:21:17 2004
From: jurgen at botz.org (Jurgen Botz)
Date: Mon, 10 May 2004 08:21:17 -0700
Subject: CD ripping is broken on USB drives
In-Reply-To: <20040510150846.GA13325@devserv.devel.redhat.com>
References: <409D6A24.6050808@botz.org> <409F232F.9050505@botz.org>
	<1084172679.4925.11.camel@laptop.fenrus.com>
	<409F9A2A.8070008@botz.org>
	<20040510150846.GA13325@devserv.devel.redhat.com>
Message-ID: <409F9DED.6070907@botz.org>

Arjan van de Ven wrote:
> this means something has /dev/scd0 open already, for example magicdev or
> nautilus or ...

Naw, you don't get off that easy.  I tried it without X running
and I get the same thing.  I can eject my audio CD, insert a data
CD, mount it, unmount & eject, re-insert my audio CD and I still
get the same thing.

Could you just actually try it?  Try ripping a track of an audio
CD without sg loaded and tell us what the cdparanoia invocation is
that works.

:j




From cra at WPI.EDU  Mon May 10 15:28:41 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Mon, 10 May 2004 11:28:41 -0400
Subject: Which kernel will be integrated into Fedora Core 2 ?
In-Reply-To: <0HXI0089C6TOHE@inbound2.hz.gov.cn>
References: <0HXI0089C6TOHE@inbound2.hz.gov.cn>
Message-ID: <20040510152841.GF17668@angus.ind.WPI.EDU>

On Mon, May 10, 2004 at 11:15:01PM +0800, hutuworm wrote:
>     Linus announced kernel 2.6.6 today, will it be integrated into Fedora Core 2 ?
> I've found many valuable bug-fixes in the new release.
> 	http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.6

Probably not.  It is too late for FC2 release to change the kernel. 
However, it probably doesn't matter much since the kernel that FC2
does have is based on 2.6.6-rc3, with all of those fixes in there.

An update to FC2 could possibly have 2.6.6 or later.




From katzj at redhat.com  Mon May 10 15:34:31 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 10 May 2004 11:34:31 -0400
Subject: rawhide custom compose syntax?
In-Reply-To: <409D738E.6040703@redhat.com>
References: <409D738E.6040703@redhat.com>
Message-ID: <1084203271.2704.4.camel@bree.local.net>

On Sat, 2004-05-08 at 13:55 -1000, Warren Togami wrote:
> I have been using the above syntax suggested by Justin Forbes in order 
> to create my own modified rawhide trees while testing Anaconda.  It 
> seems to create a working net installable tree, but the pkgorder is 
> always messed up so the resulting installed system is unusable.  Anyone 
> know what I am doing wrong?

You're missing a genhdlist --fileorder /pkgorderfile to get the package
ordering embedded in the hdlist.

Jeremy




From htaira-fdr at pantora.net  Mon May 10 16:45:29 2004
From: htaira-fdr at pantora.net (Hajime Taira)
Date: Tue, 11 May 2004 01:45:29 +0900
Subject: RECOMPILE KERNEL
In-Reply-To: <8E989C0B7380C3468D3BDC11C4F9569A035417@srvcodesimn.CODESISA.COM>
References: <8E989C0B7380C3468D3BDC11C4F9569A035417@srvcodesimn.CODESISA.COM>
Message-ID: <20040511014529.245d4bb4.htaira-fdr@pantora.net>

I also have the computer of the same model.

It has escaped as the starting option at the time of installation.
nofirewire or firewire=no

If the version of a kernel is 2.4.26 or higher, firewire will also run well.
The sample of construction of a kernel is appended.

.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
Hajime Taira <htaira at pantora.net>     (private)
             <htaira-fdr at pantora.net> (for fedora)
            web: http://pantora.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-2.4.27-pre1-nx9k
Type: application/octet-stream
Size: 27939 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040511/409bd52f/attachment.obj>

From ronny-vlug at vlugnet.org  Mon May 10 16:25:34 2004
From: ronny-vlug at vlugnet.org (Ronny Buchmann)
Date: Mon, 10 May 2004 18:25:34 +0200
Subject: CD ripping is broken on USB drives
In-Reply-To: <409F9BC8.2070100@botz.org>
References: <409D6A24.6050808@botz.org> <409F9A2A.8070008@botz.org>
	<409F9BC8.2070100@botz.org>
Message-ID: <200405101825.34814.ronny-vlug@vlugnet.org>

On Monday 10 May 2004 17:12, Jurgen Botz wrote:
> Jurgen Botz wrote:
> > I explicitly tell cdparanoia to used /dev/scd0 as both
> > the cdrom device and generic device it still tries to
> > open sg0...
> >[...]
> >   Error trying to open /dev/scd0 exclusively (Read-only file system).
> >     retrying in 1 second.
>
> I just noticed that the error message is not consistent with
> what I said... in fact, if I just use "cdparaoia -g /dev/scd0"
> then I get "Error trying to open /dev/sg0 exclusively (No such
> device or address)", i.e. it seems to be ignoring my "-g" and
> trying to open sg0 anyway.  If I specify both -d and -g I get
> the above which is maybe even stranger.
Did you try cdda2wav (it should have the same device handling code as 
cdrecord)?

Maybe only cdparanoia is not fixed to not use sg.

-- 
http://LinuxWiki.org/RonnyBuchmann




From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Mon May 10 16:57:26 2004
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Mon, 10 May 2004 18:57:26 +0200
Subject: Which kernel will be integrated into Fedora Core 2 ?
In-Reply-To: <20040510152841.GF17668@angus.ind.WPI.EDU>
References: <0HXI0089C6TOHE@inbound2.hz.gov.cn>
	<20040510152841.GF17668@angus.ind.WPI.EDU>
Message-ID: <20040510185726.294e76da@localhost>

Charles R. Anderson wrote :

> An update to FC2 could possibly have 2.6.6 or later.

Seems pretty obvious, especially if the final FC2 kernel does ship with
firewire support disabled :-(

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1.92 (FC2 Test 3) - Linux kernel 2.6.5-1.351
Load : 1.28 1.36 1.32




From ulrick2 at faith4miracle.org  Mon May 10 18:27:34 2004
From: ulrick2 at faith4miracle.org (Steven P. Ulrick)
Date: Mon, 10 May 2004 13:27:34 -0500
Subject: CD ripping is broken on USB drives (Not any more :))
In-Reply-To: <200405101825.34814.ronny-vlug@vlugnet.org>
References: <409D6A24.6050808@botz.org> <409F9A2A.8070008@botz.org>
	<409F9BC8.2070100@botz.org>
	<200405101825.34814.ronny-vlug@vlugnet.org>
Message-ID: <20040510132734.7fbbea73.ulrick2@faith4miracle.org>

On Mon, 10 May 2004 18:25:34 +0200
Ronny Buchmann <ronny-vlug at vlugnet.org> wrote:

> On Monday 10 May 2004 17:12, Jurgen Botz wrote:
> > Jurgen Botz wrote:
> > > I explicitly tell cdparanoia to used /dev/scd0 as both
> > > the cdrom device and generic device it still tries to
> > > open sg0...
> > >[...]
> > >   Error trying to open /dev/scd0 exclusively (Read-only file
> > >   system).
> > >     retrying in 1 second.
> >
> > I just noticed that the error message is not consistent with
> > what I said... in fact, if I just use "cdparaoia -g /dev/scd0"
> > then I get "Error trying to open /dev/sg0 exclusively (No such
> > device or address)", i.e. it seems to be ignoring my "-g" and
> > trying to open sg0 anyway.  If I specify both -d and -g I get
> > the above which is maybe even stranger.
> Did you try cdda2wav (it should have the same device handling code as 
> cdrecord)?
> 
> Maybe only cdparanoia is not fixed to not use sg.

Hello, Ronny :)
A sublimely simple answer, but exactly what the doctor ordered, none the
less :)  I guess it shouldn't be to suprising that there might be issues
with cdparanoia, seeing as it doesn't appear to be under active
development.  (If I am mistaken, I do apologize.  The project page on
freshmeat appears to have been updated in 2002, and cdparanoia's home
page leads me to believe the same)

Anyway, thanks, Ronny.  I am now able to rip cd's again with my USB2
external CDRW drive :)

Have a Great Day :)
Steven P. Ulrick




From markf78 at yahoo.com  Mon May 10 20:09:14 2004
From: markf78 at yahoo.com (Mark Fonnemann)
Date: Mon, 10 May 2004 13:09:14 -0700 (PDT)
Subject: Self Introduction : Mark A. Fonnemann
Message-ID: <20040510200914.12787.qmail@web11409.mail.yahoo.com>

Hello-

1. Mark Alan Fonnemann

2. Chestnut Hill, MA, USA

3. Recently received my Master's in Mathematics. Looking for full-time
employment currently. do you have a job available for me??? :-)

4. Boston College, Computer Science, B.A.; Mathematics, M.A.

5. I'd like to see ghex packaged on a more regular basis i.e. every new source
release, I plan on packaging shortly after. It has been included in the past in
fedora.us but the package available is very old (2.4.*) where as (stable 2.5.*
and 2.6.0) has been available for some time.
 
6. I've been doing testing and filing bugs for Fedora Core 2 (especially
firewire). I've been around on fedora-test-list either finding firewire bugs or
asking stupid questions. ;-) i'm good for that. :-)

   I spend most of my time programming in C, VB, and Java. Hope to find a
position doing just that in the near future. I've also been known to be
interested in emulation, bison generated grammars, and (f)lexical analysis
along with a bunch of other theoretical computer science problems.

    Favorite computer book is (obviously) K&R C with Stevens' Unix Network
Programming a close second. Redhat user since RHL4... Fedora/Redhat has come a
long way since then!!

7.  i'm new to GPG. hopefully, i did this right!

pub  1024D/B0B9FE52 2004-05-10 Mark A. Fonnemann <m.fonneman.n at bc.edu>
     Key fingerprint = B121 4717 7D61 5E61 BC53  0729 1A92 D7EC B0B9 FE52
sub  1024g/8C4CED67 2004-05-10

mark. :-)


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 




From hp at redhat.com  Mon May 10 21:13:52 2004
From: hp at redhat.com (Havoc Pennington)
Date: Mon, 10 May 2004 17:13:52 -0400
Subject: systematic Kerberization
Message-ID: <1084223631.2770.77.camel@localhost.localdomain>

Hi,

Something we've wanted to do for a long time is create a matrix of
programs that should support Kerberos authentication, and start checking
them off. I guess this includes both client-side and server-side.

Does anyone have a good start on this?

Any real-world experience/scenarios where Kerberos support was needed
and not available? (Which things should be Kerberized first?)

Havoc





From sopwith at redhat.com  Mon May 10 21:49:29 2004
From: sopwith at redhat.com (Elliot Lee)
Date: Mon, 10 May 2004 17:49:29 -0400 (EDT)
Subject: systematic Kerberization
In-Reply-To: <1084223631.2770.77.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0405101743590.17813@devserv.devel.redhat.com>

On Mon, 10 May 2004, Havoc Pennington wrote:

> Something we've wanted to do for a long time is create a matrix of
> programs that should support Kerberos authentication, and start checking
> them off. I guess this includes both client-side and server-side.
>
> Does anyone have a good start on this?
> 
> Any real-world experience/scenarios where Kerberos support was needed
> and not available? (Which things should be Kerberized first?)

I started doing a mozilla plugin to allow Kerberos auth. If you can get
mozilla bug #134103 fixed, there is the potential for making intranet web
app auth be transparent.

-- Elliot
I keep committing atrocities in an attempt to learn from my mistakes.




From pryce at ucla.edu  Mon May 10 22:15:25 2004
From: pryce at ucla.edu (RIGOR,PAUL MACARAEG)
Date: Mon, 10 May 2004 15:15:25 -0700
Subject: Java Netbeans compatibility with FC2t3
Message-ID: <1084227325.409ffefd3d2bc@mail.ucla.edu>



Are there any known compatibility issues with the current FC2 test and Java?
 Their install doesn't seem to be working... ie, "busy text file" when I
try to execute

thanks,
paul




From skvidal at phy.duke.edu  Mon May 10 22:20:10 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 10 May 2004 18:20:10 -0400
Subject: systematic Kerberization
In-Reply-To: <1084223631.2770.77.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
Message-ID: <1084227610.2785.39.camel@opus>

On Mon, 2004-05-10 at 17:13, Havoc Pennington wrote:
> Hi,
> 
> Something we've wanted to do for a long time is create a matrix of
> programs that should support Kerberos authentication, and start checking
> them off. I guess this includes both client-side and server-side.
> 
> Does anyone have a good start on this?
> 
> Any real-world experience/scenarios where Kerberos support was needed
> and not available? (Which things should be Kerberized first?)
> 

Applications like gaim for jabber-based gssapi support would be handy -
this is where single sign on gets noticed.

Applications like the mailbox checker in the gnome panel applets -
actually having an applet lib that was kerberos aware (if that is even
possible) would be really handy for writing kerb apps for an applet.
like something to reinit your ticket, or blog applet, or any myriad of
things.

-sv





From petersen at redhat.com  Mon May 10 22:47:08 2004
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 11 May 2004 07:47:08 +0900
Subject: fedora 1.92, tclx-8.3.5-2 bug?
In-Reply-To: <409E389E.6000703@free.fr>
References: <409E389E.6000703@free.fr>
Message-ID: <m3hdunew7n.wl%petersen@redhat.com>

>>>>> "JF" == Jean-Luc FONTAINE <jfontain at free.fr> writes:

    JF> $ tclsh
    JF> % package require Tclx
    JF> Can't find tclx.tcl in the following directories:
    :
    JF> This probably means that TclX wasn't installed
    JF> properly.

    JF> Note: this is using my own Tcl 8.4.6 shell, but I
    JF> suspect it also happens with the tcl rpm in the 1.92
    JF> distribution.

Both /usr/bin/tclsh and /usr/bin/tcl work ok for me.  If you
look through the rpm changelog for tcl or tclx it will
probably become apparent what you're missing.  Otherwise if
you can still reproduce with the FC2 tcl please report the
problem in bugzilla.

Thanks, Jens




From ijuma82 at f2s.com  Mon May 10 22:52:41 2004
From: ijuma82 at f2s.com (Ismael Juma)
Date: Mon, 10 May 2004 23:52:41 +0100
Subject: Java Netbeans compatibility with FC2t3
In-Reply-To: <1084227325.409ffefd3d2bc@mail.ucla.edu>
References: <1084227325.409ffefd3d2bc@mail.ucla.edu>
Message-ID: <40A007B9.8080309@f2s.com>

RIGOR,PAUL MACARAEG wrote:
> 
> Are there any known compatibility issues with the current FC2 test and Java?
>  Their install doesn't seem to be working... ie, "busy text file" when I
> try to execute

I installed Netbeans 3.6 yesterday to a fully updated FC2 Test 3 machine 
without any problems. I had the J2SE 1.4.2_04 RPM from Sun installed and 
  I downloaded the .bin file from www.netbeans.org. All I had to do was 
make the file executable, run it and follow the instructions.

More information on what JVM you are using and what package you 
downloaded from the netbeans website would allow people to more easily 
diagnose your problem.

Regards,
Ismael

P.S. I'm not sure if this is the right list to discuss these issues. I 
think fedora-test-list would be more appropriate.




From enrico.scholz at informatik.tu-chemnitz.de  Mon May 10 22:31:49 2004
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Tue, 11 May 2004 00:31:49 +0200
Subject: systematic Kerberization
In-Reply-To: <1084223631.2770.77.camel@localhost.localdomain> (Havoc
	Pennington's message of "Mon, 10 May 2004 17:13:52 -0400")
References: <1084223631.2770.77.camel@localhost.localdomain>
Message-ID: <871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>

hp at redhat.com (Havoc Pennington) writes:

> Any real-world experience/scenarios where Kerberos support was needed
> and not available? (Which things should be Kerberized first?)

* cups
* evolution + mozilla (LDAP-bind with GSSAPI based auth) (maybe
  already added; there passed some time since my last tests)
* all the mail-notifier which are accessing IMAP/POP3 mailboxes
* cups
* dovecot (??)
* cups
* ssh
* CVS gserver is not runnable as non-root (a small LD_PRELOAD hack
  which overloads getuid()/getgid() helps; but native functionality
  would be nice) --> perhaps the alternative version management systems
  (subversion, arch) need kerberos support also

aah.. nearly I forgot one: cups




Enrico




From fedora at andrewfarris.com  Mon May 10 23:19:10 2004
From: fedora at andrewfarris.com (Andrew Farris)
Date: Mon, 10 May 2004 16:19:10 -0700
Subject: A few issues
In-Reply-To: <409F6EC2.402@it4texas.com>
References: <409F6EC2.402@it4texas.com>
Message-ID: <1084231150.23659.18.camel@CirithUngol>

On Mon, 2004-05-10 at 07:00 -0500, Robert Trembath wrote:
<snip>
> adding nvidia drivers that nvidia states supports 2.6.x kernels kills 
> the kernel. I get a message while compiling the module that the kernel 
> has been tainted and the system becones unusable.

Known issue, search the archives for the keywords nvidia and 4KSTACK or
just 4K.  The kernel in use for FC2 tests and release will not support
the current nVIDIA drivers.. you must recompile it with slight
modifications (details in the archives or on www.fedoraforum.org or
www.nvnews.net).

-- 
Andrew Farris, CPE senior (California Polytechnic State University, SLO)
fedora at andrewfarris.com :: lmorgul on irc.freenode.net
"The only thing necessary for the triumph of evil is for good men
to do nothing." (Edmond Burke)




From walters at redhat.com  Mon May 10 23:30:30 2004
From: walters at redhat.com (Colin Walters)
Date: Mon, 10 May 2004 19:30:30 -0400
Subject: systematic Kerberization
In-Reply-To: <871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <1084231829.7082.10.camel@nexus.verbum.private>

On Mon, 2004-05-10 at 18:31, Enrico Scholz wrote:
> perhaps the alternative version management systems
>   (subversion, arch) need kerberos support also

There is no arch server - basically all computation is done client-side,
for scalability and ease-of-use reasons.

-------------- 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/20040510/ac2309ac/attachment.sig>

From skvidal at phy.duke.edu  Mon May 10 23:47:00 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 10 May 2004 19:47:00 -0400
Subject: systematic Kerberization
In-Reply-To: <871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <1084232820.2008.4.camel@binkley>


> * cups

This is what I last saw on the subject -  I thought something else had
recently happened too:
http://www.cups.org/str.php?L646


> * evolution + mozilla (LDAP-bind with GSSAPI based auth) (maybe
>   already added; there passed some time since my last tests)
> * all the mail-notifier which are accessing IMAP/POP3 mailboxes

This exists. yes.

> * cups
I see a trend ;)

> * dovecot (??)
Timo is finishing 1.0 now, I'm not sure if he's implemented gssapi
support or not.

> * cups
hmm - indeed :)

> * ssh
I agree - having these in by default would be handy but I'm not sure
they're in upstream

> * CVS gserver is not runnable as non-root (a small LD_PRELOAD hack
>   which overloads getuid()/getgid() helps; but native functionality
>   would be nice) --> perhaps the alternative version management systems
>   (subversion, arch) need kerberos support also

subversion will need the 'server side' which I think is the subversion
or webdav module to be kerberized, too.



> aah.. nearly I forgot one: cups
 :)

-sv





From carwyn at carwyn.com  Tue May 11 00:15:20 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Tue, 11 May 2004 01:15:20 +0100
Subject: systematic Kerberization
In-Reply-To: <1084223631.2770.77.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
Message-ID: <40A01B18.9090508@carwyn.com>

Havoc Pennington wrote:

>Any real-world experience/scenarios where Kerberos support was needed
>and not available?
>
It would be nice to have _real_ kerberos support not just initial 
authentication support. Proper delegation for example would be very useful.

Carwyn




From smoogen at lanl.gov  Tue May 11 02:52:40 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Mon, 10 May 2004 20:52:40 -0600 (MDT)
Subject: systematic Kerberization
In-Reply-To: <1084227610.2785.39.camel@opus>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084227610.2785.39.camel@opus>
Message-ID: <Pine.LNX.4.58.0405102049240.9403@smoogen1.lanl.gov>


On Mon, 10 May 2004, seth vidal wrote:

>On Mon, 2004-05-10 at 17:13, Havoc Pennington wrote:
>> Hi,
>> 
>> Something we've wanted to do for a long time is create a matrix of
>> programs that should support Kerberos authentication, and start checking
>> them off. I guess this includes both client-side and server-side.
>> 
>> Does anyone have a good start on this?
>> 
>> Any real-world experience/scenarios where Kerberos support was needed
>> and not available? (Which things should be Kerberized first?)
>> 
>
>Applications like gaim for jabber-based gssapi support would be handy -
>this is where single sign on gets noticed.
>
>Applications like the mailbox checker in the gnome panel applets -
>actually having an applet lib that was kerberos aware (if that is even
>possible) would be really handy for writing kerb apps for an applet.
>like something to reinit your ticket, or blog applet, or any myriad of
>things.
>
>-sv

Lost the initial email so I am going to hang off of Seths

web authentication/tie ins 
cups
nfs
ssh + gssapi
samba (WinDomain)
jabber





-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From kaboom at gatech.edu  Tue May 11 03:08:31 2004
From: kaboom at gatech.edu (Chris Ricker)
Date: Mon, 10 May 2004 23:08:31 -0400 (EDT)
Subject: systematic Kerberization
In-Reply-To: <1084223631.2770.77.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
Message-ID: <Pine.GSO.4.58.0405102242580.3038@redfish.gatech.edu>

On Mon, 10 May 2004, Havoc Pennington wrote:

> Hi,
> 
> Something we've wanted to do for a long time is create a matrix of
> programs that should support Kerberos authentication, and start checking
> them off. I guess this includes both client-side and server-side.
> 
> Does anyone have a good start on this?
> 
> Any real-world experience/scenarios where Kerberos support was needed
> and not available? (Which things should be Kerberized first?)

RH actually used to support krb a bit better than it does now ;-(

At any rate, apps which need kerberization:

ssh -- can't remember off-hand if RH RPMs are patched now or not?
cups -- lprng did support, cups doesn't yet
dovecot -- uw-imap did support, dovecot doesn't yet
MUA -- no idea, as I don't use any of the ones RH ships
Mozilla -- efforts appear underway here
amanda -- not sure if upstream supports krb5 or just krb4 right now, but 
kerberized backups are a requirement here

For me, though, the biggest problem is the generic pam / glibc / moon phase
/ whatever interaction where RH and Fedora systems blow up badly, failing to
degrade back to existing local accounts, if a distributed information /
authentication (LDAP, krb, NIS) is down.... Any enterprise that's going
Kerberos, IMHO, can mostly work around the rest simply by pushing out more
functional software than what RH ships, but that one can be kinda a pain to
work around....

later,
chris




From nathanael at gnat.ca  Tue May 11 03:11:05 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Mon, 10 May 2004 20:11:05 -0700
Subject: IPSEC NETLINK errors
Message-ID: <D74A2489-A2F8-11D8-9C94-0003931B4D6A@gnat.ca>

Hello,
	I'm a little unsure of where to post this problem, but google turned 
up some results relating to it on this list I figured I might at least 
get a pointer of where to go.

	I am attempting to setup an IPSEC VPN in a net-to-net configuration. 
I've done it with freeswan/openswan and openvpn, so do know a bit about 
the stuff going on. I recently learned that the RH supplied kernels 
contain the 2.6 IPSEC stack backported, and the package ipsec-tools can 
be used to set up these tunnels. I started to learn the setkey to 
manually set one up. As I did that I found out that the 
redhat-config-network contains a tab for IPSEC stuff. Made me happy. 
Unfortunately I can't get it to work. The command ifup ipsec0 returns 
with NETLINK answers: Network is unreachable.
here is my ifcfg-ipsec0 file

# COMP A ifcfg-ipsec0
DSTGW=192.168.0.1
SRCGW=10.0.0.1
DSTNET=192.168.0.0/24
SRCNET=10.0.0.0/24
DST=24.72.x.x
TYPE=IPSEC
ONBOOT=no

		      --------------					                    ---------------
10.0.0.0/24---| COMP A | 24.68.x.x --- internet --- 24.72.x.x | COMP B 
| --- 192.168.0.0/24
		     ---------------							 ---------------

I've tried 2 different configuration setups with the compA's 
ifcfg-ipsec0 file.
this is the other one
# COMP A ifcfg-ipsec0

DSTGW=24.72.x.x
SRCGW=24.68.x.x
DSTNET=192.168.0.0/24
SRCNET=10.0.0.0/24
DST=24.72.x.x
TYPE=IPSEC
ONBOOT=no

my iptables contain on both sides...

iptables -t udp -p udp --dport 500 -j ACCEPT
iptables -p 50 -j ACCEPT
iptables -p 51 -j ACCEPT


So my two questions are:
1) What am I doing wrong?
	1a) How can I get greater debug info if that is what is needed?
2) If here isn't a good place to ask the above question, where do I go?


Thanks for any help you can provide.

-- 
Nathanael D. Noblet
Gnat Solutions
412 - 135 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/




From cmadams at hiwaay.net  Tue May 11 03:11:31 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 10 May 2004 22:11:31 -0500
Subject: systematic Kerberization
In-Reply-To: <871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <20040511031131.GA1442155@hiwaay.net>

Once upon a time, Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> said:
> * ssh

As I understand it (I don't yet do Kerberos), the latest OpenSSH has
integrated GSSAPI support.  Also, from what I understand, the FC version
of OpenSSH is older due to FC-specific patches (related to SELinux?), so
that has to be worked out (and then it should just be changing a compile
option to OpenSSH).
-- 
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 smoogen at lanl.gov  Tue May 11 03:15:09 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Mon, 10 May 2004 21:15:09 -0600 (MDT)
Subject: systematic Kerberization
In-Reply-To: <20040511031131.GA1442155@hiwaay.net>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<20040511031131.GA1442155@hiwaay.net>
Message-ID: <Pine.LNX.4.58.0405102113440.9403@smoogen1.lanl.gov>

On Mon, 10 May 2004, Chris Adams wrote:

>Once upon a time, Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> said:
>> * ssh
>
>As I understand it (I don't yet do Kerberos), the latest OpenSSH has
>integrated GSSAPI support.  Also, from what I understand, the FC version
>of OpenSSH is older due to FC-specific patches (related to SELinux?), so
>that has to be worked out (and then it should just be changing a compile
>option to OpenSSH).

3.8.1p1 has some GSSAPI support but not all GSSAPI support that 3.6 
does. It is a matter of the OpenSSH guys wanting to make sure it goes in 
working pieces than a ball. THe second matter is that the 3.6 GSSAPI is 
not compatible with the 3.8 version due to the differences in the 
proposed RFC between the 2 times.


-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From carwyn at carwyn.com  Tue May 11 03:19:51 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Tue, 11 May 2004 04:19:51 +0100
Subject: systematic Kerberization
In-Reply-To: <20040511031131.GA1442155@hiwaay.net>
References: <1084223631.2770.77.camel@localhost.localdomain>	<871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<20040511031131.GA1442155@hiwaay.net>
Message-ID: <40A04657.4030500@carwyn.com>

Chris Adams wrote:

>>* ssh
>>    
>>
>it should just be changing a compile option to OpenSSH.
>  
>
Last time I checked you could enable GSS suport in the RH OpenSSH rpms 
by simply adding the string "gss" to the release field:

 From the specfile:

# Apply gss-specific patches only if the release tag includes "gss".  (Not
# to be used for actual releases until it's in the mainline.)
if echo "%{release}" | grep -q gss; then
%patch11 -p1 -b .gssapi
autoreconf
fi

This worked for FC1 ones at least.

Carwyn




From smoogen at lanl.gov  Tue May 11 03:21:37 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Mon, 10 May 2004 21:21:37 -0600 (MDT)
Subject: systematic Kerberization
In-Reply-To: <Pine.GSO.4.58.0405102242580.3038@redfish.gatech.edu>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405102242580.3038@redfish.gatech.edu>
Message-ID: <Pine.LNX.4.58.0405102115500.9403@smoogen1.lanl.gov>

On Mon, 10 May 2004, Chris Ricker wrote:

>On Mon, 10 May 2004, Havoc Pennington wrote:
>
>> Hi,
>> 
>> Something we've wanted to do for a long time is create a matrix of
>> programs that should support Kerberos authentication, and start checking
>> them off. I guess this includes both client-side and server-side.
>> 
>> Does anyone have a good start on this?
>> 
>> Any real-world experience/scenarios where Kerberos support was needed
>> and not available? (Which things should be Kerberized first?)
>
>RH actually used to support krb a bit better than it does now ;-(
>
>At any rate, apps which need kerberization:
>
>ssh -- can't remember off-hand if RH RPMs are patched now or not?
>cups -- lprng did support, cups doesn't yet
>dovecot -- uw-imap did support, dovecot doesn't yet

 cyrus-imap does support it. We have had good success integrating it 
with squirrelmail also.

>MUA -- no idea, as I don't use any of the ones RH ships
>Mozilla -- efforts appear underway here
>amanda -- not sure if upstream supports krb5 or just krb4 right now, but 
>kerberized backups are a requirement here
>
>For me, though, the biggest problem is the generic pam / glibc / moon phase
>/ whatever interaction where RH and Fedora systems blow up badly, failing to
>degrade back to existing local accounts, if a distributed information /
>authentication (LDAP, krb, NIS) is down.... Any enterprise that's going
>Kerberos, IMHO, can mostly work around the rest simply by pushing out more
>functional software than what RH ships, but that one can be kinda a pain to
>work around....

Yes. right now that is the biggest complaint with the RHEL-3/Fedora 
laptops is that they are useless if taken offline without a manual 
change of turning off LDAP+etc. 


-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From kaboom at gatech.edu  Tue May 11 03:28:07 2004
From: kaboom at gatech.edu (Chris Ricker)
Date: Mon, 10 May 2004 23:28:07 -0400 (EDT)
Subject: systematic Kerberization
In-Reply-To: <Pine.LNX.4.58.0405102115500.9403@smoogen1.lanl.gov>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405102242580.3038@redfish.gatech.edu>
	<Pine.LNX.4.58.0405102115500.9403@smoogen1.lanl.gov>
Message-ID: <Pine.GSO.4.58.0405102324250.3038@redfish.gatech.edu>

On Mon, 10 May 2004, Stephen Smoogen wrote:

> >dovecot -- uw-imap did support, dovecot doesn't yet
> 
>  cyrus-imap does support it. We have had good success integrating it 
> with squirrelmail also.

Sure, but cyrus is a bit overkill for lots of situations. It'd be nice to
get things to the point where non-graybeards can easily run Kerberos on
their home network, and making them learn to admin cyrus instead of using
something simpler just throws another barrier in front of them....

later,
chris




From katzj at redhat.com  Tue May 11 04:27:55 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 11 May 2004 00:27:55 -0400
Subject: systematic Kerberization
In-Reply-To: <Pine.LNX.4.58.0405102113440.9403@smoogen1.lanl.gov>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<20040511031131.GA1442155@hiwaay.net>
	<Pine.LNX.4.58.0405102113440.9403@smoogen1.lanl.gov>
Message-ID: <1084249674.2942.1.camel@bree.local.net>

On Mon, 2004-05-10 at 21:15 -0600, Stephen Smoogen wrote:
> THe second matter is that the 3.6 GSSAPI is 
> not compatible with the 3.8 version due to the differences in the 
> proposed RFC between the 2 times.

Which, incidentally, is why we didn't include the patches when they were
first being proposed :)   Nalin was, justifiably, worried about just
this happening.

Jeremy




From katzj at redhat.com  Tue May 11 04:37:21 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 11 May 2004 00:37:21 -0400
Subject: systematic Kerberization
In-Reply-To: <Pine.GSO.4.58.0405102242580.3038@redfish.gatech.edu>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405102242580.3038@redfish.gatech.edu>
Message-ID: <1084250241.2942.13.camel@bree.local.net>

I'll reply... and since it's the -devel-list, I'll give pointers for
people looking for a project to work on :-)

On Mon, 2004-05-10 at 23:08 -0400, Chris Ricker wrote:
> ssh -- can't remember off-hand if RH RPMs are patched now or not?

Not at present, but with upstream traction on including this (or
starting to), this should be an easy one.  The thing that always bit me
with using this was questions about how ticket forwarding should work,
etc -- those may be resolved now since it's been about two years since I
seriously played with it.  Reports from people brave enough to try to
get the patches we include working with the current upstream version of
openssh and seeing how this works would probably be helpful.

> cups -- lprng did support, cups doesn't yet

There's some work upstream going on for this, see elsewhere in the
thread.  I also think I've seen links to even more positive information,
but I don't have a link off-hand.  

> dovecot -- uw-imap did support, dovecot doesn't yet

I started looking at this at one point, it seemed pretty straight
forward, it just requires the developer round 'tuits.  There are two
different approaches that can be taken here, one would be adding it
directly and the other would be improving the cyrus-sasl support and
then using cyrus-sasl-gssapi.  Upstream is definitely willing to accept
work in this area.

> MUA -- no idea, as I don't use any of the ones RH ships

evolution supports IMAP, SMTP and LDAP with gssapi auth.  So in theory,
this should be good.  Some of the new calendaring stuff may not yet, but
I haven't looked at that very closely.

> Mozilla -- efforts appear underway here

Yep, progress is being made.

> For me, though, the biggest problem is the generic pam / glibc / moon phase
> / whatever interaction where RH and Fedora systems blow up badly, failing to
> degrade back to existing local accounts, if a distributed information /
> authentication (LDAP, krb, NIS) is down.... Any enterprise that's going
> Kerberos, IMHO, can mostly work around the rest simply by pushing out more
> functional software than what RH ships, but that one can be kinda a pain to
> work around....

Yeah, I'm not quite sure what's going on here.  At the same time, it's
definitely not an unsolvable problem.  And since this is Havoc's
wishlist thread, we should make sure that fixing this ends up in
there ;)

Jeremy




From katzj at redhat.com  Tue May 11 04:54:37 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 11 May 2004 00:54:37 -0400
Subject: systematic Kerberization
In-Reply-To: <1084227610.2785.39.camel@opus>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084227610.2785.39.camel@opus>
Message-ID: <1084251276.2942.18.camel@bree.local.net>

On Mon, 2004-05-10 at 18:20 -0400, seth vidal wrote:
> Applications like the mailbox checker in the gnome panel applets -

One of the bounties was to have an evolution based applet to show when
you have new mail.  Basically, why should you configure your mail
sources twice?  From what I remember (and backed up by the bug --
http://bugzilla.gnome.org/show_bug.cgi?id=127516) someone got one
working, just after the original deadline.

> actually having an applet lib that was kerberos aware (if that is even
> possible) would be really handy for writing kerb apps for an applet.
> like something to reinit your ticket, or blog applet, or any myriad of
> things.

Maybe I'm missing something, but I don't see what you can genericize
here.  The applet itself wouldn't have any intrinsic properties related
to Kerberos, it has to do with the way that you actually contact and
authenticate with whatever service you're trying to use and they're all
a bit different here.  As far as the just doing the kerberos bits,
that's what libkrb5 is for.

Jeremy




From NOS at Utel.no  Tue May 11 07:17:41 2004
From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=)
Date: Tue, 11 May 2004 09:17:41 +0200
Subject: systematic Kerberization
In-Reply-To: <000101c436d3$e1173390$14aaa8c0@utelsystems.local>
References: <000101c436d3$e1173390$14aaa8c0@utelsystems.local>
Message-ID: <1084259861.15159.4.camel@nos-rh.utelsystems.local>

On Mon, 2004-05-10 at 23:15, Havoc Pennington wrote:
> Hi,
> 
> Something we've wanted to do for a long time is create a matrix of
> programs that should support Kerberos authentication, and start checking
> them off. I guess this includes both client-side and server-side.
> 
> Does anyone have a good start on this?
> 
> Any real-world experience/scenarios where Kerberos support was needed
> and not available? (Which things should be Kerberized first?)
* gnome-vfs , had some users that really would rather use GUI
applications
(Nautilus) to reach a kerberized ftp server.

Which btw reminds me, I rewrote gnome-kerberos a while ago, only used
by local users here yet, but it has among other things a systray icon
showing the status of your kerberos ticket, screenshot:
ftp://utelsystems.dyndns.org/pub/snapshot1.png
Something for Fedora ?

-- 
Nils Olav Sel?sdal
System Engineer
w w w . u t e l s y s t e m s . c o m





From NOS at Utel.no  Tue May 11 07:21:10 2004
From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=)
Date: Tue, 11 May 2004 09:21:10 +0200
Subject: systematic Kerberization
In-Reply-To: <000001c436e4$b31333c0$14aaa8c0@utelsystems.local>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<000001c436e4$b31333c0$14aaa8c0@utelsystems.local>
Message-ID: <1084260070.15155.8.camel@nos-rh.utelsystems.local>

On Tue, 2004-05-11 at 01:15, Enrico Scholz wrote:
> hp at redhat.com (Havoc Pennington) writes:
> 
> > Any real-world experience/scenarios where Kerberos support was needed
> > and not available? (Which things should be Kerberized first?)
...
> * CVS gserver is not runnable as non-root (a small LD_PRELOAD hack
>   which overloads getuid()/getgid() helps; but native functionality
>   would be nice) --> perhaps the alternative version management systems
>   (subversion, arch) need kerberos support also
> 
There is afaik gssapi support in neon now, and gssapi modules for
apache.
Should probably do to make Subversion kerberized. Never tried it myself 
thoug.

-- 
Nils Olav Sel?sdal
System Engineer
w w w . u t e l s y s t e m s . c o m





From felipe_alfaro at linuxmail.org  Tue May 11 07:22:22 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Tue, 11 May 2004 09:22:22 +0200
Subject: systematic Kerberization
In-Reply-To: <1084223631.2770.77.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
Message-ID: <1084260141.1685.8.camel@teapot.felipe-alfaro.com>

On Mon, 2004-05-10 at 23:13, Havoc Pennington wrote:
> Hi,
> 
> Something we've wanted to do for a long time is create a matrix of
> programs that should support Kerberos authentication, and start checking
> them off. I guess this includes both client-side and server-side.
> 
> Does anyone have a good start on this?
> 
> Any real-world experience/scenarios where Kerberos support was needed
> and not available? (Which things should be Kerberized first?)

My home network is completely Kerberized, and runs ontop of IPv6 +
IPSec... A lot of programs do already suppport Kerberos but, of course,
there are still programs that don't support some of these technologies. 

For example:

* cyrus-imapd supports Kerberos, since it uses cyrus-sasl, but does not
still support IPv6.
* evolution does support Kerberos and IPv6.
* OpenLDAP supports Kerberos and IPv6.
* OpenSSH does support Kerberos and IPv6.
* AFAICT, Apache does not still supoort Kerberos, but does support IPv6.
This would be interesting.
* AFAICT, Squid does not still support Kerberos.
* IIRC, ncftp and lftp don't support Kerberos, but do support IPv6
* The ftp command line tool that comes with krb5-workstation does
support Kerberos, but not IPv6.
* The telnet commnand line tool that comes with krb5-workstation does
support Kerberos plus IPv6, with encrypted sessions.
* IIRC, cups has some patches to add Kerberos support, but I think they
are not included upstream.

These are mainly the programs I use daily on my home network.

I think Apache and Squid should be immediately Kerberized, as well as
cups. They are basic infrastructure software.




From felipe_alfaro at linuxmail.org  Tue May 11 07:26:43 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Tue, 11 May 2004 09:26:43 +0200
Subject: systematic Kerberization
In-Reply-To: <1084232820.2008.4.camel@binkley>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<1084232820.2008.4.camel@binkley>
Message-ID: <1084260403.1685.12.camel@teapot.felipe-alfaro.com>

On Tue, 2004-05-11 at 01:47, seth vidal wrote:

> > * ssh
> I agree - having these in by default would be handy but I'm not sure
> they're in upstream

Kerberos support has been included upstream since 3.7, IIRC. In fact,
previous versions had Kerberos support, but it did only work with SSH
protocol version 1. 3.7+ does support Kerberos even when using SSH
protocol 2:

excerpt from /etc/ssh/sshd_config for OpenSSH 3.8:

# For SSH protocol version 1
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# For SSH protocol version 2
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes




From felipe_alfaro at linuxmail.org  Tue May 11 07:28:55 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Tue, 11 May 2004 09:28:55 +0200
Subject: systematic Kerberization
In-Reply-To: <Pine.LNX.4.58.0405102049240.9403@smoogen1.lanl.gov>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084227610.2785.39.camel@opus>
	<Pine.LNX.4.58.0405102049240.9403@smoogen1.lanl.gov>
Message-ID: <1084260534.1685.15.camel@teapot.felipe-alfaro.com>

On Tue, 2004-05-11 at 04:52, Stephen Smoogen wrote:

> Lost the initial email so I am going to hang off of Seths
> 
> web authentication/tie ins 
> cups
> nfs

NFSv4 does already support Kerberos/GSSAPI authentication. However, I
haven't tried to set it up yet.

> ssh + gssapi

Already included upstream since OpenSSH 3.7.




From wtogami at redhat.com  Tue May 11 08:12:27 2004
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 10 May 2004 22:12:27 -1000
Subject: Help Needed: Firefox 0.8 and Thunderbird 0.6
Message-ID: <40A08AEB.1030705@redhat.com>

https://bugzilla.fedora.us/show_bug.cgi?id=1460

Please assist Fedora Extras in preparing revisions of the firefox-0.8 
and thunderbird-0.6 packages before the release of FC2.  These packages 
are patched with Blizzard's xremote fixes which finally allow perfect 
integration with both firefox & thunderbird running simultaneously.  We 
have also spent a great deal of time making sure they work within the 
newly fixed Preferred Application framework of FC2.

Only minor changes are needed to both packages before publication.  Also 
it would help if Fedora Desktop volunteers can help to contact upstream 
developers to either act as liasons, or work directly with Fedora Extras 
development.

https://bugzilla.fedora.us/show_bug.cgi?id=1443
Even non-programmers can help by searching upstream mozilla.org bugzilla 
and talking to firefox or mozilla developers about this issue.  It is 
very likely that there already exists a patch or workaround for this 
issue, but the developers are too busy to search for it.  You can help!

For example, we have made this kind of very successful partnership with 
three upstream gaim developers.  They are automatically added to all 
Fedora gaim bug reports, and have helped us immensely to be very 
responsive to user bugzilla reports and package fixing.  (Currently 
there are ZERO open gaim reports in FC!)

Warren Togami
wtogami at redhat.com




From buildsys at redhat.com  Tue May 11 11:19:12 2004
From: buildsys at redhat.com (Build System)
Date: Tue, 11 May 2004 07:19:12 -0400
Subject: rawhide report: 20040511 changes
Message-ID: <200405111119.i4BBJCD00736@porkchop.devel.redhat.com>

 

 
Updated Packages:

cyrus-imapd-2.2.3-11
--------------------
* Sun May 09 2004 Karsten Hopp <karsten at redhat.de> 2.2.3-11

- don't enable cyrus-imapd per default (#122615)

fedora-release-2-2
------------------

fedora-release-2-3
------------------

im-sdk-11.4-42
--------------
* Mon May 10 2004 Akira TAGOH <tagoh at redhat.com> 1:11.4-42

- im-sdk-11.4-initscript-lock.patch: to avoid the conflicts, which causes 100%
  CPU eaten. (Warren Togami, FC2 BLOCKER #122631)

rpmdb-fedora-1.92-0.20040511
----------------------------

xinitrc-3.39-1
--------------
* Tue Mar 30 2004 Mike A. Harris <mharris at redhat.com> 3.39-1

- Fix problem in xinput script caused due to a bit of over-quoting in recent
  changes, which result in logged erros (FC2 BLOCKER #119529)

* Mon Mar 29 2004 Mike A. Harris <mharris at redhat.com> 3.38-1

- xinput fixes:
  - Fix missing ']' on elif test on line 25 (FC2 BLOCKER #119284)
  - Change test for /etc/profile.d/lang.sh to test with -r instead of -f
  - Change all non-null string tests to use -n instead of != ""
  - Change broken test logic in KDE block to use -o instead of ||
  - Fixes for iiimf getting turned on even for European languages where it
    is not useful. (Jens Petersen, FC2 BLOCKER #119241)
- Xsession cleanups:
  - Update Xsession for new switchdesk (Than Ngo, FC2 BLOCKER #116164)
  - Change all file existance tests using -f, to -r since we care if it is
    readable rather than if it exists or not.
  - Use new style $() command substitution rather than ``
- Updated the copyright messages of all script files, and added missing
  GPLv2 notices where appropriate.  Updated License: tag of spec file to be
  "GPLv2, MIT/X11"

* Tue Mar 16 2004 Mike A. Harris <mharris at redhat.com> 3.37-1

- Disable Requires: XFree86 dep, and add comment to spec file with reasoning,
  so if anything breaks, we can fix it up in a better way later on
- Xclients cleanups:
  - Check for existance of xclock and xterm binaries, both in /usr/bin, and
    in /usr/X11R6/bin before trying to execute either in failsafe
  - Check for executable existance of mozilla/fvwm/twm with -x, rather than
    just checking for existance with -f, and then use the explicit path to
    these binaries when executing them
- xinput cleanups:
  - Change shebang to use /bin/bash instead of /bin/sh, as our OS is always
    guaranteed to have /bin/bash installed on it because many other things
    require it anyway.  This makes it explicitly legal to use bashisms
    everywhere, of which are usually already being used anyway without notice,
    because /bin/sh is a link to /bin/bash by default.
  - Replace old style usage of "test x$foo" with 'if [ "$foo"' as it is much
    more readable.
  - Test for the readability of /etc/sysconfig/i18n with -r, rather than
    it's mere existance with -e
  - Everywhere -e was used to test for the existance of a binary prior to
    executing it, has been replaced with -x, which tests for executability
- Added "Requires: /usr/X11R6/bin/sessreg" for GiveConsole and TakeConsole
- Added "Requires: which /usr/X11R6/bin/RunWM" for Xclients
- Added "Requires: /sbin/pidof /usr/X11R6/bin/xsetroot" for Xsetup_0





From stonebeat at ya.com  Tue May 11 11:43:59 2004
From: stonebeat at ya.com (StoneBeat)
Date: Tue, 11 May 2004 13:43:59 +0200
Subject: Fedora treats security as a joke.
Message-ID: <200405111343.59319.stonebeat@ya.com>

I want to warn about the way that Fedora treats security, i'm a compulsive 
reader of security lists like bugtraq, and I've never seen some security 
advisor published by Fedora Security Coordinator (or something like that) as 
I've seen in other distros (Debian, Gentoo, SuSE ....) about notifying some 
important security advisors.

With regularly I am checking for updates using yum and see that there are new 
RPM updates. I believe that in these updates are the security fixes but  I 
really don't know it because there aren't advisors.

I fed up and i did a little research about security and Fedora, so i took some 
quite old security advisor relating "lha". Some people found security bugs in 
these tool, you can see more info here:
http://www.securiteam.com/unixfocus/5LP000KCVC.html

Today many distros have the  appropriate security advisor and patch, one of 
these distros is RedHat: http://rhn.redhat.com/errata/RHSA-2004-179.html
but Fedora users don't have security advisor or security patch, i check  yum 
and I don't see anything about lha and the lha version shipped with Fedora 
Core 1 is vulnerable:
[ice at laptop ice]$ rpm -qa | grep -i lha
lha-1.14i-12

[ice at laptop ice]$ lha x buf_oflow.lha
LHa: Error: Unknown information 
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
Segmentation fault
[ice at laptop ice]$

Where is the security advisor ??? and the security patch ???
Why Fedora doesn't have a security coordinator  or even a security team ?? 




From sds at epoch.ncsc.mil  Tue May 11 11:56:24 2004
From: sds at epoch.ncsc.mil (Stephen Smalley)
Date: Tue, 11 May 2004 07:56:24 -0400
Subject: systematic Kerberization
In-Reply-To: <20040511031131.GA1442155@hiwaay.net>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<20040511031131.GA1442155@hiwaay.net>
Message-ID: <1084276584.7460.1.camel@moss-spartans.epoch.ncsc.mil>

On Mon, 2004-05-10 at 23:11, Chris Adams wrote:
> As I understand it (I don't yet do Kerberos), the latest OpenSSH has
> integrated GSSAPI support.  Also, from what I understand, the FC version
> of OpenSSH is older due to FC-specific patches (related to SELinux?), so
> that has to be worked out (and then it should just be changing a compile
> option to OpenSSH).

AFAIK, the SELinux patch for openssh is _not_ holding back an update to
openssh in Fedora.  It certainly shouldn't, as the patch is quite
trivial now that sshd is using pam_selinux.

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




From jspaleta at gmail.com  Tue May 11 12:11:24 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 11 May 2004 08:11:24 -0400
Subject: Fedora treats security as a joke.
In-Reply-To: <200405111343.59319.stonebeat@ya.com>
References: <200405111343.59319.stonebeat@ya.com>
Message-ID: <604aa79104051105111beb1159@mail.gmail.com>

On Tue, 11 May 2004 13:43:59 +0200, StoneBeat <stonebeat at ya.com> wrote:
> Where is the security advisor ??? and the security patch ???

Security advisories for updates that have been released go here:
http://www.redhat.com/archives/fedora-announce-list/

Sercurity advisories for updates in testing go to
http://www.redhat.com/archives/fedora-test-list/

FedoraNews even has an rss feed.
http://www.fedoranews.org/rss/fedora-updates.xml

Cross-posting the update release annoucements to other lists is
something to consider. Why isn't it happening yet? That I don't know,
maybe its just one of those tasks waiting for a community volunteer to
take responsibility for.

> Why Fedora doesn't have a security coordinator  or even a security team ??

A difficult question, and probably too important an answer to be
sustituted with the assumption i'm working under that Red Hat's
security coord is also coordinating fedora security to some extent.


-jef




From leonard at den.ottolander.nl  Tue May 11 12:52:58 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Tue, 11 May 2004 14:52:58 +0200
Subject: Fedora treats security as a joke.
In-Reply-To: <604aa79104051105111beb1159@mail.gmail.com>
References: <200405111343.59319.stonebeat@ya.com>
	<604aa79104051105111beb1159@mail.gmail.com>
Message-ID: <1084279977.4753.5.camel@athlon.localdomain>

Hi Jeff, StoneBeat,

> > Why Fedora doesn't have a security coordinator  or even a security team ??
> 
> A difficult question, and probably too important an answer to be
> sustituted with the assumption i'm working under that Red Hat's
> security coord is also coordinating fedora security to some extent.

Also see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121417 :-)


From jorton at redhat.com  Tue May 11 13:02:44 2004
From: jorton at redhat.com (Joe Orton)
Date: Tue, 11 May 2004 14:02:44 +0100
Subject: systematic Kerberization
In-Reply-To: <871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <20040511130243.GA2239@redhat.com>

On Tue, May 11, 2004 at 12:31:49AM +0200, Enrico Scholz wrote:
> * CVS gserver is not runnable as non-root (a small LD_PRELOAD hack
>   which overloads getuid()/getgid() helps; but native functionality
>   would be nice) --> perhaps the alternative version management systems
>   (subversion, arch) need kerberos support also

We included Kerberos-over-HTTP support for both neon and httpd (courtesy
of the mod_auth_kerb package) in Fedora Core 2, so this should be simple
to configure for Subversion using the mod_dav_svn server.

Regards,

joe




From hp at redhat.com  Tue May 11 13:24:34 2004
From: hp at redhat.com (Havoc Pennington)
Date: Tue, 11 May 2004 09:24:34 -0400
Subject: systematic Kerberization
In-Reply-To: <1084250241.2942.13.camel@bree.local.net>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405102242580.3038@redfish.gatech.edu>
	<1084250241.2942.13.camel@bree.local.net>
Message-ID: <1084281874.3447.6.camel@localhost.localdomain>

On Tue, 2004-05-11 at 00:37, Jeremy Katz wrote:
> > For me, though, the biggest problem is the generic pam / glibc / moon phase
> > / whatever interaction where RH and Fedora systems blow up badly, failing to
> > degrade back to existing local accounts, if a distributed information /
> > authentication (LDAP, krb, NIS) is down.... Any enterprise that's going
> > Kerberos, IMHO, can mostly work around the rest simply by pushing out more
> > functional software than what RH ships, but that one can be kinda a pain to
> > work around....
> 
> Yeah, I'm not quite sure what's going on here.  At the same time, it's
> definitely not an unsolvable problem.  And since this is Havoc's
> wishlist thread, we should make sure that fixing this ends up in
> there ;)

This isn't the first strong customer request for disconnected operation.
I have no idea what's involved though (it seems like there would be some
tricky security issues?). I could ask Nalin, but public lists beat
hallway conversations. ;-)

Havoc





From smoogen at lanl.gov  Tue May 11 13:25:09 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Tue, 11 May 2004 07:25:09 -0600
Subject: systematic Kerberization
In-Reply-To: <1084249674.2942.1.camel@bree.local.net>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<871xlrx6ay.fsf@kosh.ultra.csn.tu-chemnitz.de>
	<20040511031131.GA1442155@hiwaay.net>
	<Pine.LNX.4.58.0405102113440.9403@smoogen1.lanl.gov>
	<1084249674.2942.1.camel@bree.local.net>
Message-ID: <1084281908.7192.7.camel@smoogen3.lanl.gov>

On Mon, 2004-05-10 at 22:27, Jeremy Katz wrote:
> On Mon, 2004-05-10 at 21:15 -0600, Stephen Smoogen wrote:
> > THe second matter is that the 3.6 GSSAPI is 
> > not compatible with the 3.8 version due to the differences in the 
> > proposed RFC between the 2 times.
> 
> Which, incidentally, is why we didn't include the patches when they were
> first being proposed :)   Nalin was, justifiably, worried about just
> this happening.
> 

Well sadly, I know of several large organizations that had to include
them anyway (or stop Linux deployment period.) Thankfully there is a
patch to enable backwards compatibility so that a transition can be done
someday.

> Jeremy
-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From smoogen at lanl.gov  Tue May 11 13:27:46 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Tue, 11 May 2004 07:27:46 -0600
Subject: systematic Kerberization
In-Reply-To: <1084260534.1685.15.camel@teapot.felipe-alfaro.com>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084227610.2785.39.camel@opus>
	<Pine.LNX.4.58.0405102049240.9403@smoogen1.lanl.gov>
	<1084260534.1685.15.camel@teapot.felipe-alfaro.com>
Message-ID: <1084282064.7192.11.camel@smoogen3.lanl.gov>

On Tue, 2004-05-11 at 01:28, Felipe Alfaro Solana wrote:
> On Tue, 2004-05-11 at 04:52, Stephen Smoogen wrote:
> 
> > Lost the initial email so I am going to hang off of Seths
> > 
> > web authentication/tie ins 
> > cups
> > nfs
> 
> NFSv4 does already support Kerberos/GSSAPI authentication. However, I
> haven't tried to set it up yet.
> 

Me either.

> > ssh + gssapi
> 
> Already included upstream since OpenSSH 3.7.

 Mostly. There is some more parts that need to be included to make it
the same as Simons 3.6 implementation. 

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From cra at WPI.EDU  Tue May 11 13:39:17 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Tue, 11 May 2004 09:39:17 -0400
Subject: systematic Kerberization
In-Reply-To: <1084260141.1685.8.camel@teapot.felipe-alfaro.com>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084260141.1685.8.camel@teapot.felipe-alfaro.com>
Message-ID: <20040511133917.GH12303@angus.ind.WPI.EDU>

On Tue, May 11, 2004 at 09:22:22AM +0200, Felipe Alfaro Solana wrote:
> * The ftp command line tool that comes with krb5-workstation does
> support Kerberos, but not IPv6.

I got bit by this one recently when the krb5 one was in my path before 
the standard one and IPv6 wasn't working.




From dennis at ausil.us  Tue May 11 13:40:50 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 11 May 2004 23:40:50 +1000
Subject: systematic Kerberization
In-Reply-To: <1084281874.3447.6.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084250241.2942.13.camel@bree.local.net>
	<1084281874.3447.6.camel@localhost.localdomain>
Message-ID: <200405112340.54305.dennis@ausil.us>

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

Once upon a time Tuesday 11 May 2004 11:24 pm, Havoc Pennington wrote:

>
> This isn't the first strong customer request for disconnected operation.
> I have no idea what's involved though (it seems like there would be some
> tricky security issues?). I could ask Nalin, but public lists beat
> hallway conversations. ;-)

I see disconected authentication as the caching of just enough data to allow 
system authentication.  all other authentication should be resolved when user 
becomes online again and can ask for new tickets.  for instance  at my old 
work i had 2 pcs  and sometimes i would have one disconected from the network 
so i could use my laptop on its network port.  and sometimes my password 
would expire before i could reconnect  so i would use my old password  but 
once i plugged back into the network i would have to reauthenticate so 
everything would work

but i guess to do it what you would need to do is create the key based on the 
password and compare it to an old key which needs to be stored somewhere 
secure

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAoNfmkSxm47BaWfcRAmN/AJ9rwqe3qLlfHQGyEiP1q8mptM2KLACeO1SJ
6PimrR7OlhcnKzUW8WTO5SM=
=w3oC
-----END PGP SIGNATURE-----




From mjc at redhat.com  Tue May 11 13:43:21 2004
From: mjc at redhat.com (Mark J Cox)
Date: Tue, 11 May 2004 14:43:21 +0100 (BST)
Subject: Fedora treats security as a joke.
In-Reply-To: <1084279977.4753.5.camel@athlon.localdomain>
References: <200405111343.59319.stonebeat@ya.com>
	<604aa79104051105111beb1159@mail.gmail.com>
	<1084279977.4753.5.camel@athlon.localdomain>
Message-ID: <Pine.LNX.4.58.0405111429490.17391@dell1.moose.awe.com>

> Also see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121417 :-)

Over the last few days we've been doing some checking of FC1 and FC2 
security issues.

For FC1 there are a few cases where updates have been made available but
the associated announcement email seems to have been eaten before making
it out to fedora-announce-list.  Thse are CAN-2004-0179, CAN-2003-0695,
CAN-2004-0180, and recent CAN-2004-0421, CAN-2003-0856.  We'll have to
redo those announcements.

For FC1 there have also been a few cases where updates are required but
are not released (I've pinged all the folks responsible for those packages
individually and now have bugzilla entries at "security" level). These are
CAN-2004-0234/5, CAN-2003-0988, CAN-2004-0409, CAN-2003-0564,
CAN-2004-0191, CAN-2004-0113.

For FC2 we went back through the issues of the last 6 months to see if
these were fixed by FC2 containing a fixed upstream version or if the FC2
package contained a backport.  There are a few issues that will require
updates:  I've opened bugzila entries for each of these at "security"
level.  These include CAN-2004-0399/0400, CAN-2004-0403, CAN-2004-0409.

Thanks, Mark
-- 
Mark J Cox / Red Hat Security Response Team


 




From kaboom at gatech.edu  Tue May 11 14:00:06 2004
From: kaboom at gatech.edu (Chris Ricker)
Date: Tue, 11 May 2004 10:00:06 -0400 (EDT)
Subject: systematic Kerberization
In-Reply-To: <200405112340.54305.dennis@ausil.us>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084250241.2942.13.camel@bree.local.net>
	<1084281874.3447.6.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
Message-ID: <Pine.GSO.4.58.0405110946280.9888@redfish.gatech.edu>

On Tue, 11 May 2004, Dennis Gilmore wrote:

> I see disconected authentication as the caching of just enough data to allow 
> system authentication.  all other authentication should be resolved when user 
> becomes online again and can ask for new tickets.  for instance  at my old 
> work i had 2 pcs  and sometimes i would have one disconected from the network 
> so i could use my laptop on its network port.  and sometimes my password 
> would expire before i could reconnect  so i would use my old password  but 
> once i plugged back into the network i would have to reauthenticate so 
> everything would work
> 
> but i guess to do it what you would need to do is create the key based on the 
> password and compare it to an old key which needs to be stored somewhere 
> secure

Why invent a new caching? We already have an off-line authentication system
-- standard Unix authentication. Rather than caching authentication, I'd
just like fall back to local accounts when disconnected. When I'm in the
airport, I should still be able to log into my laptop authenticating against
/etc/shadow even though I'm either not on a network, or on a network but not
able to access my ldap server, my kdc, etc.

later,
chris




From dennis at ausil.us  Tue May 11 14:05:22 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Wed, 12 May 2004 00:05:22 +1000
Subject: systematic Kerberization
In-Reply-To: <Pine.GSO.4.58.0405110946280.9888@redfish.gatech.edu>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<Pine.GSO.4.58.0405110946280.9888@redfish.gatech.edu>
Message-ID: <200405120005.22495.dennis@ausil.us>

Once upon a time Wednesday 12 May 2004 12:00 am, Chris Ricker wrote:
> On Tue, 11 May 2004, Dennis Gilmore wrote:
>
> Why invent a new caching? We already have an off-line authentication system
> -- standard Unix authentication. Rather than caching authentication, I'd
> just like fall back to local accounts when disconnected. When I'm in the
> airport, I should still be able to log into my laptop authenticating
> against /etc/shadow even though I'm either not on a network, or on a
> network but not able to access my ldap server, my kdc, etc.
>
> later,
> chris

because organisations with thousands of users  want to setup authentication 
once only in a central place  and have that information used for many 
different services and servers  as well as different machines.  




From smoogen at lanl.gov  Tue May 11 14:10:30 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Tue, 11 May 2004 08:10:30 -0600
Subject: systematic Kerberization
In-Reply-To: <200405120005.22495.dennis@ausil.us>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<Pine.GSO.4.58.0405110946280.9888@redfish.gatech.edu>
	<200405120005.22495.dennis@ausil.us>
Message-ID: <1084284629.7192.18.camel@smoogen3.lanl.gov>

On Tue, 2004-05-11 at 08:05, Dennis Gilmore wrote:
> Once upon a time Wednesday 12 May 2004 12:00 am, Chris Ricker wrote:
> > On Tue, 11 May 2004, Dennis Gilmore wrote:
> >
> > Why invent a new caching? We already have an off-line authentication system
> > -- standard Unix authentication. Rather than caching authentication, I'd
> > just like fall back to local accounts when disconnected. When I'm in the
> > airport, I should still be able to log into my laptop authenticating
> > against /etc/shadow even though I'm either not on a network, or on a
> > network but not able to access my ldap server, my kdc, etc.
> >
> > later,
> > chris
> 
> because organisations with thousands of users  want to setup authentication 
> once only in a central place  and have that information used for many 
> different services and servers  as well as different machines.  

The standard way I have seen it implemented on other versions of Linux
(here and other large organizations) is that the central authentication
is used first in the pam stack and if it fails/isnt available you get
authorized against the local password db which if it works lets you in.

In this scenario the person only gets network credentials if the
kerberos server is there and cant get off the box otherwise.  Anything
else is considered too security prone because the attacker already has
physical access to the asset.

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From kaboom at gatech.edu  Tue May 11 14:14:56 2004
From: kaboom at gatech.edu (Chris Ricker)
Date: Tue, 11 May 2004 10:14:56 -0400 (EDT)
Subject: systematic Kerberization
In-Reply-To: <200405120005.22495.dennis@ausil.us>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<Pine.GSO.4.58.0405110946280.9888@redfish.gatech.edu>
	<200405120005.22495.dennis@ausil.us>
Message-ID: <Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>

On Wed, 12 May 2004, Dennis Gilmore wrote:

> because organisations with thousands of users  want to setup authentication 
> once only in a central place  and have that information used for many 
> different services and servers  as well as different machines.  

Organizations also want security. Random authentication caching mechanisms 
are kinda counter to that....

later,
chris




From dennis at ausil.us  Tue May 11 14:17:58 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Wed, 12 May 2004 00:17:58 +1000
Subject: systematic Kerberization
In-Reply-To: <Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
Message-ID: <200405120017.58823.dennis@ausil.us>

Once upon a time Wednesday 12 May 2004 12:14 am, Chris Ricker wrote:
> On Wed, 12 May 2004, Dennis Gilmore wrote:
> > because organisations with thousands of users  want to setup
> > authentication once only in a central place  and have that information
> > used for many different services and servers  as well as different
> > machines.
>
> Organizations also want security. Random authentication caching mechanisms
> are kinda counter to that....
>
> later,
> chris


perhaps you shold read up on how kerberos authenticates users

Dennis




From NOS at Utel.no  Tue May 11 14:18:56 2004
From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=)
Date: Tue, 11 May 2004 16:18:56 +0200
Subject: systematic Kerberization
In-Reply-To: <000601c4375c$20b97340$14aaa8c0@utelsystems.local>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405102242580.3038@redfish.gatech.edu>
	<1084250241.2942.13.camel@bree.local.net>
	<000601c4375c$20b97340$14aaa8c0@utelsystems.local>
Message-ID: <1084285136.15160.25.camel@nos-rh.utelsystems.local>

On Tue, 2004-05-11 at 15:30, Havoc Pennington wrote:
> > Yeah, I'm not quite sure what's going on here.  At the same time, it's
> > definitely not an unsolvable problem.  And since this is Havoc's
> > wishlist thread, we should make sure that fixing this ends up in
> > there ;)
> 
> This isn't the first strong customer request for disconnected operation.
> I have no idea what's involved though (it seems like there would be some
> tricky security issues?). I could ask Nalin, but public lists beat
> hallway conversations. ;-)
It's twofold. One might need disconnected operations, in that you log
in as a user found in an LDAP directory. It can probably be discussed
wether you should be allowed to log in as that user if you pull your
network plug ;),  or that everything should continue to work if you pull
it after you already logged in.

The other thing is wether to log in to the box at all(to a local
account) if you configured ldap/kerberos/etc. in system-config-auth
Currently you cannot, which is very bad. Last I looked at it, it's just
a matter of changing some "required" to "suffcient" or similar in 
/etc/pam.d/system-auth





From kaboom at gatech.edu  Tue May 11 14:26:21 2004
From: kaboom at gatech.edu (Chris Ricker)
Date: Tue, 11 May 2004 10:26:21 -0400 (EDT)
Subject: systematic Kerberization
In-Reply-To: <200405120017.58823.dennis@ausil.us>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
Message-ID: <Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>

On Wed, 12 May 2004, Dennis Gilmore wrote:

> Once upon a time Wednesday 12 May 2004 12:14 am, Chris Ricker wrote:
> > On Wed, 12 May 2004, Dennis Gilmore wrote:
> > > because organisations with thousands of users  want to setup
> > > authentication once only in a central place  and have that information
> > > used for many different services and servers  as well as different
> > > machines.
> >
> > Organizations also want security. Random authentication caching mechanisms
> > are kinda counter to that....
> >
> > later,
> > chris
> 
> 
> perhaps you shold read up on how kerberos authenticates users

I'm well aware of how it works. I'm also aware that it doesn't solve the
problem of wanting to work disconnected. Kerberos ticket caching still
requires initial connectivity. It also does nothing for LDAP, NIS, etc.
You'd need a totally new ad-hoc caching mechanism above and beyond the krb
ticket cache, and I don't think it would turn out to be something any sane
organization would want.... Local accounts, OTOH, are an access control
mechanism that is at least well-understood, which is why our standard is to
fall back to them if distributed is unavailable.

later,
chris




From harald at redhat.com  Tue May 11 15:40:28 2004
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 11 May 2004 17:40:28 +0200
Subject: IPSEC NETLINK errors
In-Reply-To: <D74A2489-A2F8-11D8-9C94-0003931B4D6A@gnat.ca>
References: <D74A2489-A2F8-11D8-9C94-0003931B4D6A@gnat.ca>
Message-ID: <40A0F3EC.7060302@redhat.com>

Do you have
net.ipv4.ip_forward = 1
in /etc/sysctl.conf ??

Nathanael Noblet wrote:
> Hello,
>     I'm a little unsure of where to post this problem, but google turned 
> up some results relating to it on this list I figured I might at least 
> get a pointer of where to go.
> 
>     I am attempting to setup an IPSEC VPN in a net-to-net configuration. 
> I've done it with freeswan/openswan and openvpn, so do know a bit about 
> the stuff going on. I recently learned that the RH supplied kernels 
> contain the 2.6 IPSEC stack backported, and the package ipsec-tools can 
> be used to set up these tunnels. I started to learn the setkey to 
> manually set one up. As I did that I found out that the 
> redhat-config-network contains a tab for IPSEC stuff. Made me happy. 
> Unfortunately I can't get it to work. The command ifup ipsec0 returns 
> with NETLINK answers: Network is unreachable.
> here is my ifcfg-ipsec0 file
> 
> # COMP A ifcfg-ipsec0
> DSTGW=192.168.0.1
> SRCGW=10.0.0.1
> DSTNET=192.168.0.0/24
> SRCNET=10.0.0.0/24
> DST=24.72.x.x
> TYPE=IPSEC
> ONBOOT=no
> 
>               --------------                                        
> ---------------
> 10.0.0.0/24---| COMP A | 24.68.x.x --- internet --- 24.72.x.x | COMP B | 
> --- 192.168.0.0/24
>              ---------------                             ---------------
> 
> I've tried 2 different configuration setups with the compA's 
> ifcfg-ipsec0 file.
> this is the other one
> # COMP A ifcfg-ipsec0
> 
> DSTGW=24.72.x.x
> SRCGW=24.68.x.x
> DSTNET=192.168.0.0/24
> SRCNET=10.0.0.0/24
> DST=24.72.x.x
> TYPE=IPSEC
> ONBOOT=no
> 
> my iptables contain on both sides...
> 
> iptables -t udp -p udp --dport 500 -j ACCEPT
> iptables -p 50 -j ACCEPT
> iptables -p 51 -j ACCEPT
> 
> 
> So my two questions are:
> 1) What am I doing wrong?
>     1a) How can I get greater debug info if that is what is needed?
> 2) If here isn't a good place to ask the above question, where do I go?
> 
> 
> Thanks for any help you can provide.
> 




From harald at redhat.com  Tue May 11 15:42:14 2004
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 11 May 2004 17:42:14 +0200
Subject: IPSEC NETLINK errors
In-Reply-To: <D74A2489-A2F8-11D8-9C94-0003931B4D6A@gnat.ca>
References: <D74A2489-A2F8-11D8-9C94-0003931B4D6A@gnat.ca>
Message-ID: <40A0F456.2080400@redhat.com>

you can also have a look in:
/etc/sysconfig/network-scripts/ifup-ipsec
and trace it with:
# sh -x /etc/sysconfig/network-scripts/ifup-ipsec [....]

Nathanael Noblet wrote:
> Hello,
>     I'm a little unsure of where to post this problem, but google turned 
> up some results relating to it on this list I figured I might at least 
> get a pointer of where to go.
> 
>     I am attempting to setup an IPSEC VPN in a net-to-net configuration. 
> I've done it with freeswan/openswan and openvpn, so do know a bit about 
> the stuff going on. I recently learned that the RH supplied kernels 
> contain the 2.6 IPSEC stack backported, and the package ipsec-tools can 
> be used to set up these tunnels. I started to learn the setkey to 
> manually set one up. As I did that I found out that the 
> redhat-config-network contains a tab for IPSEC stuff. Made me happy. 
> Unfortunately I can't get it to work. The command ifup ipsec0 returns 
> with NETLINK answers: Network is unreachable.
> here is my ifcfg-ipsec0 file
> 
> # COMP A ifcfg-ipsec0
> DSTGW=192.168.0.1
> SRCGW=10.0.0.1
> DSTNET=192.168.0.0/24
> SRCNET=10.0.0.0/24
> DST=24.72.x.x
> TYPE=IPSEC
> ONBOOT=no
> 
>               --------------                                        
> ---------------
> 10.0.0.0/24---| COMP A | 24.68.x.x --- internet --- 24.72.x.x | COMP B | 
> --- 192.168.0.0/24
>              ---------------                             ---------------
> 
> I've tried 2 different configuration setups with the compA's 
> ifcfg-ipsec0 file.
> this is the other one
> # COMP A ifcfg-ipsec0
> 
> DSTGW=24.72.x.x
> SRCGW=24.68.x.x
> DSTNET=192.168.0.0/24
> SRCNET=10.0.0.0/24
> DST=24.72.x.x
> TYPE=IPSEC
> ONBOOT=no
> 
> my iptables contain on both sides...
> 
> iptables -t udp -p udp --dport 500 -j ACCEPT
> iptables -p 50 -j ACCEPT
> iptables -p 51 -j ACCEPT
> 
> 
> So my two questions are:
> 1) What am I doing wrong?
>     1a) How can I get greater debug info if that is what is needed?
> 2) If here isn't a good place to ask the above question, where do I go?
> 
> 
> Thanks for any help you can provide.
> 




From nathanael at gnat.ca  Tue May 11 15:57:54 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Tue, 11 May 2004 08:57:54 -0700
Subject: IPSEC NETLINK errors
In-Reply-To: <40A0F3EC.7060302@redhat.com>
Message-ID: <F6AB5432-A363-11D8-A88A-0003931B4D6A@gnat.ca>


On Tuesday, May 11, 2004, at 08:40 AM, Harald Hoyer wrote:

> Do you have
> net.ipv4.ip_forward = 1
> in /etc/sysctl.conf ??

Yes.

-- 
Nathanael D. Noblet
Gnat Solutions
412 - 135 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/




From nathanael at gnat.ca  Tue May 11 15:58:18 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Tue, 11 May 2004 08:58:18 -0700
Subject: IPSEC NETLINK errors
In-Reply-To: <40A0F456.2080400@redhat.com>
Message-ID: <04ED89CF-A364-11D8-A88A-0003931B4D6A@gnat.ca>


On Tuesday, May 11, 2004, at 08:42 AM, Harald Hoyer wrote:

> you can also have a look in:
> /etc/sysconfig/network-scripts/ifup-ipsec
> and trace it with:
> # sh -x /etc/sysconfig/network-scripts/ifup-ipsec [....]
>

ooh cool nifty feature. I see what is dying now to get that all 
working...

-- 
Nathanael D. Noblet
Gnat Solutions
412 - 135 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/




From hp at redhat.com  Tue May 11 16:10:40 2004
From: hp at redhat.com (Havoc Pennington)
Date: Tue, 11 May 2004 12:10:40 -0400
Subject: systematic Kerberization
In-Reply-To: <Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
Message-ID: <1084291840.4999.7.camel@localhost.localdomain>

On Tue, 2004-05-11 at 10:26, Chris Ricker wrote:
> I'm well aware of how it works. I'm also aware that it doesn't solve the
> problem of wanting to work disconnected. Kerberos ticket caching still
> requires initial connectivity. It also does nothing for LDAP, NIS, etc.
> You'd need a totally new ad-hoc caching mechanism above and beyond the krb
> ticket cache, and I don't think it would turn out to be something any sane
> organization would want.... Local accounts, OTOH, are an access control
> mechanism that is at least well-understood, which is why our standard is to
> fall back to them if distributed is unavailable.

What does Windows do for laptops?

Havoc





From bpm at ec-group.com  Tue May 11 16:35:04 2004
From: bpm at ec-group.com (Brian Millett)
Date: Tue, 11 May 2004 11:35:04 -0500 (CDT)
Subject: kernel: spurious 8259A interrupt: IRQ7
Message-ID: <21048.12.41.112.51.1084293304.squirrel@webmail.ec-group.com>

Hello,
I have a toshiba laptop with a miniPCI EL-2511MP PLUS 802.11/b card in it.
I am running kernel 2.6.5-1.358 with all of the updates as of today.

I am a bit confused (understatement)

I just lost ethernet connectivity and had to power cycle the laptop.  I
was getting so many messages written to /var/log/messages that the system
was unresponsive.  I was using XMMS listening to radio station.

Messages start with:
May 11 10:10:31 mktg6nt kernel: spurious 8259A interrupt: IRQ7.
May 11 10:41:27 mktg6nt kernel: eth1: error -110 reading info frame. Frame
dropped.
May 11 10:41:27 mktg6nt kernel: eth1: Error -110 writing Tx descriptor to BAP
May 11 10:41:29 mktg6nt last message repeated 349 times
May 11 10:41:29 mktg6nt kernel: hermes @ MEM 0x21ea1000: Timeout waiting
for command completion.
May 11 10:41:29 mktg6nt kernel: hermes @ MEM 0x21ea1000: Error -16 issuing
command.
May 11 10:41:29 mktg6nt kernel: eth1: Error -110 writing Tx descriptor to BAP
May 11 10:41:30 mktg6nt last message repeated 63 times
May 11 10:41:30 mktg6nt kernel: eth1: Ereth1: Error -110 writing Tx
descriptor to BAP
May 11 10:41:30 mktg6nt kernel: eth1: Error -110 writing Tx descriptor to BAP
May 11 10:41:31 mktg6nt last message repeated 81 times
May 11 10:41:31 mktg6nt kernel: eth1: Error -110 writing Tx eth1: Error
-110 writing Tx descriptor to BAP
May 11 10:41:31 mktg6nt kernel: eth1: Error -110 writing Tx descriptor to BAP
May 11 10:41:31 mktg6nt last message repeated 81 times
May 11 10:41:31 mktg6nt kernel: eth1: Error -110 writing Tx eth1: Error
-110 writing Tx descriptor to BAP


What I am really confused about are the following output from dmesg.

eth0: Station identity 001f:0009:0001:0004
eth0: Looks like an Intersil firmware version 1.4.9
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
eth0: MAC address 00:02:6F:04:64:6A
eth0: Station name "Prism  I"
eth0: ready
8139too Fast Ethernet driver 0.9.27
divert: allocating divert_blk for eth1
eth1: RealTek RTL8139 at 0x3000, 00:02:3f:8f:19:0e, IRQ 10
eth1:  Identified 8139 chip type 'RTL-8100B/8139D'

BUT I have this from ifconfig:

mktg6nt: ifconfig -a
eth1      Link encap:Ethernet  HWaddr 00:02:6F:04:64:6A
          inet addr:192.9.200.42  Bcast:192.9.200.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4129 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1028 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:826960 (807.5 Kb)  TX bytes:177917 (173.7 Kb)
          Interrupt:11 Base address:0x8000 Memory:e0500000-e0500fff


and in my modprobe.conf:
alias eth0 8139too
alias eth1 orinoco_pci


I am writting this with my laptop, so it came back up clean.  I just do
not understand the differences in the eth0/eth1 being reversed in the
dmesg output from the ifconfig output.

Should I change the modprobe.conf to have the orinoco_pci aliased to eth0
and the builtin 8139too aliased to eth0?

What is the 8259A interupt?  It seems like the builtin sound card.

Thanks.
-- 
Brian Millett
Enterprise Consulting Group  "Shifts in paradigms
(314) 205-9030           often cause nose bleeds."
bpmATec-groupDOTcom                     Greg Glenn






From ronny-vlug at vlugnet.org  Tue May 11 16:48:19 2004
From: ronny-vlug at vlugnet.org (Ronny Buchmann)
Date: Tue, 11 May 2004 18:48:19 +0200
Subject: systematic Kerberization
In-Reply-To: <1084291840.4999.7.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
Message-ID: <200405111848.19841.ronny-vlug@vlugnet.org>

On Tuesday 11 May 2004 18:10, you wrote:
> On Tue, 2004-05-11 at 10:26, Chris Ricker wrote:
> > I'm well aware of how it works. I'm also aware that it doesn't solve the
> > problem of wanting to work disconnected. Kerberos ticket caching still
> > requires initial connectivity. It also does nothing for LDAP, NIS, etc.
> > You'd need a totally new ad-hoc caching mechanism above and beyond the
> > krb ticket cache, and I don't think it would turn out to be something any
> > sane organization would want.... Local accounts, OTOH, are an access
> > control mechanism that is at least well-understood, which is why our
> > standard is to fall back to them if distributed is unavailable.
>
> What does Windows do for laptops?
Windows does caching.

 1. login on network (domain login)
 2. authentication information (user/password(hash?) is cached)
 3. logout
 4. timespan of length x
 5. disconnect
 5. login at domain (against cached auth info)

So in short, if you once were logged in, you can login at (any?) later time 
without network (AFAIK this needs to be enabled somewhere, it's not default).

-- 
http://LinuxWiki.org/RonnyBuchmann




From pmatilai at welho.com  Tue May 11 17:19:22 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Tue, 11 May 2004 20:19:22 +0300
Subject: systematic Kerberization
In-Reply-To: <200405111848.19841.ronny-vlug@vlugnet.org>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<200405111848.19841.ronny-vlug@vlugnet.org>
Message-ID: <1084295962.2833.14.camel@weasel.net.laiskiainen.org>

On Tue, 2004-05-11 at 19:48, Ronny Buchmann wrote:
> On Tuesday 11 May 2004 18:10, you wrote:
> > On Tue, 2004-05-11 at 10:26, Chris Ricker wrote:
> > > I'm well aware of how it works. I'm also aware that it doesn't solve the
> > > problem of wanting to work disconnected. Kerberos ticket caching still
> > > requires initial connectivity. It also does nothing for LDAP, NIS, etc.
> > > You'd need a totally new ad-hoc caching mechanism above and beyond the
> > > krb ticket cache, and I don't think it would turn out to be something any
> > > sane organization would want.... Local accounts, OTOH, are an access
> > > control mechanism that is at least well-understood, which is why our
> > > standard is to fall back to them if distributed is unavailable.
> >
> > What does Windows do for laptops?
> Windows does caching.
> 
>  1. login on network (domain login)
>  2. authentication information (user/password(hash?) is cached)
>  3. logout
>  4. timespan of length x
>  5. disconnect
>  5. login at domain (against cached auth info)
> 
> So in short, if you once were logged in, you can login at (any?) later time 
> without network (AFAIK this needs to be enabled somewhere, it's not default).

>From what I've seen I think Windows defaults to caching (but this is
just guessing from what I've seen, not claiming to know :) Anyway it's
not laptop specific: you have any workstation authenticating from a
domain, pull out the network cable and you're still able to log in if
you have previously logged in to that particular system. IIRC it also
cache's account and password expiration times so you can't just
endlessly keep logging into a system just by keeping it out of the
network.

I wrote a "pam_cache" module as an quick experiment a couple of years
ago which grabs the essential user+auth information from LDAP when you
login while connected to the network, rewrites the info to /etc/passwd &
friends and thus keeps the accounts more-or-less in sync. It sorta
worked but boy it was ugly :)

PADL has started some work towards this:
http://www.padl.com/OSS/pam_ccreds.html and
http://www.padl.com/OSS/nss_updatedb.html
However the way it currently works is that it dumps the whole contents
of user and group information from a directory to the local disk, which
isn't really acceptable with tens of thousands of users and groups...

	- Panu -



	- Panu -




From kaboom at gatech.edu  Tue May 11 17:25:13 2004
From: kaboom at gatech.edu (Chris Ricker)
Date: Tue, 11 May 2004 13:25:13 -0400 (EDT)
Subject: systematic Kerberization
In-Reply-To: <1084291840.4999.7.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
Message-ID: <Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>

On Tue, 11 May 2004, Havoc Pennington wrote:

> On Tue, 2004-05-11 at 10:26, Chris Ricker wrote:
> > I'm well aware of how it works. I'm also aware that it doesn't solve the
> > problem of wanting to work disconnected. Kerberos ticket caching still
> > requires initial connectivity. It also does nothing for LDAP, NIS, etc.
> > You'd need a totally new ad-hoc caching mechanism above and beyond the krb
> > ticket cache, and I don't think it would turn out to be something any sane
> > organization would want.... Local accounts, OTOH, are an access control
> > mechanism that is at least well-understood, which is why our standard is to
> > fall back to them if distributed is unavailable.
> 
> What does Windows do for laptops?

By default, domain accounts are cached locally, so that once you've logged
into a machine joined to the domain as a specific user, you can in the
future log in as that domain user to that machine using the cached password
even when disconnected. This caching of domain accounts can be disabled
through a registry edit, and various aspects of the caching can be
configured through the registry as well.

Also, it's always possible to select the local computer and log into that,
rather than into the domain.

later,
chris




From scribusdocs at atlantictechsolutions.com  Tue May 11 18:15:35 2004
From: scribusdocs at atlantictechsolutions.com (Peter Linnell)
Date: Tue, 11 May 2004 14:15:35 -0400
Subject: Help Needed: Firefox 0.8 and Thunderbird 0.6
In-Reply-To: <20040511134118.28D1F741F0@hormel.redhat.com>
References: <20040511134118.28D1F741F0@hormel.redhat.com>
Message-ID: <1084299334.1582.99.camel@localhost.localdomain>

<snip>

>For example, we have made this kind of very successful partnership
>with 
>three upstream gaim developers.  They are automatically added to all 
>Fedora gaim bug reports, and have helped us immensely to be very 
>responsive to user bugzilla reports and package fixing.  (Currently 
>there are ZERO open gaim reports in FC!)
>
>Warren Togami
>wtogami at redhat.com

This is one of the main reasons I began to become involved in Fedora.

Speaking only of Scribus, I want to know of *any* issues so that: a. we
can determine if it is a Fedora specific or packaging problem. b. make
Fedora aware of updates and new releases. c. provide a work around if
possible.

Once CVS is opened, this is something IMO which needs to be formalized.
Every project should have at its option the ability to be cc'd on all
bug reports relating to their package. 

 
Our experience with Debian and Scribus is instructive. There were
unknown to us for a long time, many stale bug reports in Debian's
tracker for Scribus. We also received a disproportionate amount of
complaints and issues from Debian users.

Scribus now has an outstanding Debian maintainer, who has worked very
closely with us to resolve most all the issues. Results: happy users,
fewer issues.

Cheers,
Peter










From sopwith at redhat.com  Tue May 11 18:50:45 2004
From: sopwith at redhat.com (Elliot Lee)
Date: Tue, 11 May 2004 14:50:45 -0400 (EDT)
Subject: Which kernel will be integrated into Fedora Core 2 ?
In-Reply-To: <0HXI0089C6TOHE@inbound2.hz.gov.cn>
References: <0HXI0089C6TOHE@inbound2.hz.gov.cn>
Message-ID: <Pine.LNX.4.58.0405101123130.17813@devserv.devel.redhat.com>

On Mon, 10 May 2004, hutuworm wrote:

> fedora-devel-list,
> 
>     Linus announced kernel 2.6.6 today, will it be integrated into Fedora Core 2 ?
> I've found many valuable bug-fixes in the new release.

Most of these fixes are already incorporated in one form or another in
2.6.5-1.358, which is very likely to be the final kernel for FC2.

-- Elliot
I keep committing atrocities in an attempt to learn from my mistakes.




From bubbob at ntlworld.com  Tue May 11 19:06:40 2004
From: bubbob at ntlworld.com (Steve Randall)
Date: Tue, 11 May 2004 20:06:40 +0100
Subject: Ximian-Connector (evolution-exchange) now GPL'd - time to sneak it
 in?
Message-ID: <40A12440.60808@ntlworld.com>


Now that the Ximian Connector for Microsoft Exchange has been GPL'd, is 
there any chance of it's inclusion?

http://cvs.gnome.org/viewcvs/evolution-exchange/

Steve




From felipe_alfaro at linuxmail.org  Tue May 11 19:13:55 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Tue, 11 May 2004 21:13:55 +0200
Subject: systematic Kerberization
In-Reply-To: <200405112340.54305.dennis@ausil.us>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084250241.2942.13.camel@bree.local.net>
	<1084281874.3447.6.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
Message-ID: <1084302834.3086.2.camel@teapot.felipe-alfaro.com>

On Tue, 2004-05-11 at 15:40, Dennis Gilmore wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Once upon a time Tuesday 11 May 2004 11:24 pm, Havoc Pennington wrote:
> 
> >
> > This isn't the first strong customer request for disconnected operation.
> > I have no idea what's involved though (it seems like there would be some
> > tricky security issues?). I could ask Nalin, but public lists beat
> > hallway conversations. ;-)
> 
> I see disconected authentication as the caching of just enough data to allow 
> system authentication.  all other authentication should be resolved when user 
> becomes online again and can ask for new tickets.  for instance  at my old 
> work i had 2 pcs  and sometimes i would have one disconected from the network 
> so i could use my laptop on its network port.  and sometimes my password 
> would expire before i could reconnect  so i would use my old password  but 
> once i plugged back into the network i would have to reauthenticate so 
> everything would work

Although I know this is not long-term solution, to allow using my laptop
when disconnected from my LAN, I have set up a local (i.e. shadow)
password for my user account which is the same as the one in the
Kerberos real.

Next, I configured PAM to first try pam_krb5.so and, if unable to
contact the KDC, try local shadow passwords. It works great when my KDC
is not reachable, but I must manually keep the shadow and Kerberos
password synched up.

Until disconnected operation works transparently, this is what I'll keep
using :-)




From felipe_alfaro at linuxmail.org  Tue May 11 19:18:42 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Tue, 11 May 2004 21:18:42 +0200
Subject: systematic Kerberization
In-Reply-To: <Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
Message-ID: <1084303122.3086.5.camel@teapot.felipe-alfaro.com>

On Tue, 2004-05-11 at 19:25, Chris Ricker wrote:
> On Tue, 11 May 2004, Havoc Pennington wrote:
> 
> > On Tue, 2004-05-11 at 10:26, Chris Ricker wrote:
> > > I'm well aware of how it works. I'm also aware that it doesn't solve the
> > > problem of wanting to work disconnected. Kerberos ticket caching still
> > > requires initial connectivity. It also does nothing for LDAP, NIS, etc.
> > > You'd need a totally new ad-hoc caching mechanism above and beyond the krb
> > > ticket cache, and I don't think it would turn out to be something any sane
> > > organization would want.... Local accounts, OTOH, are an access control
> > > mechanism that is at least well-understood, which is why our standard is to
> > > fall back to them if distributed is unavailable.
> > 
> > What does Windows do for laptops?
> 
> By default, domain accounts are cached locally, so that once you've logged
> into a machine joined to the domain as a specific user, you can in the
> future log in as that domain user to that machine using the cached password
> even when disconnected. This caching of domain accounts can be disabled
> through a registry edit, and various aspects of the caching can be
> configured through the registry as well.

Yep... It has worked that way since NT 4.0.

> Also, it's always possible to select the local computer and log into that,
> rather than into the domain.

Which is the same as authenticating against the local shadow password
;-)

We see there aren't much differences, indeed.
What worries me is how cached login information can be used by an
attacker to later gain access to resources on the local machine or the
network.




From jean-rene.cormier at cipanb.ca  Tue May 11 19:21:53 2004
From: jean-rene.cormier at cipanb.ca (Jean-Rene Cormier)
Date: Tue, 11 May 2004 16:21:53 -0300
Subject: systematic Kerberization
In-Reply-To: <1084302834.3086.2.camel@teapot.felipe-alfaro.com>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084250241.2942.13.camel@bree.local.net>
	<1084281874.3447.6.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<1084302834.3086.2.camel@teapot.felipe-alfaro.com>
Message-ID: <1084303312.13965.23.camel@forbidden.cipanb.ca>

On Tue, 2004-05-11 at 16:13, Felipe Alfaro Solana wrote:
> On Tue, 2004-05-11 at 15:40, Dennis Gilmore wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Once upon a time Tuesday 11 May 2004 11:24 pm, Havoc Pennington wrote:
> > 
> > >
> > > This isn't the first strong customer request for disconnected operation.
> > > I have no idea what's involved though (it seems like there would be some
> > > tricky security issues?). I could ask Nalin, but public lists beat
> > > hallway conversations. ;-)
> > 
> > I see disconected authentication as the caching of just enough data to allow 
> > system authentication.  all other authentication should be resolved when user 
> > becomes online again and can ask for new tickets.  for instance  at my old 
> > work i had 2 pcs  and sometimes i would have one disconected from the network 
> > so i could use my laptop on its network port.  and sometimes my password 
> > would expire before i could reconnect  so i would use my old password  but 
> > once i plugged back into the network i would have to reauthenticate so 
> > everything would work
> 
> Although I know this is not long-term solution, to allow using my laptop
> when disconnected from my LAN, I have set up a local (i.e. shadow)
> password for my user account which is the same as the one in the
> Kerberos real.
> 
> Next, I configured PAM to first try pam_krb5.so and, if unable to
> contact the KDC, try local shadow passwords. It works great when my KDC
> is not reachable, but I must manually keep the shadow and Kerberos
> password synched up.
> 
> Until disconnected operation works transparently, this is what I'll keep
> using :-)
> 

Why can't you setup PAM to change both the Kerberos and the shadow
password? 

Jean-Rene Cormier





From felipe_alfaro at linuxmail.org  Tue May 11 20:01:21 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Tue, 11 May 2004 22:01:21 +0200
Subject: systematic Kerberization
In-Reply-To: <1084303312.13965.23.camel@forbidden.cipanb.ca>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084250241.2942.13.camel@bree.local.net>
	<1084281874.3447.6.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<1084302834.3086.2.camel@teapot.felipe-alfaro.com>
	<1084303312.13965.23.camel@forbidden.cipanb.ca>
Message-ID: <1084305680.3086.7.camel@teapot.felipe-alfaro.com>

On Tue, 2004-05-11 at 21:21, Jean-Rene Cormier wrote:

> > Until disconnected operation works transparently, this is what I'll keep
> > using :-)
> > 
> 
> Why can't you setup PAM to change both the Kerberos and the shadow
> password? 

Cause I don't know how to do it? ;-)




From sp at linworx.cz  Tue May 11 20:04:10 2004
From: sp at linworx.cz (=?windows-1252?Q?Stanislav_Pol=E1=9Aek?=)
Date: Tue, 11 May 2004 22:04:10 +0200
Subject: Which kernel will be integrated into Fedora Core 2 ?
In-Reply-To: <Pine.LNX.4.58.0405101123130.17813@devserv.devel.redhat.com>
References: <0HXI0089C6TOHE@inbound2.hz.gov.cn>
	<Pine.LNX.4.58.0405101123130.17813@devserv.devel.redhat.com>
Message-ID: <40A131BA.3020603@linworx.cz>

Elliot Lee wrote:

>On Mon, 10 May 2004, hutuworm wrote:
>
>  
>
>>fedora-devel-list,
>>
>>    Linus announced kernel 2.6.6 today, will it be integrated into Fedora Core 2 ?
>>I've found many valuable bug-fixes in the new release.
>>    
>>
>
>Most of these fixes are already incorporated in one form or another in
>2.6.5-1.358, which is very likely to be the final kernel for FC2.
>
>  
>
Does it mean there will be no way to install fc2 on any asus p4p800 
mobo? Please see 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121819. I can 
confirm the problem persists with the 2.6.5-1.358 kernel. However, the 
smp kernel boots without problems.

Stanislav Polasek




From smoogen at lanl.gov  Tue May 11 20:09:12 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Tue, 11 May 2004 14:09:12 -0600
Subject: Ximian-Connector (evolution-exchange) now GPL'd - time to
	sneak it in?
In-Reply-To: <40A12440.60808@ntlworld.com>
References: <40A12440.60808@ntlworld.com>
Message-ID: <1084306150.4365.15.camel@smoogen3.lanl.gov>

On Tue, 2004-05-11 at 13:06, Steve Randall wrote:
> Now that the Ximian Connector for Microsoft Exchange has been GPL'd, is 
> there any chance of it's inclusion?
> 
> http://cvs.gnome.org/viewcvs/evolution-exchange/
> 

Maybe for FC3. I doubt it would be possible for FC2

> Steve
-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From ronny-vlug at vlugnet.org  Tue May 11 20:54:26 2004
From: ronny-vlug at vlugnet.org (Ronny Buchmann)
Date: Tue, 11 May 2004 22:54:26 +0200
Subject: systematic Kerberization
In-Reply-To: <1084295962.2833.14.camel@weasel.net.laiskiainen.org>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405111848.19841.ronny-vlug@vlugnet.org>
	<1084295962.2833.14.camel@weasel.net.laiskiainen.org>
Message-ID: <200405112254.26709.ronny-vlug@vlugnet.org>

On Tuesday 11 May 2004 19:19, Panu Matilainen wrote:
> I wrote a "pam_cache" module as an quick experiment a couple of years
> ago which grabs the essential user+auth information from LDAP when you
> login while connected to the network, rewrites the info to /etc/passwd &
> friends and thus keeps the accounts more-or-less in sync. It sorta
> worked but boy it was ugly :)
doesn't sound too bad
but I think it shouldn't change /etc/passwd but some /var/cache/pam or the 
like
And it should have some timeout (which of course only makes sense, if the 
hardware clock cannot be changed by the regular user)

> PADL has started some work towards this:
> http://www.padl.com/OSS/pam_ccreds.html and
> http://www.padl.com/OSS/nss_updatedb.html
> However the way it currently works is that it dumps the whole contents
> of user and group information from a directory to the local disk, which
> isn't really acceptable with tens of thousands of users and groups...
that sounds *really* ugly

-- 
http://LinuxWiki.org/RonnyBuchmann




From pmatilai at welho.com  Tue May 11 21:13:32 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Wed, 12 May 2004 00:13:32 +0300
Subject: Ximian-Connector (evolution-exchange) now GPL'd - time to
	sneak it in?
In-Reply-To: <40A12440.60808@ntlworld.com>
References: <40A12440.60808@ntlworld.com>
Message-ID: <1084310012.16788.0.camel@weasel.net.laiskiainen.org>

On Tue, 2004-05-11 at 22:06, Steve Randall wrote:
> Now that the Ximian Connector for Microsoft Exchange has been GPL'd, is 
> there any chance of it's inclusion?
> 
> http://cvs.gnome.org/viewcvs/evolution-exchange/

Just submitted to fedora.us QA :)
https://bugzilla.fedora.us/show_bug.cgi?id=1590

	- Panu -




From dennis at ausil.us  Tue May 11 21:35:57 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Wed, 12 May 2004 07:35:57 +1000
Subject: systematic Kerberization
In-Reply-To: <1084281874.3447.6.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084250241.2942.13.camel@bree.local.net>
	<1084281874.3447.6.camel@localhost.localdomain>
Message-ID: <200405120735.57953.dennis@ausil.us>

Once upon a time Tuesday 11 May 2004 11:24 pm, Havoc Pennington wrote:
> On Tue, 2004-05-11 at 00:37, Jeremy Katz wrote:
>
> This isn't the first strong customer request for disconnected operation.
> I have no idea what's involved though (it seems like there would be some
> tricky security issues?). I could ask Nalin, but public lists beat
> hallway conversations. ;-)

I had a thought on some way of maybe acheiving this  when you log in for first 
time to the kerberos Authentication server  a new entry is placed 
in /etc/passwd  but instead of a x for shadow password  you use a k for 
kerberos when you generate the  key between the Authentication server and 
user  you encrypt the password with it and save in /etc/kerberos/<username>  
so then in the future  if the user is disconnected  they can generate the key 
and decrypt the password  when not connecte to the network.  

Just an idea

Dennis




From hp at redhat.com  Tue May 11 22:01:04 2004
From: hp at redhat.com (Havoc Pennington)
Date: Tue, 11 May 2004 18:01:04 -0400
Subject: systematic Kerberization
In-Reply-To: <Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
Message-ID: <1084312863.3728.33.camel@localhost.localdomain>

On Tue, 2004-05-11 at 13:25, Chris Ricker wrote:
> On Tue, 11 May 2004, Havoc Pennington wrote:
> 
> > On Tue, 2004-05-11 at 10:26, Chris Ricker wrote:
> > > I'm well aware of how it works. I'm also aware that it doesn't solve the
> > > problem of wanting to work disconnected. Kerberos ticket caching still
> > > requires initial connectivity. It also does nothing for LDAP, NIS, etc.
> > > You'd need a totally new ad-hoc caching mechanism above and beyond the krb
> > > ticket cache, and I don't think it would turn out to be something any sane
> > > organization would want.... Local accounts, OTOH, are an access control
> > > mechanism that is at least well-understood, which is why our standard is to
> > > fall back to them if distributed is unavailable.
> > 
> > What does Windows do for laptops?
> 
> By default, domain accounts are cached locally, so that once you've logged
> into a machine joined to the domain as a specific user, you can in the
> future log in as that domain user to that machine using the cached password
> even when disconnected. This caching of domain accounts can be disabled
> through a registry edit, and various aspects of the caching can be
> configured through the registry as well.
> 
> Also, it's always possible to select the local computer and log into that,
> rather than into the domain.
> 

So the message I've gotten from others is "Windows solves this problem
and Linux does not" and they were aware of the ability to set up a local
passwd file when complaining.

I think the question we have to answer is why is there a perceived
deficiency vs. Windows, and can we address that without fundamental
security problems. Appears the perceived deficiency would include 1) we
aren't working out of the box, only if you fool around with it and
possibly requiring the end user to run authconfig 2) the local/remote
passwords can get out of sync.

Havoc





From nutello at sweetness.com  Tue May 11 22:31:17 2004
From: nutello at sweetness.com (Rudi Chiarito)
Date: Wed, 12 May 2004 00:31:17 +0200
Subject: systematic Kerberization
In-Reply-To: <1084303312.13965.23.camel@forbidden.cipanb.ca>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084250241.2942.13.camel@bree.local.net>
	<1084281874.3447.6.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<1084302834.3086.2.camel@teapot.felipe-alfaro.com>
	<1084303312.13965.23.camel@forbidden.cipanb.ca>
Message-ID: <20040511223117.GA28971@server4.8080.it>

On Tue, May 11, 2004 at 04:21:53PM -0300, Jean-Rene Cormier wrote:
> Why can't you setup PAM to change both the Kerberos and the shadow
> password? 

Then you need to handle the case when changing either (and not both of
them) fails.

Rudi




From jkeating at j2solutions.net  Tue May 11 23:15:37 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 11 May 2004 16:15:37 -0700
Subject: Which kernel will be integrated into Fedora Core 2 ?
In-Reply-To: <40A131BA.3020603@linworx.cz>
References: <0HXI0089C6TOHE@inbound2.hz.gov.cn>
	<Pine.LNX.4.58.0405101123130.17813@devserv.devel.redhat.com>
	<40A131BA.3020603@linworx.cz>
Message-ID: <200405111615.37569.jkeating@j2solutions.net>

On Tuesday 11 May 2004 13:04, Stanislav Pol??ek wrote:
> Does it mean there will be no way to install fc2 on any asus p4p800
> mobo? Please see
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121819. I can
> confirm the problem persists with the 2.6.5-1.358 kernel. However,
> the smp kernel boots without problems.

Yes unfortunately.  We have as of yet figured out what is wrong with 
those particular motherboards.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating




From dhollis at davehollis.com  Wed May 12 00:45:36 2004
From: dhollis at davehollis.com (David T Hollis)
Date: Tue, 11 May 2004 20:45:36 -0400
Subject: systematic Kerberization
In-Reply-To: <200405111848.19841.ronny-vlug@vlugnet.org>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<200405111848.19841.ronny-vlug@vlugnet.org>
Message-ID: <1084322736.3991.11.camel@dhollis-lnx.kpmg.com>

On Tue, 2004-05-11 at 18:48 +0200, Ronny Buchmann wrote:
> On Tuesday 11 May 2004 18:10, you wrote:
> >
> >
> > What does Windows do for laptops?
> Windows does caching.
> 
>  1. login on network (domain login)
>  2. authentication information (user/password(hash?) is cached)
>  3. logout
>  4. timespan of length x
>  5. disconnect
>  5. login at domain (against cached auth info)
> 
> So in short, if you once were logged in, you can login at (any?) later time 
> without network (AFAIK this needs to be enabled somewhere, it's not default).

Caching user credentials is enabled by default (for 10 user accounts
IIRC) up through XP.  Win2k3 may not do it since it is server oriented
and the whole "security push" marketing show.  Any security guide worth
its salt will tell you to turn that off, though in the Windows paradigm,
that does mess up laptops (which are the ones you would want it off on
since they are roaming all over the place!).  Another problem with it is
that if I login with LaptopA, do my thing and shutdown and then login
with LaptopB and change my password, I can still log into LaptopA while
disconnected from the network with my old password.

-- 
David T Hollis <dhollis at davehollis.com>




From vibol at khmer.cc  Wed May 12 01:03:46 2004
From: vibol at khmer.cc (Vibol Hou)
Date: Tue, 11 May 2004 18:03:46 -0700
Subject: kernel: spurious 8259A interrupt: IRQ7
In-Reply-To: <21048.12.41.112.51.1084293304.squirrel@webmail.ec-group.com>
References: <21048.12.41.112.51.1084293304.squirrel@webmail.ec-group.com>
Message-ID: <40A177F2.7040007@khmer.cc>

Brian Millett wrote:
> I am writting this with my laptop, so it came back up clean.  I just do
> not understand the differences in the eth0/eth1 being reversed in the
> dmesg output from the ifconfig output.

The exact same thing happens on my Latitude C400.  Sometimes it gets it 
right, sometimes it's flipped.  In the end, it works as long as I leave 
it alone.

> Should I change the modprobe.conf to have the orinoco_pci aliased to eth0
> and the builtin 8139too aliased to eth0?

I wouldn't touch it; I tried messing around with it a bit and it 
confused redhat-network-config.

--
vh




From kaboom at gatech.edu  Wed May 12 02:06:09 2004
From: kaboom at gatech.edu (Chris Ricker)
Date: Tue, 11 May 2004 22:06:09 -0400 (EDT)
Subject: systematic Kerberization
In-Reply-To: <1084312863.3728.33.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
	<1084312863.3728.33.camel@localhost.localdomain>
Message-ID: <Pine.GSO.4.58.0405112124230.21732@redfish.gatech.edu>

On Tue, 11 May 2004, Havoc Pennington wrote:

> So the message I've gotten from others is "Windows solves this problem
> and Linux does not" and they were aware of the ability to set up a local
> passwd file when complaining.
> 
> I think the question we have to answer is why is there a perceived
> deficiency vs. Windows, and can we address that without fundamental
> security problems. Appears the perceived deficiency would include 1) we
> aren't working out of the box, only if you fool around with it and
> possibly requiring the end user to run authconfig 2) the local/remote
> passwords can get out of sync.

Make that "require the end user NOT to run authconfig". Once you fix the pam
configs and actually get local authentication as fall-back running, you can
never run authconfig again without it undoing all your hard work (though
that's historically true of pam customization in general, but may be
changing since I vaguely recall recent changelogs mentioning changes to 
allow preservation of custom password quality settings).

At any rate, I don't think it's a case of a "perceived deficiency vs. 
Windows." It's a perceived deficiency, period, and it's not how other Unixen 
(Solaris, for example) or even other Linux distros behave....

later,
chris




From rgreab at fx.ro  Wed May 12 02:07:40 2004
From: rgreab at fx.ro (Radu Greab)
Date: Wed, 12 May 2004 05:07:40 +0300
Subject: Latest tree broke rpm?
In-Reply-To: <20040506180441.188568f8@localhost>
References: <20040505195208.441a4f26@localhost>
	<20040505195853.2e95e49c@localhost>
	<20040505190446.GD30909@devserv.devel.redhat.com>
	<20040505215517.GF30909@devserv.devel.redhat.com>
	<20040506180441.188568f8@localhost>
Message-ID: <m3zn8egzyr.wl@fx.ro>

Matthias Saou wrote:
> 
> I think such glibc knowledge would be useful to track down something
> funny that has been seen when trying to run a FC1 chroot on a FC2 test
> host... can't point to the discussion as sf.net lists seem to have
> stopped archiving, though :-(
> Basically all applications in the FC1 root segfault, and this doesn't
> happen with FC2test or RHLx roots and is reproducible. If it rings a
> bell, pointers are welcome ;-)
> 

The problem is caused by the FC1 old glibc running on a VDSO enabled
kernel. Disabling vdso (sysctl -w kernel.vdso=0) before creating the FC1
root and building inside it seems to be a good enough solution. 




From kaboom at gatech.edu  Wed May 12 02:10:01 2004
From: kaboom at gatech.edu (Chris Ricker)
Date: Tue, 11 May 2004 22:10:01 -0400 (EDT)
Subject: systematic Kerberization
In-Reply-To: <1084322736.3991.11.camel@dhollis-lnx.kpmg.com>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<200405111848.19841.ronny-vlug@vlugnet.org>
	<1084322736.3991.11.camel@dhollis-lnx.kpmg.com>
Message-ID: <Pine.GSO.4.58.0405112207290.21732@redfish.gatech.edu>

On Tue, 11 May 2004, David T Hollis wrote:

> Caching user credentials is enabled by default (for 10 user accounts
> IIRC) up through XP.  Win2k3 may not do it since it is server oriented
> and the whole "security push" marketing show.  Any security guide worth
> its salt will tell you to turn that off, though in the Windows paradigm,
> that does mess up laptops (which are the ones you would want it off on
> since they are roaming all over the place!).  Another problem with it is
> that if I login with LaptopA, do my thing and shutdown and then login
> with LaptopB and change my password, I can still log into LaptopA while
> disconnected from the network with my old password.

There are lots of corner cases with it. If you have password aging policies,
it will sometimes allow your users to log in with an expired password, for 
example....

later,
chris




From hp at redhat.com  Wed May 12 02:14:58 2004
From: hp at redhat.com (Havoc Pennington)
Date: Tue, 11 May 2004 22:14:58 -0400
Subject: Ximian-Connector (evolution-exchange) now GPL'd - time to
	sneak it in?
In-Reply-To: <1084306150.4365.15.camel@smoogen3.lanl.gov>
References: <40A12440.60808@ntlworld.com>
	<1084306150.4365.15.camel@smoogen3.lanl.gov>
Message-ID: <1084328098.2569.4.camel@localhost.localdomain>

On Tue, 2004-05-11 at 16:09, Stephen Smoogen wrote:
> On Tue, 2004-05-11 at 13:06, Steve Randall wrote:
> > Now that the Ximian Connector for Microsoft Exchange has been GPL'd, is 
> > there any chance of it's inclusion?
> > 
> > http://cvs.gnome.org/viewcvs/evolution-exchange/
> > 
> 
> Maybe for FC3. I doubt it would be possible for FC2
> 

Dave Malcolm was packaging it today, but won't be in FC2 official
release. I'm sure the package will work with FC2 though.

Havoc





From wtogami at redhat.com  Wed May 12 02:17:23 2004
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 11 May 2004 16:17:23 -1000
Subject: Ximian-Connector (evolution-exchange) now GPL'd - time to	sneak
 it in?
In-Reply-To: <1084328098.2569.4.camel@localhost.localdomain>
References: <40A12440.60808@ntlworld.com>	<1084306150.4365.15.camel@smoogen3.lanl.gov>
	<1084328098.2569.4.camel@localhost.localdomain>
Message-ID: <40A18933.4010502@redhat.com>

Havoc Pennington wrote:
> On Tue, 2004-05-11 at 16:09, Stephen Smoogen wrote:
> 
>>On Tue, 2004-05-11 at 13:06, Steve Randall wrote:
>>
>>>Now that the Ximian Connector for Microsoft Exchange has been GPL'd, is 
>>>there any chance of it's inclusion?
>>>
>>>http://cvs.gnome.org/viewcvs/evolution-exchange/
>>>
>>
>>Maybe for FC3. I doubt it would be possible for FC2
>>
> 
> 
> Dave Malcolm was packaging it today, but won't be in FC2 official
> release. I'm sure the package will work with FC2 though.
> 
> Havoc

https://bugzilla.fedora.us/show_bug.cgi?id=1589
spot packaged it...

https://bugzilla.fedora.us/show_bug.cgi?id=1590
panu packaged it...

Let's place bets on who wins. =)

Warren




From hp at redhat.com  Wed May 12 02:18:46 2004
From: hp at redhat.com (Havoc Pennington)
Date: Tue, 11 May 2004 22:18:46 -0400
Subject: systematic Kerberization
In-Reply-To: <Pine.GSO.4.58.0405112124230.21732@redfish.gatech.edu>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
	<1084312863.3728.33.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405112124230.21732@redfish.gatech.edu>
Message-ID: <1084328325.2569.8.camel@localhost.localdomain>

On Tue, 2004-05-11 at 22:06, Chris Ricker wrote:
> At any rate, I don't think it's a case of a "perceived deficiency vs. 
> Windows." It's a perceived deficiency, period, and it's not how other Unixen 
> (Solaris, for example) or even other Linux distros behave....

In that case it should be an easy fix - what do the other guys do, let's
get the change in.

The current situation seems to pretty obviously not work at all for
laptops, so security benefits are sort of irrelevant (a laptop may as
well be entombed in concrete if you can't log in while traveling...)

Havoc





From mattdm at mattdm.org  Wed May 12 02:44:03 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 11 May 2004 22:44:03 -0400
Subject: systematic Kerberization
In-Reply-To: <1084284629.7192.18.camel@smoogen3.lanl.gov>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<Pine.GSO.4.58.0405110946280.9888@redfish.gatech.edu>
	<200405120005.22495.dennis@ausil.us>
	<1084284629.7192.18.camel@smoogen3.lanl.gov>
Message-ID: <20040512024403.GA23960@jadzia.bu.edu>

On Tue, May 11, 2004 at 08:10:30AM -0600, Stephen Smoogen wrote:
> The standard way I have seen it implemented on other versions of Linux
> (here and other large organizations) is that the central authentication
> is used first in the pam stack and if it fails/isnt available you get
> authorized against the local password db which if it works lets you in.

"Other versions" including Red Hat Linux up until it suddenly stopped
working circa version 7.3.

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55193>


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




From kaboom at gatech.edu  Wed May 12 02:42:44 2004
From: kaboom at gatech.edu (Chris Ricker)
Date: Tue, 11 May 2004 22:42:44 -0400 (EDT)
Subject: systematic Kerberization
In-Reply-To: <1084328325.2569.8.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
	<1084312863.3728.33.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405112124230.21732@redfish.gatech.edu>
	<1084328325.2569.8.camel@localhost.localdomain>
Message-ID: <Pine.GSO.4.58.0405112219470.21732@redfish.gatech.edu>

On Tue, 11 May 2004, Havoc Pennington wrote:

> In that case it should be an easy fix - what do the other guys do, let's
> get the change in.
> 
> The current situation seems to pretty obviously not work at all for
> laptops, so security benefits are sort of irrelevant (a laptop may as
> well be entombed in concrete if you can't log in while traveling...)

Local accounts working when distributed source is down is AFAIK primarily
pam configuration (though the 40 bazillion bugzilla reports about it point
fingers all over the place -- debugging pam / nss / etc interactions is more
complex than is good for quality bug reports ;-).

later,
chris




From mattdm at mattdm.org  Wed May 12 02:46:00 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 11 May 2004 22:46:00 -0400
Subject: systematic Kerberization
In-Reply-To: <1084303122.3086.5.camel@teapot.felipe-alfaro.com>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
	<1084303122.3086.5.camel@teapot.felipe-alfaro.com>
Message-ID: <20040512024600.GB23960@jadzia.bu.edu>

On Tue, May 11, 2004 at 09:18:42PM +0200, Felipe Alfaro Solana wrote:
> Which is the same as authenticating against the local shadow password

Which is broken in Fedora.


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




From jeff at ollie.clive.ia.us  Wed May 12 04:27:55 2004
From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie)
Date: Tue, 11 May 2004 23:27:55 -0500
Subject: systematic Kerberization
In-Reply-To: <1084260141.1685.8.camel@teapot.felipe-alfaro.com>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084260141.1685.8.camel@teapot.felipe-alfaro.com>
Message-ID: <1084336075.2981.6.camel@pc05987.campus.dmacc.edu>

On Tue, 2004-05-11 at 09:22 +0200, Felipe Alfaro Solana wrote:
>
> * AFAICT, Apache does not still supoort Kerberos, but does support IPv6.
> This would be interesting.

http://modauthkerb.sourceforge.net/

Got it working earlier today on RH9 and FC1 systems.

There's a experimental plugin for Mozilla that supports transparent
authentication to a Kerberized web server (but I haven't tried it yet):

http://negotiateauth.mozdev.org/

Also, Samba supports Kerberos so that it can access Active Directory
domains.

Jeff





From helios82 at optushome.com.au  Wed May 12 05:15:49 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Wed, 12 May 2004 15:15:49 +1000
Subject: systematic Kerberization
In-Reply-To: <20040512024403.GA23960@jadzia.bu.edu>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<Pine.GSO.4.58.0405110946280.9888@redfish.gatech.edu>
	<200405120005.22495.dennis@ausil.us>
	<1084284629.7192.18.camel@smoogen3.lanl.gov>
	<20040512024403.GA23960@jadzia.bu.edu>
Message-ID: <1084338949.3436.9.camel@fc1>

On Wed, 2004-05-12 at 12:44, Matthew Miller wrote:
> On Tue, May 11, 2004 at 08:10:30AM -0600, Stephen Smoogen wrote:
> > The standard way I have seen it implemented on other versions of Linux
> > (here and other large organizations) is that the central authentication
> > is used first in the pam stack and if it fails/isnt available you get
> > authorized against the local password db which if it works lets you in.
> 
> "Other versions" including Red Hat Linux up until it suddenly stopped
> working circa version 7.3.
> 
> <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55193>


That bug report is over 2 1/2 years old without a single comment from
Nalin. Maybe Nalin doesn't maintain it anymore or is too busy - but
either way, maybe it should be re-assigned to another engineer?

Regards,
-Matt
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 

-------------- 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/20040512/f4032d99/attachment.sig>

From norm at turing.une.edu.au  Wed May 12 05:51:15 2004
From: norm at turing.une.edu.au (Norman Gaywood)
Date: Wed, 12 May 2004 15:51:15 +1000
Subject: systematic Kerberization
In-Reply-To: <1084338949.3436.9.camel@fc1>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<Pine.GSO.4.58.0405110946280.9888@redfish.gatech.edu>
	<200405120005.22495.dennis@ausil.us>
	<1084284629.7192.18.camel@smoogen3.lanl.gov>
	<20040512024403.GA23960@jadzia.bu.edu>
	<1084338949.3436.9.camel@fc1>
Message-ID: <20040512055115.GA6575@turing.une.edu.au>

On Wed, 2004-05-12 at 12:44, Matthew Miller wrote:
> On Tue, May 11, 2004 at 08:10:30AM -0600, Stephen Smoogen wrote:
> > The standard way I have seen it implemented on other versions of Linux
> > (here and other large organizations) is that the central authentication
> > is used first in the pam stack and if it fails/isnt available you get
> > authorized against the local password db which if it works lets you in.
> 
> "Other versions" including Red Hat Linux up until it suddenly stopped
> working circa version 7.3.
> 
> <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55193>

I just posted this on that bugzilla:

In September 2002 I went to a AUUG conference and listened to a talk
"Polythene PAM ain't what she used to be". This problem was described
then. Nalin is mentioned in the paper.

http://meltin.net/people/martin/publications/polythenepam.pdf

I don't know if the workaround in the paper solves the problem.

-- 
Norman Gaywood, Systems Administrator
School of Mathematics, Statistics and Computer Science
University of New England, Armidale, NSW 2351, Australia

norm at turing.une.edu.au            Phone: +61 (0)2 6773 2412
http://turing.une.edu.au/~norm    Fax:   +61 (0)2 6773 3312

Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html




From rc040203 at freenet.de  Wed May 12 06:39:52 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 12 May 2004 08:39:52 +0200
Subject: Choosing rpm-release for fc1 and fdr add-on rpms
Message-ID: <1084343991.3770.10772.camel@mccallum.corsepiu.local>

Hi,

I am planing to release a couple of rpms which are supposed to be add-on
packages to Fedora Core and/or Fedora Extras.

What is the current convention on choosing rpm release tags for such
packages to provide co-existence for such kind of packages?

AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist
such kind of convention. Conversely, all seem to be designed "to take
over the system". 

Ralf





From felipe_alfaro at linuxmail.org  Wed May 12 05:20:45 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Wed, 12 May 2004 07:20:45 +0200
Subject: systematic Kerberization
In-Reply-To: <20040512024600.GB23960@jadzia.bu.edu>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
	<1084303122.3086.5.camel@teapot.felipe-alfaro.com>
	<20040512024600.GB23960@jadzia.bu.edu>
Message-ID: <1084339245.1685.0.camel@teapot.felipe-alfaro.com>

On Wed, 2004-05-12 at 04:46, Matthew Miller wrote:
> On Tue, May 11, 2004 at 09:18:42PM +0200, Felipe Alfaro Solana wrote:
> > Which is the same as authenticating against the local shadow password
> 
> Which is broken in Fedora.

Yep! I reported this sometime ago, but it never got nailed down right. I
still have to manually tweak pam configuration files to get it working.




From thomas at apestaart.org  Wed May 12 07:26:59 2004
From: thomas at apestaart.org (Thomas Vander Stichele)
Date: Wed, 12 May 2004 09:26:59 +0200
Subject: Latest tree broke rpm?
In-Reply-To: <m3zn8egzyr.wl@fx.ro>
References: <20040505195208.441a4f26@localhost>
	<20040505195853.2e95e49c@localhost>
	<20040505190446.GD30909@devserv.devel.redhat.com>
	<20040505215517.GF30909@devserv.devel.redhat.com>
	<20040506180441.188568f8@localhost>  <m3zn8egzyr.wl@fx.ro>
Message-ID: <1084346819.29688.93.camel@otto.amantes>

On Wed, 2004-05-12 at 04:07, Radu Greab wrote:
> Matthias Saou wrote:
> > 
> > I think such glibc knowledge would be useful to track down something
> > funny that has been seen when trying to run a FC1 chroot on a FC2 test
> > host... can't point to the discussion as sf.net lists seem to have
> > stopped archiving, though :-(
> > Basically all applications in the FC1 root segfault, and this doesn't
> > happen with FC2test or RHLx roots and is reproducible. If it rings a
> > bell, pointers are welcome ;-)
> > 
> 
> The problem is caused by the FC1 old glibc running on a VDSO enabled
> kernel. Disabling vdso (sysctl -w kernel.vdso=0) before creating the FC1
> root and building inside it seems to be a good enough solution. 

Woah, thanks ! I was tearing my hair out trying to debug this.  I had
noticed that ldd seemed to claim everything was linked to
linux-gate.so.1, and had already figured out that this was some
kernel-provided dynamic .so, but I was unable to find much useful info
on linux-gate.so.1

I don't seem to find a lot about what vdso is either; could you please
enlighten me and point me to some locations where I can read up about
this feature ?

Anyway, this fixed our mach problems, so I'll look at integrating this
somewhere.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
When you can't trust yourself
trust someone else
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/





From wtogami at redhat.com  Wed May 12 08:11:42 2004
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 11 May 2004 22:11:42 -1000
Subject: Choosing rpm-release for fc1 and fdr add-on rpms
In-Reply-To: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
Message-ID: <40A1DC3E.4080506@redhat.com>

Ralf Corsepius wrote:
> Hi,
> 
> I am planing to release a couple of rpms which are supposed to be add-on
> packages to Fedora Core and/or Fedora Extras.
> 
> What is the current convention on choosing rpm release tags for such
> packages to provide co-existence for such kind of packages?
> 
> AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist
> such kind of convention. Conversely, all seem to be designed "to take
> over the system". 
> 

http://www.fedora.us/wiki/PackageSubmissionQAPolicy
http://www.fedora.us/wiki/PackageNamingGuidelines
If you follow these rules you generally will not clash with FC packages, 
but it takes a little practice to get it right.  The other volunteers 
will help you if you make mistakes, so don't worry.  It would help if 
you submit your packages to fedora.us QA just so other people know it 
exists.  (That process will NOT become easier when the SCM goes online, 
because only trusted & proven developers will have any checkin access at 
all, while everyone else must earn that trust through demonstrated hard 
work and dedication.)

I assume you mean by "taking over the system" you mean replacing 
packages that are within the core distribution?  fedora.us and livna 
does not do that at all.  The other 3rd party repositories are 
controlled by single persons and they generally do whatever they want 
unilaterally, for better or worse.

Warren




From den at tourinfo.ru  Wed May 12 09:27:17 2004
From: den at tourinfo.ru (Den)
Date: Wed, 12 May 2004 13:27:17 +0400
Subject: mozilla langpack
Message-ID: <40A1EDF5.1090608@tourinfo.ru>

I prepare localization package for Mozilla 1.6. It's doesn't contain in 
FedoraCore2-devel. My package already contain all localization stuff 
from mozilla.org.
It's tested with russian, ukrainian and belorusian locales and must work 
in all others. If you can test this package please get it from:

http://www.tourinfo.ru/mozilla-i18n-1.6-1.src.rpm (~17??)
http://www.tourinfo.ru/mozilla-i18n-1.6-1.i386.rpm (~16??)
http://www.tourinfo.ru/mozilla-i18n.spec

Den.




From Axel.Thimm at ATrpms.net  Wed May 12 09:31:04 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 12 May 2004 11:31:04 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on rpms)
In-Reply-To: <40A1DC3E.4080506@redhat.com>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com>
Message-ID: <20040512093104.GA9771@neu.nirvana>

On Tue, May 11, 2004 at 10:11:42PM -1000, Warren Togami wrote:
> Ralf Corsepius wrote:
> >I am planing to release a couple of rpms which are supposed to be add-on
> >packages to Fedora Core and/or Fedora Extras.
> >
> >What is the current convention on choosing rpm release tags for such
> >packages to provide co-existence for such kind of packages?
> >
> >AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist
> >such kind of convention.

We tried to discuss this here, but there wasn't much interest from Red
Hat's side, as Red Hat is always focusing on the latest release and
resolves concurrent builds for different distros (whenever they
happen) on an as needed basis (so each time the solution is different,
sometimes without a tag, sometimes with a tag like "FC1" and so on).

The main idea is to have a scheme that does not apply to the scope of
this one distribution and this current time window. It should apply on
FC, RHL, RHEL and why not Mandrake/SuSE, whatever.

So the general stance is to have a suffux to the release tag
containing an rpm-sortable disttag and an optional repotag, like

foo-1.2.3-4.rh9.ralf.src.rpm

So the release tag looks like

   <buildid><distid><distversion><repotag_opt>

where buildid shound end with digits (for example a simple integer
like "3", or something conatining cvs info like "0.cvs20040512.16"),
distid should be invariant for the family of distributions and
distversion should be rpm-sortable (7.3, 8.0, 9 for instance). Repotag
is placed at the least significant place wrt to rpm comparison and is
optional.

Nobody objected this scheme above, but the implementation was
difficult, given the constraint, that FC should be considered as a
successor to RHL in rpm upgrade path terms. So the disttag to FC
needed to be rpm-higher than that of RHL.

A solution used by currently most free repos is to have "rh" for RHL
and "rhfc" for FC. It works very well, but some (Warren ;) disliked
the association with rh in FC rpms and decided to find another
solution. Current rpm (2003 upwards) sort digits above letters, so
a trick/kludge is used in fedora.us' convention to ensure
upgradability, the distid in the scheme above is completely dropped.

There is no perfect scheme, and you need to choose for yourself. I
wished there would ba a scheme that would allow for 

       foo-1.2.3-4.fc1.ralf.src.rpm

without breaking too much the schemes for RH9 downwards. A suggestion
that was dropped here and died in silence, was to use fc0.9 for rh9 to
make it fit into this scheme, e.g. declaring RHL as a 0-dot
predecessor to FC. But again that was politicaly non-correct. :(

Anyway, RHx are all past EOL and perhaps it is time to consider a
scheme that is clan for FC ("fc1", "fc2", ...) and obfuscates RHL
releases. Anything that is rpm-smaller than "fc", e.g. let it start
with a-e, or maybe indeed the "fc0." distid for RHL.

> >Conversely, all seem to be designed "to take over the system".

Even though this is our secret obsession, what do you man by that? 

> I assume you mean by "taking over the system" you mean replacing 
> packages that are within the core distribution?  fedora.us and livna 
> does not do that at all.  The other 3rd party repositories are 
> controlled by single persons and they generally do whatever they want 
> unilaterally, for better or worse.

I am sure for better, but I am biased :)

It is funny that the single-person-controlls-all was the main argument
for the free repos leaving fedora.us last year ...

FWIW AFAIK all free repos accept submissions of packages and also help
you in setting up your repo, if that is what you want to do.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040512/445cc3d1/attachment.sig>

From leonard at den.ottolander.nl  Wed May 12 09:32:22 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Wed, 12 May 2004 11:32:22 +0200
Subject: Fedora treats security as a joke.
In-Reply-To: <Pine.LNX.4.58.0405111429490.17391@dell1.moose.awe.com>
References: <200405111343.59319.stonebeat@ya.com>
	<604aa79104051105111beb1159@mail.gmail.com>
	<1084279977.4753.5.camel@athlon.localdomain>
	<Pine.LNX.4.58.0405111429490.17391@dell1.moose.awe.com>
Message-ID: <1084354342.4746.51.camel@athlon.localdomain>

Hi Mark,

> Over the last few days we've been doing some checking of FC1 and FC2 
> security issues.

Thanks for the update, but instead of using only CAN numbers it would be
more clear to most when you'd also name the involved packages.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From rc040203 at freenet.de  Wed May 12 10:41:42 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 12 May 2004 12:41:42 +0200
Subject: Choosing rpm-release for fc1 and fdr add-on rpms
In-Reply-To: <40A1DC3E.4080506@redhat.com>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com>
Message-ID: <1084358501.3770.11305.camel@mccallum.corsepiu.local>

On Wed, 2004-05-12 at 10:11, Warren Togami wrote:
> Ralf Corsepius wrote:
> > Hi,
> > 
> > I am planing to release a couple of rpms which are supposed to be add-on
> > packages to Fedora Core and/or Fedora Extras.
> > 
> > What is the current convention on choosing rpm release tags for such
> > packages to provide co-existence for such kind of packages?
> > 
> > AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist
> > such kind of convention. Conversely, all seem to be designed "to take
> > over the system". 
> > 
> 
> http://www.fedora.us/wiki/PackageSubmissionQAPolicy
> http://www.fedora.us/wiki/PackageNamingGuidelines
> If you follow these rules you generally will not clash with FC packages, 
> but it takes a little practice to get it right.  The other volunteers 
> will help you if you make mistakes, so don't worry.  It would help if 
> you submit your packages to fedora.us QA just so other people know it 
> exists.  (That process will NOT become easier when the SCM goes online, 
> because only trusted & proven developers will have any checkin access at 
> all, while everyone else must earn that trust through demonstrated hard 
> work and dedication.)
> 
Some background info: I have a local repository of locally built RPMs, I
am considering some of them for submission to Fedora.Us/Extra/Legacy and
some of them for submission to 3rd party repositories, e.g. because some
of them are of too little general interest. 

Therefore I want to choose these rpms release tags in such a way that
they "play it nicely" with Fedora Core and Fedora Extras.

I.e. I want choose my rpm tags in such a way, that Fedora
Core/Updates/Extras/Legacy packages shall replace my rpms once Fedora
Core/Updates/Extras/Legacy should release the same packages.

> I assume you mean by "taking over the system" you mean replacing 
> packages that are within the core distribution?
I meant co-existence of packages from different origins (mixing Fedora
Core and Extras with 3rd party sources of RPMs).

>   fedora.us and livna 
> does not do that at all.
Theoretical example: Suppose the legal situation of a package changes,
and you would consider to move this package from Livna to Fedora Extras.
How would you deal with that?

ATM, Fedora/Stable uses 0.fdr.x.1, Livna uses 0.lvn.y.1.

RPM-wise, a package using 0.lvn* will always be greater than a package
using 0.fdr*. 
Now, you could increase the Epoch for the fdr package - Not necessarily
a good solution, IMHO.
You could increase the actual "release number" (use 1.fdr.*) - AFAIU,
this would contradict the Fedora.US versioning policy, because it would
cause problems with Fedora Core.

>   The other 3rd party repositories are 
> controlled by single persons and they generally do whatever they want 
> unilaterally, for better or worse.
That's why I am looking for "the better solution".
Or to bring it to the point: Which release-tag do you (Fedora US)
recommend for my purposes?

Ralf





From fedora at wir-sind-cool.org  Wed May 12 11:02:43 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 12 May 2004 13:02:43 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
 rpms)
In-Reply-To: <20040512093104.GA9771@neu.nirvana>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
Message-ID: <20040512130243.2b86c4ae.fedora@wir-sind-cool.org>

On Wed, 12 May 2004 11:31:04 +0200, Axel Thimm wrote:

> So the general stance is to have a suffux to the release tag
> containing an rpm-sortable disttag and an optional repotag, like
> 
> foo-1.2.3-4.rh9.ralf.src.rpm

Which is a bad suggestion, because the package %release version should
begin at 0, so any other version of the package which might appear in
Fedora Core would serve as an upgrade of this add-on.




From rdieter at math.unl.edu  Wed May 12 11:43:18 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 12 May 2004 06:43:18 -0500
Subject: mozilla langpack
In-Reply-To: <40A1EDF5.1090608@tourinfo.ru>
References: <40A1EDF5.1090608@tourinfo.ru>
Message-ID: <40A20DD6.7060708@math.unl.edu>

Den wrote:
> I prepare localization package for Mozilla 1.6. It's doesn't contain in 
> FedoraCore2-devel. My package already contain all localization stuff 
> from mozilla.org.
> It's tested with russian, ukrainian and belorusian locales and must work 
> in all others. If you can test this package please get it from:
> 
> http://www.tourinfo.ru/mozilla-i18n-1.6-1.src.rpm (~17??)
> http://www.tourinfo.ru/mozilla-i18n-1.6-1.i386.rpm (~16??)
> http://www.tourinfo.ru/mozilla-i18n.spec

Is there any reason this couldn't be built as a .noarch.rpm to share 
among all architectures?

-- Rex




From jean-rene.cormier at cipanb.ca  Wed May 12 11:53:38 2004
From: jean-rene.cormier at cipanb.ca (Jean-Rene Cormier)
Date: Wed, 12 May 2004 08:53:38 -0300
Subject: systematic Kerberization
In-Reply-To: <20040511223117.GA28971@server4.8080.it>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084250241.2942.13.camel@bree.local.net>
	<1084281874.3447.6.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<1084302834.3086.2.camel@teapot.felipe-alfaro.com>
	<1084303312.13965.23.camel@forbidden.cipanb.ca>
	<20040511223117.GA28971@server4.8080.it>
Message-ID: <1084362818.22183.10.camel@forbidden.cipanb.ca>

On Tue, 2004-05-11 at 19:31, Rudi Chiarito wrote:
> On Tue, May 11, 2004 at 04:21:53PM -0300, Jean-Rene Cormier wrote:
> > Why can't you setup PAM to change both the Kerberos and the shadow
> > password? 
> 
> Then you need to handle the case when changing either (and not both of
> them) fails.

There's a few things that could be done for that, if you change your
password while being disconnected you'll have to change it again to sync
them when you'll connect back to the network. Or only allow users to
change their password if they're connected to the network. Configuring
PAM for either of these way shouldn't be too hard. I'm sure there are
other ways to do it also.

Jean-Rene Cormier





From rdieter at math.unl.edu  Wed May 12 11:55:52 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 12 May 2004 06:55:52 -0500
Subject: Choosing rpm-release for fc1 and fdr add-on rpms
In-Reply-To: <1084358501.3770.11305.camel@mccallum.corsepiu.local>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>	<40A1DC3E.4080506@redhat.com>
	<1084358501.3770.11305.camel@mccallum.corsepiu.local>
Message-ID: <40A210C8.6060509@math.unl.edu>

Ralf Corsepius wrote:

> ATM, Fedora/Stable uses 0.fdr.x.1, Livna uses 0.lvn.y.1.
> 
> RPM-wise, a package using 0.lvn* will always be greater than a package
> using 0.fdr*. 

Unless you know your packages are definitely non-free, use fdr

-- Rex

p.s.  It has been argued that the repo_tag part of the release should 
appear *at the very end* for the very reason you describe.




From jean-rene.cormier at cipanb.ca  Wed May 12 11:56:04 2004
From: jean-rene.cormier at cipanb.ca (Jean-Rene Cormier)
Date: Wed, 12 May 2004 08:56:04 -0300
Subject: systematic Kerberization
In-Reply-To: <1084305680.3086.7.camel@teapot.felipe-alfaro.com>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<1084250241.2942.13.camel@bree.local.net>
	<1084281874.3447.6.camel@localhost.localdomain>
	<200405112340.54305.dennis@ausil.us>
	<1084302834.3086.2.camel@teapot.felipe-alfaro.com>
	<1084303312.13965.23.camel@forbidden.cipanb.ca>
	<1084305680.3086.7.camel@teapot.felipe-alfaro.com>
Message-ID: <1084362964.22183.13.camel@forbidden.cipanb.ca>

On Tue, 2004-05-11 at 17:01, Felipe Alfaro Solana wrote:
> On Tue, 2004-05-11 at 21:21, Jean-Rene Cormier wrote:
> 
> > > Until disconnected operation works transparently, this is what I'll keep
> > > using :-)
> > > 
> > 
> > Why can't you setup PAM to change both the Kerberos and the shadow
> > password? 
> 
> Cause I don't know how to do it? ;-)
> 

If you configured PAM to authenticate via pam_krb5.so then fall back on
local shadow passwords I'm sure you'll be able to figure out a way to
put pam_krb5.so in your /etc/pam.d/passwd ;)

Jean-Rene Cormier





From Nicolas.Mailhot at laPoste.net  Wed May 12 12:16:22 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 12 May 2004 14:16:22 +0200
Subject: mozilla langpack
In-Reply-To: <40A1EDF5.1090608@tourinfo.ru>
References: <40A1EDF5.1090608@tourinfo.ru>
Message-ID: <1084364181.17962.4.camel@ulysse.olympe.o2t>

Le mer, 12/05/2004 ? 13:27 +0400, Den a ?crit :
> I prepare localization package for Mozilla 1.6. It's doesn't contain in 
> FedoraCore2-devel. My package already contain all localization stuff 
> from mozilla.org.

Where do you download mozilla-i18n.tar.bz2 from ?

Cheers,

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

From den at tourinfo.ru  Wed May 12 12:25:43 2004
From: den at tourinfo.ru (Den)
Date: Wed, 12 May 2004 16:25:43 +0400
Subject: mozilla langpack
In-Reply-To: <1084364181.17962.4.camel@ulysse.olympe.o2t>
References: <40A1EDF5.1090608@tourinfo.ru>
	<1084364181.17962.4.camel@ulysse.olympe.o2t>
Message-ID: <40A217C7.90805@tourinfo.ru>

Nicolas Mailhot ?????:

>Le mer, 12/05/2004 ? 13:27 +0400, Den a ?crit :
>  
>
>
>Where do you download mozilla-i18n.tar.bz2 from ?
>
>Cheers,
>
>  
>
This is localization jar-files from xpi-packages and hand-made 
lang-locale.jar.txt and lang-locale-unix.jar.txt in one tar.bz2-archive.
http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib-localized-builds/

Den.




From buildsys at redhat.com  Wed May 12 12:37:42 2004
From: buildsys at redhat.com (Build System)
Date: Wed, 12 May 2004 08:37:42 -0400
Subject: rawhide report: 20040512 changes
Message-ID: <200405121237.i4CCbgl07693@porkchop.devel.redhat.com>

 

 
Updated Packages:

elilo-3.4-5
-----------
* Mon May 10 2004 Jeremy Katz <katzj at redhat.com> - 3.4-5

- update efibootmgr to 0.5.0-test3 adding sysfs support (#122566)

fedora-release-2-4
------------------

fedora-release-2-5
------------------

file-4.07-4
-----------
* Mon May 10 2004 Jakub Jelinek <jakub at redhat.com>

- fix ELF note handling (#109495)

* Tue Mar 23 2004 Karsten Hopp <karsten at redhat.de> 4.07-3 

- add docs (#115966)

* Tue Mar 02 2004 Elliot Lee <sopwith at redhat.com>

- rebuilt


glibc-2.3.3-27
--------------
* Tue May 11 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-27

- remove /lib64/tls/librtkaio-2.3.[23].so in glibc_post_upgrade
  on x86-64, s390x and ppc64 instead of /lib/tls/librtkaio-2.3.[23].so
- build mq_{send,receive} with -fexceptions

im-sdk-11.4-43
--------------
* Mon May 10 2004 Warren Togami <wtogami at redhat.com> 1:11.4-43

- im-sdk-11.4-htt-local-permit.patch: Allow htt connections when DNS does not match
  Fixes CJK for many users.  FC2 BLOCKER #121480

mozilla-1.6-8
-------------
* Mon May 10 2004 Christopher Blizzard <blizzard at redhat.com> 37:1.6-8

- Make sure that MOZ_APP_NAME is defined so that a non-empty property is
  set on the moz window.

* Mon May 10 2004 Christopher Blizzard <blizzard at redhat.com> 37:1.6-7

- Add a -a mozilla to the client in the startup script so that it will
  only talk to mozilla instances

rpmdb-fedora-2-0.20040512
-------------------------

udev-024-6
----------
* Mon May 10 2004 Elliot Lee <sopwith at redhat.com> 024-6

- Turn off udevd by default for FC2

up2date-4.3.19-1
----------------
* Tue May 11 2004 Adrian Likins <alikins at redhat.com>

- point sources at the new correct repo urls
- merge some multilib fixes from RHEL3 branch

* Fri May 07 2004 Adrian Likins <alikins at redhat.com>

- fix #122088 (arch->noarch updates)

yum-2.0.7-1.1
-------------
* Tue May 11 2004 Elliot Lee <sopwith at redhat.com> 2.0.7-1.1

- Update config again




From Nicolas.Mailhot at laPoste.net  Wed May 12 12:44:41 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 12 May 2004 14:44:41 +0200
Subject: mozilla langpack
In-Reply-To: <40A217C7.90805@tourinfo.ru>
References: <40A1EDF5.1090608@tourinfo.ru>
	<1084364181.17962.4.camel@ulysse.olympe.o2t>
	<40A217C7.90805@tourinfo.ru>
Message-ID: <1084365881.17962.9.camel@ulysse.olympe.o2t>

Le mer, 12/05/2004 ? 16:25 +0400, Den a ?crit :
> Nicolas Mailhot ?????:
> 
> >Le mer, 12/05/2004 ? 13:27 +0400, Den a ?crit :
> >  
> >
> >
> >Where do you download mozilla-i18n.tar.bz2 from ?
> >
> >Cheers,
> >
> >  
> >
> This is localization jar-files from xpi-packages and hand-made 
> lang-locale.jar.txt and lang-locale-unix.jar.txt in one tar.bz2-archive.
> http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib-localized-builds/

Ok, this is more or less what I suspected.

Please do not make up sources that do not exist upstream. Use original
sources in whatever format upstream chooses to release them, jar, zip,
txt, tar.gz, tar.bz2, xpi, cab, iso etc.

The rpm process is about documenting builds. When you performs steps
like archive creation out of the rpm process, you're breaking the QA
trail.

Cheers,

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

From Nicolas.Mailhot at laPoste.net  Wed May 12 12:51:44 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 12 May 2004 14:51:44 +0200
Subject: mozilla langpack
In-Reply-To: <40A217C7.90805@tourinfo.ru>
References: <40A1EDF5.1090608@tourinfo.ru>
	<1084364181.17962.4.camel@ulysse.olympe.o2t>
	<40A217C7.90805@tourinfo.ru>
Message-ID: <1084365881.17962.9.camel@ulysse.olympe.o2t>

Le mer, 12/05/2004 ? 16:25 +0400, Den a ?crit :
> Nicolas Mailhot ?????:
> 
> >Le mer, 12/05/2004 ? 13:27 +0400, Den a ?crit :
> >  
> >
> >
> >Where do you download mozilla-i18n.tar.bz2 from ?
> >
> >Cheers,
> >
> >  
> >
> This is localization jar-files from xpi-packages and hand-made 
> lang-locale.jar.txt and lang-locale-unix.jar.txt in one tar.bz2-archive.
> http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib-localized-builds/

Ok, this is more or less what I suspected.

Please do not make up sources that do not exist upstream. Use original
sources in whatever format upstream chooses to release them, jar, zip,
txt, tar.gz, tar.bz2, xpi, cab, iso etc.

The rpm process is about documenting builds. When you performs steps
like archive creation out of the rpm process, you're breaking the QA
trail.

Cheers,

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

From alan at redhat.com  Wed May 12 13:11:56 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 12 May 2004 09:11:56 -0400
Subject: systematic Kerberization
In-Reply-To: <Pine.GSO.4.58.0405112219470.21732@redfish.gatech.edu>
References: <200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
	<1084312863.3728.33.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405112124230.21732@redfish.gatech.edu>
	<1084328325.2569.8.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405112219470.21732@redfish.gatech.edu>
Message-ID: <20040512131156.GD30020@devserv.devel.redhat.com>

On Tue, May 11, 2004 at 10:42:44PM -0400, Chris Ricker wrote:
> Local accounts working when distributed source is down is AFAIK primarily
> pam configuration (though the 40 bazillion bugzilla reports about it point
> fingers all over the place -- debugging pam / nss / etc interactions is more
> complex than is good for quality bug reports ;-).

It seems to be pam layer bugs in part but as you say its non trivial. There
are some possible fixes sittin gin bugzilla.




From fedora at wir-sind-cool.org  Wed May 12 11:49:51 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 12 May 2004 13:49:51 +0200
Subject: Choosing rpm-release for fc1 and fdr add-on rpms
In-Reply-To: <1084358501.3770.11305.camel@mccallum.corsepiu.local>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com>
	<1084358501.3770.11305.camel@mccallum.corsepiu.local>
Message-ID: <20040512134951.1f826eb8.fedora@wir-sind-cool.org>

On Wed, 12 May 2004 12:41:42 +0200, Ralf Corsepius wrote:

> Therefore I want to choose these rpms release tags in such a way that
> they "play it nicely" with Fedora Core and Fedora Extras.
> 
> I.e. I want choose my rpm tags in such a way, that Fedora
> Core/Updates/Extras/Legacy packages shall replace my rpms once Fedora
> Core/Updates/Extras/Legacy should release the same packages.

That's what the fedora.us package naming guidelines address. You can find
the Fedora Legacy package naming guidelines on their own website.
 
> Theoretical example: Suppose the legal situation of a package changes,
> and you would consider to move this package from Livna to Fedora Extras.
> How would you deal with that?
> 
> ATM, Fedora/Stable uses 0.fdr.x.1, Livna uses 0.lvn.y.1.

It's the classical "repotags suck" example. :)

Similarly, disttags cause problems too, so preferably the ".fdr"
and ".lvn" would be dropped.

> You could increase the actual "release number" (use 1.fdr.*) - AFAIU,
> this would contradict the Fedora.US versioning policy, because it would
> cause problems with Fedora Core.

Which would be fine nevertheless, since at some point in time, a bit of
coordinating would not hurt and existing packages in fedora.us should not
be ignored.
 
> Or to bring it to the point: Which release-tag do you (Fedora US)
> recommend for my purposes?

Stick to the current one for the time being.




From rc040203 at freenet.de  Wed May 12 13:44:53 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 12 May 2004 15:44:53 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040512093104.GA9771@neu.nirvana>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com>  <20040512093104.GA9771@neu.nirvana>
Message-ID: <1084369435.3770.11838.camel@mccallum.corsepiu.local>

This answer has become lengthy. The essential part is at the end of this mail
:-)

On Wed, 2004-05-12 at 11:31, Axel Thimm wrote:
> On Tue, May 11, 2004 at 10:11:42PM -1000, Warren Togami wrote:
> > Ralf Corsepius wrote:
> > >I am planing to release a couple of rpms which are supposed to be add-on
> > >packages to Fedora Core and/or Fedora Extras.
> > >
> > >What is the current convention on choosing rpm release tags for such
> > >packages to provide co-existence for such kind of packages?
> > >
> > >AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist
> > >such kind of convention.
> 
> We tried to discuss this here, but there wasn't much interest from Red
> Hat's side, as Red Hat is always focusing on the latest release and
> resolves concurrent builds for different distros (whenever they
> happen) on an as needed basis (so each time the solution is different,
> sometimes without a tag, sometimes with a tag like "FC1" and so on).
Though not having participated, I recall these discussions and wish they
would have come to a satisfactory conclusion ;)

> The main idea is to have a scheme that does not apply to the scope of
> this one distribution and this current time window. It should apply on
> FC, RHL, RHEL and why not Mandrake/SuSE, whatever.
In an ideal world, yes. 

But I have given in hope vendors can agree on a common naming scheme and
am focusing on Fedora Core and Fedora US/Extras.

> So the general stance is to have a suffux to the release tag
> containing an rpm-sortable disttag and an optional repotag, like
> 
> foo-1.2.3-4.rh9.ralf.src.rpm

AFAICT, this approach considers upgrades between distros, but it does
not consider replacing RH supplied Core packages or nor replacing
Fedora.US supplied packages nor does it consider replacing "local
packages" with Fedora.US supplied packages.


> A solution used by currently most free repos is to have "rh" for RHL
> and "rhfc" for FC.
Hmm? Fedora uses 0.fdr.<...>.1 , freshrpms used fr and now seems to have
switched to using 'fc1.fr', you seem to be using rhfc, packman (No FC1
rpms there yet, but I am involved there) uses '<vendor-release>.pm', ...
finally there are Ximian and JPackage ... and ...

>  It works very well, but some (Warren ;) disliked
> the association with rh in FC rpms and decided to find another
> solution.
Well, I want somebody being in charge (be it RH or Fedora.US) to give an
official recommendation ;)

All I read on the "old Fedora Project" home page
(http://www.fedora.us/wiki/PackageNamingGuidelines) is:
...
C-4. Dist tag
...
  0.fdr.%{X}.%{disttag}
...

AFAIS, this doesn't match with what Fedora.US currently ships: 
0.fdr.%{disttag}.%{X}

It also does not seem to cover conventions on
* Replacement packages
* 3rd party add-on packages
both wrt. FedoraCore/RedHat and FedoraCore/RedHat+Fedora.US.

In my understanding, for replacement packages the "leading 0" must match
the FC/RH version the package is supposed to replace, while third party
packages are supposed to use a custom %{disttag}, while leaving the rest
of the Fedora.US release-tag intact.

Let's try to apply the GuideLines to an example:
A package of mine requires perl-XML-LibXML-Common.

Neither Fedora Core 1 nor Fedora.US ship perl-XML-LibXML-Common, but
Fedora Core 2 has it. There is a package proposal pending for months in
Fedora.US's QA to add perl-XML-LibXML-Common to Fedora.US/FC1, but ATM
it is not available for FC1.

As I want to release my "pkg" for FC1 *now*, I'd have to release a
perl-XML-LibXML-Common legacy package for FC1 *now*. However, I actually
do not want to maintain a perl-XML-LibXML-Common myself and want the
Fedora.US/FC1-Extras package to replace mine, once it will/should be
released.

How to choose the "release-tag" for my "temporary legacy package", that
an upgrade from FC1->FC2 will replace my perl-XML-LibXML-Common rpm with
that shipped with FC2 and that a potential release of
perl-XML-LibXML-Common by Fedora.US will replace my package?

* FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm
* Thereofore I'd expect a potential FC1-Extras/Legacy package to be
named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.

Now, which release-tag to use for my "temporary legacy package"?

As it seems to me, the only functional solution for my purposes is:
perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm

For example:
perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm

Ralf




From fedora at wir-sind-cool.org  Wed May 12 14:10:33 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 12 May 2004 16:10:33 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
 rpms)
In-Reply-To: <1084369435.3770.11838.camel@mccallum.corsepiu.local>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<1084369435.3770.11838.camel@mccallum.corsepiu.local>
Message-ID: <20040512161033.4310ab70.fedora@wir-sind-cool.org>

On Wed, 12 May 2004 15:44:53 +0200, Ralf Corsepius wrote:

> All I read on the "old Fedora Project" home page
> (http://www.fedora.us/wiki/PackageNamingGuidelines) is:
> ...
> C-4. Dist tag
> ...
>   0.fdr.%{X}.%{disttag}
> ...
> 
> AFAIS, this doesn't match with what Fedora.US currently ships: 

It does. %{disttag} is the target distribution and evaluates to rh80,
rh90, 1, 2, and so on. %{X} is what you increase with each package
revision. Example:

  foo-1.0-0.fdr.4.rh80

%X = 4
%disttag = rh80
 
> It also does not seem to cover conventions on
> * Replacement packages

Do you mean upgrades of what is included within Fedora Core?
Obviously, %release must be higher than the current %release of
the package in Fedora Core, but preferably lower than the next
security Update.

> * 3rd party add-on packages
> both wrt. FedoraCore/RedHat and FedoraCore/RedHat+Fedora.US.
> 
> In my understanding, for replacement packages the "leading 0" must match
> the FC/RH version the package is supposed to replace, while third party
> packages are supposed to use a custom %{disttag}, while leaving the rest
> of the Fedora.US release-tag intact.

That part I didn't understand. What is a "replacement package"?
 
> Let's try to apply the GuideLines to an example:
> A package of mine requires perl-XML-LibXML-Common.
> 
> Neither Fedora Core 1 nor Fedora.US ship perl-XML-LibXML-Common, but
> Fedora Core 2 has it. There is a package proposal pending for months in
> Fedora.US's QA to add perl-XML-LibXML-Common to Fedora.US/FC1, but ATM
> it is not available for FC1.

Then review and approve Ville's package.
 
> As I want to release my "pkg" for FC1 *now*, I'd have to release a
> perl-XML-LibXML-Common legacy package for FC1 *now*. However, I actually
> do not want to maintain a perl-XML-LibXML-Common myself and want the
> Fedora.US/FC1-Extras package to replace mine, once it will/should be
> released.
> 
> How to choose the "release-tag" for my "temporary legacy package", that
> an upgrade from FC1->FC2 will replace my perl-XML-LibXML-Common rpm with
> that shipped with FC2 and that a potential release of
> perl-XML-LibXML-Common by Fedora.US will replace my package?

Choose a %release lower than the current package in the queue and lower
than the package in FC2:

  perl-XML-LibXML-Common-0.13-0.fdr.4.ralf.1.1.rpm

Or choose the lowest %epoch:%version-%release possible. If you have doubts
that 0.13-0 is enough, as a last resort you could even decrease %version
to 0 and move the actual software version into the %release tag, e.g.
perl-XML-LibXML-Common-0-0.13.1.ralf to indicate that this is temporary
package only.

> * FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm
> * Thereofore I'd expect a potential FC1-Extras/Legacy package to be
> named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.
> 
> Now, which release-tag to use for my "temporary legacy package"?

Dist-tags are evil. Attempts at defining inter-repository release-tags
fail miserably as soon as multiple versions/releases of a package
exist and contain different %release tags. Even if you put "ralf"
at the very right, it would be included in EVR comparison and win
over tags like "fdr" or "lvn", but also over numerical ones.
 
> As it seems to me, the only functional solution for my purposes is:
> perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm
> 
> For example:
> perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm

Yes, just with 4, not 5.




From Axel.Thimm at ATrpms.net  Wed May 12 14:43:16 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 12 May 2004 16:43:16 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040512130243.2b86c4ae.fedora@wir-sind-cool.org>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<20040512130243.2b86c4ae.fedora@wir-sind-cool.org>
Message-ID: <20040512144316.GD17416@neu.nirvana>

On Wed, May 12, 2004 at 01:02:43PM +0200, Michael Schwendt wrote:
> On Wed, 12 May 2004 11:31:04 +0200, Axel Thimm wrote:
> 
> > So the general stance is to have a suffux to the release tag
> > containing an rpm-sortable disttag and an optional repotag, like
> > 
> > foo-1.2.3-4.rh9.ralf.src.rpm
> 
> Which is a bad suggestion, because the package %release version should
> begin at 0, so any other version of the package which might appear in
> Fedora Core would serve as an upgrade of this add-on.

for one it is a simple suggestion, I didn't want to have cvs pre-alpha
builds with kernel modules discussed, but give the general idea.

Of course, just as version cut-off moved to the disttags, you can have
hierarchical buildtags, like <vendor>_<3rd party> build structures,
leading to things like foo-1.2.3-4_5.rh9.ralf.src.rpm or
foo-1.2.3-0_5.rh9.ralf.src.rpm, if the vendor does not yet offer foo
in version 1.2.3.

For packages not existing in FC and where it looks like it will take
some time to get them in (or perhaps will by definition not ever make
it), I suggest to not use hierarchical tags, as it is easier to ask
the "man-inside" to use a higher build.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040512/868f5253/attachment.sig>

From Axel.Thimm at ATrpms.net  Wed May 12 14:56:37 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 12 May 2004 16:56:37 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <1084369435.3770.11838.camel@mccallum.corsepiu.local>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<1084369435.3770.11838.camel@mccallum.corsepiu.local>
Message-ID: <20040512145637.GE17416@neu.nirvana>

On Wed, May 12, 2004 at 03:44:53PM +0200, Ralf Corsepius wrote:
> > The main idea is to have a scheme that does not apply to the scope of
> > this one distribution and this current time window. It should apply on
> > FC, RHL, RHEL and why not Mandrake/SuSE, whatever.
> In an ideal world, yes. 
> 
> But I have given in hope vendors can agree on a common naming scheme

Why? It hasn't even been proposed/tried, yet. And it is too early to
propose it, but it can be taken account for to not blcok this path.

> > So the general stance is to have a suffux to the release tag
> > containing an rpm-sortable disttag and an optional repotag, like
> > 
> > foo-1.2.3-4.rh9.ralf.src.rpm
> 
> AFAICT, this approach considers upgrades between distros, but it does
> not consider replacing RH supplied Core packages or nor replacing
> Fedora.US supplied packages nor does it consider replacing "local
> packages" with Fedora.US supplied packages.

I am not sure, what this means. The repotag can be used as an
indicator about which packages in your system come from where (there
are other ways apart from versioning/naming to achieve this).

If a repo choses to replace some part of the base distribution for
some reason, it is in the responsibility of the repo to do so in a way
as to not break anything and ensure future upgrade paths either by
hierarchical build tags for automatically being replaced by newer
vendor releases, or commitment to a community SLA.

> > A solution used by currently most free repos is to have "rh" for RHL
> > and "rhfc" for FC.
> Hmm? Fedora uses 0.fdr.<...>.1 , freshrpms used fr and now seems to have
> switched to using 'fc1.fr', you seem to be using rhfc, packman (No FC1
> rpms there yet, but I am involved there) uses '<vendor-release>.pm', ...
> finally there are Ximian and JPackage ... and ...

most != all ;)
Other than ATrpms rhfc1 is currently used by DAG, PlanetCCRMA, spc,
dries, biorpms, and probably more.

> * FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm
> * Thereofore I'd expect a potential FC1-Extras/Legacy package to be
> named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.
> 
> Now, which release-tag to use for my "temporary legacy package"?
> 
> As it seems to me, the only functional solution for my purposes is:
> perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm
> 
> For example:
> perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm

Is this a simple backport? For such packages I started to subtract
0.01 from the release to make me aware, that I changed almost nothing
but add some BuildRequires, so I'd package the rebuild rpm as

perl-XML-LibXML-Common-0.13.0-4.99.rhfc1.ralf.src.rpm

:)

BTW that package already exists:
# apt-cache policy perl-XML-LibXML-Common
perl-XML-LibXML-Common:
  Installed: (none)
  Candidate: 0.13-2.rhfc1.dag
  Version Table:
     0.13-2.rhfc1.dag 0
        995 http://apt.sw.be redhat/fc1/en/i386/dag pkglist
     0.13-1.rhfc1.dag 0
        995 http://apt.sw.be redhat/fc1/en/i386/dag pkglist

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040512/3ffdb21e/attachment.sig>

From rgreab at fx.ro  Wed May 12 15:47:59 2004
From: rgreab at fx.ro (Radu Greab)
Date: Wed, 12 May 2004 18:47:59 +0300
Subject: Latest tree broke rpm?
In-Reply-To: <1084346819.29688.93.camel@otto.amantes>
References: <20040505195208.441a4f26@localhost>
	<20040505195853.2e95e49c@localhost>
	<20040505190446.GD30909@devserv.devel.redhat.com>
	<20040505215517.GF30909@devserv.devel.redhat.com>
	<20040506180441.188568f8@localhost> <m3zn8egzyr.wl@fx.ro>
	<1084346819.29688.93.camel@otto.amantes>
Message-ID: <m3k6zhir4g.wl@fx.ro>

Thomas Vander Stichele wrote:
> 
> I don't seem to find a lot about what vdso is either; could you please
> enlighten me and point me to some locations where I can read up about
> this feature ?

Dave Jones explained it at:
http://www.redhat.com/archives/fedora-test-list/2004-April/msg00658.html




From rc040203 at freenet.de  Wed May 12 16:09:03 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 12 May 2004 18:09:03 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040512161033.4310ab70.fedora@wir-sind-cool.org>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<1084369435.3770.11838.camel@mccallum.corsepiu.local>
	<20040512161033.4310ab70.fedora@wir-sind-cool.org>
Message-ID: <1084378142.3770.12303.camel@mccallum.corsepiu.local>

On Wed, 2004-05-12 at 16:10, Michael Schwendt wrote:
> On Wed, 12 May 2004 15:44:53 +0200, Ralf Corsepius wrote:
> 
> > All I read on the "old Fedora Project" home page
> > (http://www.fedora.us/wiki/PackageNamingGuidelines) is:
> > ...
> > C-4. Dist tag
> > ...
> >   0.fdr.%{X}.%{disttag}
> > ...
> > 
> > AFAIS, this doesn't match with what Fedora.US currently ships: 
> 
> It does. 

Sorry, apparently I misread it.

> > It also does not seem to cover conventions on
> > * Replacement packages
> 
> Do you mean upgrades of what is included within Fedora Core?
Yes.

> Obviously, %release must be higher than the current %release of
> the package in Fedora Core,
Not necessarily - E.g. I might want to apply patches or configure a
package with different options etc.

> > * 3rd party add-on packages
> > both wrt. FedoraCore/RedHat and FedoraCore/RedHat+Fedora.US.
> > 
> > In my understanding, for replacement packages the "leading 0" must match
> > the FC/RH version the package is supposed to replace,
Yes.

> > while third party
> > packages are supposed to use a custom %{disttag}, while leaving the rest
> > of the Fedora.US release-tag intact.
Yes.

> That part I didn't understand. What is a "replacement package"?
Cf. above. I meant replacing a FC/RH or Fedora.US package with a 3rd
party or local package.

> > Let's try to apply the GuideLines to an example:
> > A package of mine requires perl-XML-LibXML-Common.
> > 
> > Neither Fedora Core 1 nor Fedora.US ship perl-XML-LibXML-Common, but
> > Fedora Core 2 has it. There is a package proposal pending for months in
> > Fedora.US's QA to add perl-XML-LibXML-Common to Fedora.US/FC1, but ATM
> > it is not available for FC1.

> Choose a %release lower than the current package in the queue and lower
> than the package in FC2:

That's not necessary:

# rpmver 0:0.13-0.fdr.5.ralf.1.1 0:0.13-5
0:0.13-5 is newer

=> FC1->FC2 upgrade will work.

# rpmver 0:0.13-0.fdr.5.ralf.1.1 0:0.13-0.fdr.5.1
0:0.13-0.fdr.5.1 is newer

=> An upgrade to a Fedora.US package will work.
 

>   perl-XML-LibXML-Common-0.13-0.fdr.4.ralf.1.1.rpm
> 
> Or choose the lowest %epoch:%version-%release possible. If you have doubts
> that 0.13-0 is enough, as a last resort you could even decrease %version
> to 0 and move the actual software version into the %release tag, e.g.
> perl-XML-LibXML-Common-0-0.13.1.ralf
This would contradict to the PackageGuideLines :)

> > * FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm
> > * Thereofore I'd expect a potential FC1-Extras/Legacy package to be
> > named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.
> > 
> > Now, which release-tag to use for my "temporary legacy package"?
> 
> Dist-tags are evil. Attempts at defining inter-repository release-tags
> fail miserably as soon as multiple versions/releases of a package
> exist and contain different %release tags.

This is only one side of the medal. On the other side dist-tags provide
a clean separation for 3rd party supplied packages and prevents users
from mixing up incompatible packages.

>  Even if you put "ralf"
> at the very right, it would be included in EVR comparison and win
> over tags like "fdr" or "lvn", but also over numerical ones.
>  
> > As it seems to me, the only functional solution for my purposes is:
> > perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm
> > 
> > For example:
> > perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm
> 
> Yes, just with 4, not 5.
Cf. above.

Ralf





From njm at njm.org  Wed May 12 17:11:05 2004
From: njm at njm.org (N Joshua Madan)
Date: Wed, 12 May 2004 13:11:05 -0400
Subject: kernel: spurious 8259A interrupt: IRQ7
In-Reply-To: <21048.12.41.112.51.1084293304.squirrel@webmail.ec-group.com>
References: <21048.12.41.112.51.1084293304.squirrel@webmail.ec-group.com>
Message-ID: <40A25AA9.7060203@njm.org>

i have a similar problem with a sharp actius um32w with a RealTek 
RTL8139 and an Intersil Corporation|Prism 2.5 Wavelan chipset' wireless 
card (see my message on 8-may to fedora-test-list for details).  using 
stock kernels the wireless card is configured as eth0 and the ethernet 
card as eth1.  then it configures them both again and confuses eth0 and 
eth1.  kudzu then tries to configure the wireless card as eth2, 
redhat-network-config is totally confused.  the ethernet card is working 
  fine, the wireless card is not functioning at all.  problems started 
with 2.6.5 kernels as best i can recall but i wiped out all the kernels 
before 2.6.5-1.327 to make space so i can't be totally sure.

Brian Millett wrote:
> Hello,
> I have a toshiba laptop with a miniPCI EL-2511MP PLUS 802.11/b card in it.
> I am running kernel 2.6.5-1.358 with all of the updates as of today.
> 
> I am a bit confused (understatement)
> 
> I just lost ethernet connectivity and had to power cycle the laptop.  I
> was getting so many messages written to /var/log/messages that the system
> was unresponsive.  I was using XMMS listening to radio station.
> 
> Messages start with:
> May 11 10:10:31 mktg6nt kernel: spurious 8259A interrupt: IRQ7.
> May 11 10:41:27 mktg6nt kernel: eth1: error -110 reading info frame. Frame
> dropped.
> May 11 10:41:27 mktg6nt kernel: eth1: Error -110 writing Tx descriptor to BAP
> May 11 10:41:29 mktg6nt last message repeated 349 times
> May 11 10:41:29 mktg6nt kernel: hermes @ MEM 0x21ea1000: Timeout waiting
> for command completion.
> May 11 10:41:29 mktg6nt kernel: hermes @ MEM 0x21ea1000: Error -16 issuing
> command.
> May 11 10:41:29 mktg6nt kernel: eth1: Error -110 writing Tx descriptor to BAP
> May 11 10:41:30 mktg6nt last message repeated 63 times
> May 11 10:41:30 mktg6nt kernel: eth1: Ereth1: Error -110 writing Tx
> descriptor to BAP
> May 11 10:41:30 mktg6nt kernel: eth1: Error -110 writing Tx descriptor to BAP
> May 11 10:41:31 mktg6nt last message repeated 81 times
> May 11 10:41:31 mktg6nt kernel: eth1: Error -110 writing Tx eth1: Error
> -110 writing Tx descriptor to BAP
> May 11 10:41:31 mktg6nt kernel: eth1: Error -110 writing Tx descriptor to BAP
> May 11 10:41:31 mktg6nt last message repeated 81 times
> May 11 10:41:31 mktg6nt kernel: eth1: Error -110 writing Tx eth1: Error
> -110 writing Tx descriptor to BAP
> 
> 
> What I am really confused about are the following output from dmesg.
> 
> eth0: Station identity 001f:0009:0001:0004
> eth0: Looks like an Intersil firmware version 1.4.9
> eth0: Ad-hoc demo mode supported
> eth0: IEEE standard IBSS ad-hoc mode supported
> eth0: WEP supported, 104-bit key
> eth0: MAC address 00:02:6F:04:64:6A
> eth0: Station name "Prism  I"
> eth0: ready
> 8139too Fast Ethernet driver 0.9.27
> divert: allocating divert_blk for eth1
> eth1: RealTek RTL8139 at 0x3000, 00:02:3f:8f:19:0e, IRQ 10
> eth1:  Identified 8139 chip type 'RTL-8100B/8139D'
> 
> BUT I have this from ifconfig:
> 
> mktg6nt: ifconfig -a
> eth1      Link encap:Ethernet  HWaddr 00:02:6F:04:64:6A
>           inet addr:192.9.200.42  Bcast:192.9.200.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:4129 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:1028 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:826960 (807.5 Kb)  TX bytes:177917 (173.7 Kb)
>           Interrupt:11 Base address:0x8000 Memory:e0500000-e0500fff
> 
> 
> and in my modprobe.conf:
> alias eth0 8139too
> alias eth1 orinoco_pci
> 
> 
> I am writting this with my laptop, so it came back up clean.  I just do
> not understand the differences in the eth0/eth1 being reversed in the
> dmesg output from the ifconfig output.
> 
> Should I change the modprobe.conf to have the orinoco_pci aliased to eth0
> and the builtin 8139too aliased to eth0?
> 
> What is the 8259A interupt?  It seems like the builtin sound card.
> 
> Thanks.




From rc040203 at freenet.de  Wed May 12 18:01:09 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 12 May 2004 20:01:09 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040512145637.GE17416@neu.nirvana>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<1084369435.3770.11838.camel@mccallum.corsepiu.local>
	<20040512145637.GE17416@neu.nirvana>
Message-ID: <1084384869.3770.12437.camel@mccallum.corsepiu.local>

On Wed, 2004-05-12 at 16:56, Axel Thimm wrote:
> On Wed, May 12, 2004 at 03:44:53PM +0200, Ralf Corsepius wrote:
> > > The main idea is to have a scheme that does not apply to the scope of
> > > this one distribution and this current time window. It should apply on
> > > FC, RHL, RHEL and why not Mandrake/SuSE, whatever.
> > In an ideal world, yes. 
> > 
> > But I have given in hope vendors can agree on a common naming scheme
> 
> Why? It hasn't even been proposed/tried, yet. And it is too early to
> propose it, but it can be taken account for to not blcok this path.
> 
> > > So the general stance is to have a suffux to the release tag
> > > containing an rpm-sortable disttag and an optional repotag, like
> > > 
> > > foo-1.2.3-4.rh9.ralf.src.rpm
> > 
> > AFAICT, this approach considers upgrades between distros, but it does
> > not consider replacing RH supplied Core packages or nor replacing
> > Fedora.US supplied packages nor does it consider replacing "local
> > packages" with Fedora.US supplied packages.
> 
> I am not sure, what this means. The repotag can be used as an
> indicator about which packages in your system come from where (there
> are other ways apart from versioning/naming to achieve this).
Exactly.

> If a repo choses to replace some part of the base distribution for
> some reason, it is in the responsibility of the repo to do so in a way
> as to not break anything and ensure future upgrade paths either by
> hierarchical build tags for automatically being replaced by newer
> vendor releases, or commitment to a community SLA.
Exactly, that's what I am trying to achieve.

> > > A solution used by currently most free repos is to have "rh" for RHL
> > > and "rhfc" for FC.
> > Hmm? Fedora uses 0.fdr.<...>.1 , freshrpms used fr and now seems to have
> > switched to using 'fc1.fr', you seem to be using rhfc, packman (No FC1
> > rpms there yet, but I am involved there) uses '<vendor-release>.pm', ...
> > finally there are Ximian and JPackage ... and ...
> 
> most != all ;)
> Other than ATrpms rhfc1 is currently used by DAG, PlanetCCRMA, spc,
> dries, biorpms, and probably more.
OK, ok, ... :-)

> > * FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm
> > * Thereofore I'd expect a potential FC1-Extras/Legacy package to be
> > named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.
> > 
> > Now, which release-tag to use for my "temporary legacy package"?
> > 
> > As it seems to me, the only functional solution for my purposes is:
> > perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm
> > 
> > For example:
> > perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm
> 
> Is this a simple backport?
It's even simpler: It is just a rebuilt FC2 package.

I.e. it would make the "classical case" of a Fedora.US Legacy package.

Michael's remark "sign Ville's proposal" however, makes me wonder if Red
Hat and Fedora.US actually have an official policy on such packages.

His remark makes doubt it :(

> BTW that package already exists:
> # apt-cache policy perl-XML-LibXML-Common
> perl-XML-LibXML-Common:
>   Installed: (none)
>   Candidate: 0.13-2.rhfc1.dag
>   Version Table:
>      0.13-2.rhfc1.dag 0
>         995 http://apt.sw.be redhat/fc1/en/i386/dag pkglist
>      0.13-1.rhfc1.dag 0
>         995 http://apt.sw.be redhat/fc1/en/i386/dag pkglist
I am well aware perl-XML-LibXML-Common exists at various places (Even I
have a local one), but ... it now is part of FC2 and there exists a
proposal for Fedora.US/FC1 ...

Ralf






From fedora at wir-sind-cool.org  Wed May 12 18:47:29 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 12 May 2004 20:47:29 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
 rpms)
In-Reply-To: <1084378142.3770.12303.camel@mccallum.corsepiu.local>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<1084369435.3770.11838.camel@mccallum.corsepiu.local>
	<20040512161033.4310ab70.fedora@wir-sind-cool.org>
	<1084378142.3770.12303.camel@mccallum.corsepiu.local>
Message-ID: <20040512204729.4fcb7934.fedora@wir-sind-cool.org>

On Wed, 12 May 2004 18:09:03 +0200, Ralf Corsepius wrote:

> > > It also does not seem to cover conventions on
> > > * Replacement packages
> > 
> > Do you mean upgrades of what is included within Fedora Core?
>
> Yes.

Updates for Fedora Core are not fedora.us' area. Except for the very few
packages in the "patches" repository. But that one is a dead end. If
something in Fedora Core is broken, it should be fixed in Fedora Core, not
updated by a 3rd party repo. Replacements, i.e. substitutes for available
functionality of packages in Fedora Core should be prepared as Fedora
Alternatives.
 
> > Obviously, %release must be higher than the current %release of
> > the package in Fedora Core,
>
> Not necessarily - E.g. I might want to apply patches or configure a
> package with different options etc.

To maintain a clean install/update path in one direction (i.e. _to_ your
packages), your packages must win EVR comparison. Downgrade back to
original Core packages would be a special case (rpm -Uvh --oldpackage).
 
> > > Let's try to apply the GuideLines to an example:
> > > A package of mine requires perl-XML-LibXML-Common.
> > > 
> > > Neither Fedora Core 1 nor Fedora.US ship perl-XML-LibXML-Common, but
> > > Fedora Core 2 has it. There is a package proposal pending for months in
> > > Fedora.US's QA to add perl-XML-LibXML-Common to Fedora.US/FC1, but ATM
> > > it is not available for FC1.
> 
> > Choose a %release lower than the current package in the queue and lower
> > than the package in FC2:
> 
> That's not necessary:
> 
> # rpmver 0:0.13-0.fdr.5.ralf.1.1 0:0.13-5
> 0:0.13-5 is newer
> 
> => FC1->FC2 upgrade will work.
> 
> # rpmver 0:0.13-0.fdr.5.ralf.1.1 0:0.13-0.fdr.5.1
> 0:0.13-0.fdr.5.1 is newer
> 
> => An upgrade to a Fedora.US package will work.

Well, that's just a side-effect of "ralf < 1".

> >   perl-XML-LibXML-Common-0.13-0.fdr.4.ralf.1.1.rpm
> > 
> > Or choose the lowest %epoch:%version-%release possible. If you have doubts
> > that 0.13-0 is enough, as a last resort you could even decrease %version
> > to 0 and move the actual software version into the %release tag, e.g.
> > perl-XML-LibXML-Common-0-0.13.1.ralf
> This would contradict to the PackageGuideLines :)

Package naming guidelines are for fedora.us, not for indivual people's
packages.
 
> > > Now, which release-tag to use for my "temporary legacy package"?
> > 
> > Dist-tags are evil. Attempts at defining inter-repository release-tags
> > fail miserably as soon as multiple versions/releases of a package
> > exist and contain different %release tags.
> 
> This is only one side of the medal. On the other side dist-tags provide
> a clean separation for 3rd party supplied packages and prevents users
> from mixing up incompatible packages.

How that? repotags don't appear in dependencies.
 




From rhally at mindspring.com  Wed May 12 18:53:44 2004
From: rhally at mindspring.com (Richard Hally)
Date: Wed, 12 May 2004 14:53:44 -0400
Subject: rawhide report: 20040512 changes
In-Reply-To: <200405121237.i4CCbgl07693@porkchop.devel.redhat.com>
References: <200405121237.i4CCbgl07693@porkchop.devel.redhat.com>
Message-ID: <40A272B8.7060200@mindspring.com>

Build System wrote:

>  
> 
>  
> Updated Packages:
> 
> elilo-3.4-5
> -----------

> fedora-release-2-4
> ------------------
> 
> fedora-release-2-5
> ------------------
> 
> file-4.07-4
> -----------

> 
> glibc-2.3.3-27
> --------------

> im-sdk-11.4-43
> --------------

> mozilla-1.6-8
> -------------

> rpmdb-fedora-2-0.20040512
> -------------------------
> 
> udev-024-6
> ----------

> up2date-4.3.19-1
> ----------------
> 
> yum-2.0.7-1.1
> -------------

Are these packages going to be in FC2 Final?






From chabotc at 4-ice.com  Wed May 12 19:01:46 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Wed, 12 May 2004 21:01:46 +0200
Subject: rawhide report: 20040512 changes
References: <200405121237.i4CCbgl07693@porkchop.devel.redhat.com>
	<40A272B8.7060200@mindspring.com>
Message-ID: <001f01c43853$92b6efc0$0200a8c0@gandalf>

Usualy the redhat/fedora tree's are frozen for the release cycle, so no
experimental packages untill the release has been finalised.. Ergo chances
are those packages will be in FC2 final.

ps, noted the fedora-release-2 package? Goes without saying that will be in
fedora release 2 :-)

----- Original Message ----- 
From: "Richard Hally" <rhally at mindspring.com>
To: "Development discussions related to Fedora Core"
<fedora-devel-list at redhat.com>

<snip>

> Are these packages going to be in FC2 Final?




From bpm at ec-group.com  Wed May 12 19:14:42 2004
From: bpm at ec-group.com (Brian Millett)
Date: Wed, 12 May 2004 14:14:42 -0500 (CDT)
Subject: Tettnang ??
Message-ID: <17697.12.41.112.51.1084389282.squirrel@webmail.ec-group.com>

Ok, so why a town in Germany?

-- 
Brian Millett
Enterprise Consulting Group  "Shifts in paradigms
(314) 205-9030           often cause nose bleeds."
bpmATec-groupDOTcom                     Greg Glenn






From rhally at mindspring.com  Wed May 12 19:39:56 2004
From: rhally at mindspring.com (Richard Hally)
Date: Wed, 12 May 2004 15:39:56 -0400
Subject: rawhide report: 20040512 changes
In-Reply-To: <001f01c43853$92b6efc0$0200a8c0@gandalf>
References: <200405121237.i4CCbgl07693@porkchop.devel.redhat.com>	<40A272B8.7060200@mindspring.com>
	<001f01c43853$92b6efc0$0200a8c0@gandalf>
Message-ID: <40A27D8C.2020904@mindspring.com>

Chris Chabot wrote:

> Usualy the redhat/fedora tree's are frozen for the release cycle, so no
> experimental packages untill the release has been finalised.. Ergo chances
> are those packages will be in FC2 final.
> 
> ps, noted the fedora-release-2 package? Goes without saying that will be in
> fedora release 2 :-)
> 
> ----- Original Message ----- 
> From: "Richard Hally" <rhally at mindspring.com>
> To: "Development discussions related to Fedora Core"
> <fedora-devel-list at redhat.com>
> 
> <snip>
> 
>>Are these packages going to be in FC2 Final?
> 
> 
> 
Thanks for your reply, Perhaps someone at Red Hat/Fedora can give a more 
definitive answer. ;)

Richard Hally




From katzj at redhat.com  Wed May 12 20:50:56 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 12 May 2004 16:50:56 -0400
Subject: rawhide report: 20040512 changes
In-Reply-To: <40A272B8.7060200@mindspring.com>
References: <200405121237.i4CCbgl07693@porkchop.devel.redhat.com>
	<40A272B8.7060200@mindspring.com>
Message-ID: <1084395056.6870.76.camel@bree.local.net>

On Wed, 2004-05-12 at 14:53 -0400, Richard Hally wrote:
> Are these packages going to be in FC2 Final?

Yes

Jeremy




From fedora at andrewfarris.com  Wed May 12 22:26:43 2004
From: fedora at andrewfarris.com (Andrew Farris)
Date: Wed, 12 May 2004 15:26:43 -0700
Subject: Fedora treats security as a joke.
In-Reply-To: <1084354342.4746.51.camel@athlon.localdomain>
References: <200405111343.59319.stonebeat@ya.com>
	<604aa79104051105111beb1159@mail.gmail.com>
	<1084279977.4753.5.camel@athlon.localdomain>
	<Pine.LNX.4.58.0405111429490.17391@dell1.moose.awe.com>
	<1084354342.4746.51.camel@athlon.localdomain>
Message-ID: <1084400803.9733.6.camel@CirithUngol>

On Wed, 2004-05-12 at 11:32 +0200, Leonard den Ottolander wrote:
> Hi Mark,
> 
> > Over the last few days we've been doing some checking of FC1 and FC2 
> > security issues.
> 
> Thanks for the update, but instead of using only CAN numbers it would be
> more clear to most when you'd also name the involved packages.
> 
> Leonard.

Perhaps simply a suggestion of where people should find more
information.  The purpose of CAN numbers is to clearly, unambiguously,
identify issues... so people won't have to explain each issue -- they
could indirectly involve numerous packages...

The initial email was from a 'compulsive reader of security lists' so it
was fair to assume he knew this.

http://www.cve.mitre.org/cve/

For CAN-2004-0113 for instance...
http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CAN-2004-0113

-- 
Andrew Farris, CPE senior (California Polytechnic State University, SLO)
fedora at andrewfarris.com :: lmorgul on irc.freenode.net
"The only thing necessary for the triumph of evil is for good men
to do nothing." (Edmond Burke)




From aoliva at redhat.com  Wed May 12 23:01:24 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 12 May 2004 20:01:24 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040512093104.GA9771@neu.nirvana>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
Message-ID: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>

On May 12, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

> So the general stance is to have a suffux to the release tag
> containing an rpm-sortable disttag and an optional repotag, like

> foo-1.2.3-4.rh9.ralf.src.rpm

> So the release tag looks like

>    <buildid><distid><distversion><repotag_opt>

> where buildid shound end with digits (for example a simple integer
> like "3", or something conatining cvs info like "0.cvs20040512.16"),
> distid should be invariant for the family of distributions and
> distversion should be rpm-sortable (7.3, 8.0, 9 for instance). Repotag
> is placed at the least significant place wrt to rpm comparison and is
> optional.

> Nobody objected this scheme above

I thought there was some minor opposition.  <buildid> should *always*
start with `0.', such that, whenever the distro contains the same
version of the package, starting with 1 or above, the version in the
distro is used.  If you build multiple times, use 0.1, 0.2, etc.

My actual preference would be to instead use:

     0.<distid><distversion><repotag_opt><buildid>

>> >Conversely, all seem to be designed "to take over the system".

> Even though this is our secret obsession, what do you man by that? 

Dunno what he meant, but IMHO external repositories should be split
into Extras and Alternatives, where Extras contain packages that add
to the system without replacing any of its core components, leaving
replacing/upgrading to Alternatives.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From helios82 at optushome.com.au  Wed May 12 23:06:08 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Thu, 13 May 2004 09:06:08 +1000
Subject: Tettnang ??
In-Reply-To: <17697.12.41.112.51.1084389282.squirrel@webmail.ec-group.com>
References: <17697.12.41.112.51.1084389282.squirrel@webmail.ec-group.com>
Message-ID: <1084403167.3386.7.camel@fc1>

On Thu, 2004-05-13 at 05:14, Brian Millett wrote:
> Ok, so why a town in Germany?

Heh, wasn't sure what you were talking about until I:

$ cat /etc/fedora-release
Fedora Core release 2 (Tettnang)
$

So, release name is decided! So who came up with this one? 
Maybe it's Karsten Hopp's hometown? ;)

Regards,
-Matt
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 

-------------- 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/20040513/699308ee/attachment.sig>

From Axel.Thimm at ATrpms.net  Wed May 12 23:30:48 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 13 May 2004 01:30:48 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <20040512233048.GA25548@neu.nirvana>

On Wed, May 12, 2004 at 08:01:24PM -0300, Alexandre Oliva wrote:
> On May 12, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> > So the release tag looks like
> 
> >    <buildid><distid><distversion><repotag_opt>
> 
> > where buildid shound end with digits (for example a simple integer
> > like "3", or something conatining cvs info like "0.cvs20040512.16"),
> > distid should be invariant for the family of distributions and
> > distversion should be rpm-sortable (7.3, 8.0, 9 for instance). Repotag
> > is placed at the least significant place wrt to rpm comparison and is
> > optional.
> 
> > Nobody objected this scheme above
> 
> I thought there was some minor opposition.  <buildid> should *always*
> start with `0.', such that, whenever the distro contains the same
> version of the package, starting with 1 or above, the version in the
> distro is used.  If you build multiple times, use 0.1, 0.2, etc.

The scheme above abstracts hierarchical buildid into simply
<buildid>. It was also proposed for Fedora Core packages, too, not
only for 3rd party repos.

When we introduced the zero-prefix one and a half year ago, it was
done in the assumption of a lack of communication with the higher
hierarchy (the vendor).

IMHO in the Fedora context the communication is starting to become
bilateral and such safeguards are less an issue. Packages proposed for
submission from 3rd party repos into FC have been accompanied by a
coordination of the 3rd party repo and the Red Hat insider ensuring
proper upgrade paths (which is more than only the versioning).

> My actual preference would be to instead use:
> 
>      0.<distid><distversion><repotag_opt><buildid>

In hierarchical buildid the 0 is used when the version is higher than
that of the vendor (or higher hierarchry). If the updated package is
based on the same upstream version like the vendor's you need to use
the vendor's buildid as the prefix.

Buildid at the least significant position? That would make it less
important than the "random" repotag, e.g. the scheme above would be
valid only within one repo and one dist.

Suppose you have

	foo-1.2.3-4.rhfc1.blah.i386.rpm
	foo-1.2.3-4.rhfc2.blah.i386.rpm

A security errata lets you roll out

        foo-1.2.3-5.rhfc1.blah.i386.rpm
	foo-1.2.3-5.rhfc2.blah.i386.rpm

In this scheme you know that both fc1 and fc2 will have the fixed
version, even when the fc1 box decides to upgrade.

In the case of

	foo-1.2.3-rhfc1.blah.4.i386.rpm
	foo-1.2.3-rhfc2.blah.4.i386.rpm

and

	foo-1.2.3-rhfc1.blah.5.i386.rpm
	foo-1.2.3-rhfc2.blah.5.i386.rpm

The broken version of fc2 (4) will have a higher significance for rpm
than the fixed for fc1 (5).

So the buildid (however composed, hierarchical or containing
subverision information and so on) should be placed first in the
release tag, the repotag last (as it should not be involved in
comparisons) and the disttag can only be placed in the middle. ;)

> >> >Conversely, all seem to be designed "to take over the system".
> 
> > Even though this is our secret obsession, what do you man by that? 
> 
> Dunno what he meant, but IMHO external repositories should be split
> into Extras and Alternatives, where Extras contain packages that add
> to the system without replacing any of its core components, leaving
> replacing/upgrading to Alternatives.

I can only speak for the packages I have been upgrading, which are
mostly upgraded for enabling other packages either in build
dependencies (make, automake, autoconf) or in runtime
dependencies. The consistent approach would be to pull packages
depending on Alternatives into Alternatives themselves, so soon there
would only be packages in Alternatives.

In general I don't see what purpose Alternatives would have. Users
would have the (false) feeling of a more stable system by not using
them, as no core packages have been replaced, but a couple of dozen
kernel module rpms and daemons can destabilize and insecure your
system far more than an updated package.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040513/d05f4e65/attachment.sig>

From karsten at redhat.com  Thu May 13 01:48:15 2004
From: karsten at redhat.com (Karsten Hopp)
Date: Thu, 13 May 2004 03:48:15 +0200
Subject: Tettnang ??
In-Reply-To: <1084403167.3386.7.camel@fc1>
References: <17697.12.41.112.51.1084389282.squirrel@webmail.ec-group.com>
	<1084403167.3386.7.camel@fc1>
Message-ID: <20040513014815.GB11660@redhat.com>

On Thu, May 13, 2004 at 09:06:08AM +1000, Matt Hansen wrote:
> On Thu, 2004-05-13 at 05:14, Brian Millett wrote:
> > Ok, so why a town in Germany?
> 
> Heh, wasn't sure what you were talking about until I:
> 
> $ cat /etc/fedora-release
> Fedora Core release 2 (Tettnang)
> $
> 
> So, release name is decided! So who came up with this one? 
> Maybe it's Karsten Hopp's hometown? ;)
> 

It isn't ;-) And I have no idea who came up with the name.

   Karsten


--
Emacs is a nice OS - but it lacks a good text editor.
That's why I am using Vim.  --Anonymous




From daryll at daryll.net  Wed May 12 23:51:12 2004
From: daryll at daryll.net (Daryll Strauss)
Date: Wed, 12 May 2004 16:51:12 -0700
Subject: glibc-kernheaders?
Message-ID: <1084405871.2295.15.camel@ninja2>


The current release of glibc-kernheaders is 2.4-8.44. 

This includes linux/version.h and states the version is 2.4.20.

I assume this is a mistake, right?

						- |Daryll







From remco at rvt.com  Thu May 13 00:16:16 2004
From: remco at rvt.com (Remco Treffkorn)
Date: Wed, 12 May 2004 17:16:16 -0700
Subject: Tettnang ??
In-Reply-To: <1084403167.3386.7.camel@fc1>
References: <17697.12.41.112.51.1084389282.squirrel@webmail.ec-group.com>
	<1084403167.3386.7.camel@fc1>
Message-ID: <200405121716.16795.remco@rvt.com>

On Wednesday 12 May 2004 16:06, Matt Hansen wrote:
> On Thu, 2004-05-13 at 05:14, Brian Millett wrote:
> > Ok, so why a town in Germany?
>
...
> So, release name is decided! So who came up with this one?
> Maybe it's Karsten Hopp's hometown? ;)

No, no, no!

It's because Linux is free software.
Free as in 'libre', not as in beer.
And what is a main ingredient in beer? Hops!
And good hops comes from Tettnang.

So, there!

-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco at rvt.com   (831) 685-1201




From helios82 at optushome.com.au  Thu May 13 00:17:40 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Thu, 13 May 2004 10:17:40 +1000
Subject: Tettnang ??
In-Reply-To: <200405121716.16795.remco@rvt.com>
References: <17697.12.41.112.51.1084389282.squirrel@webmail.ec-group.com>
	<1084403167.3386.7.camel@fc1>  <200405121716.16795.remco@rvt.com>
Message-ID: <1084407459.3386.12.camel@fc1>

On Thu, 2004-05-13 at 10:16, Remco Treffkorn wrote:
> On Wednesday 12 May 2004 16:06, Matt Hansen wrote:
> > On Thu, 2004-05-13 at 05:14, Brian Millett wrote:
> > > Ok, so why a town in Germany?
> >
> ...
> > So, release name is decided! So who came up with this one?
> > Maybe it's Karsten Hopp's hometown? ;)
> 
> No, no, no!
> 
> It's because Linux is free software.
> Free as in 'libre', not as in beer.
> And what is a main ingredient in beer? Hops!
> And good hops comes from Tettnang.

Actually, the main ingredient in beer is plain 'ole water. ;) But I'm
getting quite OT now for this list. :-| But thanks, I see the connection
now between Tettnang and Yarrow. :-) 

Regards,
-Matt
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 

-------------- 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/20040513/a8fa16e8/attachment.sig>

From feliciano.matias at free.fr  Thu May 13 01:20:06 2004
From: feliciano.matias at free.fr (Matias Feliciano)
Date: Thu, 13 May 2004 03:20:06 +0200
Subject: mozilla langpack
In-Reply-To: <1084365881.17962.9.camel@ulysse.olympe.o2t>
References: <40A1EDF5.1090608@tourinfo.ru>
	<1084364181.17962.4.camel@ulysse.olympe.o2t>
	<40A217C7.90805@tourinfo.ru>
	<1084365881.17962.9.camel@ulysse.olympe.o2t>
Message-ID: <1084411202.4235.11.camel@localhost.localdomain>

Le mer 12/05/2004 ? 14:51, Nicolas Mailhot a ?crit :
> Le mer, 12/05/2004 ? 16:25 +0400, Den a ?crit :
> > Nicolas Mailhot ?????:
> > 
> > >Le mer, 12/05/2004 ? 13:27 +0400, Den a ?crit :
> > >  
> > >
> > >
> > >Where do you download mozilla-i18n.tar.bz2 from ?
> > >
> > >Cheers,
> > >
> > >  
> > >
> > This is localization jar-files from xpi-packages and hand-made 
> > lang-locale.jar.txt and lang-locale-unix.jar.txt in one tar.bz2-archive.
> > http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib-localized-builds/
> 
> Ok, this is more or less what I suspected.
> 
> Please do not make up sources that do not exist upstream. Use original
> sources in whatever format upstream chooses to release them, jar, zip,
> txt, tar.gz, tar.bz2, xpi, cab, iso etc.
> 
> The rpm process is about documenting builds. When you performs steps
> like archive creation out of the rpm process, you're breaking the QA
> trail.
> 

btw, try to use some thing like :
Source1: http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib-localized-builds/mozilla-i686-pc-linux-gnu-1.6-frFR.tar.gz

Here the package works great with LANG=fr_FR .
> Cheers,




From ivg2 at cornell.edu  Thu May 13 01:40:49 2004
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Wed, 12 May 2004 21:40:49 -0400
Subject: Fedora.us sync with devel
Message-ID: <40A2D221.3080804@cornell.edu>

Why is there no repository for the fedora.us packages that's in sync 
with fedora development? I've noticed fedora-devel packages tend to 
update in batches in order not to break dependencies. It becomes a pain 
to make fedora devel work with fedora.us packages against the last 
release. Isn't the idea to merge the two anyway? When will that happen?








From aoliva at redhat.com  Thu May 13 05:54:11 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 13 May 2004 02:54:11 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040512233048.GA25548@neu.nirvana>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040512233048.GA25548@neu.nirvana>
Message-ID: <oru0ykrhx8.fsf@livre.redhat.lsd.ic.unicamp.br>

On May 12, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

>> My actual preference would be to instead use:
>> 
>> 0.<distid><distversion><repotag_opt><buildid>

> Buildid at the least significant position?

Doh, that was stupid, sorry.  I keep forgetting the reason why it has
to go before distid.  Anyhow, I'd still strongly suggest it to start
with for packages that are not in the Core.  Use 0.<count> for
<buildid> if you must, but don't start with 1 or higher unless you
actually mean to update a package with such a buildid from the Core
(or elsewhere).

> In general I don't see what purpose Alternatives would have.

I can only speak for myself, but the reason I'd like to have separate
Alternatives would be to enable myself to keep a rawhide install plus
add-ons, such that, if some package from rawhide fails, I know the
problem is in rawhide, not in an external repository that accidentally
or intentionally brought in a different version of a library, program,
whatever.  I realize kernel modules are a trickier issue, but on a
system meant to QA rawhide I wouldn't install them.

Another reason is that most repos lag behind rawhide.  Just to give an
example of one of my favorite pet peeves (without any offense to Dag
intended), Dag's FC1 has a mozilla 1.6 build with a higher epoch than
that of rawhide, even though his build is not actually more recent.
However, when I run up2date -u, it won't ugprade because of epiphany's
dependency on rawhide's mozilla, while dag's epiphany looks older than
that in rawhide so up2date won't use it.

Sure enough, if the epoch wasn't higher than that of rawhide, I
wouldn't run into this problem.  It would be lovely if this could be
fixed somehow, but there's no way for dag to downgrade the epoch
without breaking his <= FC1 repos, and blizzard didn't think this was
enough of a reason to bump up rawhide's mozilla epoch.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From wtogami at redhat.com  Thu May 13 06:05:49 2004
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 12 May 2004 20:05:49 -1000
Subject: Fedora.us sync with devel
In-Reply-To: <40A2D221.3080804@cornell.edu>
References: <40A2D221.3080804@cornell.edu>
Message-ID: <40A3103D.4030802@redhat.com>

Ivan Gyurdiev wrote:
> Why is there no repository for the fedora.us packages that's in sync 
> with fedora development? I've noticed fedora-devel packages tend to 
> update in batches in order not to break dependencies. It becomes a pain 
> to make fedora devel work with fedora.us packages against the last 
> release. Isn't the idea to merge the two anyway? When will that happen?

What are you talking about?  fedora.us has been in sync with development 
during this entire FC2 cycle.  Now we've moved to a version '2' 
repository in preparation for release, so we can do a mass rebuild of 
all Extras packages and make sure everything works.

Warren




From den at tourinfo.ru  Thu May 13 06:16:51 2004
From: den at tourinfo.ru (Den)
Date: Thu, 13 May 2004 10:16:51 +0400
Subject: mozilla langpack
In-Reply-To: <1084411202.4235.11.camel@localhost.localdomain>
References: <40A1EDF5.1090608@tourinfo.ru>	<1084364181.17962.4.camel@ulysse.olympe.o2t>	<40A217C7.90805@tourinfo.ru>	<1084365881.17962.9.camel@ulysse.olympe.o2t>
	<1084411202.4235.11.camel@localhost.localdomain>
Message-ID: <40A312D3.8070408@tourinfo.ru>

Matias Feliciano wrote:

>
>btw, try to use some thing like :
>Source1: http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib-localized-builds/mozilla-i686-pc-linux-gnu-1.6-frFR.tar.gz
>
>Here the package works great with LANG=fr_FR .
>  
>
>>Cheers,
>>    
>>
Yes! But this package is work fine with 31 locales and with 1.6 mozilla, 
included in final FC2 release (tested with 1.6-6 and 1.6-8).
Den.




From Axel.Thimm at ATrpms.net  Thu May 13 06:54:22 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 13 May 2004 08:54:22 +0200
Subject: Alternatives and packaging policies for multiple installs of
	different versions (was: On disttags)
In-Reply-To: <oru0ykrhx8.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040512233048.GA25548@neu.nirvana>
	<oru0ykrhx8.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <20040513065422.GA29888@neu.nirvana>

On Thu, May 13, 2004 at 02:54:11AM -0300, Alexandre Oliva wrote:
> On May 12, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> > In general I don't see what purpose Alternatives would have.
> 
> I can only speak for myself, but the reason I'd like to have separate
> Alternatives would be to enable myself to keep a rawhide install plus
> add-ons, such that, if some package from rawhide fails, I know the
> problem is in rawhide, not in an external repository that accidentally
> or intentionally brought in a different version of a library, program,
> whatever.  I realize kernel modules are a trickier issue, but on a
> system meant to QA rawhide I wouldn't install them.

For QAing rawhide (or any other release) I would really not install
anything but the object to QA. A lot of "non-Alternatives" are plugins
that alter the functionality of the system. So reporting back, that
rawhide has great mp3 playback in xmms will not help QA ;)

> Another reason is that most repos lag behind rawhide.  Just to give an
> example of one of my favorite pet peeves (without any offense to Dag
> intended), Dag's FC1 has a mozilla 1.6 build with a higher epoch than
> that of rawhide, even though his build is not actually more recent.
> However, when I run up2date -u, it won't ugprade because of epiphany's
> dependency on rawhide's mozilla, while dag's epiphany looks older than
> that in rawhide so up2date won't use it.
> 
> Sure enough, if the epoch wasn't higher than that of rawhide, I
> wouldn't run into this problem.  It would be lovely if this could be
> fixed somehow, but there's no way for dag to downgrade the epoch
> without breaking his <= FC1 repos, and blizzard didn't think this was
> enough of a reason to bump up rawhide's mozilla epoch.

That was a packaging buglet, of the kind that hurts whereever it
happens:

http://lists.atrpms.net/pipermail/repo-coord/2004-April/000240.html

I think Christopher would bump up and fix the epoch, if the other
repos would promise not to continue epoch-inflation. :)

The problem there is less that of a missing Alternatives, but that of
a lack of support of rawhide in most of the repos (until the last
testing minutes ;).

You will find yourself in the same unpleasant situation if you were
using Dag's galeon or something else that relies on say FC1's mozilla
and could block upgrading to rawhide mozilla. Same for any library
upgrade that bumbs up the major version in rawhide, but has 3rd party
packages relying on the old version.

The way to attack these problems is to accept the fact that multiple
incarnations of the same package should exist on a system (for packages
that support this, like shared libraries). The current method of
sometimes rebuilding compatibility packages is consuming too much
time. Having packaging guidelines (like Mandrake/Debian for some
areas) that allow concurrent use of different versions from the
beginning will make mixing different ages of rawhide/FCN repos easier.

The drawback is that old libraries not used by anthing else anymore
will sit and occupy space. These need to be identified and
removed. There are already tools for identifying these packages and
defining a "Provides: allow-multiple-versions" or "Provides:
remove-if-no-reverse-dependencies" guideline would make this model
waterproof.

While the first straightforward packages to dress that way would be
shared libs, mozilla or gcc concurrent versions would also come to
mind.

At the very least this solves more than Alternatives and is useful
even in fedora core/rhel by itself for deploying new libraries w/o
repackaging compatibility libs and re-QAing the "new" compatibility
packages.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040513/dc5d0502/attachment.sig>

From arjanv at redhat.com  Thu May 13 07:15:04 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 13 May 2004 09:15:04 +0200
Subject: glibc-kernheaders?
In-Reply-To: <1084405871.2295.15.camel@ninja2>
References: <1084405871.2295.15.camel@ninja2>
Message-ID: <1084432504.2781.2.camel@laptop.fenrus.com>

On Thu, 2004-05-13 at 01:51, Daryll Strauss wrote:
> The current release of glibc-kernheaders is 2.4-8.44. 
> 
> This includes linux/version.h and states the version is 2.4.20.
> 
> I assume this is a mistake, right?

no. the version doesn't matter at all. Nothing should depend on it or
use it.

-------------- 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/20040513/14a17bba/attachment.sig>

From rc040203 at freenet.de  Thu May 13 09:10:31 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 13 May 2004 11:10:31 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <1084439431.3770.13705.camel@mccallum.corsepiu.local>

On Thu, 2004-05-13 at 01:01, Alexandre Oliva wrote:
> On May 12, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> 
> > So the general stance is to have a suffux to the release tag
> > containing an rpm-sortable disttag and an optional repotag, like
> 
> > foo-1.2.3-4.rh9.ralf.src.rpm
> 
> > So the release tag looks like
> 
> >    <buildid><distid><distversion><repotag_opt>
> 
> > where buildid shound end with digits (for example a simple integer
> > like "3", or something conatining cvs info like "0.cvs20040512.16"),
> > distid should be invariant for the family of distributions and
> > distversion should be rpm-sortable (7.3, 8.0, 9 for instance). Repotag
> > is placed at the least significant place wrt to rpm comparison and is
> > optional.
> 
> > Nobody objected this scheme above
> 
> I thought there was some minor opposition.  <buildid> should *always*
> start with `0.', such that, whenever the distro contains the same
> version of the package, starting with 1 or above, the version in the
> distro is used.  If you build multiple times, use 0.1, 0.2, etc.
> 
> My actual preference would be to instead use:
> 
>      0.<distid><distversion><repotag_opt><buildid>
> 
> >> >Conversely, all seem to be designed "to take over the system".
> 
> > Even though this is our secret obsession, what do you man by that? 
> 
> Dunno what he meant,

I meant external repositories having chosen their release tags in such
way, that they can not be upgraded to original RH or Fedora.US packages.

For example: Consider a package now being shipped by livna for legal
issues: xxx-0.lvn.1.1.i386.rpm

Now suppose, the legal situation changes and the package shall be moved
to Fedora.US: xxx-0.fdr.2.i386.rpm

# rpmver 0.fdr.2.1 0.lvn.1.1
0.lvn.1.1 is newer

=> Can't get rid of this lvn rpm by using Fedora.US PackageGuideLine
conforming release tags, once you have installed it.


The same applies to other 3rd parties.

Another example: Axel ships perl-XML-Writer-0.4.6-7.rhfc1.at for FC1.

Now suppose, RH had chosen to ship perl-XML-Writer-0.4.6-1 with FC2
# rpmver 0.4.6-7.rhfc1.at 0.4.6-1
0.4.6-7.rhfc1.at is newer

=> An apt or yum based upgrade from FC1->FC2 will fail to pickup this
FC2 package without Axel having any possibility to do anything about it.

Now consider my situation: In general, I want have a clean Fedora Core +
Fedora Extras installation, but want to install packages which
_currently_ are not part of Fedora Core1 nor Fedora Extra.
Some of them (like the perl-XML-LibXML-Common rpm I had mentioned) are
known to be part of FC2, others are likely to be part of future FC/FE
release, others will probably be shipped by 3rd parties.

ATM, however I have to resort to locally built or non-FC/FE rpms, but do
want to keep the possibility of FC and FE packages to replace my local
packages during updates/upgrades.

>  but IMHO external repositories should be split
> into Extras and Alternatives, where Extras contain packages that add
> to the system without replacing any of its core components, leaving
> replacing/upgrading to Alternatives.

I am still missing an official RH or Fedora.US guide line.

What I see from experimenting with release tags yesterday, there
implicitly exists such a convention:

<fc-release>.fdr.<fdr-release>.<local-vendor-id>.<local-release>.<disttag>

with:
<fc-release> .. RH/FC package release number this package is supposed to
be replace. 0 for Extras, equal to the RH/FC release number for
Alternatives.
<fdr-release> ... Fedora.US release number this package is supposed to
replace. 0 if neither FC nor FE has this package. equal to FE's release
number if FE has the packages.
<local-vendor-id> ... an arbitrary string starting with a non-numeric
character.
<local-release> ... "Local Vendor's" actual build-number
<disttag>  ... Fedora US's disttag.

Some of the dots might be optional but didn't look into them (I like them :-) )

Ralf





From Axel.Thimm at ATrpms.net  Thu May 13 09:40:57 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 13 May 2004 11:40:57 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <1084439431.3770.13705.camel@mccallum.corsepiu.local>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
Message-ID: <20040513094057.GF29888@neu.nirvana>

On Thu, May 13, 2004 at 11:10:31AM +0200, Ralf Corsepius wrote:
> On Thu, 2004-05-13 at 01:01, Alexandre Oliva wrote:
> > On May 12, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> > >> >Conversely, all seem to be designed "to take over the system".
> > > Even though this is our secret obsession, what do you man by that? 
> > Dunno what he meant,
> 
> I meant external repositories having chosen their release tags in such
> way, that they can not be upgraded to original RH or Fedora.US packages.
> 
> For example: Consider a package now being shipped by livna for legal
> issues: xxx-0.lvn.1.1.i386.rpm
> 
> Now suppose, the legal situation changes and the package shall be moved
> to Fedora.US: xxx-0.fdr.2.i386.rpm
> 
> # rpmver 0.fdr.2.1 0.lvn.1.1
> 0.lvn.1.1 is newer
> 
> => Can't get rid of this lvn rpm by using Fedora.US PackageGuideLine
> conforming release tags, once you have installed it.

That's why the repotag needs to get moved to the back of the release
tag. If it were

xxx-0.1.1.lvn.i386.rpm

then

xxx-0.2.fdr.i386.rpm

would have been OK.

> The same applies to other 3rd parties.

Why? Almost all have the repotag at the end or missing.

> Another example: Axel ships perl-XML-Writer-0.4.6-7.rhfc1.at for FC1.
> 
> Now suppose, RH had chosen to ship perl-XML-Writer-0.4.6-1 with FC2
> # rpmver 0.4.6-7.rhfc1.at 0.4.6-1
> 0.4.6-7.rhfc1.at is newer
> 
> => An apt or yum based upgrade from FC1->FC2 will fail to pickup this
> FC2 package without Axel having any possibility to do anything about it.

Axel could package perl-XML-Writer for FC2 for instance, or the person
inside Red Hat should have picked a higher release number than already
available. Which _is happening_, indeed!

After all this _is_ a community project, and Red Hat and 3rd parties
are supposed to work together and not blindly package anymore. :)
If you were to detect such an anomaly as above you should report it
and either party can fix the issue. Nobody promised you no packaging
bugs! :)

> I am still missing an official RH or Fedora.US guide line.

There is an official Fedora.US guideline, you quoted it in previous
mails :)

There is no official Red Hat guideline or no commitment to adopting
all or parts of Fedora.US guidelines. I believe that the guidelines
you are seeking are considered in draft mode. Since the completion of
the merger between Red Hat's fedora and fedora.us requires a common
guideline, this needs to be addressed before that, so it needs to get
dealt with at some time.

Ralf, just go ahead and package in any scheme you now feel comfortable
with, even if you later believe the scheme you chose was broken, you
can still fix it. (Just don't use epoch inflation in any scheme!!! :)

Have fun packaging!
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040513/5d973883/attachment.sig>

From feliciano.matias at free.fr  Thu May 13 12:46:42 2004
From: feliciano.matias at free.fr (Matias Feliciano)
Date: Thu, 13 May 2004 14:46:42 +0200
Subject: mozilla langpack
In-Reply-To: <40A312D3.8070408@tourinfo.ru>
References: <40A1EDF5.1090608@tourinfo.ru>
	<1084364181.17962.4.camel@ulysse.olympe.o2t>	<40A217C7.90805@tourinfo.ru>
	<1084365881.17962.9.camel@ulysse.olympe.o2t>
	<1084411202.4235.11.camel@localhost.localdomain>
	<40A312D3.8070408@tourinfo.ru>
Message-ID: <1084452398.5967.4.camel@localhost.localdomain>

Le jeu 13/05/2004 ? 08:16, Den a ?crit :
> Matias Feliciano wrote:
> 
> >
> >btw, try to use some thing like :
> >Source1: http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib-localized-builds/mozilla-i686-pc-linux-gnu-1.6-frFR.tar.gz
> >
> >Here the package works great with LANG=fr_FR .
> >  

I mean YOUR package ( mozilla-i18n-1.6-1.i386.rpm )
:-)


> >
> >>Cheers,
> >>    
> >>
> Yes! But this package is work fine with 31 locales and with 1.6 mozilla, 
> included in final FC2 release (tested with 1.6-6 and 1.6-8).
> Den.
> 




From vallimar at sexorcisto.net  Thu May 13 13:03:42 2004
From: vallimar at sexorcisto.net (Troy Edwards)
Date: Thu, 13 May 2004 09:03:42 -0400 (EDT)
Subject: glibc-kernheaders?
In-Reply-To: <1084432504.2781.2.camel@laptop.fenrus.com>
References: <1084405871.2295.15.camel@ninja2>
	<1084432504.2781.2.camel@laptop.fenrus.com>
Message-ID: <1077.192.168.1.2.1084453422.squirrel@192.168.1.2>

> On Thu, 2004-05-13 at 01:51, Daryll Strauss wrote:
>> The current release of glibc-kernheaders is 2.4-8.44.
>>
>> This includes linux/version.h and states the version is 2.4.20.
>>
>> I assume this is a mistake, right?
>
> no. the version doesn't matter at all. Nothing should depend on it or
> use it.
>

Actually, glibc requires linux/version.h in order to compile.
It checks that the kernel level you specify is at least that
defined in version.h




From daryll at daryll.net  Thu May 13 14:23:51 2004
From: daryll at daryll.net (Daryll Strauss)
Date: Thu, 13 May 2004 07:23:51 -0700
Subject: glibc-kernheaders?
In-Reply-To: <1084432504.2781.2.camel@laptop.fenrus.com>
References: <1084405871.2295.15.camel@ninja2>
	<1084432504.2781.2.camel@laptop.fenrus.com>
Message-ID: <1084458231.2295.18.camel@ninja2>


OK, I've got an app running on FC1. It uses sched_setaffinity. The
number of arguments to that function has changed. How do I write my code
so that it compiles under FC1 and FC2?

						- |Daryll





From arjanv at redhat.com  Thu May 13 14:25:03 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 13 May 2004 16:25:03 +0200
Subject: glibc-kernheaders?
In-Reply-To: <1084458231.2295.18.camel@ninja2>
References: <1084405871.2295.15.camel@ninja2>
	<1084432504.2781.2.camel@laptop.fenrus.com>
	<1084458231.2295.18.camel@ninja2>
Message-ID: <20040513142503.GB24316@devserv.devel.redhat.com>

On Thu, May 13, 2004 at 07:23:51AM -0700, Daryll Strauss wrote:
> 
> OK, I've got an app running on FC1. It uses sched_setaffinity. The
> number of arguments to that function has changed. How do I write my code
> so that it compiles under FC1 and FC2?

you should use the glibc interface really, that shouldn't have changed.
(and I suspect you only think it changed the number of arguments because one
of the two releases you're using the kernel interface direct while in the
other the glibc one)
-------------- 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/20040513/c3ee2c5e/attachment.sig>

From jakub at redhat.com  Thu May 13 14:26:50 2004
From: jakub at redhat.com (Jakub Jelinek)
Date: Thu, 13 May 2004 10:26:50 -0400
Subject: glibc-kernheaders?
In-Reply-To: <1084458231.2295.18.camel@ninja2>
References: <1084405871.2295.15.camel@ninja2>
	<1084432504.2781.2.camel@laptop.fenrus.com>
	<1084458231.2295.18.camel@ninja2>
Message-ID: <20040513142650.GW30909@devserv.devel.redhat.com>

On Thu, May 13, 2004 at 07:23:51AM -0700, Daryll Strauss wrote:
> 
> OK, I've got an app running on FC1. It uses sched_setaffinity. The
> number of arguments to that function has changed. How do I write my code
> so that it compiles under FC1 and FC2?

configure check?

	Jakub




From steve at silug.org  Thu May 13 14:41:17 2004
From: steve at silug.org (Steven Pritchard)
Date: Thu, 13 May 2004 09:41:17 -0500
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <oru0ykrhx8.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040512233048.GA25548@neu.nirvana>
	<oru0ykrhx8.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <20040513144117.GA11170@osiris.silug.org>

On Thu, May 13, 2004 at 02:54:11AM -0300, Alexandre Oliva wrote:
> I can only speak for myself, but the reason I'd like to have separate
> Alternatives would be to enable myself to keep a rawhide install plus
> add-ons, such that, if some package from rawhide fails, I know the
> problem is in rawhide, not in an external repository that accidentally
> or intentionally brought in a different version of a library, program,
> whatever.

This sort of thing is where apt really shines.  On my desktop systems,
I like to be able to pull packages from freshrpms.net, since Matthias
still has some packages that aren't available from fedora.us or
livna.org.  He has a lot of packages in common with fedora.us and
livna.org though, so I use the following /etc/apt/preferences:

Package: *
Pin: release c=os
Pin-Priority: 992

Package: *
Pin: release c=stable
Pin-Priority: 991

("os" is Fedora Core stuff (apparently a lot of apt repositories are
using "core" now), and "stable" is fedora.us/livna.org.)

With that, apt will prefer packages from Fedora Core over any of the
other repositories, and fedora.us/livna.org packages over anything
else.

I've been using this setup for quite a while now, and it works great.
Now if only I could use apt on my x86-64 boxes...  :-)

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)398-7360               Mobile: (618)567-7320




From P at draigBrady.com  Thu May 13 14:47:51 2004
From: P at draigBrady.com (P at draigBrady.com)
Date: Thu, 13 May 2004 15:47:51 +0100
Subject: glibc-kernheaders?
In-Reply-To: <1084458231.2295.18.camel@ninja2>
References: <1084405871.2295.15.camel@ninja2>	<1084432504.2781.2.camel@laptop.fenrus.com>
	<1084458231.2295.18.camel@ninja2>
Message-ID: <40A38A97.1050004@draigBrady.com>

Daryll Strauss wrote:
> OK, I've got an app running on FC1. It uses sched_setaffinity. The
> number of arguments to that function has changed. How do I write my code
> so that it compiles under FC1 and FC2?

Well there is something funny going on,
as the man pages for sched_setaffinity
doesn't correspond to <sched.h> on FC1
at least. The man page has an extra len
parameter?

P?draig.




From fedora at wir-sind-cool.org  Thu May 13 15:16:02 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Thu, 13 May 2004 17:16:02 +0200
Subject: Fedora.us sync with devel
In-Reply-To: <40A3103D.4030802@redhat.com>
References: <40A2D221.3080804@cornell.edu>
	<40A3103D.4030802@redhat.com>
Message-ID: <20040513171602.1cda51ac.fedora@wir-sind-cool.org>

On Wed, 12 May 2004 20:05:49 -1000, Warren Togami wrote:

> Ivan Gyurdiev wrote:
> > Why is there no repository for the fedora.us packages that's in sync 
> > with fedora development? I've noticed fedora-devel packages tend to 
> > update in batches in order not to break dependencies. It becomes a pain 
> > to make fedora devel work with fedora.us packages against the last 
> > release. Isn't the idea to merge the two anyway? When will that happen?
> 
> What are you talking about?  fedora.us has been in sync with development 
> during this entire FC2 cycle.  Now we've moved to a version '2' 
> repository in preparation for release, so we can do a mass rebuild of 
> all Extras packages and make sure everything works.

It sounds like he wants the complete fedora.us extras repository being
rebuilt daily against the development tree or something like that.




From ville.skytta at iki.fi  Thu May 13 16:42:30 2004
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Thu, 13 May 2004 19:42:30 +0300
Subject: Fedora.us sync with devel
In-Reply-To: <40A2D221.3080804@cornell.edu>
References: <40A2D221.3080804@cornell.edu>
Message-ID: <1084466550.13842.232.camel@bobcat.mine.nu>

On Thu, 2004-05-13 at 04:40, Ivan Gyurdiev wrote:
> Why is there no repository for the fedora.us packages that's in sync 
> with fedora development? I've noticed fedora-devel packages tend to 
> update in batches in order not to break dependencies. It becomes a pain 
> to make fedora devel work with fedora.us packages against the last 
> release.

If something needs to be rebuilt due to a changed dependency ->
bugzilla.fedora.us.




From aoliva at redhat.com  Thu May 13 18:55:27 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 13 May 2004 15:55:27 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040513144117.GA11170@osiris.silug.org>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040512233048.GA25548@neu.nirvana>
	<oru0ykrhx8.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513144117.GA11170@osiris.silug.org>
Message-ID: <orvfj0p36o.fsf@livre.redhat.lsd.ic.unicamp.br>

On May 13, 2004, Steven Pritchard <steve at silug.org> wrote:

> This sort of thing is where apt really shines.

Yeah, pinning is the one feature from apt that I miss in up2date.  But
I don't use apt atm because some of the repos I use only have yum.
Since up2date supports both apt and yum, that's what I use.  But I get
to live with the lack of pinning, for now :-/

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From aoliva at redhat.com  Thu May 13 19:02:11 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 13 May 2004 16:02:11 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040513094057.GF29888@neu.nirvana>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
Message-ID: <orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>

On May 13, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

>> => An apt or yum based upgrade from FC1->FC2 will fail to pickup this
>> FC2 package without Axel having any possibility to do anything about it.

> Axel could package perl-XML-Writer for FC2 for instance, or the person
> inside Red Hat should have picked a higher release number than already
> available. Which _is happening_, indeed!

But a Fedora Core packager can't possibly monitor every single RPM
repository in existence.  Sure s/he can monitor the major ones, but
that doesn't cover, for example, private repos that aren't available
outside.  The packaging guidelines are useful for such private repos
as well, such that private packages.  And if it's good for private
repos in the sense of getting a clear upgrade path, it's good for
public repos in the this sense as well.

Using 0.<buildnumber> for Extras-like packages is a very simple way to
ensure that, if the package ever makes it to the Core, there will be a
clear upgrade path.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From Axel.Thimm at ATrpms.net  Thu May 13 19:28:00 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 13 May 2004 21:28:00 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <20040513192800.GS29888@neu.nirvana>

On Thu, May 13, 2004 at 04:02:11PM -0300, Alexandre Oliva wrote:
> On May 13, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> 
> >> => An apt or yum based upgrade from FC1->FC2 will fail to pickup this
> >> FC2 package without Axel having any possibility to do anything about it.
> 
> > Axel could package perl-XML-Writer for FC2 for instance, or the person
> > inside Red Hat should have picked a higher release number than already
> > available. Which _is happening_, indeed!
> 
> But a Fedora Core packager can't possibly monitor every single RPM
> repository in existence.  Sure s/he can monitor the major ones, but
> that doesn't cover, for example, private repos that aren't available
> outside.

Certainly, and the hierarchy buildid method should be applied by
private repos for their own sake. OTOH private rpms do not exist in
the common name- and version space, so private repos can do as they
please, for any purpose of theirs.

> The packaging guidelines are useful for such private repos as well,
> such that private packages.  And if it's good for private repos in
> the sense of getting a clear upgrade path, it's good for public
> repos in the this sense as well.

And consequently good for Red Hat's own packages themselves. ;)

No packaging policy will have a real chance if the major part of
packages, the ones from the base don't follow it. Even a suboptimal
policy chosen by RH would be better than the current situation.

More than the 0-prefix which RH as the first tier hierarchy would not
need, the disttag issue should be addressed and finally brought to an
end (the discussion is more than half a year old). So my suggestion
would be for Red Hat to choose the names of the disttags. Anything
that starts with letters and rpm sorts safely RHL and FC release
lines, like

	 rhl7.3  <  rhl8.0   <  rhl9 <  tfp1 <  tfp2 ("the fedora project")
	fp0.7.3  < fp0.8.0   < fp0.9 <   fp1 <   fp2
	  rh7.3  <   rh8.0   <   rh9 < rhfc1 < rhfc2

(and el3 or rhel3 for the RHEL family, the RHEL family should not
rpm-sort with the above, as there are no officially supported upgrade
paths RHEL <-> FC).

Yes, I know some people do not like the connotation "rh" to "fc", but
the above is a technical solution. Let Red Hat just set the disttags
to any working set (both technically and politically) and the repos
will adopt it immediately, I am sure.

So will FC3 has disttags? :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040513/6a0d5d79/attachment.sig>

From snickell at redhat.com  Thu May 13 22:04:32 2004
From: snickell at redhat.com (Seth Nickell)
Date: Thu, 13 May 2004 18:04:32 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
Message-ID: <1084485872.5572.13.camel@localhost.localdomain>

1) Don't change menu structures without asking. FYI, most of the time
the answer will be "no".

2) If your package is in any of the default package sets:
  a) You must get approval for any changes that change the menus. This
includes renaming items or adding new .desktop files. In other words,
almost any change to a .desktop file, save translations.
  b) The menu item should usually be the application's
generic/descriptive name. For example, use "Web Browser" instead of
"Mozilla" or "Mozilla Web Browser".

3) If your package is NOT in any of the default package sets:
  a) The menu name should usually be the application's given name + the
generic/descriptive name. For example, use "Mozilla Web Browser" instead
of "Web Browser" or "Mozilla".

3) The default packages in the  package sets (in the comps file) may not
include any applications that are functional duplicates. In other words,
if the user clicks all the package sets in the installer (other than
everything), they should not end up with two web browsers or two
spreadsheets in the menus. To give a hypothetical example, lets say we
shipped Gnumeric as one of the default apps in the "Office" package set.
In this case OpenOffice.org Calc should not show up in the menus, even
if the openoffice.org package is installed (presuming we install the
rest of openoffice by default). One way to address this would be to
include a separate "openoffice.org-calc" package that simply installs
a .desktop file.
  a) Exception: Although KDE and GNOME overlap we include both in
package sets. To deal with this, we mark smaller utilities and core
desktop pieces that overlap (e.g. gnome-utils, kdeutils, kdebase,
kdemultimedia, gnome-media, kdeadmin, etc) with "OnlyShowIn=...". That
way we still don't get overlapping menu items. By default all items in
these sort of packages should be marked OnlyShowIn. Ask me about
specific things you think should be exceptions.

Some general guidelines:

- Include a generic version of the name, even if your app isn't install
by default (e.g. "Mozilla Web Browser").
- Don't add menu entries for things for the heck of it. For example, the
number of people who launch emacs from the menus is probably very
small. ;-) If its mostly launched from the command line (could still be
an X application, note), don't put it in the menus.
- Don't add a bunch of entries for the same application unless its a
really big monster application (like OpenOffice.org). For example,
KBabel, a translation tool has three menu entries. It shouldn't!
- Don't have a "_____ Configuration" menu entry (e.g. Chromium
Configuration). Configuration should be launched from inside the app. If
its not, cry, but don't add it to the menus ;-)

As soon as we have a Fedora wiki, I'll put this information up there and
maintain it.

-Seth




From cmadams at hiwaay.net  Fri May 14 00:06:39 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 13 May 2004 19:06:39 -0500
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084485872.5572.13.camel@localhost.localdomain>
References: <1084485872.5572.13.camel@localhost.localdomain>
Message-ID: <20040514000639.GA1123340@hiwaay.net>

Once upon a time, Seth Nickell <snickell at redhat.com> said:
> 3) The default packages in the  package sets (in the comps file) may not
> include any applications that are functional duplicates. In other words,
> if the user clicks all the package sets in the installer (other than
> everything), they should not end up with two web browsers or two
> spreadsheets in the menus. To give a hypothetical example, lets say we
> shipped Gnumeric as one of the default apps in the "Office" package set.
> In this case OpenOffice.org Calc should not show up in the menus, even
> if the openoffice.org package is installed (presuming we install the
> rest of openoffice by default). One way to address this would be to
> include a separate "openoffice.org-calc" package that simply installs
> a .desktop file.

I understand trying to make things simpler, but I also have a problem
with this.  I will sometimes intentionally install multiple things (like
OOo and Gnumeric), with the intention of checking them both out to see
which one I like (or does what I want) better.  I install both from the
regular install menu in anaconda; with your rule above, I wouldn't end
up with both in the desktop menus that way.

-- 
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 alan at clueserver.org  Fri May 14 00:04:38 2004
From: alan at clueserver.org (alan)
Date: Thu, 13 May 2004 17:04:38 -0700 (PDT)
Subject: Menu Policy - please read if you maintain a package with a
 .desktop file in it!
In-Reply-To: <20040514000639.GA1123340@hiwaay.net>
Message-ID: <Pine.LNX.4.44.0405131702070.8834-100000@ebersisk.clueserver.org>

On Thu, 13 May 2004, Chris Adams wrote:

> Once upon a time, Seth Nickell <snickell at redhat.com> said:
> > 3) The default packages in the  package sets (in the comps file) may not
> > include any applications that are functional duplicates. In other words,
> > if the user clicks all the package sets in the installer (other than
> > everything), they should not end up with two web browsers or two
> > spreadsheets in the menus. To give a hypothetical example, lets say we
> > shipped Gnumeric as one of the default apps in the "Office" package set.
> > In this case OpenOffice.org Calc should not show up in the menus, even
> > if the openoffice.org package is installed (presuming we install the
> > rest of openoffice by default). One way to address this would be to
> > include a separate "openoffice.org-calc" package that simply installs
> > a .desktop file.
> 
> I understand trying to make things simpler, but I also have a problem
> with this.  I will sometimes intentionally install multiple things (like
> OOo and Gnumeric), with the intention of checking them both out to see
> which one I like (or does what I want) better.  I install both from the
> regular install menu in anaconda; with your rule above, I wouldn't end
> up with both in the desktop menus that way.

There is also the issue of where one app provides functionality that 
another does not.

An example (but not part of Fedora core) is Xine v.s. Mplayer.  I have 
various files that one will play and not the other.  When one does not 
work, I try the other.

The Highlander approach ("There can only be one!") is a bad way to handle 
things.  Not something to lose ones head over...





From skvidal at phy.duke.edu  Fri May 14 00:11:14 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 13 May 2004 20:11:14 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <20040514000639.GA1123340@hiwaay.net>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
Message-ID: <1084493474.16881.1.camel@binkley>


> I understand trying to make things simpler, but I also have a problem
> with this.  I will sometimes intentionally install multiple things (like
> OOo and Gnumeric), with the intention of checking them both out to see
> which one I like (or does what I want) better.  I install both from the
> regular install menu in anaconda; with your rule above, I wouldn't end
> up with both in the desktop menus that way.
> 

I couldn't agree more - I admin systems for a number of people. They use
various pieces of software on their own - some like gnumeric b/c it is
fast, some like open office calc for other reasons. What is the merit in
removing these menu options? How will you allow for difference of
choices b/t users?

-sv





From snickell at redhat.com  Fri May 14 00:35:36 2004
From: snickell at redhat.com (Seth Nickell)
Date: Thu, 13 May 2004 20:35:36 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <20040514000639.GA1123340@hiwaay.net>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
Message-ID: <1084494935.5572.16.camel@localhost.localdomain>

On Thu, 2004-05-13 at 19:06 -0500, Chris Adams wrote:
> Once upon a time, Seth Nickell <snickell at redhat.com> said:
> > 3) The default packages in the  package sets (in the comps file) may not
> > include any applications that are functional duplicates. In other words,
> > if the user clicks all the package sets in the installer (other than
> > everything), they should not end up with two web browsers or two
> > spreadsheets in the menus. To give a hypothetical example, lets say we
> > shipped Gnumeric as one of the default apps in the "Office" package set.
> > In this case OpenOffice.org Calc should not show up in the menus, even
> > if the openoffice.org package is installed (presuming we install the
> > rest of openoffice by default). One way to address this would be to
> > include a separate "openoffice.org-calc" package that simply installs
> > a .desktop file.
> 
> I understand trying to make things simpler, but I also have a problem
> with this.  I will sometimes intentionally install multiple things (like
> OOo and Gnumeric), with the intention of checking them both out to see
> which one I like (or does what I want) better.  I install both from the
> regular install menu in anaconda; with your rule above, I wouldn't end
> up with both in the desktop menus that way.

You would if you install OOo and Gnumeric and OOo Calc. This isn't a
restriction on installing individual packages, or even packages inside a
package set, just packages that get turned on by default when you enable
a package set.

-Seth




From snickell at redhat.com  Fri May 14 00:39:20 2004
From: snickell at redhat.com (Seth Nickell)
Date: Thu, 13 May 2004 20:39:20 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084493474.16881.1.camel@binkley>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
Message-ID: <1084495159.5572.20.camel@localhost.localdomain>

On Thu, 2004-05-13 at 20:11 -0400, seth vidal wrote:
> > I understand trying to make things simpler, but I also have a problem
> > with this.  I will sometimes intentionally install multiple things (like
> > OOo and Gnumeric), with the intention of checking them both out to see
> > which one I like (or does what I want) better.  I install both from the
> > regular install menu in anaconda; with your rule above, I wouldn't end
> > up with both in the desktop menus that way.
> > 
> 
> I couldn't agree more - I admin systems for a number of people. They use
> various pieces of software on their own - some like gnumeric b/c it is
> fast, some like open office calc for other reasons. What is the merit in
> removing these menu options? How will you allow for difference of
> choices b/t users?

This is not the same issue. You can still install whatever the hell you
want for your users. This is about what we treat as a default, or
slightly customized default, install. From the installer you can still
select individual packages, or go inside a package set and select one of
the packages that is not installed by default but is a member of that
set.

That said, the current "everything shows up in everybody's menu" way of
doing things is lame. That problem should be addressed head on.

-Seth




From katzj at redhat.com  Fri May 14 01:15:24 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 13 May 2004 21:15:24 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <20040514000639.GA1123340@hiwaay.net>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
Message-ID: <1084497324.10851.35.camel@bree.local.net>

On Thu, 2004-05-13 at 19:06 -0500, Chris Adams wrote:
> I understand trying to make things simpler, but I also have a problem
> with this.  I will sometimes intentionally install multiple things (like
> OOo and Gnumeric), with the intention of checking them both out to see
> which one I like (or does what I want) better.  I install both from the
> regular install menu in anaconda; with your rule above, I wouldn't end
> up with both in the desktop menus that way.

Actually, I think this would be fine as long as only one of them were
selected as a default in anaconda.  If somebody goes to the trouble of
clicking to turn on all of the optional things in every component, if
the results are somewhat similar to an everything install in terms of
having a little bit more clutter, that doesn't strike me as a horrible
thing

Jeremy




From skvidal at phy.duke.edu  Fri May 14 02:07:19 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 13 May 2004 22:07:19 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084495159.5572.20.camel@localhost.localdomain>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
Message-ID: <1084500439.16881.7.camel@binkley>


> This is not the same issue. You can still install whatever the hell you
> want for your users. This is about what we treat as a default, or
> slightly customized default, install. From the installer you can still
> select individual packages, or go inside a package set and select one of
> the packages that is not installed by default but is a member of that
> set.

ok - this part wasn't terribly clear in your policy - it would be useful
to specify that a bit.


> That said, the current "everything shows up in everybody's menu" way of
> doing things is lame. That problem should be addressed head on.

I think that is a function of getting the menu editing working, not a
function of setting .desktop file policy. Moreover, when a user first
logs in - they should probably see the range of options of installed
software, otherwise they'll probably never find the rest of it.

-sv





From rhally at mindspring.com  Fri May 14 02:58:29 2004
From: rhally at mindspring.com (Richard Hally)
Date: Thu, 13 May 2004 22:58:29 -0400
Subject: Menu Policy - please read if you maintain a package with
 a	.desktop file in it!
In-Reply-To: <1084495159.5572.20.camel@localhost.localdomain>
References: <1084485872.5572.13.camel@localhost.localdomain>	<20040514000639.GA1123340@hiwaay.net>	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
Message-ID: <40A435D5.8000605@mindspring.com>

Seth Nickell wrote:

<snip>
> 
> This is not the same issue. You can still install whatever the hell you
> want for your users. This is about what we treat as a default, or
> slightly customized default, install. From the installer you can still
> select individual packages, or go inside a package set and select one of
> the packages that is not installed by default but is a member of that
> set.
> 
> That said, the current "everything shows up in everybody's menu" way of
> doing things is lame. That problem should be addressed head on.
> 
> -Seth
> 

Once you get past that 20th century-command line mentality, you'll be 
ok. ;) There are billions of people that use computers that never see 
the command line: If it's not on a menu it doesn't exist.
If I install some software it better show up on the menu. Especially if 
I do an 'everything' install, I what to be able to find everything on a 
menu somewhere! I guess that attitude comes from having been a GUI 
designer/builder/programmer for several years.
Richard Hally




From aoliva at redhat.com  Fri May 14 04:51:56 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 14 May 2004 01:51:56 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040513192800.GS29888@neu.nirvana>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
Message-ID: <ork6zfbogj.fsf@livre.redhat.lsd.ic.unicamp.br>

On May 13, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

> So will FC3 has disttags? :)

Frankly, I don't see the point of disttags for the core packages.  The
only purpose of disttags IMHO is to differentiate builds of the very
same package for different OSs/releases.  Fedora Core packages never
use this; if there's a rebuild for the next release of Fedora Core,
the build number is incremented.  If there's an errata-like patch
build for an update for an earlier release, it can get a .1 suffix
to the released build number, for the first such build, and have this
suffix incremented for subsequent builds.  So, when are they useful
for packages in the Core?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From barryn at pobox.com  Fri May 14 06:22:52 2004
From: barryn at pobox.com (Barry K. Nathan)
Date: Thu, 13 May 2004 23:22:52 -0700
Subject: Menu Policy - please read if you maintain a package with
	a	.desktop file in it!
In-Reply-To: <40A435D5.8000605@mindspring.com>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<40A435D5.8000605@mindspring.com>
Message-ID: <20040514062252.GA3465@ip68-4-98-123.oc.oc.cox.net>

On Thu, May 13, 2004 at 10:58:29PM -0400, Richard Hally wrote:
> Once you get past that 20th century-command line mentality, you'll be 
> ok. ;)

And Red Hat even recognizes this, to some degree (that's why the
Terminal was stuffed into the System Tools submenu in the Red Hat 8.0
era, IIRC).

> There are billions of people that use computers that never see 
> the command line: If it's not on a menu it doesn't exist.

This *almost* matches my thoughts. More precisely, I think it's more
like "if it's not reachable via the GUI, without having to know the
program's name in advance, it doesn't exist." For instance, Mac OS X
programs tend to show up in an "Applications" folder on the hard drive
rather than in a menu. Perhaps there could be a folder, somewhat like
this (and reachable from the "Places" menu in Nautilus) could be used to
avoid overloading the menus. (I say "somewhat" because in some sense the
Applications folder in OS X also takes the place of RPM, insofar as it
can be used to install or remove the typical OS X program.)

Or perhaps there could be a "Show More Programs"/"Show Fewer Programs"
toggle in the menu, which would explode the menu with everything that's
installed or trim it back down to the Red Hat defaults. This would be
sort of like the little menu expansion tab thingies in Windows ME/XP,
except it would not attempt to adapt itself to the user, and perhaps
would be less annoying as a result.

FWIW, under Mac OS 9 (arguably the best real-world OS from a usability
standpoint) the normal setup was to put very few programs into the
menus, and to leave the rest accessible via the file manager. The x most
frequently used programs were also placed in a "Recent Applications"
submenu (the typical value of x was something like 10 or 15). However,
it was pretty easy to make a submenu with an entry for each file on
your hard drive, if you wished. (BTW, the Apple Menu also existed as a
folder in the file manager, and that's how the menu was edited.)

I'm starting to ramble a bit, but hopefully somebody will find this
feedback useful. One last point: IMO we need some sort of functional and
easy menu editing before we can deal with this problem in a sane manner.
Without that, we're going to be whacking at problems with a hammer when
we really need to use a screwdriver, so to speak.

-Barry K. Nathan <barryn at pobox.com>




From Axel.Thimm at ATrpms.net  Fri May 14 06:57:52 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Fri, 14 May 2004 08:57:52 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <ork6zfbogj.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
References: <20040513192800.GS29888@neu.nirvana>
	<ork6zfbogj.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
Message-ID: <20040514065752.GA17038@neu.nirvana>

On Thu, May 13, 2004 at 09:28:00PM +0200, Axel Thimm wrote:
> On Thu, May 13, 2004 at 04:02:11PM -0300, Alexandre Oliva wrote:
> > The packaging guidelines are useful for such private repos as well,
> > such that private packages.  And if it's good for private repos in
> > the sense of getting a clear upgrade path, it's good for public
> > repos in the this sense as well.
> 
> And consequently good for Red Hat's own packages themselves. ;)
> [...]
> So will FC3 has disttags? :)

On Fri, May 14, 2004 at 01:51:56AM -0300, Alexandre Oliva wrote:
> Frankly, I don't see the point of disttags for the core packages.  The
> only purpose of disttags IMHO is to differentiate builds of the very
> same package for different OSs/releases.  Fedora Core packages never
> use this; if there's a rebuild for the next release of Fedora Core,
> the build number is incremented.  If there's an errata-like patch
> build for an update for an earlier release, it can get a .1 suffix
> to the released build number, for the first such build, and have this
> suffix incremented for subsequent builds.  So, when are they useful
> for packages in the Core?

o for first it will certainly not hurt at all. 
o it will enable the cousing fedoralegacy to have clean backbuilds.
o it will enable Red Hat to have decent common errata for multiple
  non-EOLed releases.
o it will enable rawhide to have good upgrade paths for unchanged
  packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all
  packages for test2.
o it will provide a coherent specification for Red Hat and third party
  repos to use. Asking of repos to change/apply vereioning specs w/o
  Red Hat to follow is not going to work.
o there will be no more big threads about disttags w/o a resolution :)

The downside is that someone must spent a day and a half to get the
build system at Red Hat to add disttags.

Disttags are a good concept. The only thing hindering them in the
Fedora/RHEL world is the choice for a specific implementation. If the
vendor does not go along, you will continue to have anarchy in
guidelines.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040514/d3e90130/attachment.sig>

From laroche at redhat.com  Fri May 14 08:13:43 2004
From: laroche at redhat.com (Florian La Roche)
Date: Fri, 14 May 2004 10:13:43 +0200
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084497324.10851.35.camel@bree.local.net>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084497324.10851.35.camel@bree.local.net>
Message-ID: <20040514081343.GF25523@dudweiler.stuttgart.redhat.com>

On Thu, May 13, 2004 at 09:15:24PM -0400, Jeremy Katz wrote:
> On Thu, 2004-05-13 at 19:06 -0500, Chris Adams wrote:
> > I understand trying to make things simpler, but I also have a problem
> > with this.  I will sometimes intentionally install multiple things (like
> > OOo and Gnumeric), with the intention of checking them both out to see
> > which one I like (or does what I want) better.  I install both from the
> > regular install menu in anaconda; with your rule above, I wouldn't end
> > up with both in the desktop menus that way.
> 
> Actually, I think this would be fine as long as only one of them were
> selected as a default in anaconda.  If somebody goes to the trouble of
> clicking to turn on all of the optional things in every component, if
> the results are somewhat similar to an everything install in terms of
> having a little bit more clutter, that doesn't strike me as a horrible
> thing

This sounds like a very good idea to really come to useful menues.

greetings,

Florian La Roche




From laroche at redhat.com  Fri May 14 08:17:48 2004
From: laroche at redhat.com (Florian La Roche)
Date: Fri, 14 May 2004 10:17:48 +0200
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084493474.16881.1.camel@binkley>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
Message-ID: <20040514081748.GG25523@dudweiler.stuttgart.redhat.com>

> I couldn't agree more - I admin systems for a number of people. They use
> various pieces of software on their own - some like gnumeric b/c it is
> fast, some like open office calc for other reasons. What is the merit in
> removing these menu options? How will you allow for difference of
> choices b/t users?

I think this example shows why we need "enough entries" in the menues.
It still must remain a longterm goal to only ship the useful apps we
find and instead of e.g. having 3 apps with different features to have
only one app with all features and working for all users.
That might be a little bit simplistic and might not match OOcalc versus
gnucash where both apps will be needed by users to put them both into
the menues. Users dislike a lot to start apps from the commandline...

greetings,

Florian La Roche




From aoliva at redhat.com  Fri May 14 08:32:54 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 14 May 2004 05:32:54 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040514065752.GA17038@neu.nirvana>
References: <20040513192800.GS29888@neu.nirvana>
	<ork6zfbogj.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
Message-ID: <oru0yj9znt.fsf@livre.redhat.lsd.ic.unicamp.br>

On May 14, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

> On Thu, May 13, 2004 at 09:28:00PM +0200, Axel Thimm wrote:

> On Fri, May 14, 2004 at 01:51:56AM -0300, Alexandre Oliva wrote:
>> Frankly, I don't see the point of disttags for the core packages.
>> [...] when are they useful for packages in the Core?

> o for first it will certainly not hurt at all. 
> o it will enable the cousing fedoralegacy to have clean backbuilds.
> o it will enable Red Hat to have decent common errata for multiple
>   non-EOLed releases.
> o it will enable rawhide to have good upgrade paths for unchanged
>   packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all
>   packages for test2.
> o it will provide a coherent specification for Red Hat and third party
>   repos to use. Asking of repos to change/apply vereioning specs w/o
>   Red Hat to follow is not going to work.
> o there will be no more big threads about disttags w/o a resolution :)

You seem to have good points.  I'm convinced.  Unfortunately, I have
no say on what happens to Fedora Core packages, other than what I talk
developers into doing by filing bug reports in bugzilla :-)

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From nphilipp at redhat.com  Fri May 14 08:42:18 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 14 May 2004 10:42:18 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040514065752.GA17038@neu.nirvana>
References: <20040513192800.GS29888@neu.nirvana>
	<ork6zfbogj.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
Message-ID: <1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>

On Fri, 2004-05-14 at 08:57, Axel Thimm wrote:
> On Thu, May 13, 2004 at 09:28:00PM +0200, Axel Thimm wrote:
> > On Thu, May 13, 2004 at 04:02:11PM -0300, Alexandre Oliva wrote:
> > > The packaging guidelines are useful for such private repos as well,
> > > such that private packages.  And if it's good for private repos in
> > > the sense of getting a clear upgrade path, it's good for public
> > > repos in the this sense as well.
> > 
> > And consequently good for Red Hat's own packages themselves. ;)
> > [...]
> > So will FC3 has disttags? :)
> 
> On Fri, May 14, 2004 at 01:51:56AM -0300, Alexandre Oliva wrote:
> > Frankly, I don't see the point of disttags for the core packages.  The
> > only purpose of disttags IMHO is to differentiate builds of the very
> > same package for different OSs/releases.  Fedora Core packages never
> > use this; if there's a rebuild for the next release of Fedora Core,
> > the build number is incremented.  If there's an errata-like patch
> > build for an update for an earlier release, it can get a .1 suffix
> > to the released build number, for the first such build, and have this
> > suffix incremented for subsequent builds.  So, when are they useful
> > for packages in the Core?
> 
> o for first it will certainly not hurt at all. 

It hurts in the eyes ;-)

> o it will enable the cousing fedoralegacy to have clean backbuilds.

I'm not sure if I understand you correctly (what is "cousing"?), but you
can simply do the obvious and append the release to the existing one,
like in:

last rel: "3", next rel: "3.1"

or for the sake of being talkative to users maybe even:

last rel: "3", next rel: "3.fc1.1"

despite that being ugly to the eye. But we would have to support FC1
only for a short time after FC2 is out, don't we? In that case, even I
can live with a certain amount of ugliness.

> o it will enable Red Hat to have decent common errata for multiple
>   non-EOLed releases.

How do we not have that today?

> o it will enable rawhide to have good upgrade paths for unchanged
>   packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all
>   packages for test2.

As long as either the release itself or one component is an integer,
bumping that is easy. In fact it works today, ask Elliot -- I don't
think he fiddles manually with hundreds of release tags when doing a
mass-rebuild.

> o it will provide a coherent specification for Red Hat and third party
>   repos to use. Asking of repos to change/apply vereioning specs w/o
>   Red Hat to follow is not going to work.

I think we're talking about Fedora Core and 3rd party repos, let's make
that distinction even if Fedora Core development is largely staffed with
Red Hat people today. My impression is that Fedora Core objectives in
this issue are to work inside of Core/Extras/Alternatives however these
are defined, anything beyond is "out of scope". That's my personal
opinion.

> o there will be no more big threads about disttags w/o a resolution :)

Haha. On the other hand, we could all just shut up ;-).

> The downside is that someone must spent a day and a half to get the
> build system at Red Hat to add disttags.

Obviously you are joking, but then you haven't seen our build system
yet, have you?

> Disttags are a good concept. The only thing hindering them in the
> Fedora/RHEL world is the choice for a specific implementation. If the
> vendor does not go along, you will continue to have anarchy in
> guidelines.

In my point of view, disttags serve only one purpose, namely
differentiating from which repository a package comes in the file name,
at the price of looking ugly. They do not improve interoperability a bit
because the package manager wouldn't know that if package "foo" from
repo "bar" needs "baz" then it must come from "bar" as well or at least
from "stfu" ;-). Using disttags doesn't make upgrading package "xyz"
from the external repo "abc" to the one in Core easier unless both sides
plan in that regard.

If I were to "usurp" a package for Core, I would only want to ensure
upgradability for that package eventually existing in Extras, for which
simple integers as releases suffice, mind my words (incrementing them is
an easy operation ;-) or alternatively for the package from another repo
I based off. I would not try to be "later" v-r-wise than any other
instance of the package in one of your, Dag's or any other of the
myriads of repositories because things would then simply be getting out
of hand.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040514/8c9b3888/attachment.sig>

From Axel.Thimm at ATrpms.net  Fri May 14 09:07:09 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Fri, 14 May 2004 11:07:09 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <20040514090709.GA21879@neu.nirvana>

On Fri, May 14, 2004 at 10:42:18AM +0200, Nils Philippsen wrote:
> On Fri, 2004-05-14 at 08:57, Axel Thimm wrote:
> > o it will enable the cousing fedoralegacy to have clean backbuilds.
> 
> I'm not sure if I understand you correctly (what is "cousing"?),

sorry, that's a typo it's "cousin".

> but you can simply do the obvious and append the release to the
> existing one, like in:
> 
> last rel: "3", next rel: "3.1"
> 
> or for the sake of being talkative to users maybe even:
> 
> last rel: "3", next rel: "3.fc1.1"

But these _are_ disttags! :)

> > o it will enable Red Hat to have decent common errata for multiple
> >   non-EOLed releases.
> 
> How do we not have that today?

Don't ask me, have a look at the differnt (read per package) solutions
used at Red Hat/Fedora Core for common errata (e.g. kernel, glibc,
ethereal). Some packages got a ".7", ".8", ".9" appended, others an
"FC1" etc, even others simply enumerated them.

If there were policy, you could use foo-1.2.3-4.fc1.i386.rpm and
foo-1.2.3-4.fc2.i386.rpm for pushing out common errata for FC1 and
FC2, w/o reinventing the wheel each time.

> > o it will enable rawhide to have good upgrade paths for unchanged
> >   packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all
> >   packages for test2.
> 
> As long as either the release itself or one component is an integer,
> bumping that is easy. In fact it works today, ask Elliot -- I don't
> think he fiddles manually with hundreds of release tags when doing a
> mass-rebuild.

No, that would be suicide, but the bumbed Release tag is not helpful
for investigating what has changed. Sometime the %changelog is
helpful, other times one need to open the packages and compare
content. A changing disttag with otherwise invariant buildid doesn't
even need a changelog about rebuilding.

> > o it will provide a coherent specification for Red Hat and third party
> >   repos to use. Asking of repos to change/apply vereioning specs w/o
> >   Red Hat to follow is not going to work.
> 
> I think we're talking about Fedora Core and 3rd party repos, let's make
> that distinction even if Fedora Core development is largely staffed with
> Red Hat people today. My impression is that Fedora Core objectives in
> this issue are to work inside of Core/Extras/Alternatives however these
> are defined, anything beyond is "out of scope". That's my personal
> opinion.

Well, the thread started about someone wanting to provide packages for
third party repos or Extras with disttags. If you look at fedora.us,
which is deemed ti become Fedora Extras, you will see disttags. Are
you suggesting to remove them? fedora.us developers would not be happy
about that.

> > The downside is that someone must spent a day and a half to get the
> > build system at Red Hat to add disttags.
> 
> Obviously you are joking, but then you haven't seen our build system
> yet, have you?

Of course, I am joking. OTOH there are existing buildsystems in
various projects including ATrpms, fedora.us, Dag and probably more
that have solved this a long time since. So it is not really rocket
science, once a disttag scheme has been approved. Perhaps you should
hire me ;)

> > Disttags are a good concept. The only thing hindering them in the
> > Fedora/RHEL world is the choice for a specific implementation. If the
> > vendor does not go along, you will continue to have anarchy in
> > guidelines.
> 
> In my point of view, disttags serve only one purpose, namely
> differentiating from which repository a package comes in the file name,
> at the price of looking ugly.

Oops, I understand that we are probably talking about different
things. What you are thinking of are "repotags" like "fr", "at",
"dag", "ccrma", "spc", "dries" that only serve for uglyness and have
no functionality. I am not promoting their use, they shoudl be
considered optional and should stay out of our way (in an upgrade
path consideration, e.g. shove them at the very end of the release tag
if you really must so).

> If I were to "usurp" a package for Core, I would only want to ensure
> upgradability for that package eventually existing in Extras, for which
> simple integers as releases suffice, [...]

You should think outside of the Fedora Core scope where disttags are
indeed only useful for common errata with simultaneous non-EOLed
releases.

Projects very near to Fedora Core (not "3rd party") like Fedora Extras
predecessor fedora.us, and fedoralegacy.org do require more often to
have common builds differentiating in the release built against. So
disttags are required.

And as a community project you cannot keep out of scope "3rd party"
repos. They also support multiple releases of Red Hat and Fedora and
ths need disttags (not repotags!).

And really, disttags do not hurt at all. Aesthetics don't count in
packaging, otherwise we would package foo-1.2.3-4.el3.at.i386.rpm into
setup.exe.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040514/c8a3d8a6/attachment.sig>

From nphilipp at redhat.com  Fri May 14 11:37:45 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 14 May 2004 13:37:45 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040514090709.GA21879@neu.nirvana>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
Message-ID: <1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>

On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:

> > but you can simply do the obvious and append the release to the
> > existing one, like in:
> > 
> > last rel: "3", next rel: "3.1"
> > 
> > or for the sake of being talkative to users maybe even:
> > 
> > last rel: "3", next rel: "3.fc1.1"
> 
> But these _are_ disttags! :)

Still ugly, but I admit that packagers using them should use the same
hwen referring to the same distro-version.

> > > o it will enable Red Hat to have decent common errata for multiple
> > >   non-EOLed releases.
> > 
> > How do we not have that today?
> 
> Don't ask me, have a look at the differnt (read per package) solutions
> used at Red Hat/Fedora Core for common errata (e.g. kernel, glibc,
> ethereal). Some packages got a ".7", ".8", ".9" appended, others an
> "FC1" etc, even others simply enumerated them.

I meant that whatever the release tags of the packages are is in no way
relevant to the errata package being decent or not. As I mentioned in my
last mail, I can suffer a little ugliness but be that as it may,
packages will work (or not) regardless of how shrewdly we build our
release tags or not, as long as v-r is rising strictly monotonously for
RPM.

> If there were policy, you could use foo-1.2.3-4.fc1.i386.rpm and
> foo-1.2.3-4.fc2.i386.rpm for pushing out common errata for FC1 and
> FC2, w/o reinventing the wheel each time.

I wouldn't put "incrementing a number" in the vicinity of anything
"invention", look at the USPTO where this got us ;-).

> > > o it will enable rawhide to have good upgrade paths for unchanged
> > >   packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all
> > >   packages for test2.
> > 
> > As long as either the release itself or one component is an integer,
> > bumping that is easy. In fact it works today, ask Elliot -- I don't
> > think he fiddles manually with hundreds of release tags when doing a
> > mass-rebuild.
> 
> No, that would be suicide, but the bumbed Release tag is not helpful
> for investigating what has changed. Sometime the %changelog is
> helpful, other times one need to open the packages and compare
> content. A changing disttag with otherwise invariant buildid doesn't
> even need a changelog about rebuilding.

Nah. I don't want the release tag to be meaningful at all, that's what
changelog is for. By codifying disttags into release, you practically
limit yourself to rebuild only when the distro-version changes and
believe me, we build more often and for much more purposes than only
this.

> > > o it will provide a coherent specification for Red Hat and third party
> > >   repos to use. Asking of repos to change/apply vereioning specs w/o
> > >   Red Hat to follow is not going to work.
> > 
> > I think we're talking about Fedora Core and 3rd party repos, let's make
> > that distinction even if Fedora Core development is largely staffed with
> > Red Hat people today. My impression is that Fedora Core objectives in
> > this issue are to work inside of Core/Extras/Alternatives however these
> > are defined, anything beyond is "out of scope". That's my personal
> > opinion.
> 
> Well, the thread started about someone wanting to provide packages for
> third party repos or Extras with disttags. If you look at fedora.us,
> which is deemed ti become Fedora Extras, you will see disttags. Are
> you suggesting to remove them? fedora.us developers would not be happy
> about that.

I would leave disttags to the package maintainers discretion, perhaps
within certain limits imposed by the build system.

> > > The downside is that someone must spent a day and a half to get the
> > > build system at Red Hat to add disttags.
> > 
> > Obviously you are joking, but then you haven't seen our build system
> > yet, have you?
> 
> Of course, I am joking. OTOH there are existing buildsystems in
> various projects including ATrpms, fedora.us, Dag and probably more
> that have solved this a long time since. So it is not really rocket
> science, once a disttag scheme has been approved. Perhaps you should
> hire me ;)

You wouldn't be content with what I can offer you as a salary (speaking
strictly as a private person) ;-).

> > > Disttags are a good concept. The only thing hindering them in the
> > > Fedora/RHEL world is the choice for a specific implementation. If the
> > > vendor does not go along, you will continue to have anarchy in
> > > guidelines.
> > 
> > In my point of view, disttags serve only one purpose, namely
> > differentiating from which repository a package comes in the file name,
> > at the price of looking ugly.
> 
> Oops, I understand that we are probably talking about different
> things. What you are thinking of are "repotags" like "fr", "at",
> "dag", "ccrma", "spc", "dries" that only serve for uglyness and have
> no functionality. I am not promoting their use, they shoudl be
> considered optional and should stay out of our way (in an upgrade
> path consideration, e.g. shove them at the very end of the release tag
> if you really must so).

Understood.

> > If I were to "usurp" a package for Core, I would only want to ensure
> > upgradability for that package eventually existing in Extras, for which
> > simple integers as releases suffice, [...]
> 
> You should think outside of the Fedora Core scope where disttags are
> indeed only useful for common errata with simultaneous non-EOLed
> releases.
> 
> Projects very near to Fedora Core (not "3rd party") like Fedora Extras
> predecessor fedora.us, and fedoralegacy.org do require more often to
> have common builds differentiating in the release built against. So
> disttags are required.

Not necessarily. When discussing build systems, more than once the idea
popped up that the maintainer shouldn't care about the release and that
it would be autogenerated. These kind of build systems would be fed from
a revision control system where you would put different distro-versions
into different branches. How the build system generates release tags
from that is a matter of discussion, but nothing the package maintainer
should have to care for then.

> And as a community project you cannot keep out of scope "3rd party"
> repos. They also support multiple releases of Red Hat and Fedora and
> ths need disttags (not repotags!).

Not in my opinion.

> And really, disttags do not hurt at all. Aesthetics don't count in
> packaging, otherwise we would package foo-1.2.3-4.el3.at.i386.rpm into
> setup.exe.

Replacing ugliness with abomination here ;-)?

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040514/46a29bc3/attachment.sig>

From casimiro_barreto at uol.com.br  Fri May 14 12:16:53 2004
From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto)
Date: Fri, 14 May 2004 09:16:53 -0300
Subject: Problems with up2date
In-Reply-To: <1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
References: <20040513192800.GS29888@neu.nirvana>	<ork6zfbogj.fsf@livre.redhat.lsd.ic.unicamp.br>	<1084343991.3770.10772.camel@mccallum.corsepiu.local>	<40A1DC3E.4080506@redhat.com>
	<20040512093104.GA9771@neu.nirvana>	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<1084439431.3770.13705.camel@mccallum.corsepiu.local>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <40A4B8B5.10309@uol.com.br>

Hello,

Since 3 days ago, from the last upgrade of up2date, whenever I try to 
run it, the result is the following:

[root at 200-207-17-55 casimiro]# up2date --update
http://fedora.redhat.com/download/up2date-mirrors/fedora-core-2
using mirror: 
http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/2/i386/os/
http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc2
using mirror: http://mirror.eas.muohio.edu/fedora/linux/core/updates/2/i386/
There was a fatal error communicating with the server. The message was:
 
An HTTP error occurred:
URL: 
http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/2/i386/os//headers/header.info
Status Code: 404
Error Message: Not Found

I tried to manually download up2date from fedora and run rpm -Uvh... but 
the result is the same.

Looking for the pointed URL, it really doesn't exist (was directory 
moved without notice ???)

Regards,

Casimiro Barreto




From Axel.Thimm at ATrpms.net  Fri May 14 12:19:00 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Fri, 14 May 2004 14:19:00 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
References: <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <20040514121900.GB26108@neu.nirvana>

On Fri, May 14, 2004 at 01:37:45PM +0200, Nils Philippsen wrote:
> > Projects very near to Fedora Core (not "3rd party") like Fedora
> > Extras predecessor fedora.us, and fedoralegacy.org do require more
> > often to have common builds differentiating in the release built
> > against. So disttags are required.
> 
> Not necessarily. When discussing build systems, more than once the idea
> popped up that the maintainer shouldn't care about the release and that
> it would be autogenerated. These kind of build systems would be fed from
> a revision control system where you would put different distro-versions
> into different branches. How the build system generates release tags
> from that is a matter of discussion, but nothing the package maintainer
> should have to care for then.

Hm, I'd argue that the release tag is often quite important (the
buildid before the disttag), because it can be referred to from other
package in dependencies. E.g. when you move a file from one package to
another or have any special new releationship between packages than
need to Conflict/Require something based on the release tag.

That's another point where disttags are useful. If you fix your
package foo to foo-1.2.3-5.fc1 and foo-1.2.3-5.fc2, you can safely use
only

# foo up to 1.2.3-4 was buggy
Requires: foo >= 1.2.3-5

without mentining any disttags in the packages bar-6.7.8-9.fc1 and
bar-6.7.8-9.fc2, e.g. the disttag does not have to be mentioned in
dependencies. A scheme with manual coding of upgrade paths would
require different specfiles for bar-6.7.8-9.fc1 and bar-6.7.8-9.fc2 as
the dependencies would have to written differently.

What the buildsystem should do is add the disttags as suffixes to the
resulting rpm, so developers/packagers still only have to think about
the buildid and not the rest.

E.g. specfiles and src.rpm could stay as is in rawhide, the
buildsystem would adorne the release suffix as needed.

Later fedoralegacy in need for a security update can simply rebuild
the same package with the same buildid/specfile/src.rpm, but the
buildsystem would automatically have placed that package in a proper
upgrade path for future upgrading of the fedoralegacy build.

For example FC1 goes EOL and foo-1.2.3 has a security issue. FC3 has
foo-2.3.4-5 as foo-2.3.4-5.src.rpm and foo-2.3.4-5.fc3.i386.rpm. A
fedoralegacy packager tests whether the src.rpm rebuilds and works as
is on FC1, and if yes, simply pulls in the same source package, which
will yield foo-2.3.4-5.fc1.i386.rpm in fedoralegacy (or perhaps
fedoralegacy also uses a repotag id and this becomes
foo-2.3.4-5.fc1.lgcy.i386.rpm).

This minimizes maintainance of multiple releases at the cost of a
some little aesthetics.

(and to be honest all people are using repos like fedora.us,
freshrpms, ATrpms etc., each of which has its own interpretation of
the disharmonizing art of package naming and versioning obfuscation,
so users are hardened ;)

> > And as a community project you cannot keep out of scope "3rd party"
> > repos. They also support multiple releases of Red Hat and Fedora and
> > ths need disttags (not repotags!).
> 
> Not in my opinion.

What? Fedora is not a community project or 3rd party repos are not
within the community? :)

> > And really, disttags do not hurt at all. Aesthetics don't count in
> > packaging, otherwise we would package foo-1.2.3-4.el3.at.i386.rpm into
> > setup.exe.
> 
> Replacing ugliness with abomination here ;-)?

No, it is a psychological trick: After being shocked by uttermost
disgust disttags should look nicer, don't they? ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040514/4005c025/attachment.sig>

From rdieter at math.unl.edu  Fri May 14 12:27:11 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 14 May 2004 07:27:11 -0500
Subject: Menu Policy - please read if you maintain a package with
 a	.desktop file in it!
In-Reply-To: <1084485872.5572.13.camel@localhost.localdomain>
References: <1084485872.5572.13.camel@localhost.localdomain>
Message-ID: <40A4BB1F.6050702@math.unl.edu>

Seth Nickell wrote:

> 2) If your package is in any of the default package sets:
...
>   b) The menu item should usually be the application's
> generic/descriptive name. For example, use "Web Browser" instead of
> "Mozilla" or "Mozilla Web Browser".
> 
> 3) If your package is NOT in any of the default package sets:
>   a) The menu name should usually be the application's given name + the
> generic/descriptive name. For example, use "Mozilla Web Browser" instead
> of "Web Browser" or "Mozilla".

Why mess with names like this at all when functional equivalents exist 
*now* in .desktop files using Name and GenericName, e.g. for mozilla:
Name=Mozilla
GenericName=Web Browser

The display of these are (user) configurable (at least in KDE) whereas 
hardcoding changes as you suggest certainly are not.

-- Rex




From rms at 1407.org  Fri May 14 12:50:24 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 14 May 2004 13:50:24 +0100
Subject: Menu Policy - please read if you maintain a package with
	a	.desktop file in it!
In-Reply-To: <40A4BB1F.6050702@math.unl.edu>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<40A4BB1F.6050702@math.unl.edu>
Message-ID: <1084539024.2748.141.camel@roque>

On Fri, 2004-05-14 at 07:27 -0500, Rex Dieter wrote:
> Why mess with names like this at all when functional equivalents exist 
> *now* in .desktop files using Name and GenericName, e.g. for mozilla:
> Name=Mozilla
> GenericName=Web Browser
> 
> The display of these are (user) configurable (at least in KDE) whereas 
> hardcoding changes as you suggest certainly are not.

Because they're not using them properly, and so invent rules to work
around bugs

Name should be name and GenericName should be GenericName.

And they should be used as

  +----------------------+
  | Name  GenericName[1] |
  | Comment              |

[1] order here should respect somehow what makes sense for other
languages. maybe a field to specify invert-order is needed, like
invert-order="list of locales"

But this is a discussion for freedesktop.org's mailing lists.

Rui
-------------- 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/20040514/fda65523/attachment.sig>

From rdieter at math.unl.edu  Fri May 14 13:05:29 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 14 May 2004 08:05:29 -0500
Subject: Menu Policy - please read if you maintain a package
 with	a	.desktop file in it!
In-Reply-To: <1084539024.2748.141.camel@roque>
References: <1084485872.5572.13.camel@localhost.localdomain>	<40A4BB1F.6050702@math.unl.edu>
	<1084539024.2748.141.camel@roque>
Message-ID: <40A4C419.9070103@math.unl.edu>

Rui Miguel Seabra wrote:
> On Fri, 2004-05-14 at 07:27 -0500, Rex Dieter wrote:
> 
>>Why mess with names like this at all when functional equivalents exist 
>>*now* in .desktop files using Name and GenericName, e.g. for mozilla:
>>Name=Mozilla
>>GenericName=Web Browser
>>
>>The display of these are (user) configurable (at least in KDE) whereas 
>>hardcoding changes as you suggest certainly are not.
> 
> 
> Because they're not using them properly, and so invent rules to work
> around bugs

Who are "they"?  What bugs?

> Name should be name and GenericName should be GenericName.
> 
> And they should be used as
> 
>   +----------------------+
>   | Name  GenericName[1] |
>   | Comment              |
> 
> [1] order here should respect somehow what makes sense for other
> languages. maybe a field to specify invert-order is needed, like
> invert-order="list of locales"

I don't follow what you're saying here at all, so could you please 
elaborate for my slow moving brain this morning (probably for lack of 
coffee).

-- Rex




From carwyn at carwyn.com  Fri May 14 13:05:27 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Fri, 14 May 2004 14:05:27 +0100
Subject: Yum.conf in rawhide.
Message-ID: <40A4C417.7010404@carwyn.com>


I've just synced with devel and found this in the yum.conf.rpmnew:

distroverpkg=redhat-release

.. should this not be fedora-release?

Carwyn




From walters at redhat.com  Fri May 14 13:08:43 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 14 May 2004 09:08:43 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084500439.16881.7.camel@binkley>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
Message-ID: <1084540123.22855.9.camel@nexus.verbum.private>

On Thu, 2004-05-13 at 22:07, seth vidal wrote:

> I think that is a function of getting the menu editing working, not a
> function of setting .desktop file policy. Moreover, when a user first
> logs in - they should probably see the range of options of installed
> software, otherwise they'll probably never find the rest of it.

And you expect users to sit down when they first log in and evaluate all
the various options for software, pick one for each task?  Nobody wants
to do that.  They want one application that just works.

-------------- 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/20040514/67b5691d/attachment.sig>

From walters at redhat.com  Fri May 14 13:13:14 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 14 May 2004 09:13:14 -0400
Subject: Menu Policy - please read if you maintain a package with
	a	.desktop file in it!
In-Reply-To: <20040514062252.GA3465@ip68-4-98-123.oc.oc.cox.net>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<40A435D5.8000605@mindspring.com>
	<20040514062252.GA3465@ip68-4-98-123.oc.oc.cox.net>
Message-ID: <1084540394.22855.15.camel@nexus.verbum.private>

On Fri, 2004-05-14 at 02:22, Barry K. Nathan wrote:

> For instance, Mac OS X
> programs tend to show up in an "Applications" folder on the hard drive
> rather than in a menu. Perhaps there could be a folder, somewhat like
> this (and reachable from the "Places" menu in Nautilus) could be used to
> avoid overloading the menus. 

I think that's a good idea, personally.
-------------- 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/20040514/89555610/attachment.sig>

From rdieter at math.unl.edu  Fri May 14 13:18:57 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 14 May 2004 08:18:57 -0500
Subject: Menu Policy - please read if you maintain a package with
 a	.desktop file in it!
In-Reply-To: <1084540123.22855.9.camel@nexus.verbum.private>
References: <1084485872.5572.13.camel@localhost.localdomain>	<20040514000639.GA1123340@hiwaay.net>	<1084493474.16881.1.camel@binkley>	<1084495159.5572.20.camel@localhost.localdomain>	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
Message-ID: <40A4C741.9020702@math.unl.edu>

Colin Walters wrote:
> On Thu, 2004-05-13 at 22:07, seth vidal wrote:
> 
> 
>>I think that is a function of getting the menu editing working, not a
>>function of setting .desktop file policy. Moreover, when a user first
>>logs in - they should probably see the range of options of installed
>>software, otherwise they'll probably never find the rest of it.
> 
> 
> And you expect users to sit down when they first log in and evaluate all
> the various options for software, pick one for each task?  Nobody wants
> to do that.  They want one application that just works.

Not necessarily, but he (and I) expect to be able to make these kinds 
menu choices for ourselves, which a functional menu editor would provide.

-- Rex




From skvidal at phy.duke.edu  Fri May 14 13:21:31 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 14 May 2004 09:21:31 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084540123.22855.9.camel@nexus.verbum.private>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
Message-ID: <1084540890.16881.53.camel@binkley>


> And you expect users to sit down when they first log in and evaluate all
> the various options for software, pick one for each task?  Nobody wants
> to do that.  They want one application that just works.
> 

As opposed to what other option? Hunt around to edit their menus up?

If they don't know what's on the machine, then how are they supposed to
determine which application is best for them?

Moreover, what if they already have a preferred application? But it's
not the 'preferred one' by your standards. How are they supposed to find
it?

-sv





From skvidal at phy.duke.edu  Fri May 14 13:40:10 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 14 May 2004 09:40:10 -0400
Subject: Yum.conf in rawhide.
In-Reply-To: <40A4C417.7010404@carwyn.com>
References: <40A4C417.7010404@carwyn.com>
Message-ID: <1084542010.9636.0.camel@opus>

On Fri, 2004-05-14 at 09:05, Carwyn Edwards wrote:
> I've just synced with devel and found this in the yum.conf.rpmnew:
> 
> distroverpkg=redhat-release
> 
> .. should this not be fedora-release?
> 

No, it doesn't matter.

As it was explained to me - putting it as redhat-release means one pkg
works for fedora and rhel.

that's all I was told :)
-sv





From carwyn at carwyn.com  Fri May 14 13:52:13 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Fri, 14 May 2004 14:52:13 +0100
Subject: Yum.conf in rawhide.
In-Reply-To: <1084542010.9636.0.camel@opus>
References: <40A4C417.7010404@carwyn.com> <1084542010.9636.0.camel@opus>
Message-ID: <40A4CF0D.8000508@carwyn.com>

seth vidal wrote:
> As it was explained to me - putting it as redhat-release means one pkg
> works for fedora and rhel.

If people do want one package to check, why not follow the conventions 
set by the system-config-* packages?

system-release?

As it stands with no redhat-release in the devel rpm set $releasever is 
resolving to thin air.

Carwyn




From skvidal at phy.duke.edu  Fri May 14 13:54:22 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 14 May 2004 09:54:22 -0400
Subject: Yum.conf in rawhide.
In-Reply-To: <40A4CF0D.8000508@carwyn.com>
References: <40A4C417.7010404@carwyn.com> <1084542010.9636.0.camel@opus>
	<40A4CF0D.8000508@carwyn.com>
Message-ID: <1084542861.9636.5.camel@opus>

On Fri, 2004-05-14 at 09:52, Carwyn Edwards wrote:
> seth vidal wrote:
> > As it was explained to me - putting it as redhat-release means one pkg
> > works for fedora and rhel.
> 
> If people do want one package to check, why not follow the conventions 
> set by the system-config-* packages?
> 
> system-release?
> 
> As it stands with no redhat-release in the devel rpm set $releasever is 
> resolving to thin air.
> 

distroverpkg looks for any package named that OR anything providing
that.

fedora-release provides redhat-release.

-sv





From carwyn at carwyn.com  Fri May 14 14:06:12 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Fri, 14 May 2004 15:06:12 +0100
Subject: Yum.conf in rawhide.
In-Reply-To: <1084542861.9636.5.camel@opus>
References: <40A4C417.7010404@carwyn.com> <1084542010.9636.0.camel@opus>	
	<40A4CF0D.8000508@carwyn.com> <1084542861.9636.5.camel@opus>
Message-ID: <40A4D254.3060201@carwyn.com>

seth vidal wrote:
> distroverpkg looks for any package named that OR anything providing
> that.

Sorry, typo when merging in the new things from yum.conf.rpmnew :-)

Carwyn




From walters at redhat.com  Fri May 14 14:05:09 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 14 May 2004 10:05:09 -0400
Subject: Menu Policy - please read if you maintain a package with
	a	.desktop file in it!
In-Reply-To: <40A4C741.9020702@math.unl.edu>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<40A4C741.9020702@math.unl.edu>
Message-ID: <1084543509.23556.5.camel@nexus.verbum.private>

On Fri, 2004-05-14 at 09:18, Rex Dieter wrote:
> Colin Walters wrote:
> > On Thu, 2004-05-13 at 22:07, seth vidal wrote:
> > 
> > 
> >>I think that is a function of getting the menu editing working, not a
> >>function of setting .desktop file policy. Moreover, when a user first
> >>logs in - they should probably see the range of options of installed
> >>software, otherwise they'll probably never find the rest of it.
> > 
> > 
> > And you expect users to sit down when they first log in and evaluate all
> > the various options for software, pick one for each task?  Nobody wants
> > to do that.  They want one application that just works.
> 
> Not necessarily, but he (and I) expect to be able to make these kinds 
> menu choices for ourselves, which a functional menu editor would provide.

I'm not arguing against menu editing, I'm arguing for good defaults in
the menu.

-------------- 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/20040514/dd48059b/attachment.sig>

From skvidal at phy.duke.edu  Fri May 14 14:07:45 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 14 May 2004 10:07:45 -0400
Subject: Menu Policy - please read if you maintain a package with
	a	.desktop file in it!
In-Reply-To: <1084543509.23556.5.camel@nexus.verbum.private>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<40A4C741.9020702@math.unl.edu>
	<1084543509.23556.5.camel@nexus.verbum.private>
Message-ID: <1084543665.9636.7.camel@opus>

> > 
> > Not necessarily, but he (and I) expect to be able to make these kinds 
> > menu choices for ourselves, which a functional menu editor would provide.
> 
> I'm not arguing against menu editing, I'm arguing for good defaults in
> the menu.
> 
> 
> ______________________________________________________________________
Then I think I'm confused.

If you have good defaults, before you have editing support, how is a
user supposed to find applications that are installed by not the menu
default?

-sv





From walters at redhat.com  Fri May 14 14:09:39 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 14 May 2004 10:09:39 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084540890.16881.53.camel@binkley>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<1084540890.16881.53.camel@binkley>
Message-ID: <1084543779.23556.11.camel@nexus.verbum.private>

On Fri, 2004-05-14 at 09:21, seth vidal wrote:
> > And you expect users to sit down when they first log in and evaluate all
> > the various options for software, pick one for each task?  Nobody wants
> > to do that.  They want one application that just works.
> > 
> 
> As opposed to what other option? Hunt around to edit their menus up?

I wouldn't expect most users to edit the menu at all.  They'll just use
the default.

> If they don't know what's on the machine, then how are they supposed to
> determine which application is best for them?

Again, I don't think most users are going to want to spend time
evaluating various applications.

> Moreover, what if they already have a preferred application? But it's
> not the 'preferred one' by your standards. How are they supposed to find
> it?

If they have a preferred application, they're more of a power user. 
Probably something like the MacOS "Applications" folder would be a good
solution here, as Rex suggested.

-------------- 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/20040514/5fbe23f4/attachment.sig>

From walters at redhat.com  Fri May 14 14:11:00 2004
From: walters at redhat.com (Colin Walters)
Date: Fri, 14 May 2004 10:11:00 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084543779.23556.11.camel@nexus.verbum.private>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<1084540890.16881.53.camel@binkley>
	<1084543779.23556.11.camel@nexus.verbum.private>
Message-ID: <1084543859.23556.13.camel@nexus.verbum.private>

On Fri, 2004-05-14 at 10:09, Colin Walters wrote:

> If they have a preferred application, they're more of a power user. 
> Probably something like the MacOS "Applications" folder would be a good
> solution here, as Rex suggested.

Er, Barry I mean, sorry.

-------------- 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/20040514/c146007c/attachment.sig>

From skvidal at phy.duke.edu  Fri May 14 14:15:41 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 14 May 2004 10:15:41 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084543779.23556.11.camel@nexus.verbum.private>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<1084540890.16881.53.camel@binkley>
	<1084543779.23556.11.camel@nexus.verbum.private>
Message-ID: <1084544141.9636.11.camel@opus>


> I wouldn't expect most users to edit the menu at all.  They'll just use
> the default.

*boggle* what is the threshold to move from new user to power user - it
seems it is set a bit too low.

Just b/c someone likes a different application doesn't mean they're
skilled enough to find it buried 10 layers deep.


> Again, I don't think most users are going to want to spend time
> evaluating various applications.

Ok - so I have to ask - how many user interactions have y'all had?
(y'all == the people deciding this policy?)

I interact with users everday - more importantly users of desktop linux
systems and they pick over the apps all day until they find one they
like, then they cling to it like lichen on a cave wall.

> If they have a preferred application, they're more of a power user. 
> Probably something like the MacOS "Applications" folder would be a good
> solution here, as Rex suggested.

preferring an application makes someone a power user?

What is your scale for going from new user to power user? could you
explain it b/c I think we're working at VERY different definitions.

-sv





From pmatilai at welho.com  Fri May 14 14:29:33 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Fri, 14 May 2004 17:29:33 +0300 (EEST)
Subject: Menu Policy - please read if you maintain a package with a
 .desktop file in it!
In-Reply-To: <1084544141.9636.11.camel@opus>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<1084540890.16881.53.camel@binkley>
	<1084543779.23556.11.camel@nexus.verbum.private>
	<1084544141.9636.11.camel@opus>
Message-ID: <Pine.LNX.4.58.0405141719180.31021@chip.laiskiainen.org>

On Fri, 14 May 2004, seth vidal wrote:
> > I wouldn't expect most users to edit the menu at all.  They'll just use
> > the default.
> 
> *boggle* what is the threshold to move from new user to power user - it
> seems it is set a bit too low.

In the current situation where you have to edit xml files manually to edit 
the menus I guess the "most users dont edit the menu" stands pretty well 
:-/

> > Again, I don't think most users are going to want to spend time
> > evaluating various applications.
> 
> Ok - so I have to ask - how many user interactions have y'all had?
> (y'all == the people deciding this policy?)
> 
> I interact with users everday - more importantly users of desktop linux
> systems and they pick over the apps all day until they find one they
> like, then they cling to it like lichen on a cave wall.

Heh, nice expression :) The "most users" term bothers me here - maybe the
average secretary in corporate environment isn't interested in editing
menus or evaluating different applications but that's not the target crowd
of FC, the last I heard.

I've absolutely nothing against having sane, good defaults in the menus 
but too much of "we know whats best for you" is .. too much, especially 
considering the target group of FC, half of which are hackers and the 
rest on their way there I assume :)

	- Panu -




From jspaleta at gmail.com  Fri May 14 14:46:16 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 14 May 2004 10:46:16 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084543779.23556.11.camel@nexus.verbum.private>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<1084540890.16881.53.camel@binkley>
	<1084543779.23556.11.camel@nexus.verbum.private>
Message-ID: <604aa79104051407466516e112@mail.gmail.com>

On Fri, 14 May 2004 10:09:39 -0400, Colin Walters <walters at redhat.com> wrote:
> Again, I don't think most users are going to want to spend time
> evaluating various applications.

Don't want to...sure they dont want to. But the fact remains that
default applications that are being decided apun can be considered
at best a compromise. No one can say with authority that ALL defaults
being chosen are the best for 90% of people out there. Too many tastes
and too many apps for the 90% rule to work for all the defaults.

Most people will be fine with most defaults. Exactly 3 users in the
userbase will be completely happy with ALL the default chosen apps.
I full expect most people to feel that at least one chosen default
application is ill fitting for their needs and will go looking for an
alternative. Making it easy to find those few personalized alternative
and to incorporate those personalized choices into the establish UI
for calling apps is good design. Now... this does not require full
menu editting and control. But there must be a way...a sensible way to
promote prefered applications into the menus.

> 
> If they have a preferred application, they're more of a power user.

I don't know if I'd go that far... I would say they have been
corrupted by a power user, who got them hooked on an application. I
wouldn't call my wife a power user, but she likes galeon a lot. Its my
fault for showing to her, and now i have to make sure its on her
system or there is hell to pay.

> Probably something like the MacOS "Applications" folder would be a 
> good solution here, as Rex suggested.

UI clutter is what that is. Do we really want another way to access
applications from the gui? The fact that in mac the applictions
folders served a sort of packaging purpose as well, and mac had the
idea of the recent applictions idea, the applictions folders was a
piece of a thought out puzzle and served more than a single purpose of
keeping menus uncluttered.

I dont think implementing the Applications folder in the gnome/kde ui
makes a lot of sense since it would be solely used to push things out
of the menu and there is no corresponding recent applictions concept
to have the menu ui learn your usage habits.  If you are going to push
all the 'other' applictions besides the default into a folder view in
the file manager, you will have to have a way for the menu to learn
from that user's usage of the application folder, so the menu will
populate preferred or commonly used apps based on user habits.

The real fix to this issue is getting the menus to learn user habits. Either
get menu editting working so users can codify what they want directly
or build in some logic so that the menu structure learns from the
users habits.
Power users are going to want full control of the menus, and I would
assume that novice users would appreciate auto-population of the menus
based on application usage.

-jef




From dcbw at redhat.com  Fri May 14 14:47:36 2004
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 14 May 2004 10:47:36 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <Pine.LNX.4.58.0405141719180.31021@chip.laiskiainen.org>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<1084540890.16881.53.camel@binkley>
	<1084543779.23556.11.camel@nexus.verbum.private>
	<1084544141.9636.11.camel@opus>
	<Pine.LNX.4.58.0405141719180.31021@chip.laiskiainen.org>
Message-ID: <1084546056.9057.1.camel@dcbw.boston.redhat.com>

Hi,

Well, somebody needs to write an app that can edit the XML menu files
easily...

Dan

On Fri, 2004-05-14 at 17:29 +0300, Panu Matilainen wrote:
> On Fri, 14 May 2004, seth vidal wrote:
> > > I wouldn't expect most users to edit the menu at all.  They'll just use
> > > the default.
> > 
> > *boggle* what is the threshold to move from new user to power user - it
> > seems it is set a bit too low.
> 
> In the current situation where you have to edit xml files manually to edit 
> the menus I guess the "most users dont edit the menu" stands pretty well 
> :-/
> 
> > > Again, I don't think most users are going to want to spend time
> > > evaluating various applications.
> > 
> > Ok - so I have to ask - how many user interactions have y'all had?
> > (y'all == the people deciding this policy?)
> > 
> > I interact with users everday - more importantly users of desktop linux
> > systems and they pick over the apps all day until they find one they
> > like, then they cling to it like lichen on a cave wall.
> 
> Heh, nice expression :) The "most users" term bothers me here - maybe the
> average secretary in corporate environment isn't interested in editing
> menus or evaluating different applications but that's not the target crowd
> of FC, the last I heard.
> 
> I've absolutely nothing against having sane, good defaults in the menus 
> but too much of "we know whats best for you" is .. too much, especially 
> considering the target group of FC, half of which are hackers and the 
> rest on their way there I assume :)
> 
> 	- Panu -
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list




From jspaleta at gmail.com  Fri May 14 14:50:31 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 14 May 2004 10:50:31 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084546056.9057.1.camel@dcbw.boston.redhat.com>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<1084540890.16881.53.camel@binkley>
	<1084543779.23556.11.camel@nexus.verbum.private>
	<1084544141.9636.11.camel@opus>
	<Pine.LNX.4.58.0405141719180.31021@chip.laiskiainen.org>
	<1084546056.9057.1.camel@dcbw.boston.redhat.com>
Message-ID: <604aa7910405140750791ba2a7@mail.gmail.com>

On Fri, 14 May 2004 10:47:36 -0400, Dan Williams <dcbw at redhat.com> wrote:
> 
> Hi,
> 
> Well, somebody needs to write an app that can edit the XML menu files
> easily...
> 
> Dan

-jef"vim or emacs"spaleta




From rdieter at math.unl.edu  Fri May 14 14:51:01 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 14 May 2004 09:51:01 -0500
Subject: Menu Policy - please read if you maintain a package with
 a	.desktop file in it!
In-Reply-To: <1084546056.9057.1.camel@dcbw.boston.redhat.com>
References: <1084485872.5572.13.camel@localhost.localdomain>	<20040514000639.GA1123340@hiwaay.net>	<1084493474.16881.1.camel@binkley>	<1084495159.5572.20.camel@localhost.localdomain>	<1084500439.16881.7.camel@binkley>	<1084540123.22855.9.camel@nexus.verbum.private>	<1084540890.16881.53.camel@binkley>	<1084543779.23556.11.camel@nexus.verbum.private>	<1084544141.9636.11.camel@opus>	<Pine.LNX.4.58.0405141719180.31021@chip.laiskiainen.org>
	<1084546056.9057.1.camel@dcbw.boston.redhat.com>
Message-ID: <40A4DCD5.2030308@math.unl.edu>

Dan Williams wrote:

> Well, somebody needs to write an app that can edit the XML menu files
> easily...

Like (the omitted) kmenueditor?  (-:

-- Rex




From icon at linux.duke.edu  Fri May 14 15:00:01 2004
From: icon at linux.duke.edu (Konstantin Ryabitsev)
Date: Fri, 14 May 2004 11:00:01 -0400
Subject: Menu Policy - please read if you maintain a package with
 a	.desktop file in it!
In-Reply-To: <1084540123.22855.9.camel@nexus.verbum.private>
References: <1084485872.5572.13.camel@localhost.localdomain>	<20040514000639.GA1123340@hiwaay.net>	<1084493474.16881.1.camel@binkley>	<1084495159.5572.20.camel@localhost.localdomain>	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
Message-ID: <40A4DEF1.6040104@linux.duke.edu>

Colin Walters wrote:
> And you expect users to sit down when they first log in and evaluate all
> the various options for software, pick one for each task?  Nobody wants
> to do that.  They want one application that just works.

This works great for new users. But what about those who have been using 
the system for some time? Last year your default was application Foo. 
This year it's application Bar, with application Foo suddenly no longer 
in any menus. Do you expect the users to blindly acquiesce and switch to 
your new default choice in the middle of trying to do actual work?

Not every user will be sitting in front of your desktop for the first 
time. Some of them will be upgrading.

--icon




From veillard at redhat.com  Fri May 14 15:09:34 2004
From: veillard at redhat.com (Daniel Veillard)
Date: Fri, 14 May 2004 11:09:34 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <Pine.LNX.4.58.0405141719180.31021@chip.laiskiainen.org>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<1084540890.16881.53.camel@binkley>
	<1084543779.23556.11.camel@nexus.verbum.private>
	<1084544141.9636.11.camel@opus>
	<Pine.LNX.4.58.0405141719180.31021@chip.laiskiainen.org>
Message-ID: <20040514150934.GC1329@redhat.com>

On Fri, May 14, 2004 at 05:29:33PM +0300, Panu Matilainen wrote:
> On Fri, 14 May 2004, seth vidal wrote:
> > I interact with users everday - more importantly users of desktop linux
> > systems and they pick over the apps all day until they find one they
> > like, then they cling to it like lichen on a cave wall.
> 
> Heh, nice expression :) The "most users" term bothers me here - maybe the
> average secretary in corporate environment isn't interested in editing
> menus or evaluating different applications but that's not the target crowd
> of FC, the last I heard.

  Well I have never felt the need to change the menu myself, but that's
because I use the shell far too much. 
  In general I'm a bit vary of the concept of "normal user" vs. "power user",
because we try to make a global picture of it and I don't think it reflects
actual user behaviour. A user will learn more about an interface if there
are informations about how to change the way it interract with it. To me the
most common example is having shortcuts keystroke printed when you display
a menu, if you don't show them, 99% of the users will not learn any of them
(see how long it takes to make progresses in vi as an example). And IMHO
2 person can become more proficient in the use of a given interface even if
they take different ways to adapt their behaviour. User A may add a shortcut
to the application on the desktop, User B may add it to the menu if not present
and User C may use the "Open recent" to always get to the same document.
  The common pattern between both are:
  - that there is some user specific information associated to the interface
    to customize it to the current user way to interract with it
  - that you need some knowledge from the interface that such customization
    is possible

 IMHO Colin is right that most users won't modify the menu if there is no
easy way to do it indicated from the interface itself (IMHO a good plug would
be by within the Run Application dialog). Whether allowing the menu to be
modified to fit a given user way to interract with the interface boils down
to :
  1/ an estimate wether this would help users
  2/ how hard it would be to support this option
  3/ finding a good way to plug the support in the interface

 1/ seems to be unclear
 2/ keeping a copy of the XML should not be hard
 3/ seems not that simple.

Daniel

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




From sven at boeckelmann.org  Fri May 14 16:26:12 2004
From: sven at boeckelmann.org (Sven Boeckelmann)
Date: Fri, 14 May 2004 18:26:12 +0200
Subject: kernel panic with ivtv on amd64, firmware loading and test_ioctl
	work fine!
In-Reply-To: <1084535183.6959.43.camel@nb-boeckelmann.koeln.benelog.com>
References: <1084535183.6959.43.camel@nb-boeckelmann.koeln.benelog.com>
Message-ID: <1084551972.6970.79.camel@nb-boeckelmann.koeln.benelog.com>

hi im trying to run ivtv on an amd64-

ok, the firmware loading has been fixed.
used : http://kmos.org/~ckennedy/ivtv/ivtv-0.1.10-pre2-ck65f.tgz
to load ivtv successfully.

but the io code does not seem to be 64bit safe.

when accessing the device the kernel crashes:
when executing function ivtv_sched_DMA 

There must be someone out there who is able to check if this
is 64bit safe .. !

Thanks,
sven

PS: if someone can tell me how to save the dmesg of a crashing kernel
    i will submit the stack trace

On Fri, 2004-05-14 at 13:46, Sven Boeckelmann wrote:
> hi,
> 
> i'm trying to get ivtv working on my amd64.
> the driver is compiling on gentoo with kernel 2.6.6, gcc 3.3.3,
> module-init-tools from gentoo sys-apps/module-init-tools-3.0
> 
> 
> but when i'm doing insmod i get a modprobe Ooops:
> 
> ivtv: i2c client attach
> ivtv: i2c attach [client=saa7115[0],ok]
> ivtv: Active card count: 1.
> ivtv: Stopping VDM
> ivtv: Stopping AO
> ivtv: pinging (?) APU
> ivtv: Stopping VPU
> ivtv: Resetting Hw Blocks
> ivtv: Stopping SPU
> ivtv: Sleeping for 10ms
> ivtv: init Encoder SDRAM pre-charge
> ivtv: init Encoder SDRAM refresh to 1us
> ivtv: init Decoder SDRAM pre-charge
> ivtv: init Decoder SDRAM refresh to 1us
> ivtv: Sleeping for 600ms (600 recommended)
> ivtv: Card ready for firmware!
> ivtv: Loading encoder image
> ivtv: Loading decoder firmware
> ivtv: Sleeping for 1 sec
> ivtv: Sleeping for 1 sec
> ivtv: About to search for mailboxes
> ivtv: Searching for encoder mailbox
> ivtv: .<1>Unable to handle kernel paging request at 00000000000c8100
> RIP:
> <ffffffffa02ebdfb>{:ivtv:ivtv_find_firmware_mailbox+75}PML4 38949067 PGD
> 386ad067 PMD 0
> Oops: 0000 [1]
> CPU 0
> Pid: 5714, comm: insmod Tainted: P   2.6.6
> RIP: 0010:[<ffffffffa02ebdfb>]
> <ffffffffa02ebdfb>{:ivtv:ivtv_find_firmware_mailbox+75}RSP:
> 0018:0000010037529dc8  EFLAGS: 00010213
> RAX: ffffff00010c7fff RBX: 0000000000000000 RCX: 000000000000007f
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff80463a40
> RBP: 00000000000c8100 R08: 0000000000000034 R09: 000001003f37b0c0
> R10: 0000007fbffff3c3 R11: 0000000000000001 R12: 0000000000000000
> R13: ffffffffa02fd720 R14: 00000000005020a0 R15: 0000000000000003
> FS:  0000002a95ac9060(0000) GS:ffffffff804ce600(0000)
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000000c8100 CR3: 0000000000101000 CR4: 00000000000006e0
> Process insmod (pid: 5714, stackpage=1003e76f000)
> Stack: 0000000000000000 ffffffffa02fd720 000001003fd15000
> 0000000000000000
>        0000000000000000 ffffffffa03056b0 0000010037529e80
> 01164000381e1aa8
>        000001003ff0c3a8 ffffffff801948b1
> Call Trace:<ffffffffa03056b0>{:ivtv:ivtv_probe+1712}
> <ffffffff801948b1>{sysfs_create+113}
>        <ffffffff801951a3>{create_dir+131}
> <ffffffff8022d3cd>{pci_device_probe_static+61}
>        <ffffffff8022d419>{__pci_device_probe+25}
> <ffffffff8022d460>{pci_device_probe+48}
>        <ffffffff8028aad7>{bus_match+71}
> <ffffffff8028abf6>{driver_attach+70}
>        <ffffffff8028ae9e>{bus_add_driver+126}
> <ffffffff8028b212>{driver_register+50}
>        <ffffffff8022d68e>{pci_register_driver+62}
> <ffffffffa02ef1ac>{:ivtv:module_start+716}
>        <ffffffff80148417>{sys_init_module+263}
> <ffffffff8011141a>{system_call+126}
>         
>  
> Code: 8b 45 00 39 04 95 70 ae 2f a0 75 54 ff c3 44 8d 65 04 8d 43
> RIP <ffffffffa02ebdfb>{:ivtv:ivtv_find_firmware_mailbox+75} RSP
> <0000010037529dc8>
> CR2: 00000000000c8100
> 
> 
> i was able to track it down to this portion of the code, 
> but i guess the ivtv code is not able to 64bit at all.
> I habe been in contact with some of the ivtv developers, 
> but none of them use amd64. so it's hard for them to figure out
> where the problem is. I was hoping someone on this list can help.
>                                                                                       
> int ivtv_find_firmware_mailbox(struct ivtv *itv) {
>         u32 *searchptr, *result;
>         int match = 0;
>                                                                                       
>         searchptr = NULL;
>         result    = NULL;
>                                                                                       
>         IVTV_DEBUG(IVTV_DEBUG_INFO, "Searching for encoder mailbox\n");
>         searchptr =(u32 *)(IVTV_FIRM_SEARCH_ENCODER_START +
> itv->io_mem);
>                                                                                       
>         while (searchptr < (u32 *)(IVTV_FIRM_SEARCH_ENCODER_END +
> itv->io_mem)) {
>                 if (ivtv_firm_search_id[match] == readl(searchptr)) {
>                         (u32)result = (u32)searchptr+4; /* avoid pointer
> aritmetic */
>                         match++;
>                         while ((match > 0) && (match < 4)) {
>                                 IVTV_DEBUG(IVTV_DEBUG_INFO, "match:
> 0x%08x at "
>                                            "0x%08x. match: %d\n",
> *result,
>                                            (u32)result, match);
>                                 if (ivtv_firm_search_id[match] ==
> readl(result)) {
>                                         match++;
>                                         /* FIXME change to just
> "result++;" ? */
>                                         (u32)result =  (u32)result + 4;
>                                 }
>                                 else
>                                         match = 0;
>                         }
>                 }
>                 else {
>                         IVTV_DEBUG(IVTV_DEBUG_INFO, ".");
>                 }
>                 if ( 4 == match ) {
>                         IVTV_DEBUG(IVTV_DEBUG_INFO, "found encoder
> mailbox!\n");
> 
>                         itv->enc_mbox = (struct ivtv_mailbox *) result;
>                         break;
>                 }
>                 (u32)searchptr += IVTV_FIRM_SEARCH_STEP;
>         }
>         if (itv->enc_mbox == NULL) IVTV_DEBUG(IVTV_DEBUG_ERR, "Encoder
> mailbox not found\n");
>                                                                                       
>         IVTV_DEBUG(IVTV_DEBUG_INFO, "Searching for decoder mailbox\n");
>         match = 0;
>         searchptr = (u32 *)(IVTV_FIRM_SEARCH_DECODER_START +
> itv->io_mem);
>                                                                                       
>         while (searchptr < (u32 *)(IVTV_FIRM_SEARCH_DECODER_END +
> itv->io_mem)) {
>                 if (ivtv_firm_search_id[match] == readl(searchptr)) {
>                         (u32)result = (u32)searchptr+4;  /* avoid
> pointer aritmetic */                        match++;
>                         while ((match > 0) && (match < 4)) {
>                                 IVTV_DEBUG(IVTV_DEBUG_INFO, "match:
> 0x%08x at 0x%08x. match: %d\n",
>                                         *result, (u32)result, match);
>                                 if (ivtv_firm_search_id[match] ==
> readl(result)) {
>                                         match++;
>                                         /* FIXME change to just
> "result++;" ? */
>                                         (u32)result =  (u32)result + 4;
>                                 }
>                                 else
>                                         match = 0;
>                         }
>                 }
>                 else {
>                         IVTV_DEBUG(IVTV_DEBUG_INFO, ".");
>                 }
>                 if ( 4 == match ) {
>                         IVTV_DEBUG(IVTV_DEBUG_INFO, "found decoder
> mailbox!\n");
>                         itv->dec_mbox = (struct ivtv_mailbox *) result;
>                         break;
>                 }
>                 (u32)searchptr += IVTV_FIRM_SEARCH_STEP;
>         }
>         if (itv->dec_mbox == 0) IVTV_DEBUG(IVTV_DEBUG_ERR, "Decoder
> mailbox not found\n");
>                                                                                       
>         return 0;
> }
> 
> 
> the first time we run into the loop everything is fine,
> but after 
>  (u32)searchptr += IVTV_FIRM_SEARCH_STEP;
> is called
>  readl(searchptr) 
> causes the error.
> 
> i did a quick hack and changed it to:
>  searchptr = (u32 *) (searchptr + IVTV_FIRM_SEARCH_STEP);
> which eliminated the error.
> 
> but of course id didn't make the driver work properly :-(
> 
> no the encoder search loop works, but doesn't find a match at
>  if (ivtv_firm_search_id[match] == readl(searchptr)) {
> 
> and when we start looking for the decoder there is still the same error.
> 
> i guess there is something going wrong with ivtv->io_mem and 
> readl(searchptr).
> 
> unfortunately i don't know much about pointer and address ranges.
> I'm hoping to get in touch with one of the amd64 kernel gurus on this
> list to help us figure out how to get ivtv running on amd64.
> 
> I'm really stuck!
> 
> Cheers,
> Sven




From nphilipp at redhat.com  Fri May 14 16:47:13 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 14 May 2004 18:47:13 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040514121900.GB26108@neu.nirvana>
References: <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<20040514121900.GB26108@neu.nirvana>
Message-ID: <1084553233.19941.9.camel@gibraltar.stuttgart.redhat.com>

On Fri, 2004-05-14 at 14:19, Axel Thimm wrote:
> On Fri, May 14, 2004 at 01:37:45PM +0200, Nils Philippsen wrote:
> > > Projects very near to Fedora Core (not "3rd party") like Fedora
> > > Extras predecessor fedora.us, and fedoralegacy.org do require more
> > > often to have common builds differentiating in the release built
> > > against. So disttags are required.
> > 
> > Not necessarily. When discussing build systems, more than once the idea
> > popped up that the maintainer shouldn't care about the release and that
> > it would be autogenerated. These kind of build systems would be fed from
> > a revision control system where you would put different distro-versions
> > into different branches. How the build system generates release tags
> > from that is a matter of discussion, but nothing the package maintainer
> > should have to care for then.
> 
> Hm, I'd argue that the release tag is often quite important (the
> buildid before the disttag), because it can be referred to from other
> package in dependencies. E.g. when you move a file from one package to
> another or have any special new releationship between packages than
> need to Conflict/Require something based on the release tag.

You can always use the releasetag generated by the build system for
this.

> That's another point where disttags are useful. If you fix your
> package foo to foo-1.2.3-5.fc1 and foo-1.2.3-5.fc2, you can safely use
> only
> 
> # foo up to 1.2.3-4 was buggy
> Requires: foo >= 1.2.3-5
> 
> without mentining any disttags in the packages bar-6.7.8-9.fc1 and
> bar-6.7.8-9.fc2, e.g. the disttag does not have to be mentioned in
> dependencies. A scheme with manual coding of upgrade paths would
> require different specfiles for bar-6.7.8-9.fc1 and bar-6.7.8-9.fc2 as
> the dependencies would have to written differently.

Agreed, but this is only true in the special case where you use the same
version/release across all dists.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040514/7831bf4e/attachment.sig>

From nphilipp at redhat.com  Fri May 14 16:55:37 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 14 May 2004 18:55:37 +0200
Subject: Menu Policy - please read if you maintain a package with
	a	.desktop file in it!
In-Reply-To: <40A435D5.8000605@mindspring.com>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<40A435D5.8000605@mindspring.com>
Message-ID: <1084553737.19941.17.camel@gibraltar.stuttgart.redhat.com>

On Fri, 2004-05-14 at 04:58, Richard Hally wrote: 
> Seth Nickell wrote:
> 
> <snip>
> > 
> > This is not the same issue. You can still install whatever the hell you
> > want for your users. This is about what we treat as a default, or
> > slightly customized default, install. From the installer you can still
> > select individual packages, or go inside a package set and select one of
> > the packages that is not installed by default but is a member of that
> > set.
> > 
> > That said, the current "everything shows up in everybody's menu" way of
> > doing things is lame. That problem should be addressed head on.
> > 
> > -Seth
> > 
> 
> Once you get past that 20th century-command line mentality, you'll be 
> ok. ;) There are billions of people that use computers that never see 
> the command line: If it's not on a menu it doesn't exist.
> If I install some software it better show up on the menu. Especially if 
> I do an 'everything' install, I what to be able to find everything on a 
> menu somewhere! I guess that attitude comes from having been a GUI 
> designer/builder/programmer for several years.

I second that. In fact, I cannot help to think of the current approach
as a band-aid, to provide a reasonably sane menu structure in the light
of virtually non-existing means to edit it.

I think menu handling should ensure the following:

- Ensure a sane, uncluttered menu structure per default (current policy
would do that)
- Enable people to change the menu easily, whether in place or through a
menu editor or via the file manager needs to be discussed.
- Actually abstract the type of the application from the implementation
where that makes sense. Would make sense for e.g. web browsers to have
one "Web Browser" entry starting either the user's preferred or system
default web browser, wouldn't make sense for e.g. games. Kind of
alternatives for menu entries, but don't beat me yet ;-).

What we need IMO is basically e.g.:

- Mozilla, Galeon, Epiphany, Konqueror, ... having desktop files listing
them as web browsers (probably by GenericName or whatever though
something like AppType would be better in my eyes)
- Something defining a system wide default for each GenericName/AppType 
- Menus referencing the GenericName/AppType whatever per default
- Some means for users to override the system wide GenericName/AppType
- Some means for users to edit their menus
  - Reorganizing structure (hard)
  - Adding/Removing/Changing entries which are either generic
    applications that only call the system or user set default or
    specific apps

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040514/385b63c8/attachment.sig>

From czar at czarc.net  Fri May 14 12:48:44 2004
From: czar at czarc.net (Gene C.)
Date: Fri, 14 May 2004 08:48:44 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084497324.10851.35.camel@bree.local.net>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084497324.10851.35.camel@bree.local.net>
Message-ID: <200405140848.44680.czar@czarc.net>

On Thursday 13 May 2004 21:15, Jeremy Katz wrote:
> On Thu, 2004-05-13 at 19:06 -0500, Chris Adams wrote:
> > I understand trying to make things simpler, but I also have a problem
> > with this.  I will sometimes intentionally install multiple things (like
> > OOo and Gnumeric), with the intention of checking them both out to see
> > which one I like (or does what I want) better.  I install both from the
> > regular install menu in anaconda; with your rule above, I wouldn't end
> > up with both in the desktop menus that way.
>
> Actually, I think this would be fine as long as only one of them were
> selected as a default in anaconda.  If somebody goes to the trouble of
> clicking to turn on all of the optional things in every component, if
> the results are somewhat similar to an everything install in terms of
> having a little bit more clutter, that doesn't strike me as a horrible
> thing

I agree.  While evolution is nice, I prefer kmail and specifically select it 
for installation.  However, I also run metacity and mostly other gnome 
applications because I prefer them.  The current FC2 menus do not show kmail 
as an option in the menu ... I know how to fix this but others may not.

While some applications purely duplicate each other, others may provide a 
different style of working (kmail vs evolution) or may not work in every 
condition (Xine vs Mplayer cited by Alan).  If this effort (described in this 
thread) is intended as part of the effort to provide menu editing ... great!  
However, it should be easily possible to add or subtract items graphically.
-- 
Gene




From nphilipp at redhat.com  Fri May 14 16:59:03 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 14 May 2004 18:59:03 +0200
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084543779.23556.11.camel@nexus.verbum.private>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<1084540890.16881.53.camel@binkley>
	<1084543779.23556.11.camel@nexus.verbum.private>
Message-ID: <1084553943.19941.22.camel@gibraltar.stuttgart.redhat.com>

On Fri, 2004-05-14 at 16:09, Colin Walters wrote:
> On Fri, 2004-05-14 at 09:21, seth vidal wrote:
> > > And you expect users to sit down when they first log in and evaluate all
> > > the various options for software, pick one for each task?  Nobody wants
> > > to do that.  They want one application that just works.
> > > 
> > 
> > As opposed to what other option? Hunt around to edit their menus up?
> 
> I wouldn't expect most users to edit the menu at all.  They'll just use
> the default.

This is only true for "mere users" in the sense as the car drivers who
wouldn't change their tires by themselves. You are ignoring all those
who use e.g. enlightenment because it's so 733T, something else only
because it's different... By your reasoning nobody on Windows would use
anything besides IE which is just plain wrong (thankfully).

> > If they don't know what's on the machine, then how are they supposed to
> > determine which application is best for them?
> 
> Again, I don't think most users are going to want to spend time
> evaluating various applications.

Again, you are looking at a very limited set of users.

> > Moreover, what if they already have a preferred application? But it's
> > not the 'preferred one' by your standards. How are they supposed to find
> > it?
> 
> If they have a preferred application, they're more of a power user. 
> Probably something like the MacOS "Applications" folder would be a good
> solution here, as Rex suggested.

ACK.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040514/b64de347/attachment.sig>

From davej at redhat.com  Fri May 14 17:38:42 2004
From: davej at redhat.com (Dave Jones)
Date: Fri, 14 May 2004 18:38:42 +0100
Subject: kernel panic with ivtv on amd64, firmware loading and
	test_ioctl work fine!
In-Reply-To: <1084551972.6970.79.camel@nb-boeckelmann.koeln.benelog.com>
References: <1084535183.6959.43.camel@nb-boeckelmann.koeln.benelog.com>
	<1084551972.6970.79.camel@nb-boeckelmann.koeln.benelog.com>
Message-ID: <1084556321.30907.2.camel@delerium.codemonkey.org.uk>

On Fri, 2004-05-14 at 17:26, Sven Boeckelmann wrote:
> hi im trying to run ivtv on an amd64-
> 
> ok, the firmware loading has been fixed.
> used : http://kmos.org/~ckennedy/ivtv/ivtv-0.1.10-pre2-ck65f.tgz
> to load ivtv successfully.
> 
> but the io code does not seem to be 64bit safe.
> 
> when accessing the device the kernel crashes:
> when executing function ivtv_sched_DMA 
> 
> There must be someone out there who is able to check if this
> is 64bit safe .. !

It isn't.  It's casting addresses around as u32's which
is totally wrong. On a 64bit machine, this will chop
the upper 32 bits off a pointer.

	Dave




From feliciano.matias at free.fr  Fri May 14 21:18:23 2004
From: feliciano.matias at free.fr (Matias Feliciano)
Date: Fri, 14 May 2004 23:18:23 +0200
Subject: Menu Policy - please read if you maintain a package with
	a	.desktop file in it!
In-Reply-To: <20040514062252.GA3465@ip68-4-98-123.oc.oc.cox.net>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<40A435D5.8000605@mindspring.com>
	<20040514062252.GA3465@ip68-4-98-123.oc.oc.cox.net>
Message-ID: <1084569503.24986.51.camel@localhost.localdomain>

Sorry for my poor english.

Le ven 14/05/2004 ? 08:22, Barry K. Nathan a ?crit :
> (snip)
> Or perhaps there could be a "Show More Programs"/"Show Fewer Programs"
> toggle in the menu,

What i want seem "simple" to me.
I want a flag per Program :
Extra_flag : true|false
The default is set by RedHat/Fedora.

No "real" menu editing.

If Extra_flag is set to "true", the program is placed in an extra menu.

The extra menu can be like the one RH8.0 provided.

Extra menu can also be an entry at the top of the Gnome menu.

Exemple for system-config-bind and gucharmap (in French here).
system-config-bind : Extra_flag = false
gucharmap : Extra_flag = false
- gnome menu
	- accessoires
		- Calculatrice
		- Table de caract?res (gucharmap)
        - param?tres syst?me
                - param?tres de serveur
                	- service de nom de domaine (system-config-bind)
                - ?cran de connexion

Now suppose "Extra_flag = true" for system-config-bind and gucharmap :
- gnome menu
	- accessoires
		- Calculatrice
        - param?tres syst?me
                - ?cran de connexion
	- extra
		- accessoires
			- Table de caract?res
        	- param?tres syst?me
                        - param?tres de serveur
                        	- service de nom de domaine

Or with the layout of RH8.0
- gnome menu
	- accessoires
		- Calculatrice
		- extra
        		- Table de caract?res
        - param?tres syst?me
                - param?tres de serveur
                	- extra
                        	- service de nom de domaine
                - ?cran de connection

The extra_flag can be set by a contextual menu :
- "move to extra menu"
- "move to main menu"


> which would explode the menu with everything that's
> installed or trim it back down to the Red Hat defaults. This would be
> sort of like the little menu expansion tab thingies in Windows ME/XP,
> except it would not attempt to adapt itself to the user, and perhaps
> would be less annoying as a result.

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

From simon at sxw.org.uk  Fri May 14 21:47:04 2004
From: simon at sxw.org.uk (Simon Wilkinson)
Date: Fri, 14 May 2004 22:47:04 +0100
Subject: systematic Kerberization
Message-ID: <40A53E58.8060001@sxw.org.uk>

I'm coming somewhat late to this party, having been pointed at the 
discussion by a colleague. Apologies for the length of this mail.

I developed the authentication and directory services infrastructure for 
the Division of Informatics at the University of Edinburgh, as part of 
this work I wrote the SSHv2 GSSAPI implementation in OpenSSH, along with 
investigating and patching numerous other pieces of Kerberos code. 
Laptops are a key part of the computing infrastructure here, and we have 
looked into the disconnected authentication problem in some detail.

The key missing piece, for us, is web applications. There are a number 
of solutions floating around, from that recently implemented in Mozilla 
(Microsoft's Negotiate solution), to UMICH's kx509 technology. 
Unforunately, most web applications use their own in built 
authentication methods, making it hard to substitute new technologies. 
In addition, delegation is of critical importance to services which 
interface against other Kerberized backends (webmail, for example), and 
doesn't appear to be cleanly supported by any of the current solutions.

Its also critical to assess the correctness of a given applications 
Kerberos implementation. There are 'Kerberised protocols' which merely 
perform a Kerberos handshake upon connection establishment, and then 
allow the rest of the conversation to occur unprotected. These are 
obviously vulnerable to MITM attacks unless carried over an already 
encrypted _and authenticated_ channel. (HTTP Negotiate, and postgres's 
Kerberos authentication are both examples of this).

The killer application is probably still email. It would be good to see 
a wide spread of Kerberised IMAP and POP clients, along with MUAs which 
support SMTP-AUTH. The criticial application here for us is Mozilla.

CUPS is worrying, as it seems that the authentication options are a step 
  backwards from those available with LPRng.

The SSH support that's now in OpenSSH is suitable for small sites, but 
the lack of key exchange makes it hard to deploy over large sites, who 
are trying to avoid having to manage yet another set of key material. 
I'm trying to find the time at present to update my key exchange patches 
to both the newest releast of the I-D, and the current OpenSSH code base.

It would also be really nice to have a better solution for securing the 
nss -> LDAP server link with GSSAPI. Ideally, it would be possible to 
run a caching daemon on each machine which would manage Kerberos 
credentials for contacting the LDAP server, which the nss libraries 
would go through to gain access.

Onto disconnected operation ...

Locally, we've put a lot of time and effort into making disconnected use 
of our machines 'just work'. From an authentication and directory 
services point of view we've got fairly far along that path.

We take the view that there are two different 'tokens' that a user must 
have in order to access a machine - the first provides local access, and 
the second to network services. At the moment, these 'tokens' are 
identical - the user has the same password for both local and network 
access.

The decision to combine the two was arrived at for operational and 
usability reasons. We can envisage having a large number of disconnected 
machines, possibly more than one per user. Expecting users to remember 
different 'local' passwords for every machine and to change them all at 
the same time seemed like a nightmare. In addition, managing these local 
accounts centrally means that its easier to guarantee that password 
strength requirements are met.

We provide a tool for renewing credentials which works like 'kinit', but 
uses the PAM stack in order to allow the chaining of other 
authentication mechanisms (such as kx509). Users who have logged in 
whilst their machine is disconnected must use it after reconnecting 
their machine, and before accessing network resources.

Disconnected directory services are a hard problem, which I don't think 
we've got right yet. We currently mirror substantial chunks of our LDAP 
service to the local machine, which just isn't scalable as the volume of 
directory information grows. However, not having it there creates 
problems when increasing chunks of the machine depend on it.

Hope all thats of use!

Cheers,

Simon.





From feliciano.matias at free.fr  Fri May 14 21:51:09 2004
From: feliciano.matias at free.fr (Matias Feliciano)
Date: Fri, 14 May 2004 23:51:09 +0200
Subject: Menu Policy - please read if you maintain a package with
	a	.desktop file in it!
In-Reply-To: <1084569503.24986.51.camel@localhost.localdomain>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<40A435D5.8000605@mindspring.com>
	<20040514062252.GA3465@ip68-4-98-123.oc.oc.cox.net>
	<1084569503.24986.51.camel@localhost.localdomain>
Message-ID: <1084571468.22084.60.camel@localhost.localdomain>

Le ven 14/05/2004 ? 23:18, Matias Feliciano a ?crit :
> 
> The extra_flag can be set by a contextual menu :
> - "move to extra menu"
> - "move to main menu"
> 

This should also be great if a user who don't know the root password can
say "move the folder "system paramter" to extra". Same with the
"programming" folder.

He can also do "move to extra menu" the folder "preference" after he set
his preference.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040514/d71ab04b/attachment.sig>

From loony at loonybin.org  Fri May 14 22:21:39 2004
From: loony at loonybin.org (Peter Arremann)
Date: Fri, 14 May 2004 18:21:39 -0400
Subject: Kudzu issue
Message-ID: <20040514222139.GA8539@loonybin.org>

Hi,

we've a couple of different systems here that all experience the same
problem - Network cards get configured correctly during the install
but when you reboot, the devices get re-detected every time. We've
been able to reproduce the problem with the KT600 integrated VIA-Rhine
and realtek 8139 cards. 

I've looked at the issue quite a bit and the problem seems to be that
the ioctl calls for the hwaddress detection fail if the interface is not
up. You can verify that by booting the system in single user mode, loading
the drivers by hand and then run kudzu. it will try to reconfigure the 
device. Ignore that. Then use ifconfig to up the device (no IP required)
and then rerun kudzu.. it should work this time - at least on the 2 cards
I've tried that fixed the problem.

The code that acutally fails is in kudzu.c getNetInfo (790-810). I've no
problems fixing it and sending in a patch but to do so I'd like to 

A) Know that this really is the issue and if it happens on other cards.
B) The best way of fixing this. I see several options...
  1) Have a list of drivers (the driver is known at that time) that
     can't handle this ioctl call and then just not detect the hwaddress
  2) Have a list of drivers and just bring the interface up if it isnt
  3) Just simply gracefully fail and make an entry in the netdev list that
     is returned by getNetInfo with a special null entry for the hw address
     and then modify the compareDevices code to handle that special value.

Any input/ideas?

Peter.




From nathanael at gnat.ca  Fri May 14 23:01:39 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Fri, 14 May 2004 16:01:39 -0700
Subject: Kudzu issue
In-Reply-To: <20040514222139.GA8539@loonybin.org>
Message-ID: <A867E690-A5FA-11D8-BF75-0003931B4D6A@gnat.ca>


On Friday, May 14, 2004, at 03:21 PM, Peter Arremann wrote:

> Hi,
>
> we've a couple of different systems here that all experience the same
> problem - Network cards get configured correctly during the install
> but when you reboot, the devices get re-detected every time. We've
> been able to reproduce the problem with the KT600 integrated VIA-Rhine
> and realtek 8139 cards.
>
> I've looked at the issue quite a bit and the problem seems to be that
> the ioctl calls for the hwaddress detection fail if the interface is 
> not
> up. You can verify that by booting the system in single user mode, 
> loading
> the drivers by hand and then run kudzu. it will try to reconfigure the
> device. Ignore that. Then use ifconfig to up the device (no IP 
> required)
> and then rerun kudzu.. it should work this time - at least on the 2 
> cards
> I've tried that fixed the problem.
>
> The code that acutally fails is in kudzu.c getNetInfo (790-810). I've 
> no
> problems fixing it and sending in a patch but to do so I'd like to
>
> A) Know that this really is the issue and if it happens on other cards.

I'm not sure about Fedora, but I have 10 machines that I installed RHEL 
clones ( Whitebox & Tao) on, they experience this same problem, not a 
single machine is identical, though there are many similar cards (at 
least similar modules ie realtek etc..) I've turned kudzu off because 
of this.

I didn't know fedora had this same problem. I had a couple machines as 
fedora, and still have one dev machine as it though it has been off for 
quite awhile because of other priorities.

-- 
Nathanael D. Noblet
Gnat Solutions
412 - 135 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/




From loony at loonybin.org  Sat May 15 00:08:35 2004
From: loony at loonybin.org (Peter Arremann)
Date: Fri, 14 May 2004 20:08:35 -0400
Subject: Kudzu issue
In-Reply-To: <A867E690-A5FA-11D8-BF75-0003931B4D6A@gnat.ca>
References: <A867E690-A5FA-11D8-BF75-0003931B4D6A@gnat.ca>
Message-ID: <200405142008.36187.loony@loonybin.org>

On Friday 14 May 2004 19:01, Nathanael Noblet wrote:
> I'm not sure about Fedora, but I have 10 machines that I installed RHEL
> clones ( Whitebox & Tao) on, they experience this same problem, not a
> single machine is identical, though there are many similar cards (at
> least similar modules ie realtek etc..) I've turned kudzu off because
> of this.
>
> I didn't know fedora had this same problem. I had a couple machines as
> fedora, and still have one dev machine as it though it has been off for
> quite awhile because of other priorities.

Hi,

I've the same problem with kudzu on Centos (RHEL 3.0 respin) and Fedora... 
This list is just listed as the right place to ask on the kudzu webpage :-)

Peter.




From hp at redhat.com  Sat May 15 02:51:14 2004
From: hp at redhat.com (Havoc Pennington)
Date: Fri, 14 May 2004 22:51:14 -0400
Subject: Menu Policy - please read if you maintain a package with
	a	.desktop file in it!
In-Reply-To: <1084553737.19941.17.camel@gibraltar.stuttgart.redhat.com>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<40A435D5.8000605@mindspring.com>
	<1084553737.19941.17.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <1084589474.2878.14.camel@localhost.localdomain>

On Fri, 2004-05-14 at 12:55, Nils Philippsen wrote:
> - Enable people to change the menu easily, whether in place or through a
> menu editor or via the file manager needs to be discussed.

I'd say just right-click the menu button, choose "Add or Remove
Applications" or something.

> - Actually abstract the type of the application from the implementation
> where that makes sense. Would make sense for e.g. web browsers to have
> one "Web Browser" entry starting either the user's preferred or system
> default web browser, wouldn't make sense for e.g. games. Kind of
> alternatives for menu entries, but don't beat me yet ;-).

Would be kind of nice as an extension of the Preferred Applications
concept, but it's probably not worth the effort it involves - it'd be a
fair bit of engineering to make this go. And all you really gain is that
if you prefer Galeon your Galeon menu item says "Web Browser" instead of
"Galeon Web Browser"

I guess the bigger win would be to be able to change one place and
modify our default browser, if you're an admin who wants users to have a
different browser. Right now you have to modify the panel configuration
(not for the faint of heart), the Preferred Applications setting, and
also the MIME association, or so.

> - Some means for users to edit their menus
>   - Reorganizing structure (hard)
>   - Adding/Removing/Changing entries which are either generic
>     applications that only call the system or user set default or
>     specific apps

A simple "Add or Remove Applications" dialog that just lists all the
apps in the menu with a check box for whether to show it would be pretty
easy. It'd be nice to see someone write that. The app would just add
include/exclude entries to the XML file.

The GUI for structure rearrangement is a lot more work, and not all that
high value for end users. Admins and geeks who want to do this (e.g. to
just kill all the subfolders and have a flat list of a few items, or
whatever) should be able to edit the text files (the new format is
fairly rational and well-documented, at least I feel it is ;-)). 

Not to discourage someone who wants to write the code for structure
rearrangement, if someone wants to try. ;-)

Havoc





From paul at gear.dyndns.org  Sat May 15 06:09:43 2004
From: paul at gear.dyndns.org (Paul Gear)
Date: Sat, 15 May 2004 16:09:43 +1000
Subject: Module symbol versions in installer kernel
Message-ID: <40A5B427.4050704@gear.dyndns.org>

Hi folks,

I'm very sorry to bother you all with this, but i've asked this before
and never received an answer: what controls the presence or absence of
module symbol versions in the FC1 installer kernel?

I have a module that works fine after install, but can't be used in the
installer (either by plain insmod or by creating a driver disk) due to
the fact that it is looking for versioned module symbols that aren't there.

I have read all of the documentation i can find on this, but can't find
anything relevant in my searches due to the fact that the keywords are
too common and thus the results are not specific enough.

Could you please spare me a couple of minutes to explain what is going
on or point me to some relevant documentation?

Thanks,
Paul
http://paulgear.webhop.net
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my email reply *below* the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040515/9dd0ec28/attachment.sig>

From jkeating at j2solutions.net  Sat May 15 06:29:36 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 14 May 2004 23:29:36 -0700
Subject: Module symbol versions in installer kernel
In-Reply-To: <40A5B427.4050704@gear.dyndns.org>
References: <40A5B427.4050704@gear.dyndns.org>
Message-ID: <200405142329.39309.jkeating@j2solutions.net>

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

On Friday 14 May 2004 23:09, Paul Gear wrote:
> I have a module that works fine after install, but can't be used in the
> installer (either by plain insmod or by creating a driver disk) due to
> the fact that it is looking for versioned module symbols that aren't
> there.
>
> I have read all of the documentation i can find on this, but can't find
> anything relevant in my searches due to the fact that the keywords are
> too common and thus the results are not specific enough.
>
> Could you please spare me a couple of minutes to explain what is going
> on or point me to some relevant documentation?

When a kernel module is compiled, part of the compilation is to check the 
kernel version that it is compiling against and set that in the module 
information.  Modules can only be loaded into kernels that they are 
compiled for.  The installer uses one kernel version (uname to find out), 
while the installed system uses another.  Thus, your module that works in 
the installed system will not load in the installer.  So, you need to 
build your module against a kernel source tree that is A) configured for 
the install time kernel, and B) has the version set to such in the top 
level Makefile.

I hope this clears it up a bit for you.

- -- 
Jesse Keating RHCE	(http://geek.j2solutions.net)
Fedora Legacy Team	(http://www.fedoralegacy.org)
GPG Public Key		(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFApbjT4v2HLvE71NURApaKAJ9YiV8EDCuqmxuHlXWiDn2LQjpiJQCfa0nw
AGw20OlgcifyiWDp87HWLaw=
=y4NC
-----END PGP SIGNATURE-----




From Axel.Thimm at ATrpms.net  Sat May 15 07:29:07 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 15 May 2004 09:29:07 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <1084553233.19941.9.camel@gibraltar.stuttgart.redhat.com>
References: <1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<20040514121900.GB26108@neu.nirvana>
	<1084553233.19941.9.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <20040515072907.GA10224@neu.nirvana>

On Fri, May 14, 2004 at 06:47:13PM +0200, Nils Philippsen wrote:
> On Fri, 2004-05-14 at 14:19, Axel Thimm wrote:
> > On Fri, May 14, 2004 at 01:37:45PM +0200, Nils Philippsen wrote:
> > > > Projects very near to Fedora Core (not "3rd party") like Fedora
> > > > Extras predecessor fedora.us, and fedoralegacy.org do require more
> > > > often to have common builds differentiating in the release built
> > > > against. So disttags are required.
> > > 
> > > Not necessarily. When discussing build systems, more than once the idea
> > > popped up that the maintainer shouldn't care about the release and that
> > > it would be autogenerated. These kind of build systems would be fed from
> > > a revision control system where you would put different distro-versions
> > > into different branches. How the build system generates release tags
> > > from that is a matter of discussion, but nothing the package maintainer
> > > should have to care for then.
> > 
> > Hm, I'd argue that the release tag is often quite important (the
> > buildid before the disttag), because it can be referred to from other
> > package in dependencies. E.g. when you move a file from one package to
> > another or have any special new releationship between packages than
> > need to Conflict/Require something based on the release tag.
> 
> You can always use the releasetag generated by the build system for
> this.

If it is coming from an SCM and is immediatly retrievable, it's OK. If
you had to wait for a rawhide build to see your release tag to use in
further dependencies that would be less useful.

> > That's another point where disttags are useful. If you fix your
> > package foo to foo-1.2.3-5.fc1 and foo-1.2.3-5.fc2, you can safely use
> > only
> > 
> > # foo up to 1.2.3-4 was buggy
> > Requires: foo >= 1.2.3-5
> > 
> > without mentining any disttags in the packages bar-6.7.8-9.fc1 and
> > bar-6.7.8-9.fc2, e.g. the disttag does not have to be mentioned in
> > dependencies. A scheme with manual coding of upgrade paths would
> > require different specfiles for bar-6.7.8-9.fc1 and bar-6.7.8-9.fc2 as
> > the dependencies would have to written differently.
> 
> Agreed, but this is only true in the special case where you use the same
> version/release across all dists.

That's exactly what disttags are good for. And it is not a too special
case outside of Red Hat. Almost all 3rd party repos support more than
one release and package the same upstream version/same patches
multiple times. The closest examples are fedora.us and
fedoralegacy. Both these projects and the rest of the repos would
benefit greatly from a canonical introduction of disttags.

And there is no drawback (aesthetics put aside, but we have already
lost the beauty price, so let's try for the technology award ;).
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040515/7f27b759/attachment.sig>

From paul at gear.dyndns.org  Sat May 15 07:52:35 2004
From: paul at gear.dyndns.org (Paul Gear)
Date: Sat, 15 May 2004 17:52:35 +1000
Subject: Module symbol versions in installer kernel
In-Reply-To: <200405142329.39309.jkeating@j2solutions.net>
References: <40A5B427.4050704@gear.dyndns.org>
	<200405142329.39309.jkeating@j2solutions.net>
Message-ID: <40A5CC43.5080509@gear.dyndns.org>

Jesse Keating wrote:
> ...
> When a kernel module is compiled, part of the compilation is to check the 
> kernel version that it is compiling against and set that in the module 
> information.  Modules can only be loaded into kernels that they are 
> compiled for.  The installer uses one kernel version (uname to find out), 
> while the installed system uses another.  Thus, your module that works in 
> the installed system will not load in the installer.  So, you need to 
> build your module against a kernel source tree that is A) configured for 
> the install time kernel, and B) has the version set to such in the top 
> level Makefile.
> 
> I hope this clears it up a bit for you.

Not really.  :-)

I know that it has to match the kernel version.  The kernel in the FC1
installer is 2.4.22-1.2115.nptl, and this is the kernel i built the
driver against after install.  (I've just confirmed this again by
running uname -a under both the installer and the default kernel after
install.)

The issue is not with the kernel version, but with module symbol
versioning, which from what i've been able to work out so far is a way
of making sure you have compatible versions of modules within the same
kernel version.

This seems to be an option at kernel/module compile time - problem is, i
can't work out where.  The option seems to be turned off in the
installer kernel, and on in the installed kernel.

-- 
Paul
http://paulgear.webhop.net
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my email reply *below* the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040515/d4fc1c18/attachment.sig>

From arjanv at redhat.com  Sat May 15 09:17:55 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sat, 15 May 2004 11:17:55 +0200
Subject: Module symbol versions in installer kernel
In-Reply-To: <40A5CC43.5080509@gear.dyndns.org>
References: <40A5B427.4050704@gear.dyndns.org>
	<200405142329.39309.jkeating@j2solutions.net>
	<40A5CC43.5080509@gear.dyndns.org>
Message-ID: <1084612675.2781.2.camel@laptop.fenrus.com>


> 
> I know that it has to match the kernel version.  The kernel in the FC1
> installer is 2.4.22-1.2115.nptl, and this is the kernel i built the
> driver against after install.  (I've just confirmed this again by
> running uname -a under both the installer and the default kernel after
> install.)

but it's not the same architecture/config.


-------------- 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/20040515/15a11d0b/attachment.sig>

From buildsys at redhat.com  Sat May 15 10:21:41 2004
From: buildsys at redhat.com (Build System)
Date: Sat, 15 May 2004 06:21:41 -0400
Subject: rawhide report: 20040515 changes
Message-ID: <200405151021.i4FALfT24477@porkchop.devel.redhat.com>

 

 
Updated Packages:

fedora-release-2-rawhide
------------------------

rpmdb-fedora-2-0.20040515
-------------------------




From paul at gear.dyndns.org  Sat May 15 10:29:53 2004
From: paul at gear.dyndns.org (Paul Gear)
Date: Sat, 15 May 2004 20:29:53 +1000
Subject: Module symbol versions in installer kernel
In-Reply-To: <1084612675.2781.2.camel@laptop.fenrus.com>
References: <40A5B427.4050704@gear.dyndns.org>	<200405142329.39309.jkeating@j2solutions.net>	<40A5CC43.5080509@gear.dyndns.org>
	<1084612675.2781.2.camel@laptop.fenrus.com>
Message-ID: <40A5F121.2050608@gear.dyndns.org>

Arjan van de Ven wrote:
>>I know that it has to match the kernel version.  The kernel in the FC1
>>installer is 2.4.22-1.2115.nptl, and this is the kernel i built the
>>driver against after install.  (I've just confirmed this again by
>>running uname -a under both the installer and the default kernel after
>>install.)
> 
> 
> but it's not the same architecture/config.

Now we're getting somewhere.  :-)

Would you mind elaborating on that a little?
-- 
Paul
http://paulgear.webhop.net
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my email reply *below* the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040515/bb72fd77/attachment.sig>

From arjanv at redhat.com  Sat May 15 11:45:20 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sat, 15 May 2004 13:45:20 +0200
Subject: Module symbol versions in installer kernel
In-Reply-To: <40A5F121.2050608@gear.dyndns.org>
References: <40A5B427.4050704@gear.dyndns.org>
	<200405142329.39309.jkeating@j2solutions.net>
	<40A5CC43.5080509@gear.dyndns.org>
	<1084612675.2781.2.camel@laptop.fenrus.com>
	<40A5F121.2050608@gear.dyndns.org>
Message-ID: <1084621520.2781.6.camel@laptop.fenrus.com>

On Sat, 2004-05-15 at 12:29, Paul Gear wrote:
> Arjan van de Ven wrote:
> >>I know that it has to match the kernel version.  The kernel in the FC1
> >>installer is 2.4.22-1.2115.nptl, and this is the kernel i built the
> >>driver against after install.  (I've just confirmed this again by
> >>running uname -a under both the installer and the default kernel after
> >>install.)
> > 
> > 
> > but it's not the same architecture/config.
> 
> Now we're getting somewhere.  :-)
> 
> Would you mind elaborating on that a little?

the installer uses kernel-BOOT for floppies and (I think this changed)
the i586 kernel for the cd based installs (note: prior to fc1 this was
also the kernel-BOOT kernel). If you have a recentish intel/amd cpu then
the installed kernel will be the i686 kernel. They're all different in
config, and you can't use a module build for one into the other. 
(For the config files see the configs/ directory as part of the
kernel-source package)
-------------- 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/20040515/9e290235/attachment.sig>

From mattdm at mattdm.org  Sat May 15 14:19:52 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 15 May 2004 10:19:52 -0400
Subject: Module symbol versions in installer kernel
In-Reply-To: <1084621520.2781.6.camel@laptop.fenrus.com>
References: <40A5B427.4050704@gear.dyndns.org>
	<200405142329.39309.jkeating@j2solutions.net>
	<40A5CC43.5080509@gear.dyndns.org>
	<1084612675.2781.2.camel@laptop.fenrus.com>
	<40A5F121.2050608@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
Message-ID: <20040515141952.GA23909@jadzia.bu.edu>

On Sat, May 15, 2004 at 01:45:20PM +0200, Arjan van de Ven wrote:
> the installer uses kernel-BOOT for floppies and (I think this changed)
> the i586 kernel for the cd based installs (note: prior to fc1 this was
> also the kernel-BOOT kernel). If you have a recentish intel/amd cpu then

I was wondering about this. Is it still the case that i586 performs _worse_
on non-original-Pentium systems than i386? (Or is that wrong in the first
place, or not relevant to kernels?)

Which brings up this question: are there any i586 systems out there with
enough RAM to run anaconda anyway?


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




From jkeating at j2solutions.net  Sat May 15 15:41:17 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 15 May 2004 08:41:17 -0700
Subject: Module symbol versions in installer kernel
In-Reply-To: <20040515141952.GA23909@jadzia.bu.edu>
References: <40A5B427.4050704@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
Message-ID: <200405150841.17369.jkeating@j2solutions.net>

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

On Saturday 15 May 2004 07:19, Matthew Miller wrote:
> I was wondering about this. Is it still the case that i586 performs
> _worse_ on non-original-Pentium systems than i386? (Or is that wrong in
> the first place, or not relevant to kernels?)

Yes, as far as I know.

> Which brings up this question: are there any i586 systems out there with
> enough RAM to run anaconda anyway?

Yes, plenty of them.  The base issue is that things like nptl and such 
aren't available in an i386 kernel anymore, which is what the installer 
used to use.  So the installer has to use the next step up that supports 
everything needed, which would be i586.  Sure they could use i686 and be 
somwhat faster, but that would leave a lot of people out there unable to 
install.

- -- 
Jesse Keating RHCE	(http://geek.j2solutions.net)
Fedora Legacy Team	(http://www.fedoralegacy.org)
GPG Public Key		(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFApjod4v2HLvE71NURAs7BAJ41HoMdd94d9ToCW4+H1iCPHFdFagCeNkkC
TcTTvYMHL1zrlrC9VQ7Zk4w=
=o7IJ
-----END PGP SIGNATURE-----




From jkeating at j2solutions.net  Sat May 15 15:42:26 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 15 May 2004 08:42:26 -0700
Subject: Module symbol versions in installer kernel
In-Reply-To: <40A5F121.2050608@gear.dyndns.org>
References: <40A5B427.4050704@gear.dyndns.org>
	<1084612675.2781.2.camel@laptop.fenrus.com>
	<40A5F121.2050608@gear.dyndns.org>
Message-ID: <200405150842.26740.jkeating@j2solutions.net>

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

On Saturday 15 May 2004 03:29, Paul Gear wrote:
> Now we're getting somewhere.  :-)
>
> Would you mind elaborating on that a little?

If you look in /usr/src/linux-2.6/configs/  you will see a lot of config 
files for different archs.  If you're installing off of CD, the install 
kernel is the same version, but built for i586, and not i686.  Thus you 
must build your module against a i586 configured kernel source tree.

- -- 
Jesse Keating RHCE	(http://geek.j2solutions.net)
Fedora Legacy Team	(http://www.fedoralegacy.org)
GPG Public Key		(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFApjpi4v2HLvE71NURAkiHAJkBUgo4ivr/oriDfW6xoVMD1+4ALwCffWid
n3UbUf5m1Q9oYPdGWJBJy9M=
=b9HF
-----END PGP SIGNATURE-----




From pmatilai at welho.com  Sat May 15 15:41:43 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Sat, 15 May 2004 18:41:43 +0300 (EEST)
Subject: Menu Policy - please read if you maintain a package with a
 .desktop file in it!
In-Reply-To: <1084589474.2878.14.camel@localhost.localdomain>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<40A435D5.8000605@mindspring.com>
	<1084553737.19941.17.camel@gibraltar.stuttgart.redhat.com>
	<1084589474.2878.14.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0405151834270.1906@chip.laiskiainen.org>

On Fri, 14 May 2004, Havoc Pennington wrote:
> 
> Would be kind of nice as an extension of the Preferred Applications
> concept, but it's probably not worth the effort it involves - it'd be a
> fair bit of engineering to make this go. And all you really gain is that
> if you prefer Galeon your Galeon menu item says "Web Browser" instead of
> "Galeon Web Browser"
> 
> I guess the bigger win would be to be able to change one place and
> modify our default browser, if you're an admin who wants users to have a
> different browser. Right now you have to modify the panel configuration
> (not for the faint of heart), the Preferred Applications setting, and
> also the MIME association, or so.

Having a general framework for preferred applications without kludges like
htmlview which "everything" honors would pretty much make this whole
discussion irrelevant. I really don't want to see 5 different email
clients and 7 different browsers in the menus, regardless of what's
installed. What I want is to have "Web browser", "Email", "Text editor"  
etc generic functionality descriptions in the menus and only change it
*once* in *one* place where I can pick up my preferred browser or editor
etc from everything that's installed (or maybe even available) and be done
with it.

Easier said than done :(

	- Panu -




From mattdm at mattdm.org  Sat May 15 16:17:52 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 15 May 2004 12:17:52 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <Pine.LNX.4.58.0405151834270.1906@chip.laiskiainen.org>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<40A435D5.8000605@mindspring.com>
	<1084553737.19941.17.camel@gibraltar.stuttgart.redhat.com>
	<1084589474.2878.14.camel@localhost.localdomain>
	<Pine.LNX.4.58.0405151834270.1906@chip.laiskiainen.org>
Message-ID: <20040515161752.GA27487@jadzia.bu.edu>

On Sat, May 15, 2004 at 06:41:43PM +0300, Panu Matilainen wrote:
> Having a general framework for preferred applications without kludges like
> htmlview which "everything" honors would pretty much make this whole
> discussion irrelevant. I really don't want to see 5 different email
> clients and 7 different browsers in the menus, regardless of what's
> installed. What I want is to have "Web browser", "Email", "Text editor"  
> etc generic functionality descriptions in the menus and only change it
> *once* in *one* place where I can pick up my preferred browser or editor
> etc from everything that's installed (or maybe even available) and be done
> with it.
> 
> Easier said than done :(

But a good scheme. Even if something like htmlview can't realistically be
arranged for everything, this still seems like a decent approach for a menu
editor to take.

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




From janina at rednote.net  Sat May 15 16:49:47 2004
From: janina at rednote.net (Janina Sajka)
Date: Sat, 15 May 2004 12:49:47 -0400
Subject: Tettnang ??
In-Reply-To: <200405121716.16795.remco@rvt.com>
References: <17697.12.41.112.51.1084389282.squirrel@webmail.ec-group.com>
	<1084403167.3386.7.camel@fc1> <200405121716.16795.remco@rvt.com>
Message-ID: <20040515164947.GI2398@rednote.net>

Remco Treffkorn writes:
> On Wednesday 12 May 2004 16:06, Matt Hansen wrote:
> > On Thu, 2004-05-13 at 05:14, Brian Millett wrote:
> > > Ok, so why a town in Germany?
> >
> ...
> > So, release name is decided! So who came up with this one?
> > Maybe it's Karsten Hopp's hometown? ;)
> 
> No, no, no!
> 
> It's because Linux is free software.
> Free as in 'libre', not as in beer.
> And what is a main ingredient in beer? Hops!
> And good hops comes from Tettnang.
> 
> So, there!
> 
Nevertheless, we'll have to appraise it soberly.


<grin>


	> -- 
	> Remco Treffkorn (RT445)
> HAM DC2XT
> remco at rvt.com   (831) 685-1201
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina at afb.net		Phone: (202) 408-8175




From mr-fedora at linuxalert.org  Sat May 15 17:54:45 2004
From: mr-fedora at linuxalert.org (Magnus Runesson)
Date: Sat, 15 May 2004 19:54:45 +0200
Subject: systematic Kerberization
In-Reply-To: <1084312863.3728.33.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
	<1084312863.3728.33.camel@localhost.localdomain>
Message-ID: <1084643685.7994.2.camel@pamina.linuxalert.org>

> > Also, it's always possible to select the local computer and log into that,
> > rather than into the domain.
> > 
> 
> So the message I've gotten from others is "Windows solves this problem
> and Linux does not" and they were aware of the ability to set up a local
> passwd file when complaining.

Doesn't PADL's pam-modules ccreds and nss_updatedb help to solve the
problem. http://www.padl.com/OSS/pam_ccreds.html
Unfoutunately, I havn't got the time to test it by my self yet.

/Magnus

-- 
Magnus Runesson <mr-fedora at linuxalert.org>




From mattdm at mattdm.org  Sat May 15 18:28:19 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 15 May 2004 14:28:19 -0400
Subject: i586 kernel [was Re: Module symbol versions in installer kernel]
In-Reply-To: <200405150841.17369.jkeating@j2solutions.net>
References: <40A5B427.4050704@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
	<200405150841.17369.jkeating@j2solutions.net>
Message-ID: <20040515182819.GA31296@jadzia.bu.edu>

On Sat, May 15, 2004 at 08:41:17AM -0700, Jesse Keating wrote:
> > Which brings up this question: are there any i586 systems out there with
> > enough RAM to run anaconda anyway?
> Yes, plenty of them.  The base issue is that things like nptl and such 

Not to doubt you, but what does "plenty of them" mean? Fedora won't even
install with 32MB, and by the time more RAM than that was common, so were
newer CPUs, if I remember right.

I'm very sympathetic to making Linux run on older hardware, but Fedora is
already pretty unfriendly to those systems as is. Why not just make the
Pentium Pro the minimum for FC3? That covers us all the way to back to 1995
(well, okay, 1998, since the PPro never really caught on and there were all
those MMX P5s). Other distros -- perhaps even a tailored Fedora branch --
can cover before that.


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




From stan at ccs.neu.edu  Sat May 15 19:04:33 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Sat, 15 May 2004 15:04:33 -0400
Subject: i586 kernel [was Re: Module symbol versions in installer kernel]
In-Reply-To: <20040515182819.GA31296@jadzia.bu.edu>
References: <40A5B427.4050704@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
	<200405150841.17369.jkeating@j2solutions.net>
	<20040515182819.GA31296@jadzia.bu.edu>
Message-ID: <1084647872.10009.42.camel@duergar>

On Sat, 2004-05-15 at 14:28, Matthew Miller wrote:
> Not to doubt you, but what does "plenty of them" mean? Fedora won't even
> install with 32MB, and by the time more RAM than that was common, so were
> newer CPUs, if I remember right.
> 

Not to doubt you, but there are plenty of people using their old 586's
for everything from local ftp servers to gateways, etc... there are lots
of uses for i586's that don't need X.

> I'm very sympathetic to making Linux run on older hardware, but Fedora is
> already pretty unfriendly to those systems as is. Why not just make the

How so? A stripped down install is still more powerful than a palm :)

> Pentium Pro the minimum for FC3? That covers us all the way to back to 1995
> (well, okay, 1998, since the PPro never really caught on and there were all
> those MMX P5s). Other distros -- perhaps even a tailored Fedora branch --
> can cover before that.
> 

A simple stripped down install of fedora works on 586 CPUs, -X and the
flashy crap and you got a nice small server.  The fact of the matter is
people still use them.  This reminds me of running X on my p166, boy
those were trying times ;-)

-sb

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




From pryce at ucla.edu  Sat May 15 18:54:23 2004
From: pryce at ucla.edu (Paul Rigor)
Date: Sat, 15 May 2004 11:54:23 -0700
Subject: Problems with up2date
In-Reply-To: <40A4B8B5.10309@uol.com.br>
References: <20040513192800.GS29888@neu.nirvana>
	<ork6zfbogj.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<40A4B8B5.10309@uol.com.br>
Message-ID: <6.0.0.22.2.20040515114551.0201d168@mail.ucla.edu>

I'm not sure about the major release version that you have, i.e., "2"... 
you might wanna change that to "development"

the directory "2" is currently not available because core 2 is not yet a 
"go"...... or at least i wasn't able to access it on ibiblio.org.  but yea, 
rawhid is still under development

so yea, check out /etc/yum.conf and change the settings appropriately.  did 
you, btw, change the "$releasever" into "2"?

see ya,
paul



At 05:16 AM 5/14/2004, you wrote:
>Hello,
>
>Since 3 days ago, from the last upgrade of up2date, whenever I try to run 
>it, the result is the following:
>
>[root at 200-207-17-55 casimiro]# up2date --update
>http://fedora.redhat.com/download/up2date-mirrors/fedora-core-2
>using mirror: 
>http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/2/i386/os/
>http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc2
>using mirror: http://mirror.eas.muohio.edu/fedora/linux/core/updates/2/i386/
>There was a fatal error communicating with the server. The message was:
>An HTTP error occurred:
>URL: 
>http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/2/i386/os//headers/header.info
>Status Code: 404
>Error Message: Not Found
>
>I tried to manually download up2date from fedora and run rpm -Uvh... but 
>the result is the same.
>
>Looking for the pointed URL, it really doesn't exist (was directory moved 
>without notice ???)
>
>Regards,
>
>Casimiro Barreto
>
>
>--
>fedora-devel-list mailing list
>fedora-devel-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-devel-list

_________
Paul Rigor
pryce at ucla.edu
Go Bruins! 




From mattdm at mattdm.org  Sat May 15 19:38:34 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 15 May 2004 15:38:34 -0400
Subject: i586 kernel [was Re: Module symbol versions in installer kernel]
In-Reply-To: <1084647872.10009.42.camel@duergar>
References: <40A5B427.4050704@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
	<200405150841.17369.jkeating@j2solutions.net>
	<20040515182819.GA31296@jadzia.bu.edu>
	<1084647872.10009.42.camel@duergar>
Message-ID: <20040515193834.GA982@jadzia.bu.edu>

On Sat, May 15, 2004 at 03:04:33PM -0400, Stan Bubrouski wrote:
> Not to doubt you, but there are plenty of people using their old 586's
> for everything from local ftp servers to gateways, etc... there are lots
> of uses for i586's that don't need X.

Certainly. I was, until two years ago. And I've got a Toshiba Libretto
pentium subnotebook which I still use.

I'm just not sure that this is these are the targets for a general-purpose
distribution.


> > I'm very sympathetic to making Linux run on older hardware, but Fedora is
> > already pretty unfriendly to those systems as is. Why not just make the
> How so? A stripped down install is still more powerful than a palm :)

On the contrary -- a tailored install can be a lot more powerful than a
shoehorned general-purpose system.


> > can cover before that.
> A simple stripped down install of fedora works on 586 CPUs, -X and the
> flashy crap and you got a nice small server.  The fact of the matter is
> people still use them.  This reminds me of running X on my p166, boy
> those were trying times ;-)

I don't doubt that it works. I *would* be interested in seeing some real
numbers on usuage.


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




From dcmwai at pl.jaring.my  Sat May 15 19:49:42 2004
From: dcmwai at pl.jaring.my (Chan Min Wai)
Date: Sun, 16 May 2004 03:49:42 +0800
Subject: The Fedora Hardware Project
Message-ID: <40A67456.2010703@pl.jaring.my>

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

Hello,

How is this hardware Project working? any plane?
and by the way are fedora going to come out with some test suit like RHEL3?

Like with the link below?

http://hardware.redhat.com/hcl/?pagename=files

Which will actually increase the speed of testing hardware.
However I don't really know if this work :)

Thank You
Chan Min Wai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFApnRWV0p9slMZLW4RAmJLAKD4gv+gaXdP5yX0q9l4js2IDc9MaACdFB15
pEegsnLgHzmXkP48pUCWY0M=
=Rz1E
-----END PGP SIGNATURE-----





From cmadams at hiwaay.net  Sat May 15 20:11:55 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 15 May 2004 15:11:55 -0500
Subject: Fedora for UltraSPARC?
Message-ID: <20040515201155.GB1389246@hiwaay.net>

Is anyone working on getting Fedora working on UltraSPARC systems?  I am
aware of Aurora SPARC Linux, but I would like to run the same thing as I
run on my x86 systems.

-- 
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 gleblanc at linuxweasel.com  Sat May 15 20:34:54 2004
From: gleblanc at linuxweasel.com (Gregory Leblanc)
Date: Sat, 15 May 2004 13:34:54 -0700
Subject: Fedora for UltraSPARC?
In-Reply-To: <20040515201155.GB1389246@hiwaay.net>
References: <20040515201155.GB1389246@hiwaay.net>
Message-ID: <40A67EEE.5090101@linuxweasel.com>

Chris Adams wrote:

> Is anyone working on getting Fedora working on UltraSPARC systems?  I am
> aware of Aurora SPARC Linux, but I would like to run the same thing as I
> run on my x86 systems.

At least one Aurora developer is working on getting FC2 running on 
UltraSPARCs.  As of the last update:
Topic for #aurora: Corona/FC2 status: all that remains is gcc34+friends, 
kernel, and openoffice (building now)

Unfortunately, none of this is available to anybody other than the 
developer in question right now.  I'm sure you can figure out who they 
are, and a bit more encouragement to make it available probably wouldn't 
hurt.  :-)  HTH,
	Greg




From dave at webaugur.com  Sat May 15 20:55:40 2004
From: dave at webaugur.com (David L Norris)
Date: Sat, 15 May 2004 15:55:40 -0500
Subject: i586 kernel [was Re: Module symbol versions in installer kernel]
In-Reply-To: <20040515182819.GA31296@jadzia.bu.edu>
References: <40A5B427.4050704@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
	<200405150841.17369.jkeating@j2solutions.net>
	<20040515182819.GA31296@jadzia.bu.edu>
Message-ID: <1084654540.14071.156.camel@Daneel.WebAugur.com>

On Sat, 2004-05-15 at 13:28, Matthew Miller wrote:
> Not to doubt you, but what does "plenty of them" mean? Fedora won't even
> install with 32MB, and by the time more RAM than that was common, so were
> newer CPUs, if I remember right.

A local non-profit computer recycler asked me about using Linux a few
months ago.  They tell me that the average system they have donated is a
Pentium 75 MHz with 64 MB RAM.  Some faster, some with more RAM, some
with less RAM.  They make sure each system has 64 MB when they refurb
it.

There are a fairly substantial number of old computers being put back
into service using either Windows 98 or a Linux distribution.  (MS still
offers Win98 to non-profit recyclers _very_ cheaply.  Cheaply meaning
competitive with free.)  As I understand it most of these refurb
machines are being sent off to governments and schools in South America
where they would otherwise be without computers.

It would seem shortsighted to ignore them just because they aren't
i686.  A Pentium is still a powerful machine.  Especially when combined
with LTSP or some other X terminal arrangement.

> I'm very sympathetic to making Linux run on older hardware, but Fedora is
> already pretty unfriendly to those systems as is. Why not just make the
> Pentium Pro the minimum for FC3? That covers us all the way to back to 1995

It does?  What about AMD K6 computers?  They are i586 and they are newer
than 1995 or 1998.  Fedora Core works wonderfully on my 2001 model AMD
K6-2 450 MHz laptop with 192 MB RAM.  It works wonderfully on my 2000
model AMD 500 MHz K6-2 desktop with 256 MB RAM.  If I disable all the
services it works well on my Pentium 90 MHz laptop with 48 MB RAM and
Pentium 75 MHz desktop with 64 MB RAM.  I've experimented with kdrive on
FC1 and it drops memory usage to about 20 MB on the Pentium machines.

-- 
 David Norris
  http://www.webaugur.com/dave/
  ICQ - 412039
-------------- 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/20040515/c3362e73/attachment.sig>

From mattdm at mattdm.org  Sat May 15 21:07:54 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 15 May 2004 17:07:54 -0400
Subject: i586 kernel [was Re: Module symbol versions in installer kernel]
In-Reply-To: <1084654540.14071.156.camel@Daneel.WebAugur.com>
References: <40A5B427.4050704@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
	<200405150841.17369.jkeating@j2solutions.net>
	<20040515182819.GA31296@jadzia.bu.edu>
	<1084654540.14071.156.camel@Daneel.WebAugur.com>
Message-ID: <20040515210754.GA4962@jadzia.bu.edu>

On Sat, May 15, 2004 at 03:55:40PM -0500, David L Norris wrote:
> It would seem shortsighted to ignore them just because they aren't
> i686.  A Pentium is still a powerful machine.  Especially when combined
> with LTSP or some other X terminal arrangement.

I'm not suggesting they be ignored. In fact, I think that it'd be great if
they got special attention -- a Fedora Lite, say.


> > already pretty unfriendly to those systems as is. Why not just make the
> > Pentium Pro the minimum for FC3? That covers us all the way to back to 1995
> It does?  What about AMD K6 computers?  They are i586 and they are newer
> than 1995 or 1998.  Fedora Core works wonderfully on my 2001 model AMD

Well, maybe now is not the time. But I think next year or the year after
that *will* be.


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




From davej at redhat.com  Sat May 15 21:05:09 2004
From: davej at redhat.com (Dave Jones)
Date: Sat, 15 May 2004 22:05:09 +0100
Subject: i586 kernel [was Re: Module symbol versions in installer kernel]
In-Reply-To: <20040515182819.GA31296@jadzia.bu.edu>
References: <40A5B427.4050704@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
	<200405150841.17369.jkeating@j2solutions.net>
	<20040515182819.GA31296@jadzia.bu.edu>
Message-ID: <1084655109.2064.38.camel@delerium.codemonkey.org.uk>

On Sat, 2004-05-15 at 19:28, Matthew Miller wrote:

> I'm very sympathetic to making Linux run on older hardware, but Fedora is
> already pretty unfriendly to those systems as is. Why not just make the
> Pentium Pro the minimum for FC3? That covers us all the way to back to 1995
> (well, okay, 1998, since the PPro never really caught on and there were all
> those MMX P5s).

Not strictly true. You can pick up quad ppro systems on ebay for quite
reasonable amounts of money, which is a nice way for a developer to get
a cheap 4-way SMP system.  It's not going to give anything modern a run
for its money, but its still a very usable system.  Until a few weeks
ago, I had two of them myself, both with a gig of RAM and 20gb of hw
raid5'd SCSI. (Space/Noise considerations meant getting rid of one of
them).  They make very nice test boxes, that during the early 2.5.x
kernels brought out all sorts of bugs that didn't show up on my faster
SMP boxes until much later.

>  Other distros -- perhaps even a tailored Fedora branch --
> can cover before that.

When we have a proper infrastructure in place, I'd like to see something
like that happen for anything < 686, but right now we're quite a way
from that goal.  Ultimately at some point I wouldn't be surprised to see
this happen given that RHEL has a minimum requirement of 686.

	Dave




From mattdm at mattdm.org  Sat May 15 21:26:36 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 15 May 2004 17:26:36 -0400
Subject: i586 kernel [was Re: Module symbol versions in installer kernel]
In-Reply-To: <1084655109.2064.38.camel@delerium.codemonkey.org.uk>
References: <40A5B427.4050704@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
	<200405150841.17369.jkeating@j2solutions.net>
	<20040515182819.GA31296@jadzia.bu.edu>
	<1084655109.2064.38.camel@delerium.codemonkey.org.uk>
Message-ID: <20040515212636.GA5630@jadzia.bu.edu>

On Sat, May 15, 2004 at 10:05:09PM +0100, Dave Jones wrote:
> Not strictly true. You can pick up quad ppro systems on ebay for quite
> reasonable amounts of money, which is a nice way for a developer to get
> a cheap 4-way SMP system.  It's not going to give anything modern a run

Yes, but those are i686....

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




From jos at xos.nl  Sat May 15 21:26:47 2004
From: jos at xos.nl (Jos Vos)
Date: Sat, 15 May 2004 23:26:47 +0200
Subject: i586 kernel [was Re: Module symbol versions in installer kernel]
In-Reply-To: <20040515210754.GA4962@jadzia.bu.edu>;
	from mattdm@mattdm.org on Sat, May 15, 2004 at 05:07:54PM -0400
References: <40A5B427.4050704@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
	<200405150841.17369.jkeating@j2solutions.net>
	<20040515182819.GA31296@jadzia.bu.edu>
	<1084654540.14071.156.camel@Daneel.WebAugur.com>
	<20040515210754.GA4962@jadzia.bu.edu>
Message-ID: <20040515232647.A12389@xos037.xos.nl>

On Sat, May 15, 2004 at 05:07:54PM -0400, Matthew Miller wrote:

> > It does?  What about AMD K6 computers?  They are i586 and they are newer
> > than 1995 or 1998.  Fedora Core works wonderfully on my 2001 model AMD
> 
> Well, maybe now is not the time. But I think next year or the year after
> that *will* be.

Well, please remember that all kinds of special devices (SBC's etc.)
still often have i386 or i486-compatible CPU's and are very well
suited for use with Linux.  This could be covered by a Lite-version
or so, but keep in mind that these systems do exists *and* are used.
I think often Debian is used for these systems, but I'm not a Debian
fan and I think we should have something to choose anyway.

The world just does not only consists of "PC's" in the literal meaning.

-- 
--    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 mattdm at mattdm.org  Sat May 15 21:32:30 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 15 May 2004 17:32:30 -0400
Subject: i586 kernel [was Re: Module symbol versions in installer kernel]
In-Reply-To: <20040515232647.A12389@xos037.xos.nl>
References: <40A5B427.4050704@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
	<200405150841.17369.jkeating@j2solutions.net>
	<20040515182819.GA31296@jadzia.bu.edu>
	<1084654540.14071.156.camel@Daneel.WebAugur.com>
	<20040515210754.GA4962@jadzia.bu.edu>
	<20040515232647.A12389@xos037.xos.nl>
Message-ID: <20040515213230.GA5816@jadzia.bu.edu>

On Sat, May 15, 2004 at 11:26:47PM +0200, Jos Vos wrote:
> Well, please remember that all kinds of special devices (SBC's etc.)
> still often have i386 or i486-compatible CPU's and are very well
> suited for use with Linux.  This could be covered by a Lite-version
> or so, but keep in mind that these systems do exists *and* are used.

Hadn't left my mind. However, I don' think that those systems should
necessarily be a focus of the _core_ Fedora project.

> I think often Debian is used for these systems, but I'm not a Debian
> fan and I think we should have something to choose anyway.

There's hundreds of distributions.


> The world just does not only consists of "PC's" in the literal meaning.

I ain't arguin' with that. :)

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




From paul at gear.dyndns.org  Sat May 15 22:25:34 2004
From: paul at gear.dyndns.org (Paul Gear)
Date: Sun, 16 May 2004 08:25:34 +1000
Subject: i586 kernel [was Re: Module symbol versions in installer kernel]
In-Reply-To: <1084647872.10009.42.camel@duergar>
References: <40A5B427.4050704@gear.dyndns.org>	<1084621520.2781.6.camel@laptop.fenrus.com>	<20040515141952.GA23909@jadzia.bu.edu>	<200405150841.17369.jkeating@j2solutions.net>	<20040515182819.GA31296@jadzia.bu.edu>
	<1084647872.10009.42.camel@duergar>
Message-ID: <40A698DE.5020905@gear.dyndns.org>

Stan Bubrouski wrote:
> ...
> A simple stripped down install of fedora works on 586 CPUs, -X and the
> flashy crap and you got a nice small server.  The fact of the matter is
> people still use them.  This reminds me of running X on my p166, boy
> those were trying times ;-)

Bah - luxury!  In 1991, my X terminal was an 80186 with 1 Mb RAM (it did
1024 x 768 in 256 colours!), connected to a 33 MHz IBM RISC box.  :-)

-- 
Paul
http://paulgear.webhop.net
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my email reply *below* the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040516/5625a606/attachment.sig>

From paul at gear.dyndns.org  Sat May 15 22:32:41 2004
From: paul at gear.dyndns.org (Paul Gear)
Date: Sun, 16 May 2004 08:32:41 +1000
Subject: Module symbol versions in installer kernel
In-Reply-To: <200405150842.26740.jkeating@j2solutions.net>
References: <40A5B427.4050704@gear.dyndns.org>	<1084612675.2781.2.camel@laptop.fenrus.com>	<40A5F121.2050608@gear.dyndns.org>
	<200405150842.26740.jkeating@j2solutions.net>
Message-ID: <40A69A89.3090306@gear.dyndns.org>

Jesse Keating wrote:
> On Saturday 15 May 2004 03:29, Paul Gear wrote:
> 
>>>Now we're getting somewhere.  :-)
>>>
>>>Would you mind elaborating on that a little?
> 
> 
> If you look in /usr/src/linux-2.6/configs/  you will see a lot of config 
> files for different archs.

We're talking FC1 here, not FC2.  It is kernel 2.4.22, not 2.6.  Does
that make any difference to the situation?

> If you're installing off of CD, the install
> kernel is the same version, but built for i586, and not i686.  Thus you 
> must build your module against a i586 configured kernel source tree.

As far as i can tell, the disc i built included all kernel versions.
That is the default on Doug Ledford's dd kit, isn't it?  I'll double
check this.

Thanks for your time.
-- 
Paul
http://paulgear.webhop.net
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my email reply *below* the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040516/b661e9d9/attachment.sig>

From casimiro_barreto at uol.com.br  Sat May 15 23:13:31 2004
From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto)
Date: Sat, 15 May 2004 20:13:31 -0300
Subject: Problems with up2date
In-Reply-To: <6.0.0.22.2.20040515114551.0201d168@mail.ucla.edu>
References: <20040513192800.GS29888@neu.nirvana>	<ork6zfbogj.fsf@livre.redhat.lsd.ic.unicamp.br>	<1084343991.3770.10772.camel@mccallum.corsepiu.local>	<40A1DC3E.4080506@redhat.com>
	<20040512093104.GA9771@neu.nirvana>	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<1084439431.3770.13705.camel@mccallum.corsepiu.local>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<40A4B8B5.10309@uol.com.br>
	<6.0.0.22.2.20040515114551.0201d168@mail.ucla.edu>
Message-ID: <40A6A41B.8030703@uol.com.br>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040515/ee7de437/attachment.htm>

From hp at redhat.com  Sun May 16 02:03:34 2004
From: hp at redhat.com (Havoc Pennington)
Date: Sat, 15 May 2004 22:03:34 -0400
Subject: systematic Kerberization
In-Reply-To: <1084643685.7994.2.camel@pamina.linuxalert.org>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
	<1084312863.3728.33.camel@localhost.localdomain>
	<1084643685.7994.2.camel@pamina.linuxalert.org>
Message-ID: <1084673014.2878.141.camel@localhost.localdomain>

On Sat, 2004-05-15 at 13:54, Magnus Runesson wrote:
> > > Also, it's always possible to select the local computer and log into that,
> > > rather than into the domain.
> > > 
> > 
> > So the message I've gotten from others is "Windows solves this problem
> > and Linux does not" and they were aware of the ability to set up a local
> > passwd file when complaining.
> 
> Doesn't PADL's pam-modules ccreds and nss_updatedb help to solve the
> problem. http://www.padl.com/OSS/pam_ccreds.html
> Unfoutunately, I havn't got the time to test it by my self yet.
> 

Certainly appears so. Anyone tried this?

Havoc





From ckloiber at ckloiber.com  Sun May 16 08:26:24 2004
From: ckloiber at ckloiber.com (Chris Kloiber)
Date: Sun, 16 May 2004 16:26:24 +0800
Subject: The Fedora Hardware Project
In-Reply-To: <40A67456.2010703@pl.jaring.my>
References: <40A67456.2010703@pl.jaring.my>
Message-ID: <1084695984.27053.20.camel@galileo.ckloiber.com>

On Sun, 2004-05-16 at 03:49, Chan Min Wai wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> How is this hardware Project working? any plane?
> and by the way are fedora going to come out with some test suit like RHEL3?
> 
> Like with the link below?
> 
> http://hardware.redhat.com/hcl/?pagename=files
> 
> Which will actually increase the speed of testing hardware.
> However I don't really know if this work :)

I don't see Red Hat doing anything official with Fedora hardware support
anytime soon. That said, the scripts you located should work without
{any,many?} changes on Fedora if you want to go that route. Remember
that these tests are to see if the hardware falls over, they are not
performance benchmarks. There {are,were?} glaring omissions in the test
suite, like modems, firewire, and usb devices more complex than mice and
keyboards.

I am more familiar with the Red Hat Enterprise 2.1 test programs on that
page, as I used to be the person responsible for testing many of the
IHV's systems during those days. The newer tests are actually easier to
use I'm told, and I can answer questions about them (I may have to ping
the author first, though).

-- 
Chris Kloiber





From buildsys at redhat.com  Sun May 16 11:14:07 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 16 May 2004 07:14:07 -0400
Subject: rawhide report: 20040516 changes
Message-ID: <200405161114.i4GBE7i10505@porkchop.devel.redhat.com>

 

 
Updated Packages:

rpmdb-fedora-2-0.20040516
-------------------------




From pmatilai at welho.com  Sun May 16 12:31:56 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Sun, 16 May 2004 15:31:56 +0300 (EEST)
Subject: systematic Kerberization
In-Reply-To: <1084673014.2878.141.camel@localhost.localdomain>
References: <1084223631.2770.77.camel@localhost.localdomain>
	<200405120005.22495.dennis@ausil.us>
	<Pine.GSO.4.58.0405111010090.9888@redfish.gatech.edu>
	<200405120017.58823.dennis@ausil.us>
	<Pine.GSO.4.58.0405111018550.9888@redfish.gatech.edu>
	<1084291840.4999.7.camel@localhost.localdomain>
	<Pine.GSO.4.58.0405111304190.9888@redfish.gatech.edu>
	<1084312863.3728.33.camel@localhost.localdomain>
	<1084643685.7994.2.camel@pamina.linuxalert.org>
	<1084673014.2878.141.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0405161528560.18170@chip.laiskiainen.org>

On Sat, 15 May 2004, Havoc Pennington wrote:

> On Sat, 2004-05-15 at 13:54, Magnus Runesson wrote:
> > > > Also, it's always possible to select the local computer and log into that,
> > > > rather than into the domain.
> > > > 
> > > 
> > > So the message I've gotten from others is "Windows solves this problem
> > > and Linux does not" and they were aware of the ability to set up a local
> > > passwd file when complaining.
> > 
> > Doesn't PADL's pam-modules ccreds and nss_updatedb help to solve the
> > problem. http://www.padl.com/OSS/pam_ccreds.html
> > Unfoutunately, I havn't got the time to test it by my self yet.
> > 
> 
> Certainly appears so. Anyone tried this?

I mentioned PADLS new modules earlier in this thread: they basically do 
solve the problem BUT it does so by caching ALL of the directory data on 
the local harddisk. Not very feasible when you have tens of thousands of 
users (and never mind the security implications of carrying whole companys 
usernames and passwords around in a laptop..)

	- Panu -




From smoogen at lanl.gov  Sun May 16 16:46:38 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Sun, 16 May 2004 10:46:38 -0600 (MDT)
Subject: The Fedora Hardware Project
In-Reply-To: <1084695984.27053.20.camel@galileo.ckloiber.com>
References: <40A67456.2010703@pl.jaring.my>
	<1084695984.27053.20.camel@galileo.ckloiber.com>
Message-ID: <Pine.LNX.4.58.0405161043020.28489@smoogen1.lanl.gov>

On Sun, 16 May 2004, Chris Kloiber wrote:

>On Sun, 2004-05-16 at 03:49, Chan Min Wai wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Hello,
>> 
>> How is this hardware Project working? any plane?
>> and by the way are fedora going to come out with some test suit like RHEL3?
>> 
>> Like with the link below?
>> 
>> http://hardware.redhat.com/hcl/?pagename=files
>> 
>> Which will actually increase the speed of testing hardware.
>> However I don't really know if this work :)
>
>I don't see Red Hat doing anything official with Fedora hardware support
>anytime soon. That said, the scripts you located should work without
>{any,many?} changes on Fedora if you want to go that route. Remember
>that these tests are to see if the hardware falls over, they are not
>performance benchmarks. There {are,were?} glaring omissions in the test
>suite, like modems, firewire, and usb devices more complex than mice and
>keyboards.
>

Well I think most of those were written when many of the items didnt
exist (or were definately not on the supported list). The writers of the 
code were pretty sleep/food deprived at the time of writing so cleanups 
are probably needed. Thankfully I know that my 1 or 2 additions were 
cleaned out way before it got to a web page.


>I am more familiar with the Red Hat Enterprise 2.1 test programs on that
>page, as I used to be the person responsible for testing many of the
>IHV's systems during those days. The newer tests are actually easier to
>use I'm told, and I can answer questions about them (I may have to ping
>the author first, though).




-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From jkeating at j2solutions.net  Sun May 16 18:08:59 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 16 May 2004 11:08:59 -0700
Subject: Module symbol versions in installer kernel
In-Reply-To: <40A69A89.3090306@gear.dyndns.org>
References: <40A5B427.4050704@gear.dyndns.org>
	<200405150842.26740.jkeating@j2solutions.net>
	<40A69A89.3090306@gear.dyndns.org>
Message-ID: <200405161108.59299.jkeating@j2solutions.net>

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

On Saturday 15 May 2004 15:32, Paul Gear wrote:
> We're talking FC1 here, not FC2. ?It is kernel 2.4.22, not 2.6. ?Does
> that make any difference to the situation?

Only difference would be /usr/src/linux-2.4 instead of -2.6

> > If you're installing off of CD, the install
> > kernel is the same version, but built for i586, and not i686. ?Thus
> > you must build your module against a i586 configured kernel source
> > tree.
>
> As far as i can tell, the disc i built included all kernel versions.
> That is the default on Doug Ledford's dd kit, isn't it? ?I'll double
> check this.

Yes, I do believe so.

- -- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key          
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAp6474v2HLvE71NURAhQ4AKC5WJJ66zNIibe1ECFNTZ2ATcn8vgCgt3Zd
qH69p6FvHTH43oaFvE7GoFY=
=bQ+6
-----END PGP SIGNATURE-----




From fedora at leemhuis.info  Sun May 16 18:10:58 2004
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 16 May 2004 20:10:58 +0200
Subject: *Heads up* for FC1 Alsa users from fedora.us
Message-ID: <1084731058.1652.32.camel@work.thl.home>

Hi *,

users that have installed the package alsa-driver (needed for the alsa
kernel-modules) from the fedora.us repository should update to the
latest Version 1.0.4-0.fdr.2.1 before they upgrade to FC2. This version
is out since one week, so if you use yum, up2date or apt to keep your
system always up2date you should already have it installed. All other,
please get it at your local mirror or directly at 

http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/alsa-driver-1.0.4-0.fdr.2.1.i386.rpm

This version avoids a conflict during an FC1 -> FC2 update between
alsa-driver and the new MAKEDEV package.

Also note that it may be a good idea to remove all alsa-packages from
fedora.us before upgrading to FC2 as it contains alsa itself, but in an
older Version (fedora.us currently at 1.04, FC2 ships 1.03). This is no
must as the newer version should not do any harm.  *Should*. 

If you miss(ed) it and run into any alsa related errors after FC2 update
please remove alsa-driver, kernel-module-alsa*, alsa-lib, alsa-utils
(for the last two you properly need --nodeps parameter for rpm) and
install the FC2 packages from you FC2 install media afterwards to
resolve depencies.

BTW, Sorry for crossposting, I think this time it's worth it. Further
discussion should go to fedora-list, please.

BTW2: Is there any interest in alsa-tools and alsa-firmware packages for
FC2? FC2 will not ship them AFAIK, but I could try to package them for
fedora.us if there are interested users.

Thanks

CU
thl




From alan at redhat.com  Sun May 16 19:11:13 2004
From: alan at redhat.com (Alan Cox)
Date: Sun, 16 May 2004 15:11:13 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <Pine.LNX.4.44.0405131702070.8834-100000@ebersisk.clueserver.org>
References: <20040514000639.GA1123340@hiwaay.net>
	<Pine.LNX.4.44.0405131702070.8834-100000@ebersisk.clueserver.org>
Message-ID: <20040516191113.GA20505@devserv.devel.redhat.com>

On Thu, May 13, 2004 at 05:04:38PM -0700, alan wrote:
> > up with both in the desktop menus that way.
> 
> There is also the issue of where one app provides functionality that 
> another does not.

Same is true with OOo v Gnumeric to be honest. Gnumeric is a spreadsheet
, Ooo is an office suite with at best a toy spread sheet module.

> The Highlander approach ("There can only be one!") is a bad way to handle 
> things.  Not something to lose ones head over...

So is 500 things on the menu. The general user needs guidance on what to run,
but I agree with you that stuff that is deliberately added should be on the
menu of that user- a lot of this is "where is the ****ing menu editor" stuff
though. Once you hav that then the desktop can give you the expected basic
program described by purpose and the user can add things like "real spreadsheet"
and "non-sucky audio player"




From smoogen at lanl.gov  Sun May 16 19:16:35 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Sun, 16 May 2004 13:16:35 -0600 (MDT)
Subject: Menu Policy - please read if you maintain a package with a
 .desktop file in it!
In-Reply-To: <20040516191113.GA20505@devserv.devel.redhat.com>
References: <20040514000639.GA1123340@hiwaay.net>
	<Pine.LNX.4.44.0405131702070.8834-100000@ebersisk.clueserver.org>
	<20040516191113.GA20505@devserv.devel.redhat.com>
Message-ID: <Pine.LNX.4.58.0405161316020.28489@smoogen1.lanl.gov>

On Sun, 16 May 2004, Alan Cox wrote:

>On Thu, May 13, 2004 at 05:04:38PM -0700, alan wrote:
>> > up with both in the desktop menus that way.
>> 
>> There is also the issue of where one app provides functionality that 
>> another does not.
>
>Same is true with OOo v Gnumeric to be honest. Gnumeric is a spreadsheet
>, Ooo is an office suite with at best a toy spread sheet module.

So how much work to make gnumeric into OOspread :).


-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From alan at redhat.com  Sun May 16 20:52:34 2004
From: alan at redhat.com (Alan Cox)
Date: Sun, 16 May 2004 16:52:34 -0400
Subject: Module symbol versions in installer kernel
In-Reply-To: <20040515141952.GA23909@jadzia.bu.edu>
References: <40A5B427.4050704@gear.dyndns.org>
	<200405142329.39309.jkeating@j2solutions.net>
	<40A5CC43.5080509@gear.dyndns.org>
	<1084612675.2781.2.camel@laptop.fenrus.com>
	<40A5F121.2050608@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
Message-ID: <20040516205234.GB18735@devserv.devel.redhat.com>

On Sat, May 15, 2004 at 10:19:52AM -0400, Matthew Miller wrote:
> I was wondering about this. Is it still the case that i586 performs _worse_
> on non-original-Pentium systems than i386? (Or is that wrong in the first
> place, or not relevant to kernels?)
> 
> Which brings up this question: are there any i586 systems out there with
> enough RAM to run anaconda anyway?

Yep. Anaconda will do a minimal install with selinux=0 in 64Mb. Also 586
as an architecture covers many later processors in socket 7 form, although
586 optimisation does not.




From robn at verdi.et.tudelft.nl  Sun May 16 23:50:36 2004
From: robn at verdi.et.tudelft.nl (Rob van Nieuwkerk)
Date: Mon, 17 May 2004 01:50:36 +0200
Subject: Module symbol versions in installer kernel
In-Reply-To: <20040516205234.GB18735@devserv.devel.redhat.com>
References: <40A5B427.4050704@gear.dyndns.org>
	<200405142329.39309.jkeating@j2solutions.net>
	<40A5CC43.5080509@gear.dyndns.org>
	<1084612675.2781.2.camel@laptop.fenrus.com>
	<40A5F121.2050608@gear.dyndns.org>
	<1084621520.2781.6.camel@laptop.fenrus.com>
	<20040515141952.GA23909@jadzia.bu.edu>
	<20040516205234.GB18735@devserv.devel.redhat.com>
Message-ID: <20040517015036.5a718809.robn@verdi.et.tudelft.nl>

On Sun, 16 May 2004 16:52:34 -0400
Alan Cox <alan at redhat.com> wrote:

> > Which brings up this question: are there any i586 systems out there with
> > enough RAM to run anaconda anyway?
> 
> Yep. Anaconda will do a minimal install with selinux=0 in 64Mb. Also 586

I did one in 48 MB on an old laptop yesterday.
It's a pity that the "install everything" exploded.
But I'll get there by adding the rest manually ..

	Rob van Nieuwkerk




From toshio at tiki-lounge.com  Mon May 17 02:37:10 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Sun, 16 May 2004 22:37:10 -0400
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084485872.5572.13.camel@localhost.localdomain>
References: <1084485872.5572.13.camel@localhost.localdomain>
Message-ID: <1084761429.3097.234.camel@Madison.badger.com>

On Thu, 2004-05-13 at 18:04, Seth Nickell wrote:
> 2) If your package is in any of the default package sets:
>   a) You must get approval for any changes that change the menus. This
> includes renaming items or adding new .desktop files. In other words,
> almost any change to a .desktop file, save translations.

If I understand correctly, this scopes to F-Core packages and any
package which updates a F-Core package, not the run of the mill from
F-Extras.  At this stage of the project (Core == Redhat dominated;
Extras == Community driven) that sounds reasonable.  As that changes I
expect issues to arise such as: who is doing the approval?  What are the
criteria for adding menu entries?

>   b) The menu item should usually be the application's
> generic/descriptive name. For example, use "Web Browser" instead of
> "Mozilla" or "Mozilla Web Browser".
> 
I think this is a backwards decision.  I'm much more in need of seeing a
program's given name in order to decide if I want to run it than it's
generic purpose.  Otherwise, what happens if I've selected two or three
web browsers for my machine?  How do I tell which one "Web Browser" maps
to?  If I want to map another browser to that menu item, I would have to
remap the original to its given name in addition to mapping my new web
browser to the "web browser" entry.

(This is different from mapping an entry to invoke the 'Preferred Web
Browser' into the menu.  In that scenario, _I'd_ have selected which one
it was and there would already be another, specific, entry in the menus
for it when I wanted to change it.)

> 3) If your package is NOT in any of the default package sets:
>   a) The menu name should usually be the application's given name + the
> generic/descriptive name. For example, use "Mozilla Web Browser" instead
> of "Web Browser" or "Mozilla".
> 
Reasonable.  But I don't like the way this differs depending on default
package set/non-default package set.  Just use 'Mozilla Web Browser'
whether it's a default or not.

> 3) The default packages in the  package sets (in the comps file) may not
> include any applications that are functional duplicates. In other words,
> if the user clicks all the package sets in the installer (other than
> everything), they should not end up with two web browsers or two
> spreadsheets in the menus. To give a hypothetical example, lets say we
> shipped Gnumeric as one of the default apps in the "Office" package set.
> In this case OpenOffice.org Calc should not show up in the menus, even
> if the openoffice.org package is installed (presuming we install the
> rest of openoffice by default). One way to address this would be to
> include a separate "openoffice.org-calc" package that simply installs
> a .desktop file.

This solution seems to shift the clutter from the menu into the package
manager: Instead of an extra entry for OOo Calc in the menu we have an
extra package in the system.

As an alternative I propose giving per user menu editing the following
features:

1) 'Defaults view'/'All view' preference toggle on the menus that either
shows the entries redhat has decided are reasonable defaulted on or all
.desktop entries.

2) User is easily able to set entries to be shown in (their private)
Default view from now on.

>   a) Exception: Although KDE and GNOME overlap we include both in
> package sets. To deal with this, we mark smaller utilities and core
> desktop pieces that overlap (e.g. gnome-utils, kdeutils, kdebase,
> kdemultimedia, gnome-media, kdeadmin, etc) with "OnlyShowIn=...". That
> way we still don't get overlapping menu items. By default all items in
> these sort of packages should be marked OnlyShowIn. Ask me about
> specific things you think should be exceptions.
> 
When handling the 'All view' menu preference proposed above, I think we
need to disregard 'OnlyShowIn.'  This allows a user to display tools for
environments other than their own if they want to cherry-pick the one
that is best suited to their needs.

> Some general guidelines:
> 
> - Include a generic version of the name, even if your app isn't install
> by default (e.g. "Mozilla Web Browser").
Reasonable

> - Don't add menu entries for things for the heck of it. For example, the
> number of people who launch emacs from the menus is probably very
> small. ;-) If its mostly launched from the command line (could still be
> an X application, note), don't put it in the menus.
> - Don't add a bunch of entries for the same application unless its a
> really big monster application (like OpenOffice.org). For example,
> KBabel, a translation tool has three menu entries. It shouldn't!
> - Don't have a "_____ Configuration" menu entry (e.g. Chromium
> Configuration). Configuration should be launched from inside the app. If
> its not, cry, but don't add it to the menus ;-)

These guidelines remind me of the following Elliot Lee .signature circa
1997:
  What`s nice about GUI is that you see what you manipulate. 
  What`s bad about GUI is that you can only manipulate what you see. 

The menu provides a GUI to help you find the program you want to run. 
It may not be able to do that very effectively with five hundred web
browsers displayed but it _certainly_can't_ if there's no way to display
the program you want at all.

Unless I misunderstand how menus are generated, a policy that disallows
certain .desktop in the distribution will cause this kind of problem. 
Instead, the .desktops should be installed in the system but contain
information on whether they should _by_default_ be displayed.  That way
it's possible to create GUI'd methods to add or subtract the additional
programs from the menus.

-Toshio
-- 
_______S________U________B________L________I________M________E_______
  t  o  s  h  i  o  +  t  i  k  i  -  l  o  u  n  g  e  .  c  o  m
                                                          GA->ME 1999
-------------- 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/20040516/c21e9ad1/attachment.sig>

From rc040203 at freenet.de  Mon May 17 05:16:14 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 17 May 2004 07:16:14 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
References: <1084343991.3770.10772.camel@mccallum.corsepiu.local>
	<40A1DC3E.4080506@redhat.com> <20040512093104.GA9771@neu.nirvana>
	<orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <1084770974.3817.2141.camel@mccallum.corsepiu.local>

On Fri, 2004-05-14 at 13:37, Nils Philippsen wrote:
> On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:

> > Projects very near to Fedora Core (not "3rd party") like Fedora Extras
> > predecessor fedora.us, and fedoralegacy.org do require more often to
> > have common builds differentiating in the release built against. So
> > disttags are required.
> 
> Not necessarily. When discussing build systems, more than once the idea
> popped up that the maintainer shouldn't care about the release and that
> it would be autogenerated. These kind of build systems would be fed from
> a revision control system where you would put different distro-versions
> into different branches. How the build system generates release tags
> from that is a matter of discussion, but nothing the package maintainer
> should have to care for then.
Fully agreed.

> > And as a community project you cannot keep out of scope "3rd party"
> > repos. They also support multiple releases of Red Hat and Fedora and
> > ths need disttags (not repotags!).
> 
> Not in my opinion.
Neither in mine. IMO, what some people on this thread call "disttag"
actually is the "root distribution's" repotag. What is confusing is the
fact that RH/FC doesn't use an explicit "RH-repotag/disttag", while 3rd
party packagers apply different and partially contradicting "disttag"
conventions.

Having this in mind, I also think, what 3rd party packagers actually
need is a path into a tree of package sets originating from different
repositories, e.g.:

Fedora Core 
|
+-> Fedora Extras -> Local FC+FE Add Ons
+-> ATrpms -> Local FC+ATrpms Add Ons
+-> ....

IMO, the actual questions are: Is there a need to encode these paths
into rpms and if yes how? IMO, yes, there is a need to encode these
paths.

Ralf





From buildsys at redhat.com  Mon May 17 10:57:51 2004
From: buildsys at redhat.com (Build System)
Date: Mon, 17 May 2004 06:57:51 -0400
Subject: rawhide report: 20040517 changes
Message-ID: <200405171057.i4HAvpG15588@porkchop.devel.redhat.com>

 

 
Updated Packages:

rpmdb-fedora-2-0.20040517
-------------------------




From alan at redhat.com  Mon May 17 17:52:01 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 17 May 2004 13:52:01 -0400
Subject: Kudzu issue
In-Reply-To: <20040514222139.GA8539@loonybin.org>
References: <20040514222139.GA8539@loonybin.org>
Message-ID: <20040517175201.GA1667@devserv.devel.redhat.com>

On Fri, May 14, 2004 at 06:21:39PM -0400, Peter Arremann wrote:
> the drivers by hand and then run kudzu. it will try to reconfigure the 
> device. Ignore that. Then use ifconfig to up the device (no IP required)
> and then rerun kudzu.. it should work this time - at least on the 2 cards
> I've tried that fixed the problem.

Gak.. does lspci -vxx show the cards are in D3 (sleeping) state at this
point (post the dump for the chip please). Could be there are cases
where we need power management to turn on the chip before using it




From Axel.Thimm at ATrpms.net  Mon May 17 18:26:11 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Mon, 17 May 2004 20:26:11 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <1084770974.3817.2141.camel@mccallum.corsepiu.local>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
Message-ID: <20040517182611.GJ26400@neu.nirvana>

On Mon, May 17, 2004 at 07:16:14AM +0200, Ralf Corsepius wrote:
> On Fri, 2004-05-14 at 13:37, Nils Philippsen wrote:
> > On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:
> > > And as a community project you cannot keep out of scope "3rd
> > > party" repos. They also support multiple releases of Red Hat and
> > > Fedora and ths need disttags (not repotags!).
> > 
> > Not in my opinion.

> Neither in mine. IMO, what some people on this thread call "disttag"
> actually is the "root distribution's" repotag. What is confusing is
> the fact that RH/FC doesn't use an explicit "RH-repotag/disttag",
> while 3rd party packagers apply different and partially
> contradicting "disttag" conventions.

No, please don't add to this confusion by defining disttags to be
repotags of some kind.

For simplicity's sake forget about repotag, their current
usage/existance etc. The repotag serves no real technical
functionality.

The disttag OTOH is the tools for automatically maintaining upgrade
paths even when building from the same specfile into multiple
different distributions.

E.g. you build foo against FC1's and FC2's glibc and want to build
from FC1 to be rpm-older than the one from FC2.

You achive this by either carefully choosing release tags (say "3" for
FC1, "4" for FC2) which leads to different specfiles/src.rpm etc., and
non-predictable release tags ("which one fixed the xyz issue? Release
3 or 4?").

Or you pick the same release tag (for example "3") and add a different
suffix that will always be rpm-less for FC1 than for FC2 like "fc1"
and "fc2". The packages are now called foo-1.2-3.fc1 and foo-1.2-3.fc2
and you know that the true buildid is the "3" which can be used in
ranged dependencies (Requires: foo >= 1.2-3). And the upgrade paths
are always pertained.

> Having this in mind, I also think, what 3rd party packagers actually
> need is a path into a tree of package sets originating from different
> repositories, e.g.:
> 
> Fedora Core 
> |
> +-> Fedora Extras -> Local FC+FE Add Ons
> +-> ATrpms -> Local FC+ATrpms Add Ons
> +-> ....
> 
> IMO, the actual questions are: Is there a need to encode these paths
> into rpms and if yes how? IMO, yes, there is a need to encode these
> paths.

The above quote is about repotags, don't confuse them with
disttags. And no, repotags are not really needed. Some users think it
is better/easier for identifying package origin, some packagers need
them for their vanity. ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040517/66b4d5eb/attachment.sig>

From brads at redhat.com  Mon May 17 16:29:51 2004
From: brads at redhat.com (Brad Smith)
Date: Mon, 17 May 2004 12:29:51 -0400
Subject: Fedora Tracker (big) Update
Message-ID: <1084811390.12450.69.camel@localhost.localdomain>

Hey folks,

Well, I've been working off-and-on for the last couple of months to
implement feedback I've gotten from people on this list, along with a
few features that I've deemed necessary. 

All-in-all I think things have worked out pretty nicely and believe that
tracker is just about ready for prime-time. I'd like everybody to take a
look at the latest changes and report any problems or major suggestions
asap. If nobody gives me a good reason not to, I'm going to start
shouting from the rooftops in an attempt to make the resource known and
we can start seeing how it handles under an actual load. 

One known issue is that a few repositories like the livna non-us didn't
index when I rebuilt the db. I'm working on it.

The url, as always is: http://www.fedoratracker.org/


Changelog highlights follow:
=========================================================================
* The repo search page now has an option to generate apt/yum config
files for matching repos.

* Package and repo description search fields now support negation by
prepending '!' to any non-regex criteron. For example, you can search
for "game !rpg !puzzle".

* Package name searches are regex searches by default, so a search for
"gnome" will match *gnome* instead of nothing.

* There is no longer a field for searching by filename in the package
search dialog. Removing the need to join the repo and package tables
with the file table (which at last count had about 1.4 million records!)
has _vastly_ improved search performance. Look for searching by filename
to be added as its own search mode soon.

* The repo and package search pages now have fields for searching by
Fedora release number. These fields default to searching version 1
repositories. This will change once FC2 and co become more widely used.

* To prevent users from accidentally installing unstable packages, any
repo with "unstable", "testing" or "bleeding" in the description will be
skipped in repo or package searches by default. This is changable with a
checkbox. Eventually I would like to have a simple unstable/stable (or
something like that) chooser for when repos are added instead of
searching repo description. For now, just mind your wording when adding
a new repo (and DO use those keywords where appropriate!!) 

* On the back-end I am just working the final kinks out of having
tracker-process recognize and update the db entries for repositories
that have added or removed packages. 



Some things on my TODO (in rough order of priority):
===========================================================================
* Some repos didn't index when the db was rebuilt. Fix.

* Add a new search mode for searching by filename

* Change the various search interfaces to be static html pages instead
of modes of the script. This should improve performance under heavy
loads.

* The requires,provides and obsoletes fields are now stored for each
package, but currently nothing is done with them. I'd like to at least
let the user print out their values, similarly to how the changelog
field is currently handled.

* (probably related to #1) Currently some repos fail to index because
tracker-process.py doesn't provide a useragent string. Fix. 



Thanks in advance to anyone who can help out,
-- Brad 




From brads at redhat.com  Mon May 17 16:50:51 2004
From: brads at redhat.com (Brad Smith)
Date: Mon, 17 May 2004 12:50:51 -0400
Subject: Fedora Tracker (big) Update
In-Reply-To: <20040517193527.GA12235@osiris.silug.org>
References: <1084811390.12450.69.camel@localhost.localdomain>
	<20040517193527.GA12235@osiris.silug.org>
Message-ID: <1084812650.13685.0.camel@localhost.localdomain>

On Mon, 2004-05-17 at 15:35, Steven Pritchard wrote:
> On Mon, May 17, 2004 at 12:29:51PM -0400, Brad Smith wrote:
> > * (probably related to #1) Currently some repos fail to index because
> > tracker-process.py doesn't provide a useragent string. Fix. 
> 
> I had to remove the block on empty user agents...  Apparently anaconda
> doesn't send a user agent header when it requests stage2.img, so I
> couldn't do net installs.  (I didn't figure this out until I tried to
> do an x86_64 net install.  Apparently squid on my firewall had the
> i386 version cached, so my i386 installs were working fine.  Fun
> stuff...)
> 
> Steve

Ok. Good to know. I'll still try and fix it so at least repo maintainers
will know who to yell at if tracker starts banging on their servers too
often. =;)

--Brad




From morance at gmail.com  Mon May 17 20:08:04 2004
From: morance at gmail.com (Morteza A. Nia)
Date: Tue, 18 May 2004 00:38:04 +0430
Subject: Searching 4 Fedora core 2
Message-ID: <acc2639004051713085dbe6ec4@mail.gmail.com>

I'm using fedora core 2 test 3 , but i wanna core 2 ( real version ).
where can i find it. I wanna to achive it before its schedule! ;)




From jkeating at j2solutions.net  Mon May 17 21:40:30 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 17 May 2004 14:40:30 -0700
Subject: Searching 4 Fedora core 2
In-Reply-To: <acc2639004051713085dbe6ec4@mail.gmail.com>
References: <acc2639004051713085dbe6ec4@mail.gmail.com>
Message-ID: <200405171440.30647.jkeating@j2solutions.net>

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

On Monday 17 May 2004 13:08, Morteza A. Nia wrote:
> I'm using fedora core 2 test 3 , but i wanna core 2 ( real version ).
> where can i find it. I wanna to achive it before its schedule! ;)

It's not released yet.

- -- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key          
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAqTFO4v2HLvE71NURAuc4AJwPMk9KlJRdBbaRqgq99sNRtggImACgw+VF
qeQK4Rp4BqcT+BcDlYP0XDI=
=4QlX
-----END PGP SIGNATURE-----




From morance at gmail.com  Mon May 17 22:01:58 2004
From: morance at gmail.com (Morteza A. Nia)
Date: Tue, 18 May 2004 02:31:58 +0430
Subject: Searching 4 Fedora core 2
In-Reply-To: <200405171440.30647.jkeating@j2solutions.net>
References: <acc2639004051713085dbe6ec4@mail.gmail.com>
	<200405171440.30647.jkeating@j2solutions.net>
Message-ID: <acc263900405171501370dec3@mail.gmail.com>

i know It's not released yet, but i can't waitin 4 other developer's
work, because i temp. online, and the schedule say that it must
released before. now, I'm hacking test3, but I heared that Core 2
stable is now avaiable , but not on the public ftp (!)
 ;)

On Mon, 17 May 2004 14:40:30 -0700, Jesse Keating
<jkeating at j2solutions.net> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On Monday 17 May 2004 13:08, Morteza A. Nia wrote:
> > I'm using fedora core 2 test 3 , but i wanna core 2 ( real version ).
> > where can i find it. I wanna to achive it before its schedule! ;)
> 
> It's not released yet.
> 
> - --
> Jesse Keating RHCE      (http://geek.j2solutions.net)
> Fedora Legacy Team      (http://www.fedoralegacy.org)
> GPG Public Key
> (http://geek.j2solutions.net/jkeating.j2solutions.pub)
> 
> Was I helpful?  Let others know:
> http://svcs.affero.net/rm.php?r=jkeating
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFAqTFO4v2HLvE71NURAuc4AJwPMk9KlJRdBbaRqgq99sNRtggImACgw+VF
> qeQK4Rp4BqcT+BcDlYP0XDI=
> =4QlX
> -----END PGP SIGNATURE-----
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>




From feliciano.matias at free.fr  Mon May 17 22:33:42 2004
From: feliciano.matias at free.fr (Matias Feliciano)
Date: Tue, 18 May 2004 00:33:42 +0200
Subject: Searching 4 Fedora core 2
In-Reply-To: <acc263900405171501370dec3@mail.gmail.com>
References: <acc2639004051713085dbe6ec4@mail.gmail.com>
	<200405171440.30647.jkeating@j2solutions.net>
	<acc263900405171501370dec3@mail.gmail.com>
Message-ID: <1084833221.5875.16.camel@localhost.localdomain>

Le mar 18/05/2004 ? 00:01, Morteza A. Nia a ?crit :
> i know It's not released yet, but i can't waitin 4 other developer's
> work, because i temp. online, and the schedule say that it must
> released before. now, I'm hacking test3, but I heared that Core 2
> stable is now avaiable , but not on the public ftp (!)
>  ;)

Wait until tomorrow :
http://fedora.redhat.com/participate/schedule/

offline : try this :
http://kuix.de/fedora/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040518/6225072a/attachment.sig>

From loony at loonybin.org  Mon May 17 23:23:34 2004
From: loony at loonybin.org (Peter Arremann)
Date: Mon, 17 May 2004 19:23:34 -0400
Subject: Kudzu issue
In-Reply-To: <20040517175201.GA1667@devserv.devel.redhat.com>
References: <20040514222139.GA8539@loonybin.org>
	<20040517175201.GA1667@devserv.devel.redhat.com>
Message-ID: <200405171923.34631.loony@loonybin.org>

Alan,

The chip we're looking at is a RealTek 8139... 
here is the lspci -vxx output you asked for on bootup (hacked
the init script so it ran just before kudzu started). 

00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        Flags: bus master, medium devsel, latency 32, IRQ 11
        I/O ports at b800 [size=256]
        Memory at ee800000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2
00: ec 10 39 81 07 00 90 02 10 00 00 02 00 20 00 00
10: 01 b8 00 00 00 00 80 ee 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 39 81
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 20 40


Peter.


On Monday 17 May 2004 13:52, Alan Cox wrote:
> On Fri, May 14, 2004 at 06:21:39PM -0400, Peter Arremann wrote:
> > the drivers by hand and then run kudzu. it will try to reconfigure the
> > device. Ignore that. Then use ifconfig to up the device (no IP required)
> > and then rerun kudzu.. it should work this time - at least on the 2 cards
> > I've tried that fixed the problem.
>
> Gak.. does lspci -vxx show the cards are in D3 (sleeping) state at this
> point (post the dump for the chip please). Could be there are cases
> where we need power management to turn on the chip before using it




From naoki at valuecommerce.com  Tue May 18 01:42:49 2004
From: naoki at valuecommerce.com (Naoki)
Date: Tue, 18 May 2004 10:42:49 +0900
Subject: Anaconda (kickstart handling) idea.
Message-ID: <40A96A19.4040302@valuecommerce.com>

Hi all,

    I've got one idea and one problem, first the idea is I want pass 
something like this upon booting from CD :
"linux ks=http://website/" 

And then I want anaconda to show me the directory listing and let me 
select a kickstart file.

The problem I have is I don't know python. I'm looking inside stage 2 
and I'm taking a gander at "usr/lib/anaconda/kickstart.py" but I think 
I'm in the wrong place. 

Could anybody point me in the right direction?
-n.




From rc040203 at freenet.de  Tue May 18 04:28:17 2004
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 18 May 2004 06:28:17 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040517182611.GJ26400@neu.nirvana>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
Message-ID: <1084854496.3817.4155.camel@mccallum.corsepiu.local>

On Mon, 2004-05-17 at 20:26, Axel Thimm wrote:
> On Mon, May 17, 2004 at 07:16:14AM +0200, Ralf Corsepius wrote:
> > On Fri, 2004-05-14 at 13:37, Nils Philippsen wrote:
> > > On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:
> > > > And as a community project you cannot keep out of scope "3rd
> > > > party" repos. They also support multiple releases of Red Hat and
> > > > Fedora and ths need disttags (not repotags!).
> > > 
> > > Not in my opinion.
> 
> > Neither in mine. IMO, what some people on this thread call "disttag"
> > actually is the "root distribution's" repotag. What is confusing is
> > the fact that RH/FC doesn't use an explicit "RH-repotag/disttag",
> > while 3rd party packagers apply different and partially
> > contradicting "disttag" conventions.
> 
> No, please don't add to this confusion by defining disttags to be
> repotags of some kind.
> 
> For simplicity's sake forget about repotag, their current
> usage/existance etc. The repotag serves no real technical
> functionality.
To reiterate: I think distinguishing between "disttags" and
"repotags" is meaningless, it's all about repotags, only. 

In my understanding "disttags" actually are a special case of repotags:
The repotag of the "root" of the repository hierarchy your packages are
using.

> The disttag OTOH is the tools for automatically maintaining upgrade
> paths even when building from the same specfile into multiple
> different distributions.
This does not contradict to what I wrote above.

> You achive this by either carefully choosing release tags (say "3" for
> FC1, "4" for FC2) which leads to different specfiles/src.rpm etc., and
> non-predictable release tags ("which one fixed the xyz issue? Release
> 3 or 4?").
> 
> Or you pick the same release tag (for example "3") and add a different
> suffix that will always be rpm-less for FC1 than for FC2 like "fc1"
> and "fc2". The packages are now called foo-1.2-3.fc1 and foo-1.2-3.fc2
> and you know that the true buildid is the "3" which can be used in
> ranged dependencies (Requires: foo >= 1.2-3). And the upgrade paths
> are always pertained.
OK, an example of how I see it:

Consider you are building add-on packages to Fedora Core N

Dependency tree:
FCN -> AddOns

Fedora Core N repotag: fcN.
Add On repotag: AddOn.

A convention on release tags could be: <repotag><number>

This would result into a release tag similar to this:
fcN.<fcN-id>.AddOn.<AddOn-id>

What might confuse you is me regarding "fcN" as "repotag" and not "fc"
as you seem to be seeing it.

Another part of confusion might stem from RH/FC currently not using any
repotag/disttag (which could be interpreted as "empty") and Fedora.US
trying to add one.

Ralf





From mattdm at mattdm.org  Tue May 18 06:13:22 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 18 May 2004 02:13:22 -0400
Subject: Anaconda (kickstart handling) idea.
In-Reply-To: <40A96A19.4040302@valuecommerce.com>
References: <40A96A19.4040302@valuecommerce.com>
Message-ID: <20040518061322.GA803@jadzia.bu.edu>

On Tue, May 18, 2004 at 10:42:49AM +0900, Naoki wrote:
>    I've got one idea and one problem, first the idea is I want pass 
> something like this upon booting from CD :
> "linux ks=http://website/" 
> And then I want anaconda to show me the directory listing and let me 
> select a kickstart file.
> The problem I have is I don't know python. I'm looking inside stage 2 
> and I'm taking a gander at "usr/lib/anaconda/kickstart.py" but I think 
> I'm in the wrong place. 

Lucky you -- this functionality should take place in the first-stage
installer, which is written in plain C -- no python knowledge needed. Look
in the "loader2" subdirectory. 

There's also a mailing list for anaconda development specifically -- you
might want to join that.


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




From ckloiber at ckloiber.com  Tue May 18 08:07:13 2004
From: ckloiber at ckloiber.com (Chris Kloiber)
Date: Tue, 18 May 2004 16:07:13 +0800
Subject: Anaconda (kickstart handling) idea.
In-Reply-To: <20040518061322.GA803@jadzia.bu.edu>
References: <40A96A19.4040302@valuecommerce.com>
	<20040518061322.GA803@jadzia.bu.edu>
Message-ID: <1084867633.26603.13.camel@galileo.ckloiber.com>

On Tue, 2004-05-18 at 14:13, Matthew Miller wrote:
> On Tue, May 18, 2004 at 10:42:49AM +0900, Naoki wrote:
> >    I've got one idea and one problem, first the idea is I want pass 
> > something like this upon booting from CD :
> > "linux ks=http://website/"
> > And then I want anaconda to show me the directory listing and let me 
> > select a kickstart file.
> > The problem I have is I don't know python. I'm looking inside stage 2 
> > and I'm taking a gander at "usr/lib/anaconda/kickstart.py" but I think 
> > I'm in the wrong place. 
> 
> Lucky you -- this functionality should take place in the first-stage
> installer, which is written in plain C -- no python knowledge needed. Look
> in the "loader2" subdirectory. 
> 
> There's also a mailing list for anaconda development specifically -- you
> might want to join that.

Mind you that the whole idea of kickstart is to be non-interactive when
done correctly, and your idea blows that to smithereens. I think you
could better use DNS to select the best ks.cfg, see man dhcpd.conf,
although that would be less flexible.

-- 
Chris Kloiber





From Axel.Thimm at ATrpms.net  Tue May 18 09:25:36 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 18 May 2004 11:25:36 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <1084854496.3817.4155.camel@mccallum.corsepiu.local>
References: <20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<1084854496.3817.4155.camel@mccallum.corsepiu.local>
Message-ID: <20040518092536.GA10709@neu.nirvana>

On Tue, May 18, 2004 at 06:28:17AM +0200, Ralf Corsepius wrote:
> On Mon, 2004-05-17 at 20:26, Axel Thimm wrote:
> > On Mon, May 17, 2004 at 07:16:14AM +0200, Ralf Corsepius wrote:
> > > On Fri, 2004-05-14 at 13:37, Nils Philippsen wrote:
> > > > On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:
> > > > > And as a community project you cannot keep out of scope "3rd
> > > > > party" repos. They also support multiple releases of Red Hat and
> > > > > Fedora and ths need disttags (not repotags!).
> > > > 
> > > > Not in my opinion.
> > 
> > > Neither in mine. IMO, what some people on this thread call "disttag"
> > > actually is the "root distribution's" repotag. What is confusing is
> > > the fact that RH/FC doesn't use an explicit "RH-repotag/disttag",
> > > while 3rd party packagers apply different and partially
> > > contradicting "disttag" conventions.
> > 
> > No, please don't add to this confusion by defining disttags to be
> > repotags of some kind.
> > 
> > For simplicity's sake forget about repotag, their current
> > usage/existance etc. The repotag serves no real technical
> > functionality.

> To reiterate: I think distinguishing between "disttags" and
> "repotags" is meaningless, it's all about repotags, only. 

Well, what you define as a repotag is what the rest of us call a
disttag. Please use the nomenclature common on this list. Possible
disttags are fc1, fc2, el3 etc., they are an abbreviated rpm-sortable
id for a release (sortable within a distribution family, like FC vs
RHEL) ensuring proper upgrade paths as discussed in this thread.

(optional!) repotags are "fr", "ccrma", "at", ..., denoting origin and
should not enter the discussion about disttags! :)
They also serve not technical functionality at all!

So if you want to build packages, you can do

o Red Hat style:              no adorning at all               foo-1.2.3-4
o With disttags:              using for instance "fc1", "fc2": foo-1.2.3-4.fc1
o With disttags and repotags: using "ralf" as repotag:         foo-1.2.4-4.fc1.ralf

Just start packaging for FC1 and FC2 and you will find out what the
merits of a disttag are (and you will be crying for one ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040518/cd8d4650/attachment.sig>

From nietzel at rhinobox.org  Tue May 18 09:32:54 2004
From: nietzel at rhinobox.org (Earle Robert Nietzel)
Date: Tue, 18 May 2004 11:32:54 +0200
Subject: Menu Policy - please read if you maintain a package with a
	.desktop file in it!
In-Reply-To: <1084540890.16881.53.camel@binkley>
References: <1084485872.5572.13.camel@localhost.localdomain>
	<20040514000639.GA1123340@hiwaay.net>
	<1084493474.16881.1.camel@binkley>
	<1084495159.5572.20.camel@localhost.localdomain>
	<1084500439.16881.7.camel@binkley>
	<1084540123.22855.9.camel@nexus.verbum.private>
	<1084540890.16881.53.camel@binkley>
Message-ID: <1084872774.3256.13.camel@ws001.rhinobox.org>

> Moreover, what if they already have a preferred application? But it's
> not the 'preferred one' by your standards. How are they supposed to find
> it?
> 

Maybe all that needs to be done is expand the "Preferred Applications"
app where it will dynamically recognize all apps installed for a
particular "user function".

For example imagine a user function such as a web browser:

When the user enters into preferred apps they see every recognizable
browser that is installed on the OS. From this point there could be a
radial button that allows the user to:

1) view the default app for this function
2) view all installed apps for this function
 or
3) view only the selected apps for this function

This covers the basic users who will normally use the default, to users
want everything, to users who want just certain apps shown in the menu.

-ern




From aoliva at redhat.com  Tue May 18 11:43:11 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 18 May 2004 08:43:11 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040517182611.GJ26400@neu.nirvana>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
Message-ID: <or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>

On May 17, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

> Or you pick the same release tag (for example "3") and add a different
> suffix that will always be rpm-less for FC1 than for FC2 like "fc1"
> and "fc2". The packages are now called foo-1.2-3.fc1 and foo-1.2-3.fc2
> and you know that the true buildid is the "3" which can be used in
> ranged dependencies (Requires: foo >= 1.2-3).

Oh, that's what you want disttags for?  Sorry, but it isn't going to
work.

Consider that FC3 shipped with say foo-1.2-7.fc3.  FC4 will probably
undergo a few mass rebuilds, which will make foo-1.2-9.fc4 the package
in FC4.  While FC5 is under development, a security problem is found
in foo, and the patch is back-ported into FC3 and FC4.

I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1
and foo-1.2-10.fc5 (rawhide), all of them containing the fix.  You
can't just use the version tag to identify packages containing the
fix.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From rdieter at math.unl.edu  Tue May 18 13:15:54 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 18 May 2004 08:15:54 -0500 (CDT)
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
 rpms)
In-Reply-To: <or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>

On Tue, 18 May 2004, Alexandre Oliva wrote:

> Oh, that's what you want disttags for?  Sorry, but it isn't going to
> work.

I disagree, it certainly can work, if used properly.  This is exactly 
what many 3rd party repos are doing *right now*.

> Consider that FC3 shipped with say foo-1.2-7.fc3.  FC4 will probably
> undergo a few mass rebuilds, which will make foo-1.2-9.fc4 the package
> in FC4.  While FC5 is under development, a security problem is found
> in foo, and the patch is back-ported into FC3 and FC4.
> 
> I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1
> and foo-1.2-10.fc5 (rawhide), all of them containing the fix.  You
> can't just use the version tag to identify packages containing the
> fix.

I think you miss the point.  The point is to be able to release the 
"fixed" version as:
foo-1.2-10.%{dist_tag} 
Isn't that *much* cleaner/simpler than your 7.fc3, 9.fc4, 10.fc5 example?

-- Rex




From Axel.Thimm at ATrpms.net  Tue May 18 14:04:06 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 18 May 2004 16:04:06 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
References: <20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <20040518140406.GG5654@neu.nirvana>

On Tue, May 18, 2004 at 08:43:11AM -0300, Alexandre Oliva wrote:
> On May 17, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> 
> > Or you pick the same release tag (for example "3") and add a different
> > suffix that will always be rpm-less for FC1 than for FC2 like "fc1"
> > and "fc2". The packages are now called foo-1.2-3.fc1 and foo-1.2-3.fc2
> > and you know that the true buildid is the "3" which can be used in
> > ranged dependencies (Requires: foo >= 1.2-3).
> 
> Oh, that's what you want disttags for?

One of its used, yes (I enumerated some at the start of this thread ;)

> Sorry, but it isn't going to work.
> 
> Consider that FC3 shipped with say foo-1.2-7.fc3.  FC4 will probably
> undergo a few mass rebuilds,

Gotya! One of the other uses for a disttag is tha a mass-rebuild does
not need to bump the release tag of each innocent rpm, but can have
them bumped through the disttag, for example:

fc2.89.103 (the 103rd mass rebuild in fc3 developement)
New glibc gets pushed out, command to rebuild every rpms gets out.
Elliot changes disttag to fc2.89.104, hits a button on the build
system and goes to have some coffee or tee.

This scenario is not science fiction, it already works with the
existing disttag schemes.

But that is "just another use" of disttags.
> I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1
> and foo-1.2-10.fc5 (rawhide), all of them containing the fix.  You
> can't just use the version tag to identify packages containing the
> fix.

If the buggy version was foo-1.2-7, then the fixed is

foo-1.2-8.fc3
foo-1.2-8.fc4
foo-1.2-8.fc4.89.105

The idea is that trivial changes like rebuilds don't even need to bumb
the release tag (or the buildid component).

It does become trickier, if the different distros are based on
different _upstream versions_ and you have a policy of non-upgrading,
but only minimal backports (like RHEL or RHL). While this is not the
usual case with FC's policies, one must admit that this cannot be
fixed with disttags, you have genuine functional forks at differnt
timelines in this case.

Hey, disttags aren't considered the solution to everything, they only
make life easier, but not yet trivial ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040518/533273d4/attachment.sig>

From Axel.Thimm at ATrpms.net  Tue May 18 14:10:28 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 18 May 2004 16:10:28 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
References: <orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
Message-ID: <20040518141028.GH5654@neu.nirvana>

On Tue, May 18, 2004 at 08:15:54AM -0500, Rex Dieter wrote:
> On Tue, 18 May 2004, Alexandre Oliva wrote:
> 
> > Oh, that's what you want disttags for?  Sorry, but it isn't going to
> > work.
> 
> I disagree, it certainly can work, if used properly.  This is exactly 
> what many 3rd party repos are doing *right now*.

Yes, I always forget to underline that the disttag scheme is in place
by almost all repos, (including fedora.us, aka not only the external
"3rd parties") using the benefits outlined throughout this thread.

So it already got the field test for longer than a year now.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040518/83462a52/attachment.sig>

From jkeating at j2solutions.net  Tue May 18 14:56:37 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 18 May 2004 07:56:37 -0700
Subject: Anaconda (kickstart handling) idea.
In-Reply-To: <40A96A19.4040302@valuecommerce.com>
References: <40A96A19.4040302@valuecommerce.com>
Message-ID: <200405180756.37172.jkeating@j2solutions.net>

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

On Monday 17 May 2004 18:42, Naoki wrote:
>     I've got one idea and one problem, first the idea is I want pass
> something like this upon booting from CD :
> "linux ks=http://website/"
>
> And then I want anaconda to show me the directory listing and let me
> select a kickstart file.
>
> The problem I have is I don't know python. I'm looking inside stage 2
> and I'm taking a gander at "usr/lib/anaconda/kickstart.py" but I think
> I'm in the wrong place.
>
> Could anybody point me in the right direction?

Instead of that, why not do what many of us do.  Syslinux supports a menu 
file, that you can display to the screen.  This menu file could 'list' a 
bunch of pre-known (at burn time) kickstart options.  The person booting 
the CD could then type the menu item they wish to use to kickstart, and 
syslinux will load the appropriate kernel/initrd and use the correct 
kickstart config file from the web server.

This can even be done over PXE, which is even quicker and easier to update 
(don't have to redistribute a bunch of CDs)

Does this solution satisfy your need?

- -- 
Jesse Keating RHCE	(http://geek.j2solutions.net)
Fedora Legacy Team	(http://www.fedoralegacy.org)
GPG Public Key		(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAqiQl4v2HLvE71NURAq9WAJwPmPbCIMyc+1oZGCIWzAF/x3OC8ACdGVIy
wLuDmK7LGlEacQZFChXIY6k=
=R6gx
-----END PGP SIGNATURE-----




From rms at 1407.org  Tue May 18 15:28:51 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Tue, 18 May 2004 16:28:51 +0100
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
Message-ID: <1084894131.4105.76.camel@roque>

If this is true, then it should be considered a bug. I'll investigate
later...

-------- Forwarded Message --------
From: Richard Allen <ra at ra.is>
Reply-To: For users of Fedora Core releases <fedora-list at redhat.com>
To: For users of Fedora Core releases <fedora-list at redhat.com>
Subject: Re: Opinion: NVIDIA drivers are a Good Thing [tm]
Date: Tue, 18 May 2004 15:01:52 +0000
On Tue, May 18, 2004 at 03:08:36PM +0100, Rui Miguel Seabra wrote:

> > Well..   Ever since firstboot came along, I'm forced to accept the terms
> > of the GPL (which I love, respect and admire) before ever getting
> > a login prompt.
> 
> No! No, you don't.
> 
> With the GNU GPL the author gives you an unilateral license to run the
> software for any purpose.

Im aware of the rights the GPL gives me and also of the restrictions it
imposes.   My point was that Fedora pop's up a window with a Licence
I need to accept before I can start using the product.  (again, I havent
tried to refuse here, so I cant say what happens)

Which is prehaps a bad thing, considering this clause from the GPL:

"5.  You are not required to accept this License, since you have not signed
it. However, nothing else grants you permission to modify or distribute the
Program or its derivative works. These actions are prohibited by law if you
do not accept this License. Therefore, by modifying or distributing the
Program (or any work based on the Program), you indicate your acceptance of
this License to do so, and all its terms and conditions for copying,
distributing or modifying the Program or works based on it."

I can imagine whats going thru the heads of people not familiar with the
GPL and see that legal-speak window pop up.  "What Freedom?" :)

Rui
-------------- 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/20040518/6c34afaa/attachment.sig>

From katzj at redhat.com  Tue May 18 15:33:34 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 18 May 2004 11:33:34 -0400
Subject: Anaconda (kickstart handling) idea.
In-Reply-To: <40A96A19.4040302@valuecommerce.com>
References: <40A96A19.4040302@valuecommerce.com>
Message-ID: <1084894413.2681.9.camel@bree.local.net>

On Tue, 2004-05-18 at 10:42 +0900, Naoki wrote:
>     I've got one idea and one problem, first the idea is I want pass 
> something like this upon booting from CD :
> "linux ks=http://website/" 
> 
> And then I want anaconda to show me the directory listing and let me 
> select a kickstart file.

One problem with this is that you're not guaranteed to get a directory
listing.  In fact, even if you do, it's likely to be an HTML document.
This makes things a lot more tricky.

> The problem I have is I don't know python. I'm looking inside stage 2 
> and I'm taking a gander at "usr/lib/anaconda/kickstart.py" but I think 
> I'm in the wrong place. 

Yep, the kickstart config gets pulled before the second stage (so that
you can know where to get the second stage from).  So look in the
loader2 directory which is all C.

I'm not completely convinced of the viability, though, for some of the
other reasons stated in the thread.

Cheers,

Jeremy




From brads at redhat.com  Tue May 18 12:37:41 2004
From: brads at redhat.com (Brad Smith)
Date: Tue, 18 May 2004 08:37:41 -0400
Subject: Anaconda (kickstart handling) idea.
In-Reply-To: <1084867633.26603.13.camel@galileo.ckloiber.com>
References: <40A96A19.4040302@valuecommerce.com>
	<20040518061322.GA803@jadzia.bu.edu>
	<1084867633.26603.13.camel@galileo.ckloiber.com>
Message-ID: <1084883861.3697.44.camel@localhost.localdomain>


> Mind you that the whole idea of kickstart is to be non-interactive when
> done correctly, and your idea blows that to smithereens. I think you
> could better use DNS to select the best ks.cfg, see man dhcpd.conf,
> although that would be less flexible.


...a couple of other suggestions:

Remember that the other end of the url you give kickstart doesn't need
to be a static file. It can be a cgi script that writes a custom ks.cfg
based on url arguments, dns, subnet, or whatever.

Also, I once had a student who wrote self-writing kickstart files. by
having the %pre script modify /tmp/ks.cfg based on, well, whatever. 

That said, while I agree that the point of kickstart is to be
non-interactive, I don't think it would "blow that out of the water" to
have one non-default mode of operation that employs an interactive, but
very useful, menu system with less trouble than burning a custom
boot.iso every time you want to add an option.

--Brad






From kbn at daimi.au.dk  Tue May 18 15:51:21 2004
From: kbn at daimi.au.dk (kbn at daimi.au.dk)
Date: Tue, 18 May 2004 17:51:21 +0200
Subject: Anaconda (kickstart handling) idea.
In-Reply-To: <1084883861.3697.44.camel@localhost.localdomain>
References: <40A96A19.4040302@valuecommerce.com>	<20040518061322.GA803@jadzia.bu.edu>	<1084867633.26603.13.camel@galileo.ckloiber.com>
	<1084883861.3697.44.camel@localhost.localdomain>
Message-ID: <40AA30F9.2090208@daimi.au.dk>



Brad Smith wrote:

>>Mind you that the whole idea of kickstart is to be non-interactive when
>>done correctly, and your idea blows that to smithereens. I think you
>>could better use DNS to select the best ks.cfg, see man dhcpd.conf,
>>although that would be less flexible.
>>    
>>
Shouldn't that be DHCP, not DNS ?? :)
Actually it's quite easy to use dhcp to select the correct kickstart 
file. I've included a working example from our dhcp server:

group {
  option domain-name-servers 10.0.0.10;
  # Server where kickstart file resides
  next-server kickstartserver;
  # Kickstart filename
  filename 
"/a/home/kickstartserver/RedHat/kickstart/delta_frontier_1200-6.2.ks";
  # Router (gateway)
  option routers centauri;

  host whatever {
                hardware ethernet 00:00:00:00:00:00;
                fixed-address whatever;
        
}                                                                                                                                              

}

I've anonymized the data, for our own protection, but the example should 
be quite easy to follow. Please notice, that kickstartserver is the 
server, where the kickstartfile resides. In our setup, it's also the 
server where the install files is located, and the same server also runs 
an apache  server, which  only serves to provide the install files via http.

Another way is to use pxe installation:

http://www.stanford.edu/~alfw/PXE-Kickstart/PXE-Kickstart.html#toc6

I prefer to use pxe installation, as I can sit on my flat butt, when 
proberly configured, and reinstall all the machines...

>
>
>...a couple of other suggestions:
>
>Remember that the other end of the url you give kickstart doesn't need
>to be a static file. It can be a cgi script that writes a custom ks.cfg
>based on url arguments, dns, subnet, or whatever.
>
>Also, I once had a student who wrote self-writing kickstart files. by
>having the %pre script modify /tmp/ks.cfg based on, well, whatever. 
>
>That said, while I agree that the point of kickstart is to be
>non-interactive, I don't think it would "blow that out of the water" to
>have one non-default mode of operation that employs an interactive, but
>very useful, menu system with less trouble than burning a custom
>boot.iso every time you want to add an option.
>
>--Brad
>
>
>  
>

In our setup, we also loads a custom %post script into the kickstart 
file, to setup the machine to our liking...

Regards
/kbn




From buildsys at redhat.com  Tue May 18 17:51:46 2004
From: buildsys at redhat.com (Build System)
Date: Tue, 18 May 2004 13:51:46 -0400
Subject: rawhide report: 20040518 changes
Message-ID: <200405181751.i4IHpkk03402@porkchop.devel.redhat.com>

 

 
Updated Packages:

Canna-3.7p1-7
-------------
* Wed Apr 14 2004 Akira TAGOH <tagoh at redhat.com> 3.7p1-7

- updates cannadic-0.95b

* Sun Mar 21 2004 Florian La Roche <Florian.LaRoche at redhat.de> 3.7p1-6

- apps owned by root instead of bin

* Wed Mar 17 2004 Akira TAGOH <tagoh at redhat.com> 3.7p1-5

- Canna-3.7p1-fix-duplicated-strings.patch: applied a backport patch from CVS.
  when the characters like 'bbb...' is deleted, the preedit strings is
  duplicated. (#117140)


GConf2-2.6.0-5
--------------
* Fri Apr 16 2004 Colin Walters <walters at redhat.com> - 2.6.0-5

- Apply patch to move temporary directory creation into daemon,
  needed for SELinux GConf policy

abiword-2.0.6-1
---------------
* Wed Apr 28 2004 Caolan McNamara <caolanm at redhat.com> 1:2.0.6-1

- 2.0.6, 64bit changes made upstream

alsa-lib-1.0.4-1
----------------
* Mon May 17 2004 Colin Walters <walters at redhat.com> 1.0.4-1

- New upstream version

apr-0.9.4-12
------------
* Thu May 13 2004 Joe Orton <jorton at redhat.com> 0.9.4-12

- use APR_LARGEFILE in apr_file_{copy,append}

* Wed Mar 24 2004 Joe Orton <jorton at redhat.com> 0.9.4-11

- add APR_LARGEFILE flag

* Mon Mar 15 2004 Joe Orton <jorton at redhat.com> 0.9.4-10

- fix configure check for mmap of /dev/zero
- just put -D_GNU_SOURCE in CPPFLAGS not _{BSD,SVID,XOPEN}_SOURCE


arts-1.2.2-3
------------
* Thu May 13 2004 Than Ngo <than at redhat.com> 1.2.2-3

- add patch to enable PIE build of artsd

at-3.1.8-54
-----------
* Wed May 12 2004 Thomas Woerner <twoerner at redhat.com> - 3.1.8-54

- fixed pie patch: at is pie, now
- added build requires for libselinux-devel

authconfig-4.6.3-1
------------------
* Tue May 11 2004 Nalin Dahyabhai <nalin at redhat.com> 4.6.3-1

- omit the "ads" or "rpc" when calling "net join", Samba's smarter now (#122802)
- properly warn about missing "net" (samba-client) and libnss_winbind and
  pam_winbind (samba-common) in text mode (#122802)

automake-1.8.4-1
----------------
* Thu May 13 2004 Jens Petersen <petersen at redhat.com> - 1.8.4-1

- update to 1.8.4

binutils-2.15.90.0.3-6
----------------------
* Sat May 15 2004 Jakub Jelinek <jakub at redhat.com> 2.15.90.0.3-6

- fix a bug introduced in the ++/-- rejection patch
  from 2.15.90.0.3 (Alan Modra)

bootparamd-0.17-16
------------------
* Fri May 14 2004 Thomas Woerner <twoerner at redhat.com> 0.17-16

- compiling PIE

cadaver-0.22.1-2
----------------
* Wed May 12 2004 Joe Orton <jorton at redhat.com> 0.22.1-2

- build as PIE

* Tue Apr 20 2004 Joe Orton <jorton at redhat.com> 0.22.1-1

- update to 0.22.1

cdrtools-2.01-0.a27.4
---------------------
* Thu May 06 2004 Harald Hoyer <harald at redhat.com> - 8:2.01-0.a27.4

- provide dvdrecord with a stub to cdrecord

coreutils-5.2.1-8
-----------------
* Mon May 17 2004 Thomas Woerner <twoerner at redhat.com> 5.2.1-8

- compiling su PIE

* Wed May 12 2004 Tim Waugh <twaugh at redhat.com>

- Build requires new versions of autoconf and automake (bug #123098).

cups-1.1.20-7
-------------
* Tue May 11 2004 Tim Waugh <twaugh at redhat.com> 1:1.1.20-7

- Fix non-conformance with HTTP/1.1, which caused failures when printing
  to a Xerox Phaser 8200 via IPP (bug #122352).
- Make lppasswd(1) PIE.
- Rotate logs within cupsd (instead of relying on logrotate) if we start
  to approach the filesystem file size limit (bug #123003).

cyrus-sasl-2.1.18-3
-------------------
* Thu May 13 2004 Thomas Woerner <twoerner at redhat.com> 2.1.18-3

- removed rpath

dbh-1.0.18-3
------------
* Thu May 13 2004 Than Ngo <than at redhat.com> 1:1.0.18-3

- get rid of rpath

dhcp-3.0.1rc12-6
----------------
* Mon May 17 2004 Thomas Woerner <twoerner at redhat.com> 1:3.0.1rc12-6

- compiling dhcpd PIE

* Thu Mar 25 2004 Dan Walsh <dwalsh at redhat.com> 1:3.0.1rc12-5

- Add static routes patch to dhclient-script

doxygen-1.3.7-1
---------------
* Tue May 11 2004 Than Ngo <than at redhat.com> 1.3.7-1

- update to 1.3.7, bug #119340

dvdrtools-0.1.4-6
-----------------
* Wed Apr 07 2004 Harald Hoyer <harald at redhat.com> - 0.1.4-6

- made dvdrecord a stub to cdrecord
- changed manpage accordingly

gaim-0.77-7
-----------
* Sun May 09 2004 Warren Togami <wtogami at redhat.com> 0.77-7

- CVS backport 121: byte order badness and crashing copy & paste fix
               122: history.so scroll to bottom in new tabs fix

gdm-2.6.0.0-4
-------------
* Mon May 17 2004 Than Ngo <than at redhat.com> 1:2.6.0.0-4

- add patch to build gdm-binary with PIE

gedit-2.6.1-1
-------------
* Sat May 15 2004 Dan Williams <dcbw at redhat.com> 1:2.6.1-1

- Upgrade to 2.6.1

ggv-2.6.1-1
-----------
* Sat May 15 2004 Dan Williams <dcbw at redhat.com> 2.6.1-1

- Update to 2.6.1

glibc-kernheaders-2.4-8.46
--------------------------
* Wed Apr 21 2004 Jakub Jelinek <jakub at redhat.com> 2.4-8.46

- ppc/ppc64 mq_* syscall numbers

* Fri Apr 16 2004 Jakub Jelinek <jakub at redhat.com> 2.4-8.45

- update syscall numbers from latest kernel
- remove ia32.h and ia32_unistd.h on x86-64

gnome-audio-2.0.0-1
-------------------
* Thu May 13 2004 Colin Walters <walters at redhat.com>

- Upgrade to 2.0.0.

gnumeric-1.2.12-1
-----------------
* Wed May 05 2004 Caolan McNamara <caolanm at redhat.com> 1.2.12

- update to 1.2.12 some exported excel workbooks will not work in Excel
with older versions
_ delete unused patches

* Tue Apr 13 2004 Warren Togami <wtogami at redhat.com> 1.2.8-2

- #74034 own plugin dir
- #111112 BR intltool scrollkeeper gettext desktop-file-utils
- some cleanup

gok-0.11.2-1
------------
* Fri May 14 2004 Colin Walters <walters at redhat.com> 0.11.2-1

- New upstream version
- Use htmlview instead of mozilla directly
- BuildRequires gnome-speech-devel

gstreamer-plugins-0.8.1-2
-------------------------
* Fri May 07 2004 Colin Walters <walters at redhat.com> 0.8.1-2

- Apply patch to fix memleaks

gv-3.5.8-27
-----------
* Fri May 14 2004 Dan Williams <dcbw at redhat.com> 3.5.8-27

- display empty page when input file has size 0 (#100538)

* Fri May 14 2004 Dan Williams <dcbw at redhat.com> 3.5.8-26

- fix argv array size (#80672)

initscripts-7.54-1
------------------
* Thu May 13 2004 Than Ngo <than at redhat.com> 7.54-1

- add patch to enable PIE build of usernetctl

inn-2.3.5-10
------------
* Mon May 17 2004 Thomas Woerner <twoerner at redhat.com> 2.3.5-10

- compiling server and suid programs PIE

iproute-2.4.7-15
----------------
* Thu May 06 2004 Phil Knirsch <pknirsch at redhat.com> 2.4.7-15

- rebuilt

* Thu May 06 2004 Phil Knirsch <pknirsch at redhat.com> 2.4.7-13.2

- Built security errata version for FC1.

iputils-20020927-15
-------------------
* Wed May 12 2004 Phil Knirsch <pknirsch at redhat.com> 20020927-15

- Updated rh patch to enable PIE build of binaries.

* Thu Apr 22 2004 Phil Knirsch <pknirsch at redhat.com> 20020927-14

- Fixed bug with wrong return code check of inet_pton() in traceroute6 (#100684)

isdn4k-utils-3.2-15.p1.1
------------------------
* Thu May 13 2004 Than Ngo <than at redhat.com> 3.2-15.p1.1

- add patch to enable PIE build of userisdnctl

* Tue May 11 2004 Than Ngo <than at redhat.com> 3.2-14.p1.1

- fixed usage message in isdndial, bug #122987

joe-3.0-1.1
-----------
* Wed Apr 28 2004 Lon Hohberger <lhh at redhat.com> 3.0-1.1

- Kill ancient configure scripts in tarball to cause it to build on 
ppc64.

* Wed Apr 28 2004 Lon Hohberger <lhh at redhat.com> 3.0-1

- Import of 3.0 upstream.
- Removed zero-rc patch for now; it doesn't correctly fix the
  problem.
- Merge new SELinux patch from Dan Walsh.

k3b-0.11.9-4
------------
* Thu May 13 2004 Than Ngo <than at redhat.com> 0.11.9-4

- get rid of rpath

kdbg-1.2.9-5
------------
* Thu May 13 2004 Than Ngo <than at redhat.com> 1.2.9-5

- get rid of rpath
- add correct smp flags

kdebase-3.2.2-5
---------------
* Mon May 17 2004 Than Ngo <than at redhat.com> 6:3.2.2-5

- add patch to enable PIE build of kdm

kdelibs-3.2.2-7
---------------
* Mon May 17 2004 Than Ngo <than at redhat.com> 6:3.2.2-7

- add patch to enable PIE

* Sun May 16 2004 Than Ngo <than at redhat.com> 6:3.2.2-6

- vulnerability in the mailto handler, CAN-2004-0411

* Fri May 14 2004 Than Ngo <than at redhat.com> 3.2.2-5

- KDE Telnet URI Handler File Vulnerability , CAN-2004-0411


kernel-2.6.6-1.368
------------------

koffice-1.3.1-2
---------------
* Thu May 13 2004 Than Ngo <than at redhat.com> 1.3.1-2

- get rid of rpath

* Tue May 04 2004 Than Ngo <than at redhat.com> 1.3.1-1

- update to 1.3.1

kon2-0.3.9b-24
--------------
* Wed May 12 2004 Akira TAGOH <tagoh at redhat.com> 0.3.9b-24

- kon2-0.3.9b-fld-fonttype.patch: applied to fix the segfaults fld when fonttype
  isn't specified. (#121211) (-23)
- kon2-0.3.9b-pie.patch: PIE support for suid programs.

krb5-1.3.3-3
------------
* Wed May 12 2004 Thomas Woerner <twoerner at redhat.com> 1.3.3-3

- removed rpath

* Thu Apr 15 2004 Nalin Dahyabhai <nalin at redhat.com> 1.3.3-2

- re-enable large file support, fell out in 1.3-1
- patch rcp to use long long and %lld format specifiers when reporting file
  sizes on large files

libgnome-2.6.0-3
----------------
* Sat May 15 2004 Colin Walters <walters at redhat.com> 2.6.0-3

- Apply another patch which fixes GNOME sound events, which
  due to what appears to be a glib bug, were broken by my
  previous patch.

* Tue Apr 13 2004 Colin Walters <walters at redhat.com> 2.6.0-2

- Apply my patch to fix --disable-sound property from HEAD

* Thu Apr 01 2004 Alex Larsson <alexl at redhat.com> 2.6.0-1

- update to 2.6.0


libtool-1.5.6-2
---------------
* Thu May 13 2004 Thomas Woerner <twoerner at redhat.com> - 1.5.6-2

- compile libltdl.a PIC

libxml2-2.6.9-1
---------------
* Mon Apr 19 2004 Daniel Veillard <veillard at redhat.com>

- upstream release 2.6.9 see http://xmlsoft.org/news.html

* Thu Jan 02 2003 Daniel Veillard <veillard at redhat.com>

- integrated drv_libxml2 xml.sax driver from St?phane Bidoul
- provides the new XmlTextReader interfaces based on C# XML APIs

* Wed Oct 23 2002 Daniel Veillard <veillard at redhat.com>

- revamped the spec file, cleaned up some rpm building problems


libxslt-1.1.6-1
---------------
* Mon Apr 19 2004 Daniel Veillard <veillard at redhat.com>

- upstream release 1.1.6 see http://xmlsoft.org/XSLT/news.html

* Sun Nov 02 2003 Daniel Veillard <veillard at redhat.com>

- cleanup, removal of the deprecated breakpoint library and
  automated libxml2 dependancy level in the generated spec file.

* Wed Oct 23 2002 Daniel Veillard <veillard at redhat.com>

- revamped the spec file, cleaned up some rpm building problems


memtest86+-1.15-1
-----------------
* Sun May 16 2004 Warren Togami <wtogami at redhat.com> 1.15-1

- update to 1.15

net-snmp-5.1.1-3
----------------
* Thu May 06 2004 Phil Knirsch <pknirsch at redhat.com> 5.1.1-3

- Reworked the perl filelist stuff (Thanks to marius feraru).

net-tools-1.60-27
-----------------
* Fri May 14 2004 Phil Knirsch <pknirsch at redhat.com> 1.60-27

- Fixed compiler warning/error in netplug.
- Updated to netplug-1.2.6 for security update and fixes.

* Thu May 06 2004 Phil Knirsch <pknirsch at redhat.com> 1.60-26

- Updated netplugd to latest upstream version.
- Fixed execshield problem in main.c of netplugd.

nut-2.0.0-2
-----------
* Mon May 10 2004 Than Ngo <than at redhat.com> 2.0.0-2

- fixed permission problem, bug #122867

openldap-2.1.29-2
-----------------
* Fri Apr 16 2004 Nalin Dahyabhai <nalin at redhat.com> 2.1.29-2

- move rfc documentation from main to -devel (#121025)

oprofile-0.8-20040511.4
-----------------------
* Tue May 11 2004 Will Cohen <wcohen at redhat.com>

- Remove wildcards in the file manifests.
- Correct build directory.
- Use the 0.8 release tarball.

* Tue Mar 23 2004 Will Cohen <wcohen at redhat.com>

- Bump version and rebuild.

parted-1.6.11-1
---------------
* Thu May 13 2004 Jeremy Katz <katzj at redhat.com> - 1.6.11-1

- update to 1.6.11

* Tue May 11 2004 Jeremy Katz <katzj at redhat.com> - 1.6.9-4

- add patch from Matt Domsch to not use the get/set last sector ioctls 
  with a 2.6 kernel (#121455)

pccts-1.33mr33-9
----------------
* Thu Apr 22 2004 Karsten Hopp <karsten at redhat.de> 1.33mr33-9

- fix syntax (#115960)

perl-Compress-Zlib-1.33-5
-------------------------
* Wed Apr 21 2004 Joe Orton <jorton at redhat.com> 1.33-5

- use system zlib

policy-1.11.3-5
---------------
* Mon May 10 2004 Dan Walsh <dwalsh at redhat.com> 1.11.3-5

- Allow dvd mounts

* Mon May 10 2004 Dan Walsh <dwalsh at redhat.com> 1.11.3-4

- Fix relabel for bind mounts 
- More fixes

* Fri May 07 2004 Dan Walsh <dwalsh at redhat.com> 1.11.3-3

- Eliminate bind mounts from relabel


policycoreutils-1.11-4
----------------------
* Mon May 10 2004 Dan Walsh <dwalsh at redhat.com> 1.11-4

- Move location of log file to /var/tmp

* Mon May 10 2004 Dan Walsh <dwalsh at redhat.com> 1.11-3

- Better grep command for bind

ppp-2.4.2-2.2
-------------
* Fri May 14 2004 Thomas Woerner <twoerner at redhat.com> 2.4.2-2.2

- compiled pppd and chat PIE

* Thu May 13 2004 Thomas Woerner <twoerner at redhat.com> 2.4.2-2.1

- added 'missingok' to ppp.logrotate (#122911)

procps-3.2.1-4
--------------
* Fri Apr 09 2004 Colin Walters <walters at redhat.com> 3.2.1-4

- Add little patch to make w/who work when getattr access
  to /proc/<pid> for the user's login process is denied

* Sun Mar 28 2004 Dan Walsh <dwalsh at redhat.com> 3.2.1-3

- bump for rhel3

* Sun Mar 28 2004 Dan Walsh <dwalsh at redhat.com> 3.2.1-2

- Removed addtask patch, very buggy,
- Added FAQ to docdir


pyparted-1.6.7-1
----------------
* Thu May 13 2004 Jeremy Katz <katzj at redhat.com> - 1.6.7-1

- fix build for newer versions of gcc (fix from Jeff Law)

qt-3.3.2-4
----------
* Wed May 12 2004 Than Ngo <than at redhat.com> 1:3.3.2-4

- backport some qt patches, Symbol font works again

* Mon May 10 2004 Than Ngo <than at redhat.com> 1:3.3.2-3

- fixed annoying warning

rarpd-ss981107-17
-----------------
* Wed May 12 2004 Phil Knirsch <pknirsch at redhat.com> ss981107-17

- Enabled PIE compilation and linking.

rdate-1.4-1
-----------
* Mon Mar 22 2004 Elliot Lee <sopwith at redhat.com> 1.4-1

- Timeout (-t) patch from Johan Nilsson <joh-nils at dsv.su.se>

* Wed Jan 29 2003 Phil Knirsch <pknirsch at redhat.com> 1.3-2

- Bump release and rebuild.

* Wed Nov 06 2002 Elliot Lee <sopwith at redhat.com> 1.3-1

- New release


rpmdb-fedora-2-0.20040518
-------------------------

rsh-0.17-22
-----------
* Wed May 12 2004 Phil Knirsch <pknirsch at redhat.com> 0.17-22

- Added all other tools to list of PIE enabled apps.

rwall-0.17-20
-------------
* Wed May 12 2004 Phil Knirsch <pknirsch at redhat.com>  0.17-20

- Enabled PIE for server and application.
- Switch from Copyright to License.

rwho-0.17-21
------------
* Wed May 12 2004 Phil Knirsch <pknirsch at redhat.com> 0.17-21

- Enabled PIE for server and application.

swig-1.3.21-1
-------------
* Tue May 04 2004 Phil Knirsch <pknirsch at redhat.com>

- Update to swig-1.3.21

talk-0.17-24
------------
* Wed May 12 2004 Phil Knirsch <pknirsch at redhat.com> 0.17-24

- Enables PIE for server and application.

tcl-8.4.6-1
-----------
* Thu May 13 2004 Jens Petersen <petersen at redhat.com> - 8.4.6-1

- update to 8.4.6

tomcat-4.1.27-14
----------------
* Tue May 11 2004 Gary Benson <gbenson at redhat.com> 4.1.27-14

- Correct usage message in daemon (#114628).
- Detect HTTP requests to the AJP port and report them to the user.

* Mon May 10 2004 Gary Benson <gbenson at redhat.com>

- Fix a breakage in the testsuite's AJP library.
- Temporarily disable the load test testcase.

traceroute-1.4a12-22
--------------------
* Wed May 12 2004 Phil Knirsch <pknirsch at redhat.com> 1.4a12-22

- Enabled PIE for traceroute.

tvtime-0.9.12-6
---------------
* Mon Apr 19 2004 Than Ngo <than at redhat.com> 0.9.12-6

- add BuildRequires: libxml2-devel, bug #121237

urw-fonts-2.2-1
---------------
* Tue May 11 2004 Than Ngo <than at redhat.com> 2.2-1

- Upgrade to upstream version 1.0.7pre26, bug #122500
- drop NimbusRomNo9L-Medi* fonts that are included in pre26

w3m-0.5.1-1
-----------
* Thu May 06 2004 Akira TAGOH <tagoh at redhat.com> 0.5.1-1

- New upstream release.

xffm-4.0.5-2
------------
* Thu May 13 2004 Than Ngo <than at redhat.com> 4.0.5-2

- get rid of rpath
- fix gcc34 build problem

* Thu Apr 15 2004 Than Ngo <than at redhat.com> 4.0.5-1

- update to 4.0.5

* Thu Mar 11 2004 Than Ngo <than at redhat.com> 4.0.3-4

- fixed gcc-3.4 build problem


xinitrc-3.40-1
--------------
* Fri May 07 2004 Mike A. Harris <mharris at redhat.com> 3.40-1

- Modified xinitrc and Xsession scripts to only source files with .sh
  extensions in /etc/X11/xinit/xinitrc.d/* so that backup files that are
  created when hand editing the scripts, aren't executed. (FC2BLOCKER

xmlsec1-1.2.5-1
---------------
* Mon Apr 19 2004 Daniel Veillard <veillard at redhat.com> 1.2.5-1

- updated with upstream release from Aleksey

* Wed Feb 11 2004 Daniel Veillard <veillard at redhat.com> 1.2.4-1

- updated with upstream release from Aleksey

* Tue Jan 06 2004 Daniel Veillard <veillard at redhat.com> 1.2.3-1

- updated with upstream release from Aleksey


ypserv-2.13-1
-------------
* Mon May 17 2004 Thomas Woerner <twoerner at redhat.com> 2.13-1

- compiling rpc.yppasswdd, rpc.ypxfrd, yppush and ypserv PIE

* Fri Apr 16 2004 Steve Dickson <SteveD at RedHat.com>

- Updated to 2.13




From Jochen at herr-schmitt.de  Tue May 18 18:53:47 2004
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Tue, 18 May 2004 20:53:47 +0200
Subject: rawhide report: 20040518 changes
In-Reply-To: <200405181751.i4IHpkk03402@porkchop.devel.redhat.com>
References: <200405181751.i4IHpkk03402@porkchop.devel.redhat.com>
Message-ID: <E1BQ9io-00020l-00@mrelayng.kundenserver.de>

On Tue, 18 May 2004 13:51:46 -0400, you wrote:

>inn-2.3.5-10
>------------
>* Mon May 17 2004 Thomas Woerner <twoerner at redhat.com> 2.3.5-10
>
>- compiling server and suid programs PIE

Question: Are there no plans to release the version 2.4.1 of INN?

Best Regards:

Jochen Schmitt




From aoliva at redhat.com  Tue May 18 18:58:23 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 18 May 2004 15:58:23 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
Message-ID: <ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>

On May 18, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:

> On Tue, 18 May 2004, Alexandre Oliva wrote:
>> Oh, that's what you want disttags for?  Sorry, but it isn't going to
>> work.

> I disagree, it certainly can work, if used properly.  This is exactly 
> what many 3rd party repos are doing *right now*.

Yeah, but they do it in a totally different way.

The way 3rd party repos do it is to have the very same sources built
for multiple OS versions.

The way updates may be created is to take whatever shipped, install
the patch that fixes the problem and rebuild that.  This is more work,
but it reduces the risk of instabilities and undesirable changes that
upgrading to a newer version of the package represents.

Sure enough, Fedora Core updates aren't required to follow the
procedures that used to be followed for Red Hat Linux errata, and that
are still followed for Red Hat Enterprise Linux, but sometimes it's
just the right thing to do.

>> I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1
>> and foo-1.2-10.fc5 (rawhide), all of them containing the fix.  You
>> can't just use the version tag to identify packages containing the
>> fix.

> I think you miss the point.  The point is to be able to release the 
> "fixed" version as:
> foo-1.2-10.%{dist_tag} 
> Isn't that *much* cleaner/simpler than your 7.fc3, 9.fc4, 10.fc5 example?

It sort-of implies you use the same sources for all of the different
OSs.  This isn't necessarily a good idea.  So the approach doesn't
work in the general case.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From aoliva at redhat.com  Tue May 18 19:01:22 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 18 May 2004 16:01:22 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040518140406.GG5654@neu.nirvana>
References: <20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518140406.GG5654@neu.nirvana>
Message-ID: <orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>

On May 18, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

>> I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1
>> and foo-1.2-10.fc5 (rawhide), all of them containing the fix.  You
>> can't just use the version tag to identify packages containing the
>> fix.

> If the buggy version was foo-1.2-7, then the fixed is

> foo-1.2-8.fc3
> foo-1.2-8.fc4
> foo-1.2-8.fc4.89.105

All of the above had the bug and have to be fixed, and -8 won't do it
for them.

> The idea is that trivial changes like rebuilds don't even need to bumb
> the release tag (or the buildid component).

That's good.  But it still doesn't cover the case of patches being
added to the package, which is what got foo-1.2 bumped from -7 to -9
between FC3 and FC4.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From rdieter at math.unl.edu  Tue May 18 19:01:40 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 18 May 2004 14:01:40 -0500 (CDT)
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
 rpms)
In-Reply-To: <ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <Pine.LNX.4.58.0405181400080.30778@math.unl.edu>

On Tue, 18 May 2004, Alexandre Oliva wrote:

> On May 18, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
> > On Tue, 18 May 2004, Alexandre Oliva wrote:
> >> Oh, that's what you want disttags for?  Sorry, but it isn't going to
> >> work.
> 
> > I disagree, it certainly can work, if used properly.  This is exactly 
> > what many 3rd party repos are doing *right now*.
> 
> Yeah, but they do it in a totally different way.
> 
> The way 3rd party repos do it is to have the very same sources built
> for multiple OS versions.

Yes, exactly.  In the case where that is not true, dist_tags are 
harmless, so this shouldn't be used as an argument against using them.
 
-- Rex




From aoliva at redhat.com  Tue May 18 19:08:38 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 18 May 2004 16:08:38 -0300
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1084894131.4105.76.camel@roque>
References: <1084894131.4105.76.camel@roque>
Message-ID: <orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>

On May 18, 2004, Rui Miguel Seabra <rms at 1407.org> wrote:

> If this is true, then it should be considered a bug. I'll investigate
> later...

You're not required to accept the GNU GPL to run the code.  The GNU
GPL explicitly says that anything but copying, distribution and
modification are outside of its scope, and that the act of running the
program is not restricted.

If you have to accept the terms of the GNU GPL in order to run the
program, that's a bug.  But then, by the time you get to firstboot,
you've already run a lot of code, and you can easily skip running
firstboot, for example, by performing a kickstart install.  I haven't
seen firstboot running for quite a few releases :-)

That said, if firstboot presents you with the GNU GPL and shuts the
system down if you don't agree with it, that's a bug.  If it's some
other license (e.g., /usr/share/doc/fedora-release-*/eula.txt), then
it's ok, since that's what sets the terms of use of the collection of
software called Fedora Core.


#include <std/IANAL>

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From arjanv at redhat.com  Tue May 18 19:12:50 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Tue, 18 May 2004 21:12:50 +0200
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <1084907570.2781.10.camel@laptop.fenrus.com>

On Tue, 2004-05-18 at 21:08, Alexandre Oliva wrote:
> On May 18, 2004, Rui Miguel Seabra <rms at 1407.org> wrote:
> 
> > If this is true, then it should be considered a bug. I'll investigate
> > later...
> 
> You're not required to accept the GNU GPL to run the code.  The GNU
> GPL explicitly says that anything but copying, distribution and
> modification are outside of its scope, and that the act of running the
> program is not restricted.

Well in most of Europe, copying the binary code from disk to ram or from
ram to CPU is distributing as explicit part of copyright law ;)
-------------- 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/20040518/2481ca0b/attachment.sig>

From ckloiber at ckloiber.com  Tue May 18 19:34:58 2004
From: ckloiber at ckloiber.com (Chris Kloiber)
Date: Wed, 19 May 2004 03:34:58 +0800
Subject: Anaconda (kickstart handling) idea.
In-Reply-To: <40AA30F9.2090208@daimi.au.dk>
References: <40A96A19.4040302@valuecommerce.com>
	<20040518061322.GA803@jadzia.bu.edu>
	<1084867633.26603.13.camel@galileo.ckloiber.com>
	<1084883861.3697.44.camel@localhost.localdomain>
	<40AA30F9.2090208@daimi.au.dk>
Message-ID: <1084908898.4430.28.camel@roadrash.rdu.redhat.com>

On Tue, 2004-05-18 at 23:51, kbn at daimi.au.dk wrote:
> Brad Smith wrote:
> 
> >>Mind you that the whole idea of kickstart is to be non-interactive when
> >>done correctly, and your idea blows that to smithereens. I think you
> >>could better use DNS to select the best ks.cfg, see man dhcpd.conf,
> >>although that would be less flexible.
> >>    
> >>
> Shouldn't that be DHCP, not DNS ?? :)

Ya, I was not completely in my right mind yesterday. 
Least I got the config file right.

-- 
Chris Kloiber





From aoliva at redhat.com  Tue May 18 19:44:48 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 18 May 2004 16:44:48 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
Message-ID: <orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>

On May 18, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:

> Yes, exactly.  In the case where that is not true, dist_tags are 
> harmless, so this shouldn't be used as an argument against using them.
 
Not *totally* harmless.

Wasn't there a problem in the way old versions of rpm compared say 
-1.foo with -1.1.foo?

If you use disttags, and you have to patch a package such that the
R number goes in between two R numbers that are already out, and you
can't just append the build number at the end for the reasons Axel
already exposed, and you can't add `.number' before the disttag, what
do you do?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From aoliva at redhat.com  Tue May 18 19:50:25 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 18 May 2004 16:50:25 -0300
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1084907570.2781.10.camel@laptop.fenrus.com>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084907570.2781.10.camel@laptop.fenrus.com>
Message-ID: <orn045jz0e.fsf@free.redhat.lsd.ic.unicamp.br>

On May 18, 2004, Arjan van de Ven <arjanv at redhat.com> wrote:

> On Tue, 2004-05-18 at 21:08, Alexandre Oliva wrote:
>> On May 18, 2004, Rui Miguel Seabra <rms at 1407.org> wrote:
>> 
>> > If this is true, then it should be considered a bug. I'll investigate
>> > later...
>> 
>> You're not required to accept the GNU GPL to run the code.  The GNU
>> GPL explicitly says that anything but copying, distribution and
>> modification are outside of its scope, and that the act of running the
>> program is not restricted.

> Well in most of Europe, copying the binary code from disk to ram or from
> ram to CPU is distributing as explicit part of copyright law ;)

distributing?  I could understand copying, but distributing?!?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From Axel.Thimm at ATrpms.net  Tue May 18 20:27:33 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 18 May 2004 22:27:33 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <20040518202733.GS5654@neu.nirvana>

On Tue, May 18, 2004 at 04:44:48PM -0300, Alexandre Oliva wrote:
> On May 18, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
> > Yes, exactly.  In the case where that is not true, dist_tags are 
> > harmless, so this shouldn't be used as an argument against using them.
>  
> Not *totally* harmless.
> 
> Wasn't there a problem in the way old versions of rpm compared say 
> -1.foo with -1.1.foo?

Yes, so avoid comparing numbers and letters. OTOH it affects rpms
Versions up to RH8.0 w/o errata upgrades. So probably one can consider
this a corner case.

> If you use disttags, and you have to patch a package such that the
> R number goes in between two R numbers that are already out,

Why would you do that? Say you have foo-1.2.3-4 and foo-1.2.3-5 and
the fix comes out, you suggest foo-1.2.3-4.1 and
foo-1.2.3-5.1. Wouldn't that make foo-1.2.3-5, one of the versions
with the security vulnerability overwrite the fixed version from
foo-1.2.3-4.1?

E.g. I have a secury FC3 and use an (outdated) FC4 installation medium
to upgrade my system. Until I fire up the updater postinstallation my
box is vulnerable.

So it is better to reach for higher bumbs in these cases.

There is nothing you can do, if the upstream version differs (other
that doing the wrong thing, bumping epochs).

> and you can't just append the build number at the end for the
> reasons Axel already exposed, and you can't add `.number' before the
> disttag, what do you do?

As said, this is an old corner stone, and using dotted releases should
be considered deprecated anyway.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040518/5291e76f/attachment.sig>

From rdieter at math.unl.edu  Tue May 18 20:30:20 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 18 May 2004 15:30:20 -0500 (CDT)
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
 rpms)
In-Reply-To: <orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>

On Tue, 18 May 2004, Alexandre Oliva wrote:

> On May 18, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
> > Yes, exactly.  In the case where that is not true, dist_tags are 
> > harmless, so this shouldn't be used as an argument against using them.
>  
> Not *totally* harmless.
> 
> Wasn't there a problem in the way old versions of rpm compared say 
> -1.foo with -1.1.foo?

I believe rpm-4.0 had a problem like what you describe.  However, since 
redhat no longer supports anything with rpm-4.0, this should also be a 
non-issue, right?  (-:

Besides, the case you mention case easily be avoided.  *Always* use the 
same # of significant digits/dots in front of dist tag and/or simply 
increment the release, so you end up with either
-1.0.foo -> -1.1.foo
or
-1.foo -> -2.foo

> If you use disttags, and you have to patch a package such that the
> R number goes in between two R numbers that are already out, and you
> can't just append the build number at the end for the reasons Axel
> already exposed, and you can't add `.number' before the disttag, what
> do you do?

No problem.  (-:  Migrating *to* disttags actually helps in this 
case, and you avoid the problem you mentioned above because there is no 
existing dist_tag.  Example, foo-1-3 and foo-1-5 are released now.  
Release patched version as:
foo-1-3.0.%{dist_tag}

-- Rex




From Axel.Thimm at ATrpms.net  Tue May 18 20:33:21 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 18 May 2004 22:33:21 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>
References: <20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518140406.GG5654@neu.nirvana>
	<orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <20040518203321.GT5654@neu.nirvana>

On Tue, May 18, 2004 at 04:01:22PM -0300, Alexandre Oliva wrote:
> On May 18, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> 
> >> I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1
> >> and foo-1.2-10.fc5 (rawhide), all of them containing the fix.  You
> >> can't just use the version tag to identify packages containing the
> >> fix.
> 
> > If the buggy version was foo-1.2-7, then the fixed is
> 
> > foo-1.2-8.fc3
> > foo-1.2-8.fc4
> > foo-1.2-8.fc4.89.105
> 
> All of the above had the bug and have to be fixed, and -8 won't do it
> for them.

No, there would not have been the -9 and -10 versions (because the
rebuilds are controlled via the disttag).

Otherwise use "11" instead of "8".

> > The idea is that trivial changes like rebuilds don't even need to bumb
> > the release tag (or the buildid component).
> 
> That's good.  But it still doesn't cover the case of patches being
> added to the package, which is what got foo-1.2 bumped from -7 to -9
> between FC3 and FC4.

I still believe in common specfiles and src.rpm, so I would make the
application of patches conditional on the disttag, or the environment
probing, e.g. apply ntpl patches only if built on an ntpl platform.

And if that is not an acceptable solution, well, disttags cannot solve
everything for you, you've got to do also something ;)

The bottom line is disttags bring a lot of benefits as can bee seen in
their implementation in the wild, have caused no harm, and come at
very little expense.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040518/31c9e668/attachment.sig>

From aoliva at redhat.com  Tue May 18 21:33:37 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 18 May 2004 18:33:37 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040518202733.GS5654@neu.nirvana>
References: <1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518202733.GS5654@neu.nirvana>
Message-ID: <orisetju8e.fsf@free.redhat.lsd.ic.unicamp.br>

On May 18, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

>> If you use disttags, and you have to patch a package such that the
>> R number goes in between two R numbers that are already out,

> Why would you do that? Say you have foo-1.2.3-4 and foo-1.2.3-5 and
> the fix comes out, you suggest foo-1.2.3-4.1 and
> foo-1.2.3-5.1. Wouldn't that make foo-1.2.3-5, one of the versions
> with the security vulnerability overwrite the fixed version from
> foo-1.2.3-4.1?

> E.g. I have a secury FC3 and use an (outdated) FC4 installation medium
> to upgrade my system. Until I fire up the updater postinstallation my
> box is vulnerable.

The assumption is that someone would immediately apply the FC4
updates, fixing the hole.

But think of fixes instead of security patches.

Consider that -5 had a change to make the package buildable on FC4,
that would break on FC3.

Issuing -5.1 (or 6, for that matter) for both FC3 and FC4 implies it's
newer than 5 for FC4.  Should someone depend on the patch that made it
buildable for FC4, and say so with a Requires: foo >= 1.2.3-5, issuing
the errata as -5.1.FC3 might incorrectly satisfy the requirement.

> As said, this is an old corner stone, and using dotted releases should
> be considered deprecated anyway.

I still think they should be used for the 0.<buildid> case, for *any*
extras that might ever make it to the core (i.e., any extras at all
:-)

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From aoliva at redhat.com  Tue May 18 21:36:11 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 18 May 2004 18:36:11 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040518203321.GT5654@neu.nirvana>
References: <20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518140406.GG5654@neu.nirvana>
	<orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518203321.GT5654@neu.nirvana>
Message-ID: <orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>

On May 18, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

> The bottom line is disttags bring a lot of benefits as can bee seen in
> their implementation in the wild, have caused no harm, and come at
> very little expense.

I don't see benefits for the core proper, and I do see problems.  So
it's not as clear-cut as you say.  The reality of add-on repositories
is quite different because their goal is to use the same package on
multiple OSs.  Issuing updates doesn't work that way.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From Axel.Thimm at ATrpms.net  Tue May 18 21:49:22 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 18 May 2004 23:49:22 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518140406.GG5654@neu.nirvana>
	<orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518203321.GT5654@neu.nirvana>
	<orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <20040518214922.GX5654@neu.nirvana>

On Tue, May 18, 2004 at 06:36:11PM -0300, Alexandre Oliva wrote:
> On May 18, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> 
> > The bottom line is disttags bring a lot of benefits as can bee seen in
> > their implementation in the wild, have caused no harm, and come at
> > very little expense.
> 
> I don't see benefits for the core proper, and I do see problems.  So
> it's not as clear-cut as you say.  The reality of add-on repositories
> is quite different because their goal is to use the same package on
> multiple OSs.  Issuing updates doesn't work that way.

While there are benefits for the core (automatic rawhide rebuilds,
easier identification of fixes due to no unneccessary release bumbing,
common errata), the Fedora project is not only core.

As this is a problem discussed many times in the community and
reaching for Red Hat's participation, you cannot close your scope onto
core only. Common specs and guidelines are needed, and packages should
be technically treated equally, e.g. they should not have to be
rewritten to move to core for example, core, extras, and anything else
should blend in nicely in a canonical scheme.

Anyway this discussion only raised the interest of two Red Hat
developers, which weren't convinced about the idea (although
Alexandre was close at some time). I'd say it still cannot penetrate
into Red Hat, we'll try again in half a year ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040518/182f9c1d/attachment.sig>

From fedora at wir-sind-cool.org  Tue May 18 21:58:26 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Tue, 18 May 2004 23:58:26 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
 rpms)
In-Reply-To: <orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>
References: <20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518140406.GG5654@neu.nirvana>
	<orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518203321.GT5654@neu.nirvana>
	<orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <20040518235826.2e0090b0.fedora@wir-sind-cool.org>

On 18 May 2004 18:36:11 -0300, Alexandre Oliva wrote:

> On May 18, 2004, Axel Thimm <Axel.Thimm at ATrpms.xxx> wrote:
> 
> > The bottom line is disttags bring a lot of benefits as can bee seen in
> > their implementation in the wild, have caused no harm, and come at
> > very little expense.
> 
> I don't see benefits for the core proper, and I do see problems.  So
> it's not as clear-cut as you say.  The reality of add-on repositories
> is quite different because their goal is to use the same package on
> multiple OSs.  Issuing updates doesn't work that way.

Disttags aren't as flexible as advertized, unless you create an ugly
hierarchy such as rh73 < rh80 < rhfc1 < rhfc2 and so on. And that doesn't
include Red Hat Enterprise Linux yet.




From Axel.Thimm at ATrpms.net  Tue May 18 22:08:35 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 19 May 2004 00:08:35 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <20040518235826.2e0090b0.fedora@wir-sind-cool.org>
References: <20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518140406.GG5654@neu.nirvana>
	<orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518203321.GT5654@neu.nirvana>
	<orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518235826.2e0090b0.fedora@wir-sind-cool.org>
Message-ID: <20040518220835.GZ5654@neu.nirvana>

On Tue, May 18, 2004 at 11:58:26PM +0200, Michael Schwendt wrote:
> On 18 May 2004 18:36:11 -0300, Alexandre Oliva wrote:
> 
> > On May 18, 2004, Axel Thimm <Axel.Thimm at ATrpms.xxx> wrote:
> > 
> > > The bottom line is disttags bring a lot of benefits as can bee seen in
> > > their implementation in the wild, have caused no harm, and come at
> > > very little expense.
> > 
> > I don't see benefits for the core proper, and I do see problems.  So
> > it's not as clear-cut as you say.  The reality of add-on repositories
> > is quite different because their goal is to use the same package on
> > multiple OSs.  Issuing updates doesn't work that way.
> 
> Disttags aren't as flexible as advertized, unless you create an ugly
> hierarchy such as rh73 < rh80 < rhfc1 < rhfc2 and so on. And that doesn't
> include Red Hat Enterprise Linux yet.

and it never should, because RHEL is officially unrelated to FC,
e.g. there will be no supported upgrade path between FC and RHEL.

And yes, if you don't make sure the disttags are sorted well within
the considered distribution family then we are not talking about
disttags, so the comment isn't really helpful.

So what's your constructive suggestion?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040519/9f85c6ab/attachment.sig>

From rdieter at math.unl.edu  Wed May 19 03:22:36 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 18 May 2004 22:22:36 -0500
Subject: On disttags
In-Reply-To: <20040518235826.2e0090b0.fedora@wir-sind-cool.org>
References: <20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<20040518140406.GG5654@neu.nirvana>	<orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>	<20040518203321.GT5654@neu.nirvana>	<orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518235826.2e0090b0.fedora@wir-sind-cool.org>
Message-ID: <40AAD2FC.3050001@math.unl.edu>

Michael Schwendt wrote:


> Disttags aren't as flexible as advertized, unless you create an ugly
> hierarchy such as rh73 < rh80 < rhfc1 < rhfc2 and so on. And that doesn't
> include Red Hat Enterprise Linux yet.

Let's leave the merits of disttags and their robust implementation as 
separate discussions.  You're addressing the latter, which certainly 
can, IMO, be done well.

-- Rex




From rdieter at math.unl.edu  Wed May 19 03:23:10 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 18 May 2004 22:23:10 -0500
Subject: On disttags
In-Reply-To: <orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>
References: <20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<20040518140406.GG5654@neu.nirvana>	<orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>	<20040518203321.GT5654@neu.nirvana>
	<orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <40AAD31E.80606@math.unl.edu>

Alexandre Oliva wrote:

> I don't see benefits for the core proper, and I do see problems.  So

What problems?

-- Rex




From shahms at shahms.com  Wed May 19 06:52:34 2004
From: shahms at shahms.com (Shahms E. King)
Date: Tue, 18 May 2004 23:52:34 -0700
Subject: tmscsim module not included?
Message-ID: <1084949554.7542.3.camel@localhost.localdomain>

I knew about the firewire modules, but not having the tmscsim module in
the FC2 kernel caught me completely by surprise.  And it was an
extremely nasty surprise.  One that left my computer *completely
unbootable* in fact.  It seems that when /sbin/new-kernel-pkg can't make
an initial ram disk because the required scsi_hostadapter module isn't
included Anaconda ignores the failure and continues on it's merry way
leaving the old grub.conf in place.  You know, the one that points to
kernels which are no longer present? One would think modules not shipped
with the kernel wouldn't be added to modprobe.conf.  Being without a
SCSI driver is one thing if it isn't stable, but it shouldn't leave the
resulting upgrade unbootable.
-- 
--Shahms




From Bernd.Bartmann at sohanet.de  Wed May 19 08:23:04 2004
From: Bernd.Bartmann at sohanet.de (Bernd Bartmann)
Date: Wed, 19 May 2004 10:23:04 +0200
Subject: Some FC1 security advisories are still missing
Message-ID: <40AB1968.9050509@sohanet.de>

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

It's nice to see that some of the missing FC1 security advisories were
finally posted today:
cvs-1.11.15-1
neon-0.24.5-1
mailman-2.1.4-1

But again at least two advisories are still missing, although the
updates are already available for some time:
postfix-2.0.16-1
tcpdump-3.7.2-8.fc1.2

This again raises the question will we ever get an official FC errata
web-site on fedora.redhat.com?

Best regards.

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

iD8DBQFAqxlokQuIaHu84cIRAuUCAJ9xMlhl9giRdV8zxpv2KWbizBN//gCeMWj1
9K3O41LJaC9BLWthvHf9AEs=
=YgwF
-----END PGP SIGNATURE-----




From alan at redhat.com  Wed May 19 09:35:49 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 19 May 2004 05:35:49 -0400
Subject: tmscsim module not included?
In-Reply-To: <1084949554.7542.3.camel@localhost.localdomain>
References: <1084949554.7542.3.camel@localhost.localdomain>
Message-ID: <20040519093549.GC19761@devserv.devel.redhat.com>

On Tue, May 18, 2004 at 11:52:34PM -0700, Shahms E. King wrote:
> unbootable* in fact.  It seems that when /sbin/new-kernel-pkg can't make
> an initial ram disk because the required scsi_hostadapter module isn't
> included Anaconda ignores the failure and continues on it's merry way
> leaving the old grub.conf in place.  You know, the one that points to
> kernels which are no longer present? One would think modules not shipped
> with the kernel wouldn't be added to modprobe.conf.  Being without a
> SCSI driver is one thing if it isn't stable, but it shouldn't leave the
> resulting upgrade unbootable.

Please bugzilla this.




From harald at redhat.com  Wed May 19 10:45:50 2004
From: harald at redhat.com (Harald Hoyer)
Date: Wed, 19 May 2004 12:45:50 +0200
Subject: Some FC1 security advisories are still missing
In-Reply-To: <40AB1968.9050509@sohanet.de>
References: <40AB1968.9050509@sohanet.de>
Message-ID: <40AB3ADE.6040303@redhat.com>

Bernd Bartmann wrote:
> tcpdump-3.7.2-8.fc1.2

sent




From chabotc at 4-ice.com  Wed May 19 11:36:14 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Wed, 19 May 2004 13:36:14 +0200
Subject: FC2 Final can't get to loading kernel.. New bug?
Message-ID: <001601c43d95$7e581620$0200a8c0@gandalf>

Hi All,

I've used FC2 test 1 and 2 without any problems previously. However when i now try to boot the FC2 (release), it won't even load the kernel, but instantly reboots my system

It get's to the Loading vmlinuz... then loading initrd.. Then, boom, reboots.. (thats just before the "Uncompressing Kernel.." message)

ps i did download the first cd again (from a diff mirror even), burned 2 more copies, checked MD5's.. but nothing's wrong with the media. As mentioned, test 1 and 2 worked fine on this machine, and the hardware didn't change in the meantime

My system details:
P4 3.0 Ghz (HT) Cpu
Intel 865PE + ICH5R chipset
Maxtor 6Y080P0 80Gb (set to ATA 100) HD
3Com 3c9x Network card
ATI 9800XT (8x agp) graphics card
SB Audigy (with intergrated IEEE 1394 controller)
Plextor DVDR PX-708A dvd/cd drive

Anyone got any clue and/or hints of whats going on here and how i could get this to work? With the corrupt partition table bugs i've had with previous FC2 test versions, i would rather not use those to install..

    -- Chris

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

From s.mako at gmx.net  Wed May 19 11:59:08 2004
From: s.mako at gmx.net (Zoltan Kota)
Date: Wed, 19 May 2004 13:59:08 +0200 (CEST)
Subject: boot disk during fc2 install?
Message-ID: <Pine.LNX.4.44.0405191353030.11789-100000@erna.mpibpc.gwdg.de>

Hi,

I have just installed FC2 in text mode. It was OK, but what I missed is
the option to create a boot disk or boot cd image during the installation.
I had to reboot with the rescue CD to create the bootdisk.
Any comments?

Zoltan




From alan at redhat.com  Wed May 19 12:07:54 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 19 May 2004 08:07:54 -0400
Subject: boot disk during fc2 install?
In-Reply-To: <Pine.LNX.4.44.0405191353030.11789-100000@erna.mpibpc.gwdg.de>
References: <Pine.LNX.4.44.0405191353030.11789-100000@erna.mpibpc.gwdg.de>
Message-ID: <20040519120754.GA10687@devserv.devel.redhat.com>

On Wed, May 19, 2004 at 01:59:08PM +0200, Zoltan Kota wrote:
> I have just installed FC2 in text mode. It was OK, but what I missed is
> the option to create a boot disk or boot cd image during the installation.
> I had to reboot with the rescue CD to create the bootdisk.

Boot disks gnerally no longer fit on a floppy. there is a need to look 
into burning a boot CD, building boot usb sticks for the future.




From jakub at redhat.com  Wed May 19 12:24:35 2004
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 19 May 2004 08:24:35 -0400
Subject: Making NPTL the default for FC3, vanilla i386 support
Message-ID: <20040519122435.GL30909@devserv.devel.redhat.com>

Hi!

I'd like to make NPTL the default threading library for FC3,
as a step in phasing out LinuxThreads.

In FC2, when compiling a program which #include <pthread.h>,
or other POSIX THR option headers (or e.g. limits.h) or
when linking against -lpthread, it is compiled against
LinuxThreads headers and linked against LinuxThreads libpthread.so.
To use NPTL headers and/or link against NPTL libpthread.so,
one has to use -I/usr/include/nptl -L/usr/lib{,64}/nptl

Dynamically linked programs are then run by default against
NPTL libraries (unless LD_ASSUME_KERNEL < 2.4.19 is used),
as NPTL libraries are backwards ABI compatible with LinuxThreads
libraries, but not vice versa.

In FC3, I'd like programs to link against NPTL libpthread.so/libpthread.a
and compile against NPTL headers by default and provide some
-I/usr/include/linuxthreads -L/usr/lib{,64}/linuxthreads
way to build LinuxThreads statically linked programs and/or
dynamically linked programs which can run against LinuxThreads
too.  The advantage is that newly built programs can use
the NPTL ABI additions which are not present in LinuxThreads
(e.g. pthread_[sg]etaffinity_np, pthread_barrierattr_setpshared,
pthread_condattr_[sg]etclock, pthread_attr_[sg]etaffinity_np,
pthread_timedjoin_np, pthread_tryjoin_np and the new
__attribute__((cleanup)) based pthread_cleanup_{push,pop})
and that LinuxThreads really stays as a compatibility only
library.

The switch causes three important changes:

1) statically linked programs, no matter whether threaded or not,
   will now require a NPTL capable kernel (one from RHL 9, RHEL3,
   FC1, FC2 or any 2.6.x kernel should be enough), dynamically linked
   programs using -lpthread in some cases as well (e.g. if they are using
   the functions present in NPTL but not in LinuxThreads)

2) while previously blindly setting LD_ASSUME_KERNEL environment
   variable at the beginning of large shell scripts around some
   programs and sometimes even in /etc/profile.d/* often worked,
   now the chances are lower (any time such shell script
   runs a program which requires NPTL the program would fail
   to run).  LD_ASSUME_KERNEL should now be really only used
   on the command line of the broken program which needs
   LinuxThreads.  E.g.
   LD_ASSUME_KERNEL=2.4.19 /opt/FOOW/bin/barx --args xyz

3) NPTL has not been ported to i386, only i486+, x86_64,
   ia64, ppc32, ppc64, s390, s390x, alpha, sh and sparcv9.
   i386 (and sparc < v9) lacks atomic instructions powerful
   enough for NPTL needs.  Well, I have tried to port NPTL
   to i386, http://sources.redhat.com/ml/libc-hacker/2004-05/msg00019.html,
   but that port is severely limited and maintaining two
   different IA32 ports would be too much work.
   So for NPTL by default we need a i486-*-linux build of
   glibc at least (well, it can still use
   -march=i386 -mtune=pentium4, -march=i486 -mtune=pentium4
   wouldn't make much difference).
   This means though that almost no FC3 programs can run
   on vanilla i386{SX,DX} CPUs.  Is this a problem to anyone?
   Fedora Core installer will certainly not install on i486
   either, but if rpms from FC3 are used by RULE project...
   There have been some i486+ only instructions accidentally
   used in the past in many C++ programs (from libstdc++-v3
   headers) and apparently nobody noticed this in RHL or
   Fedora, so I assume not really many people are attempting
   to revive their i386 boxes.

Now, the question is, as at least all statically linked programs
built on Fedora Core 3 and many dynamically linked ones will require
i486+ atomic instructions (xaddl, cmpxchgl), if we should change
rpm architecture of FC3 rpms or not.

One alternative is just change the definition of .i386.rpm
to be "can run on i386{SX,DX} only with XADD/CMPXCHG emulation
in the kernel [1] or any i486+" (and I must say I'm most inclined
to this).  The corresponding rpmrc flags would be:
optflags: i386 -O2 -g -march=i386 -mtune=pentium4 -m32
optflags: i486 -O2 -g -march=i486 -m32
optflags: i586 -O2 -g -march=i586 -m32
optflags: i686 -O2 -g -march=i686 -mtune=pentium4 -m32
optflags: athlon -O2 -g -march=athlon -m32
but i386.rpm's would be allowed to contain xaddl/cmpxchgl instructions.

Another alternative is to change all rpms in FC3 which are .i386.rpm
in FC2 to .i486.rpm, with rpmrc:
optflags: i386 -O2 -g -march=i386 -m32
optflags: i486 -O2 -g -march=i486 -mtune=pentium4 -m32
optflags: i586 -O2 -g -march=i586 -m32
optflags: i686 -O2 -g -march=i686 -mtune=pentium4 -m32
optflags: athlon -O2 -g -march=athlon -m32

Using .i586.rpm's wouldn't buy us anything (-march=i586 -mtune=pentium4
is almost equivalent to -march=i486 -mtune=pentium4 and not
many programs really use cmpxchg8b instructions (which is not
even generated by GCC)) and moving the low bar to
.i686.rpm (note, i686 for GCC/rpm means i686 with X86_FEATURE_CMOV)
is probably too early for Fedora Core (there are still too many
VIA CPUs without cmov and even some Pentium's in use).

	Jakub




From leonard at den.ottolander.nl  Wed May 19 12:24:53 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Wed, 19 May 2004 14:24:53 +0200
Subject: pango_layout_iter_next_char: Now is the time?
Message-ID: <1084969493.5614.18.camel@athlon.localdomain>

Hi,

Now that all stress related to getting FC2 released has passed it might
be a good time to start spending some time on serious issues that still
need addressing.

One candidate I would like to propose is a bug in
pango_layout_iter_next_char
(http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113284 and
http://bugzilla.gnome.org/show_bug.cgi?id=89541).

But there are more...

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From arjanv at redhat.com  Wed May 19 12:27:42 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 19 May 2004 14:27:42 +0200
Subject: boot disk during fc2 install?
In-Reply-To: <20040519120754.GA10687@devserv.devel.redhat.com>
References: <Pine.LNX.4.44.0405191353030.11789-100000@erna.mpibpc.gwdg.de>
	<20040519120754.GA10687@devserv.devel.redhat.com>
Message-ID: <1084969662.2782.5.camel@laptop.fenrus.com>

On Wed, 2004-05-19 at 14:07, Alan Cox wrote:
> On Wed, May 19, 2004 at 01:59:08PM +0200, Zoltan Kota wrote:
> > I have just installed FC2 in text mode. It was OK, but what I missed is
> > the option to create a boot disk or boot cd image during the installation.
> > I had to reboot with the rescue CD to create the bootdisk.
> 
> Boot disks gnerally no longer fit on a floppy. there is a need to look 
> into burning a boot CD, building boot usb sticks for the future.

mkbootdisk --iso

makes you a nice boot cd
-------------- 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/20040519/59fee3f8/attachment.sig>

From dennis at ausil.us  Wed May 19 12:42:37 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Wed, 19 May 2004 22:42:37 +1000
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <20040519122435.GL30909@devserv.devel.redhat.com>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
Message-ID: <200405192242.37982.dennis@ausil.us>

Once upon a time Wednesday 19 May 2004 10:24 pm, Jakub Jelinek wrote:
<snip>
> One alternative is just change the definition of .i386.rpm
> to be "can run on i386{SX,DX} only with XADD/CMPXCHG emulation
> in the kernel [1] or any i486+" (and I must say I'm most inclined
> to this).  The corresponding rpmrc flags would be:
> optflags: i386 -O2 -g -march=i386 -mtune=pentium4 -m32
> optflags: i486 -O2 -g -march=i486 -m32
> optflags: i586 -O2 -g -march=i586 -m32
> optflags: i686 -O2 -g -march=i686 -mtune=pentium4 -m32
> optflags: athlon -O2 -g -march=athlon -m32
> but i386.rpm's would be allowed to contain xaddl/cmpxchgl instructions.
>
> Another alternative is to change all rpms in FC3 which are .i386.rpm
> in FC2 to .i486.rpm, with rpmrc:
> optflags: i386 -O2 -g -march=i386 -m32
> optflags: i486 -O2 -g -march=i486 -mtune=pentium4 -m32
> optflags: i586 -O2 -g -march=i586 -m32
> optflags: i686 -O2 -g -march=i686 -mtune=pentium4 -m32
> optflags: athlon -O2 -g -march=athlon -m32

i like the second option.  i still use a pentium 166 as a router  and i have a 
cyrix based system here which needs i586 kernel  and until recently  also 
used a k6-2 system  needing i586 kernel also.  since there is not really any 
gain from i486 to i586 id go with the i486  i know of some people who use 
i486's for firwalls.   just my AU$0.02  soon to be US$0.02

Dennis




From leonard at den.ottolander.nl  Wed May 19 12:55:08 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Wed, 19 May 2004 14:55:08 +0200
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <20040519122435.GL30909@devserv.devel.redhat.com>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
Message-ID: <1084971308.5614.33.camel@athlon.localdomain>

Hi Jakub,

> I'd like to make NPTL the default threading library for FC3,
> as a step in phasing out LinuxThreads.

>    This means though that almost no FC3 programs can run
>    on vanilla i386{SX,DX} CPUs.  Is this a problem to anyone?

It's always a bit sad to have to give up compatibility, but otoh most
boxes with i386 CPUs (including Cyrixes and WinChips) are usually not
that well equiped to run the bloated releases we have today anyway.

Actually i386 support has already been effectively discontinued
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078). Time to
start looking for some small footprint distros for such boxes.

>    There have been some i486+ only instructions accidentally
>    used in the past in many C++ programs (from libstdc++-v3
>    headers) and apparently nobody noticed this in RHL or
>    Fedora, so I assume not really many people are attempting
>    to revive their i386 boxes.

Well, at least one person has tried to :) .

> Another alternative is to change all rpms in FC3 which are .i386.rpm
> in FC2 to .i486.rpm, with rpmrc:

Although it might appear a bit funny at first I think this is the most
consequent solution. If it's not i386 compatible it shouldn't be called
so.

Also have a look at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933 .

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From buildsys at redhat.com  Wed May 19 12:56:41 2004
From: buildsys at redhat.com (Build System)
Date: Wed, 19 May 2004 08:56:41 -0400
Subject: rawhide report: 20040519 changes
Message-ID: <200405191256.i4JCufY05330@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-10.0.1-0.20040518223913
--------------------------------
* Tue May 18 2004 Anaconda team <bugzilla at redhat.com>

- built new version from CVS

* Fri Apr 30 2004 Jeremy Katz <katzj at redhat.com>

- Update description, remove prereq on stuff that was only needed 
  for reconfig mode

* Tue Feb 24 2004 Jeremy Katz <katzj at redhat.com>

- buildrequire libselinux-devel


coreutils-5.2.1-10
------------------
* Tue May 18 2004 Jeremy Katz <katzj at redhat.com> 5.2.1-10

- rebuild

* Mon May 17 2004 Tim Waugh <twaugh at redhat.com> 5.2.1-9

- Mention pam in the info for su (bug #122592).
- Remove wheel group rant again (bug #122886).
- Change default behaviour for chgrp/chown (bug #123263).  Patch from
  upstream.

devlabel-0.48.01-2
------------------
* Tue May 18 2004 Warren Togami <wtogami at redhat.com> 0.48.01-2

- update to 0.48.01

* Fri May 14 2004 Warren Togami <wtogami at redhat.com>

- #114892 and other spec cleanups

gnome-media-2.6.2-1
-------------------
* Tue May 18 2004 Colin Walters <walters at redhat.com> 2.6.2-1

- New upstream version
- Bump required versions of various build dependencies
- Update Source URL
- Remove BuildRequires and calls to autofoo, since we don't
  patch any autofoo files anymore.

* Thu Apr 15 2004 Warren Togami <wtogami at redhat.com> 2.6.0-2

- #111141 BR automake libtool gstreamer-plugins-devel gettext
  still something missing...

grep-2.5.1-28
-------------
* Tue May 18 2004 Jeremy Katz <katzj at redhat.com> 2.5.1-28

- rebuild

* Tue May 18 2004 Tim Waugh <twaugh at redhat.com> 2.5.1-27

- Fix dfa multibyte character class matching when -i is used (bug #123363).
- Use bracket patch before i18n patch to make it clear that the bug exists
  upstream.

kernel-2.6.6-1.370
------------------
* Tue May 18 2004 Dave Jones <davej at redhat.com>

- Fix typo in ibmtr driver preventing compile (#123391)

* Mon May 17 2004 Arjan van de Ven <arjanv at redhat.com>

- update to 2.6.6-bk3
- made kernel-source and kernel-doc noarch.rpm's since they are not
  architecture specific.

mailman-2.1.5-2
---------------
* Tue May 18 2004 Jeremy Katz <katzj at redhat.com> 3:2.1.5-2

- rebuild

* Mon May 17 2004 John Dennis <jdennis at redhat.com> 3:2.1.5-1

- bring up to latest 2.1.5 upstream release
  From Barry Warsaw: Mailman 2.1.5, a bug fix release that also
  contains new support for the Turkish language, and a few minor new
  features. Mailman 2.1.5 is a significant upgrade which should
  improve disk i/o performance, administrative overhead for discarding
  held spams, and the behavior of bouncing member disables.  This
  version also contains a fix for an exploit that could allow 3rd
  parties to retrieve member passwords.  It is thus highly recommended
  that all existing sitesupgrade to the latest version

man-pages-ja-20040515-1
-----------------------
* Wed May 19 2004 Akira TAGOH <tagoh at redhat.com> 20040515-1

- updates to 20040515.
- fixed wrong manpage for kill(1). we prefers util-linux thing rather than procps.

mgetty-1.1.30-7
---------------
* Tue May 18 2004 Nalin Dahyabhai <nalin at redhat.com> 1.1.30-7

- mark configuration files config(noreplace) (#123439)

mkinitrd-3.5.23-1
-----------------
* Tue May 18 2004 Jeremy Katz <katzj at redhat.com> - 3.5.23-1

- add support for RAID6

* Wed May 12 2004 Jeremy Katz <katzj at redhat.com>

- add support for multipath personality from Tom Callaway (#120379)

ncpfs-2.2.4-3
-------------
* Tue May 18 2004 Jeremy Katz <katzj at redhat.com> 2.2.4-3

- rebuild

* Tue May 18 2004 Thomas Woerner <twoerner at redhat.com> 2.2.4-2

- compiling sutils PIE

neon-0.24.6-1
-------------
* Wed May 19 2004 Joe Orton <jorton at redhat.com> 0.24.6-1

- update to 0.24.6

rpmdb-fedora-2-0.20040519
-------------------------

spamassassin-3.0-0.0.svn20040518
--------------------------------
* Tue May 18 2004 Warren Togami <wtogami at redhat.com> - 3.0-svn20040518

- svn snapshot 20040518

tk-8.4.6-2
----------
* Tue May 18 2004 Jeremy Katz <katzj at redhat.com> 8.4.6-2

- rebuild

* Thu May 13 2004 Jens Petersen <petersen at redhat.com> - 8.4.6-1

- update to 8.4.6




From alan at redhat.com  Wed May 19 13:04:41 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 19 May 2004 09:04:41 -0400
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <1084971308.5614.33.camel@athlon.localdomain>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
	<1084971308.5614.33.camel@athlon.localdomain>
Message-ID: <20040519130441.GA2365@devserv.devel.redhat.com>

On Wed, May 19, 2004 at 02:55:08PM +0200, Leonard den Ottolander wrote:
> It's always a bit sad to have to give up compatibility, but otoh most
> boxes with i386 CPUs (including Cyrixes and WinChips) are usually not
> that well equiped to run the bloated releases we have today anyway.

Winchip is pentium equivalent, cyrix above cyrix 386 is 486 equivalent.
We are talking
	Intel i386 (double sigma, DX, SX) [pre double sigma not supported 
		    anyway)
	AMD and Cyrix clones of the above
	Probably Nexgen 5x86 [lacks kernel side read faulting]




From davej at redhat.com  Wed May 19 13:07:01 2004
From: davej at redhat.com (Dave Jones)
Date: Wed, 19 May 2004 14:07:01 +0100
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <1084971308.5614.33.camel@athlon.localdomain>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
	<1084971308.5614.33.camel@athlon.localdomain>
Message-ID: <1084972021.16301.10.camel@delerium.codemonkey.org.uk>

On Wed, 2004-05-19 at 13:55, Leonard den Ottolander wrote:

> >    This means though that almost no FC3 programs can run
> >    on vanilla i386{SX,DX} CPUs.  Is this a problem to anyone?
> 
> It's always a bit sad to have to give up compatibility, but otoh most
> boxes with i386 CPUs (including Cyrixes and WinChips) 

nitpick: the winchips were 586's, and should still run
in a really low-end role. (just don't try running stuff like
OO.o on them).

	Dave





From leonard at den.ottolander.nl  Wed May 19 13:36:27 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Wed, 19 May 2004 15:36:27 +0200
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <20040519130441.GA2365@devserv.devel.redhat.com>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
	<1084971308.5614.33.camel@athlon.localdomain>
	<20040519130441.GA2365@devserv.devel.redhat.com>
Message-ID: <1084973787.5614.41.camel@athlon.localdomain>

Hi Alan,

> Winchip is pentium equivalent, cyrix above cyrix 386 is 486 equivalent.

No. Maybe almost but not exactly. Both (Cyrix P166 and WinChip 200) miss
tsc and cmov. The missing tsc is what causes rpm to fail. Missing cmov
might cause other problems. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 .

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From gemi at bluewin.ch  Wed May 19 13:37:30 2004
From: gemi at bluewin.ch (Gerard Milmeister)
Date: Wed, 19 May 2004 15:37:30 +0200
Subject: Upgrading FC1 to FC2: Severe problem with modules
Message-ID: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>

I yesterday upgraded from FC1 to FC2.
However the boot failed as it couldn't find the initrd. After I booted
from the rescue disk, I noticed that initrd-2.6.5-1.358.img wasn't
present. I tried to inkoke new-kernel-pkg myself, but it failed, because
it couldn't find the initio scsi driver. It seems that initio is not
supported anymore in 2.6, which isn't so dramatic as I had it only for
my Zip drive. I had to manually delete all references from modprobe.conf
and hwconf so that new-kernel-pkg would work. I think this is a severe
problem that should not have happened.

BTW, why are the harddisks shut down on reboot?
-- 
G?rard Milmeister
Tannenrauchstrasse 35
8038 Z?rich
gemi at bluewin.ch




From helios82 at optushome.com.au  Wed May 19 13:40:26 2004
From: helios82 at optushome.com.au (Matt Hansen)
Date: Wed, 19 May 2004 23:40:26 +1000
Subject: boot disk during fc2 install?
In-Reply-To: <1084969662.2782.5.camel@laptop.fenrus.com>
References: <Pine.LNX.4.44.0405191353030.11789-100000@erna.mpibpc.gwdg.de>
	<20040519120754.GA10687@devserv.devel.redhat.com>
	<1084969662.2782.5.camel@laptop.fenrus.com>
Message-ID: <1084974026.1447.12.camel@fc1>

On Wed, 2004-05-19 at 22:27, Arjan van de Ven wrote:
> On Wed, 2004-05-19 at 14:07, Alan Cox wrote:
> > On Wed, May 19, 2004 at 01:59:08PM +0200, Zoltan Kota wrote:
> > > I have just installed FC2 in text mode. It was OK, but what I missed is
> > > the option to create a boot disk or boot cd image during the installation.
> > > I had to reboot with the rescue CD to create the bootdisk.
> > 
> > Boot disks gnerally no longer fit on a floppy. there is a need to look 
> > into burning a boot CD, building boot usb sticks for the future.
> 
> mkbootdisk --iso
> 
> makes you a nice boot cd

Arjan, I just tried this on a FC1 system and got the following error:

# /sbin/mkbootdisk --iso --device bootCD.iso 2.4.22-1.2188.nptl

Size of boot image is 4 sectors -> No emulation

However, I just checked the mkisofs option layout in the mkbootdisk
script compared to the options a FC ISO uses and they are identical -
esp. the '-boot-load-size' option which is set to 4. Any ideas what's
going on here?

Regards,
-Matt 
-- 
"Would you buy a car with the hood welded shut?"
 - Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org 

-------------- 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/20040519/0b479eaa/attachment.sig>

From aoliva at redhat.com  Wed May 19 13:49:28 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 19 May 2004 10:49:28 -0300
Subject: On disttags
In-Reply-To: <40AAD31E.80606@math.unl.edu>
References: <20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518140406.GG5654@neu.nirvana>
	<orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518203321.GT5654@neu.nirvana>
	<orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>
	<40AAD31E.80606@math.unl.edu>
Message-ID: <or1xlgplw7.fsf@free.redhat.lsd.ic.unicamp.br>

On May 19, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:

> Alexandre Oliva wrote:
>> I don't see benefits for the core proper, and I do see problems.  So

> What problems?

Err...  The ones I described in my recent postings in this thread?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From jakub at redhat.com  Wed May 19 13:50:06 2004
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 19 May 2004 09:50:06 -0400
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <1084973787.5614.41.camel@athlon.localdomain>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
	<1084971308.5614.33.camel@athlon.localdomain>
	<20040519130441.GA2365@devserv.devel.redhat.com>
	<1084973787.5614.41.camel@athlon.localdomain>
Message-ID: <20040519135005.GN30909@devserv.devel.redhat.com>

On Wed, May 19, 2004 at 03:36:27PM +0200, Leonard den Ottolander wrote:
> Hi Alan,
> 
> > Winchip is pentium equivalent, cyrix above cyrix 386 is 486 equivalent.
> 
> No. Maybe almost but not exactly. Both (Cyrix P166 and WinChip 200) miss
> tsc and cmov. The missing tsc is what causes rpm to fail. Missing cmov
> might cause other problems. See
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 .

Well, missing cmov is not a problem for NPTL (and shouldn't be for rpm
in FC3 either).
The thing is just that there has been only i686 NPTL built in FC1/2 and
RHL9/RHEL3.  And rpm linked against NPTL, therefore it used cmov.
When there is a i486 NPTL build, rpm can link against that.

	Jakub




From dwmw2 at infradead.org  Wed May 19 13:53:29 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 19 May 2004 14:53:29 +0100
Subject: CUPS backend plugins
Message-ID: <1084974808.28151.117.camel@hades.cambridge.redhat.com>

The bluez-utils package now has a CUPS backend for bluetooth printers.
How should it be shipped?

The other CUPS backend which is shipped separate from CUPS itself is the
one in samba-client. That one is just shipped in the samba-client RPM,
and CUPS has a trigger script which makes a symlink to it from
/usr/lib/cups/backend/ on installation of samba-client.

Is there a reason why the trigger is done that way round -- in the
_cups_ specfile rather than the samba one? Or why we can't ship the
extra CUPS backend in a separate 'bluez-utils-cups' RPM which puts it
directly into /usr/lib/cups/backend/ instead of making the symlink in a
trigger script? Or any of the other possibilities?

-- 
dwmw2




From s.mako at gmx.net  Wed May 19 13:56:14 2004
From: s.mako at gmx.net (Zoltan Kota)
Date: Wed, 19 May 2004 15:56:14 +0200 (CEST)
Subject: boot disk during fc2 install?
In-Reply-To: <1084969662.2782.5.camel@laptop.fenrus.com>
Message-ID: <Pine.LNX.4.44.0405191551150.8531-100000@bozena.mpibpc.gwdg.de>


On Wed, 19 May 2004, Arjan van de Ven wrote:

> On Wed, 2004-05-19 at 14:07, Alan Cox wrote:

> > Boot disks gnerally no longer fit on a floppy. there is a need to look
> > into burning a boot CD, building boot usb sticks for the future.
>
> mkbootdisk --iso
>
> makes you a nice boot cd
>
 Yes. I've tried it. Without a CD burner in the box, transferring the
iso image to another machine (for further preparation) through the network
is also a possibility.
I did it indeed.

Zoltan






From felipe_alfaro at linuxmail.org  Wed May 19 14:00:05 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Wed, 19 May 2004 16:00:05 +0200
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <20040519122435.GL30909@devserv.devel.redhat.com>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
Message-ID: <1084975204.1627.3.camel@teapot.felipe-alfaro.com>

On Wed, 2004-05-19 at 14:24, Jakub Jelinek wrote:
>    This means though that almost no FC3 programs can run
>    on vanilla i386{SX,DX} CPUs.  Is this a problem to anyone?

Red Hat 9 was almost impossible to run decently on an i386-class machine
due to lack of resources (mainly, the CPU). I sill have a 386DX/20 lying
around, but it's simply unable to run anything newer than a 2.0, or
2.2-kernel based distribution.

>    Fedora Core installer will certainly not install on i486
>    either, but if rpms from FC3 are used by RULE project...
>    There have been some i486+ only instructions accidentally
>    used in the past in many C++ programs (from libstdc++-v3
>    headers) and apparently nobody noticed this in RHL or
>    Fedora, so I assume not really many people are attempting
>    to revive their i386 boxes.

As I said before, EnGarde Secure Linux 1.0, which is 2.2-kernel-based,
is what that machine can run at most.

> Another alternative is to change all rpms in FC3 which are .i386.rpm
> in FC2 to .i486.rpm, with rpmrc:
> optflags: i386 -O2 -g -march=i386 -m32
> optflags: i486 -O2 -g -march=i486 -mtune=pentium4 -m32
> optflags: i586 -O2 -g -march=i586 -m32
> optflags: i686 -O2 -g -march=i686 -mtune=pentium4 -m32
> optflags: athlon -O2 -g -march=athlon -m32

I like this one. Go for it!




From rms at 1407.org  Wed May 19 14:33:08 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Wed, 19 May 2004 15:33:08 +0100
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <1084977188.2356.146.camel@roque>

On Tue, 2004-05-18 at 16:08 -0300, Alexandre Oliva wrote:
> That said, if firstboot presents you with the GNU GPL and shuts the
> system down if you don't agree with it, that's a bug.  If it's some
> other license (e.g., /usr/share/doc/fedora-release-*/eula.txt), then
> it's ok, since that's what sets the terms of use of the collection of
> software called Fedora Core.

I verified by installing FC2 at home.
It's the FC eula, and it cancels installation.

I don't think it's okay, anyway:

2.  INTELLECTUAL PROPERTY RIGHTS.  The Software and each of its
    components, including the source code, documentation, appearance,
    structure and organization are copyrighted by Fedora Project and
    others and are protected under copyright and other laws.  Title to
    the Software and any component, or to any copy, modification, or
    merged portion shall remain with the aforementioned, subject to
    the applicable license.  The "Fedora" trademark is a trademark of
    Red Hat, Inc. ("Red Hat") in the U.S. and other countries and is
    used by permission.  This agreement permits User to distribute
    unmodified copies of Software using the Fedora trademark on the
    condition that User follows Red Hat's trademark guidelines located
    at http://fedora.redhat.com/legal.  User must abide by these
                                        ^^^^^^^^^^^^^^^^^^^^^^^^
    trademark guidelines when distributing the Software, regardless of
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    whether the Software has been modified.  If User modifies the
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Software, then User must replace all images containing the
    "Fedora" trademark.  Those images are found in the anaconda-images
    and the fedora-logos packages.  Merely deleting these files may
    corrupt the Software.

I think at least this add restrictions... which is a violation of all
the GPL and LGPL software included in FC2.

Probably, because TM and CR laws are independant of each other, it could
be ok if the formulation changed to:

    at http://fedora.redhat.com/legal.  User must abide by these
    trademark guidelines when distributing the Software unmodified.

Rui
-------------- 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/20040519/ccb1d12c/attachment.sig>

From twaugh at redhat.com  Wed May 19 14:42:48 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Wed, 19 May 2004 15:42:48 +0100
Subject: CUPS backend plugins
In-Reply-To: <1084974808.28151.117.camel@hades.cambridge.redhat.com>
References: <1084974808.28151.117.camel@hades.cambridge.redhat.com>
Message-ID: <20040519144248.GJ22616@redhat.com>

On Wed, May 19, 2004 at 02:53:29PM +0100, David Woodhouse wrote:

> The other CUPS backend which is shipped separate from CUPS itself is the
> one in samba-client. That one is just shipped in the samba-client RPM,
> and CUPS has a trigger script which makes a symlink to it from
> /usr/lib/cups/backend/ on installation of samba-client.

It was done this way by historical accident I think.  However, it
works now so there seems little point in changing it in that case.

> Is there a reason why the trigger is done that way round -- in the
> _cups_ specfile rather than the samba one? Or why we can't ship the
> extra CUPS backend in a separate 'bluez-utils-cups' RPM which puts
> it directly into /usr/lib/cups/backend/ instead of making the
> symlink in a trigger script? Or any of the other possibilities?

That certainly sounds like the best thing to do for new packages.  It
would be best to keep the knowledge of that backend in the package
that provides it.

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

From alan at redhat.com  Wed May 19 14:43:08 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 19 May 2004 10:43:08 -0400
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <1084973787.5614.41.camel@athlon.localdomain>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
	<1084971308.5614.33.camel@athlon.localdomain>
	<20040519130441.GA2365@devserv.devel.redhat.com>
	<1084973787.5614.41.camel@athlon.localdomain>
Message-ID: <20040519144308.GA31935@devserv.devel.redhat.com>

On Wed, May 19, 2004 at 03:36:27PM +0200, Leonard den Ottolander wrote:
> Hi Alan,
> 
> > Winchip is pentium equivalent, cyrix above cyrix 386 is 486 equivalent.
> 
> No. Maybe almost but not exactly. Both (Cyrix P166 and WinChip 200) miss
> tsc and cmov. The missing tsc is what causes rpm to fail. Missing cmov
> might cause other problems. See
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 .

tsc is pentium and higher. cmov is pentium pro and higher. RPM is just broken
according to that bug.




From twaugh at redhat.com  Wed May 19 14:52:38 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Wed, 19 May 2004 15:52:38 +0100
Subject: CUPS backend plugins
In-Reply-To: <20040519144248.GJ22616@redhat.com>
References: <1084974808.28151.117.camel@hades.cambridge.redhat.com>
	<20040519144248.GJ22616@redhat.com>
Message-ID: <20040519145238.GK22616@redhat.com>

On Wed, May 19, 2004 at 03:42:48PM +0100, Tim Waugh wrote:

> On Wed, May 19, 2004 at 02:53:29PM +0100, David Woodhouse wrote:
[...]
> > Is there a reason why the trigger is done that way round -- in the
> > _cups_ specfile rather than the samba one? Or why we can't ship the
> > extra CUPS backend in a separate 'bluez-utils-cups' RPM which puts
> > it directly into /usr/lib/cups/backend/ instead of making the
> > symlink in a trigger script? Or any of the other possibilities?
> 
> That certainly sounds like the best thing to do for new packages.  It
> would be best to keep the knowledge of that backend in the package
> that provides it.

I wasn't very clear here: I meant that any of these alternatives are
better than putting it in cups.spec. :-)

Having a separate subpackage (which requires cups) sounds like the
best approach.

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

From jspaleta at gmail.com  Wed May 19 14:56:41 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 19 May 2004 10:56:41 -0400
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1084977188.2356.146.camel@roque>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
Message-ID: <604aa791040519075629327003@mail.gmail.com>

On Wed, 19 May 2004 15:33:08 +0100, Rui Miguel Seabra <rms at 1407.org> wrote:
> I think at least this add restrictions... which is a violation of all
> the GPL and LGPL software included in FC2.

statements like this...pretty much demand informed legal counsel to hold
any real value. My reading of the gpl, tells me trademark law is
outside the scope of gpl completely.  And perhaps if you don't like my
opinion. Perhaps you will follow-up with your own legal counsel on the
mysql lawsuit that made it to court and see if they agree with the
statements made here:
http://www.open-mag.com/features/Vol_24/GPL/gpl.htm


-jef"or perhaps, you can have groklaw community do some legal research
for you"spaleta




From rdieter at math.unl.edu  Wed May 19 15:20:01 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 19 May 2004 10:20:01 -0500 (CDT)
Subject: On disttags
In-Reply-To: <or1xlgplw7.fsf@free.redhat.lsd.ic.unicamp.br>
References: <20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518140406.GG5654@neu.nirvana>
	<orekphlful.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040518203321.GT5654@neu.nirvana>
	<orekphju44.fsf@free.redhat.lsd.ic.unicamp.br>
	<40AAD31E.80606@math.unl.edu>
	<or1xlgplw7.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <Pine.LNX.4.58.0405191019410.22513@sting.unl.edu>

On Wed, 19 May 2004, Alexandre Oliva wrote:

> On May 19, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
> > Alexandre Oliva wrote:
> >> I don't see benefits for the core proper, and I do see problems.  So
> 
> > What problems?
> 
> Err...  The ones I described in my recent postings in this thread?

And I thought I rebutted those...

-- Rex




From rms at 1407.org  Wed May 19 15:43:35 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Wed, 19 May 2004 16:43:35 +0100
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <604aa791040519075629327003@mail.gmail.com>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
Message-ID: <1084981415.2356.163.camel@roque>

On Wed, 2004-05-19 at 10:56 -0400, Jeff Spaleta wrote:
> On Wed, 19 May 2004 15:33:08 +0100, Rui Miguel Seabra <rms at 1407.org> wrote:
> > I think at least this add restrictions... which is a violation of all
> > the GPL and LGPL software included in FC2.
> 
> statements like this...pretty much demand informed legal counsel to hold
> any real value. My reading of the gpl, tells me trademark law is
> outside the scope of gpl completely.  And perhaps if you don't like my
> opinion. Perhaps you will follow-up with your own legal counsel on the
> mysql lawsuit that made it to court and see if they agree with the
> statements made here:
> http://www.open-mag.com/features/Vol_24/GPL/gpl.htm

Look, the phrase I ponted out adds restrictions on distribution.

   YES or NO ?

The GNU GPL and LGPL do not allow one to add permissions.

   YES or NO ?

The collection includes MUCH GPL'ed and LGPL'ed software.

   YES or NO ?

I mentioned trademark is independent of copyright.

   YES or NO ?

I provided one possible rewording that *probably* *could* help clear
doubts.

   YES or NO ?


In my view, YES, YES, YES, YES and YES.

So I think that some thought leading to positive conclusions should be
applied before knee-jerk reactions.


YES or NO ?

Rui

ps: in my view, YES.
-------------- 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/20040519/3640ebfa/attachment.sig>

From jspaleta at gmail.com  Wed May 19 16:06:20 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 19 May 2004 12:06:20 -0400
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1084981415.2356.163.camel@roque>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
	<1084981415.2356.163.camel@roque>
Message-ID: <604aa7910405190906305db1ed@mail.gmail.com>

On Wed, 19 May 2004 16:43:35 +0100, Rui Miguel Seabra 
> In my view, YES, YES, YES, YES and YES.
> 
> So I think that some thought leading to positive conclusions should be
> applied before knee-jerk reactions.

I firmly agree...some informed thought is needed. Some informed
thought from people who practice law.

> 
> YES or NO ?
> 
> Rui
> 
> ps: in my view, YES.

Unfortunately...or fortunately...neither my or your opinion should be
considered informed legal counsel. I'll say it again, but a bit more
explicitly.
Once threads about licensing from people who are not lawyers get to
this point, they are pretty much worthless, navel gazing,
pontificating ianal opinion diatribes. You and I could argue for an
eterinity about where the legal line is and whether Red Hat has
crossed it with this eula.
Whether you and I agree on this...at the end of the day...doesn't matter.
Whether your opinion is more popular...doesn't matter either really.
We aren't informed legal counsel. Pretending that we are is just wasting
breath and bandwidth.

In an effort to avoid a simple and pointless opinion debate between
non-lawyers, I have cited an outside opinion reference about an actual
court case that deals with gpl and trademark restrictions. I fully
submit that becuase it is also an opinion piece, it holds far less
value than actual informed legal counsel. But I will also submit that
any opinion about what the already decided legal case involving the
mysql court case says about how trademark and the gpl interact, is far
more educational than any personal opinions you or I can state and
debate here.  Whether the eula
that comes with Fedora violates the gpl, is an issue important enough for
informed legal counsel to look at. You and I are not that legal
counsel. For us to debate facts of law, from an uninformed position,
can do nothing but
make the matter murkier than it already is.

-jef"get a lawyer"spaleta




From rms at 1407.org  Wed May 19 16:13:52 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Wed, 19 May 2004 17:13:52 +0100
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <604aa7910405190906305db1ed@mail.gmail.com>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
	<1084981415.2356.163.camel@roque>
	<604aa7910405190906305db1ed@mail.gmail.com>
Message-ID: <1084983232.2356.170.camel@roque>

On Wed, 2004-05-19 at 12:06 -0400, Jeff Spaleta wrote:
> On Wed, 19 May 2004 16:43:35 +0100, Rui Miguel Seabra 
> I firmly agree...some informed thought is needed. Some informed
> thought from people who practice law.

I would like to know the opinion of Red Hat on the matter.

Who's the best contact for this?

Rui

ps: I don't think it is a murky situation, it seems glaringly clear to
me that restrictions are being added, so I'd rather they are solved.
I don't think it is an evil plot, but some over zealous lawyer talk.
-------------- 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/20040519/0d9e83e3/attachment.sig>

From dwmw2 at infradead.org  Wed May 19 16:21:27 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 19 May 2004 17:21:27 +0100
Subject: CUPS backend plugins
In-Reply-To: <20040519145238.GK22616@redhat.com>
References: <1084974808.28151.117.camel@hades.cambridge.redhat.com>
	<20040519144248.GJ22616@redhat.com> <20040519145238.GK22616@redhat.com>
Message-ID: <1084983687.28151.183.camel@hades.cambridge.redhat.com>

On Wed, 2004-05-19 at 15:52 +0100, Tim Waugh wrote:
> On Wed, May 19, 2004 at 03:42:48PM +0100, Tim Waugh wrote:
> 
> > On Wed, May 19, 2004 at 02:53:29PM +0100, David Woodhouse wrote:
> [...]
> > > Is there a reason why the trigger is done that way round -- in the
> > > _cups_ specfile rather than the samba one? Or why we can't ship the
> > > extra CUPS backend in a separate 'bluez-utils-cups' RPM which puts
> > > it directly into /usr/lib/cups/backend/ instead of making the
> > > symlink in a trigger script? Or any of the other possibilities?
> > 
> > That certainly sounds like the best thing to do for new packages.  It
> > would be best to keep the knowledge of that backend in the package
> > that provides it.
> 
> I wasn't very clear here: I meant that any of these alternatives are
> better than putting it in cups.spec. :-)
> 
> Having a separate subpackage (which requires cups) sounds like the
> best approach.

OK, that's what I've done. A new set of bluez packages is in my yum repo
at ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/ (That's for FC2/ppc;
i386 users can rebuild if they want).

-- 
dwmw2




From Nigel.Metheringham at dev.InTechnology.co.uk  Wed May 19 16:24:33 2004
From: Nigel.Metheringham at dev.InTechnology.co.uk (Nigel Metheringham)
Date: Wed, 19 May 2004 17:24:33 +0100
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1084983232.2356.170.camel@roque>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
	<1084981415.2356.163.camel@roque>
	<604aa7910405190906305db1ed@mail.gmail.com>
	<1084983232.2356.170.camel@roque>
Message-ID: <1084983872.9646.69.camel@angua.localnet>

On Wed, 2004-05-19 at 17:13, Rui Miguel Seabra wrote:
> ps: I don't think it is a murky situation, it seems glaringly clear to
> me that restrictions are being added, so I'd rather they are solved.
> I don't think it is an evil plot, but some over zealous lawyer talk.

You are right.  Its not murky at all.  There are lots of packages under
various different licences.  The distribution of the entire collection
has to comply with all those licenses.  They have told you that a small
number of packages within that collection have trademark restrictions
which you must comply with, or purge those packages before
re-distribution.   No further restrictions are being applied to GPL
packages.

This has been had out before - I think it was RH8 (or just possibly 7.3)
which had this EULA first.  There are plenty of archives around with
earlier flame wars^W^Wdiscussions.

	Nigel.

-- 
[ Nigel Metheringham           Nigel.Metheringham at InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]




From aoliva at redhat.com  Wed May 19 16:27:40 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 19 May 2004 13:27:40 -0300
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
Message-ID: <oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>

On May 18, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:

> On Tue, 18 May 2004, Alexandre Oliva wrote:

> Besides, the case you mention case easily be avoided.  *Always* use the 
> same # of significant digits/dots in front of dist tag and/or simply 
> increment the release, so you end up with either
> -1.0.foo -> -1.1.foo
> or
> -1.foo -> -2.foo

>> If you use disttags, and you have to patch a package such that the
>> R number goes in between two R numbers that are already out, and you
>> can't just append the build number at the end for the reasons Axel
>> already exposed, and you can't add `.number' before the disttag, what
>> do you do?

> No problem.  (-:  Migrating *to* disttags actually helps in this 
> case, and you avoid the problem you mentioned above because there is no 
> existing dist_tag.  Example, foo-1-3 and foo-1-5 are released now.  
> Release patched version as:
> foo-1-3.0.%{dist_tag}

How about foo-1-3.fc3 and foo-1-4.fc4

How do I issue an errata for fc3?

3.1.fc3 (or 3.0.fc3?) won't work, because it causes numbers to be
compared with letters.  3.fc3.1 won't work because upgrading to 4.fc4
will go backwards (I'm not sure I buy that, but it's not my argument,
it's Axel's).

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From rdieter at math.unl.edu  Wed May 19 16:36:54 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 19 May 2004 11:36:54 -0500
Subject: On disttags
In-Reply-To: <oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<1084439431.3770.13705.camel@mccallum.corsepiu.local>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <40AB8D26.2090408@math.unl.edu>

Alexandre Oliva wrote:

> How about foo-1-3.fc3 and foo-1-4.fc4
> 
> How do I issue an errata for fc3?

foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)

or better, release 2 updates
foo-1-5.fc3 and foo-1-5.fc4

-- Rex




From jspaleta at gmail.com  Wed May 19 17:01:07 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 19 May 2004 13:01:07 -0400
Subject: On disttags
In-Reply-To: <40AB8D26.2090408@math.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<1084439431.3770.13705.camel@mccallum.corsepiu.local>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
	<40AB8D26.2090408@math.unl.edu>
Message-ID: <604aa7910405191001415bd496@mail.gmail.com>

On Wed, 19 May 2004 11:36:54 -0500, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
> Alexandre Oliva wrote:
> 
> > How about foo-1-3.fc3 and foo-1-4.fc4
> >
> > How do I issue an errata for fc3?
> 
> foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)
> 
> or better, release 2 updates
> foo-1-5.fc3 and foo-1-5.fc4

release foo-1.5.fc4 even if foo-1.4.fc4 was not actually affected by the errata?

yeah...lets design a package naming policy that demands package
updates on systems that are not directly affected by security errata.
won't it be fun..when users start having to eat large package updates
like the kernel or openoffice, just because the packaging naming
scheme makes rolling an update mandatory. Yeah, excuse me while i walk
to the corner of my office and throw up.

-jef




From rms at 1407.org  Wed May 19 17:13:01 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Wed, 19 May 2004 18:13:01 +0100
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1084983872.9646.69.camel@angua.localnet>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
	<1084981415.2356.163.camel@roque>
	<604aa7910405190906305db1ed@mail.gmail.com>
	<1084983232.2356.170.camel@roque>
	<1084983872.9646.69.camel@angua.localnet>
Message-ID: <1084986781.11811.17.camel@roque>

On Wed, 2004-05-19 at 17:24 +0100, Nigel Metheringham wrote:
> You are right.  Its not murky at all.  There are lots of packages under
> various different licences.  The distribution of the entire collection
> has to comply with all those licenses.  They have told you that a small
> number of packages within that collection have trademark restrictions
> which you must comply with, or purge those packages before
> re-distribution.   No further restrictions are being applied to GPL
> packages.

Look carefully:

    User must abide by these trademark guidelines

A restriction has been added. So far so good. There _are_ trademarked
logos and expressions in some packages.

    when distributing the Software,

Here they say that this restriction also abriges the act of distribution
-> touches Copyright law.

   regardless of whether the Software has been modified.

Here they say that even if the Software has been modified to remove the
trademarks, the restriction still applies.

It probably should say

    User must abide by these trademark guidelines when distributing the
    Software with files containing the "Fedora" trademark.


Rui
-------------- 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/20040519/5ccd91ab/attachment.sig>

From otaylor at redhat.com  Wed May 19 17:15:03 2004
From: otaylor at redhat.com (Owen Taylor)
Date: Wed, 19 May 2004 13:15:03 -0400
Subject: pango_layout_iter_next_char: Now is the time?
In-Reply-To: <1084969493.5614.18.camel@athlon.localdomain>
References: <1084969493.5614.18.camel@athlon.localdomain>
Message-ID: <1084986903.4372.298.camel@localhost.localdomain>

On Wed, 2004-05-19 at 08:24, Leonard den Ottolander wrote:
> Hi,
> 
> Now that all stress related to getting FC2 released has passed it might
> be a good time to start spending some time on serious issues that still
> need addressing.
> 
> One candidate I would like to propose is a bug in
> pango_layout_iter_next_char
> (http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113284 and
> http://bugzilla.gnome.org/show_bug.cgi?id=89541).

A) Generally, bug fixes for particular upstream
   packages are best discussed in the appropriate upstream forum.

B) "Please fix this bug" mails are virtually never useful

C) Your Pango problem was fixed long ago. The Pango bug is still 
   open because there are deeper/harder issues that also need
   to be fixed.

D) Your other issues have nothing to do with Pango. 
   (E.g., the crash you were getting was because the title
   of the terminal tab was being set to junk characters by
   MC. Now that the Pango crash is fixed, you see the
   junk characters...)

   The correct way to pursue these additional issues is to 
   file individual bugs against the appropriate components,
   e.g. mc.

Regards,
					Owen


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

From shahms at shahms.com  Wed May 19 17:15:44 2004
From: shahms at shahms.com (Shahms King)
Date: Wed, 19 May 2004 10:15:44 -0700
Subject: Upgrading FC1 to FC2: Severe problem with modules
In-Reply-To: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>
References: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>
Message-ID: <1084986944.23547.111.camel@shahms.mesd.k12.or.us>

On Wed, 2004-05-19 at 06:37, Gerard Milmeister wrote:
> I yesterday upgraded from FC1 to FC2.
> However the boot failed as it couldn't find the initrd. After I booted
> from the rescue disk, I noticed that initrd-2.6.5-1.358.img wasn't
> present. I tried to inkoke new-kernel-pkg myself, but it failed, because
> it couldn't find the initio scsi driver. It seems that initio is not
> supported anymore in 2.6, which isn't so dramatic as I had it only for
> my Zip drive. I had to manually delete all references from modprobe.conf
> and hwconf so that new-kernel-pkg would work. I think this is a severe
> problem that should not have happened.

This is the exact same problem I had with the tmscsim module.  Feel free
to add a rant to bug #123612.  I'm still a little puzzled as to why the
tmscsim module isn't included anymore, though.

-- 
Shahms King <shahms at shahms.com>




From rdieter at math.unl.edu  Wed May 19 17:23:31 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 19 May 2004 12:23:31 -0500
Subject: On disttags
In-Reply-To: <604aa7910405191001415bd496@mail.gmail.com>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<1084439431.3770.13705.camel@mccallum.corsepiu.local>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>	<40AB8D26.2090408@math.unl.edu>
	<604aa7910405191001415bd496@mail.gmail.com>
Message-ID: <40AB9813.4040005@math.unl.edu>

Jeff Spaleta wrote:

> release foo-1.5.fc4 even if foo-1.4.fc4 was not actually affected by the errata?

I said it was an option, not a requirement to release foo-1-5.fc4.

> yeah...lets design a package naming policy that demands package
> updates on systems that are not directly affected by security errata.

Oh please stop exagerating.  It's not *that* bad.  If it makes you feel 
better, I'll even bring you a bucket for your throw up... (-:

Speaking of useless large package updates, why does redhat bundle 
koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice 
and k3b rpms, so that any updates to koffice and k3b will also "force 
users to eat useless large updates"?

Hint: we're touching on similar issues here.  I realize things are not 
so cut-and-dried.

-- Rex




From kewley at cns.caltech.edu  Wed May 19 17:29:28 2004
From: kewley at cns.caltech.edu (David Kewley)
Date: Wed, 19 May 2004 10:29:28 -0700
Subject: FC2 Final can't get to loading kernel.. New bug?
In-Reply-To: <001601c43d95$7e581620$0200a8c0@gandalf>
References: <001601c43d95$7e581620$0200a8c0@gandalf>
Message-ID: <200405191029.28350.kewley@cns.caltech.edu>

Chris Chabot wrote on Wednesday 19 May 2004 04:36:
> I've used FC2 test 1 and 2 without any problems previously. However when i
> now try to boot the FC2 (release), it won't even load the kernel, but
> instantly reboots my system
> 
> It get's to the Loading vmlinuz... then loading initrd.. Then, boom,
> reboots.. (thats just before the "Uncompressing Kernel.." message)
> 
> ps i did download the first cd again (from a diff mirror even), burned 2
> more copies, checked MD5's.. but nothing's wrong with the media. As
> mentioned, test 1 and 2 worked fine on this machine, and the hardware
> didn't change in the meantime
> 
> My system details:
> P4 3.0 Ghz (HT) Cpu
> Intel 865PE + ICH5R chipset
> Maxtor 6Y080P0 80Gb (set to ATA 100) HD
> 3Com 3c9x Network card
> ATI 9800XT (8x agp) graphics card
> SB Audigy (with intergrated IEEE 1394 controller)
> Plextor DVDR PX-708A dvd/cd drive

Is this by any chance an Asus P4P800 motherboard?  If so, see:

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

David




From jspaleta at gmail.com  Wed May 19 17:35:38 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 19 May 2004 13:35:38 -0400
Subject: On disttags
In-Reply-To: <40AB9813.4040005@math.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<1084439431.3770.13705.camel@mccallum.corsepiu.local>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>	<40AB8D26.2090408@math.unl.edu>
	<604aa7910405191001415bd496@mail.gmail.com>
	<40AB9813.4040005@math.unl.edu>
Message-ID: <604aa7910405191035171e88be@mail.gmail.com>

On Wed, 19 May 2004 12:23:31 -0500, Rex Dieter <rdieter at math.unl.edu> wrote:
> Speaking of useless large package updates, why does redhat bundle
> koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice
> and k3b rpms, so that any updates to koffice and k3b will also "force
> users to eat useless large updates"?

I hear there is this wonderful thing that rpm has called obsoleting.....
so that if a specific package is decided to be split or combined later
on down the road, it can be handled gracefully.

what you are suggesting is a mandatory rebuild of  any packages as a
matter of overreaching naming policy....for the entire collection of
packages. In a world full of shades of gray, the contrast setting in
this argument is set pretty high.

And you still have not addressed the issue of how to handle backported
fixes. So far in this example you are talking about replace foo-1.3
with foo-1.4 or foo-1.5. The actually problem is how to roll
backported fixes. Applying targetted fixes to foo-1.3 does not make it
foo-1.4 or foo-1.5. foo-1.4 and foo-1.5 upstream could very well
include change in functionality beyond the needed fixes. It is not
always appropriate to bump a package up to the next version. You can
either accept that backport fixes will be needed and the naming policy
will need to be flexible enough to handle that, or you can't accept
it. Until you accept the need for that situation, I'm not sure any
further discussion on the list about this is worth having.

-jef




From gemi at bluewin.ch  Wed May 19 17:41:06 2004
From: gemi at bluewin.ch (Gerard Milmeister)
Date: Wed, 19 May 2004 19:41:06 +0200
Subject: Upgrading FC1 to FC2: Severe problem with modules
In-Reply-To: <1084986944.23547.111.camel@shahms.mesd.k12.or.us>
References: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>
	<1084986944.23547.111.camel@shahms.mesd.k12.or.us>
Message-ID: <1084988466.6026.7.camel@scriabin.tannenrauch.ch>

On Wed, 2004-05-19 at 19:15, Shahms King wrote:
> On Wed, 2004-05-19 at 06:37, Gerard Milmeister wrote:

> This is the exact same problem I had with the tmscsim module.  Feel free
> to add a rant to bug #123612.  I'm still a little puzzled as to why the
Done.
> tmscsim module isn't included anymore, though.
Same with initio, though I guess that this driver hasn't been maintained
anymore.

I wonder what less technical inclined people will think of Fedora if
left with an unusable system :-(

-- 
G?rard Milmeister
Tannenrauchstrasse 35
8038 Z?rich
gemi at bluewin.ch




From rdieter at math.unl.edu  Wed May 19 17:49:42 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 19 May 2004 12:49:42 -0500
Subject: On disttags
In-Reply-To: <604aa7910405191035171e88be@mail.gmail.com>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>	<40AB8D26.2090408@math.unl.edu>	<604aa7910405191001415bd496@mail.gmail.com>	<40AB9813.4040005@math.unl.edu>
	<604aa7910405191035171e88be@mail.gmail.com>
Message-ID: <40AB9E36.6070100@math.unl.edu>

Jeff Spaleta wrote:

> And you still have not addressed the issue of how to handle backported
> fixes. 

Isn't fedora's policy now, in general, to *not* backport fixes, but to 
upgrade to the latest upstream version?

-- Rex




From jspaleta at gmail.com  Wed May 19 18:00:43 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 19 May 2004 14:00:43 -0400
Subject: On disttags
In-Reply-To: <40AB9E36.6070100@math.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>	<40AB8D26.2090408@math.unl.edu>	<604aa7910405191001415bd496@mail.gmail.com>	<40AB9813.4040005@math.unl.edu>
	<604aa7910405191035171e88be@mail.gmail.com>
	<40AB9E36.6070100@math.unl.edu>
Message-ID: <604aa7910405191100744f043d@mail.gmail.com>

On Wed, 19 May 2004 12:49:42 -0500, Rex Dieter <rdieter at math.unl.edu> wrote:
> Isn't fedora's policy now, in general, to *not* backport fixes, but to
> upgrade to the latest upstream version?

what does "in general" really mean?  It certaintly doesn't mean
garunteed, absolutely not going to need to do backports. Do the right
thing for the right reasons for the right package. I'm sure upstream
latest versions of applications will be very common. I'm not so
certain that upstream latest versions will always be appropriate for
the library level nor the kernel itself. The point is any naming
policy must be flexible enough to ensure that backporting fixes and
building patched errata still has a place to work smoothly, especially
because anything important enough to require a backport over a latest
version push is going to be VERY important and need to update smoothly
since these sorts of things tend to be security related. Building a
naming policy that makes trivial feature updates work with mindnumbing
automated ease...but makes critically important security backported
package updates a pain in the ass to install...is short sighted.

-jef




From rdieter at math.unl.edu  Wed May 19 18:01:11 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 19 May 2004 13:01:11 -0500
Subject: On disttags
In-Reply-To: <604aa7910405191035171e88be@mail.gmail.com>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>	<40AB8D26.2090408@math.unl.edu>	<604aa7910405191001415bd496@mail.gmail.com>	<40AB9813.4040005@math.unl.edu>
	<604aa7910405191035171e88be@mail.gmail.com>
Message-ID: <40ABA0E7.7080705@math.unl.edu>

Jeff Spaleta wrote:

> And you still have not addressed the issue of how to handle backported
> fixes. 

IMHO, The only reason dist_tags can possibly cause any sort of problems 
with backported fixes is dealing with rpm < 4.2 (or possibly rpm < 4.1 
where is incorrectly sorts numerics vs. alphas in version/release tags). 
  In the scope of *this* discussion, we're dealing only with non-buggy 
rpm versions, so Fedora Core can safely ignore those problems(*). 
Futher, in the lack of existing dist_tags, these problems go away.

So, given foo-1-3 (for fc3) and foo-1-4 (for fc4), an fc3 errata can use 
any of these safely:

If paranoid about upgrades to fc4, so foo-1-4 is *always* newer/greater:
foo-1-3.0.fc3 (my personal preference)
foo-1-3.fc3 (*just* adding dist_tag)
And by extension, a possible 2nd errata:
foo-1-3.1.fc3

Or to simpify things for the packager(s), and always use a single source 
(and yes, possibly pushing out useless updates on some platforms):
foo-1-5.%{dist_tag}

-- Rex

(*) Or possibly someone (RedHat, fedora.us, or fedoralegacy.org) can 
release an rpm errata to fix these issues as well.




From rdieter at math.unl.edu  Wed May 19 18:03:03 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 19 May 2004 13:03:03 -0500
Subject: On disttags
In-Reply-To: <604aa7910405191100744f043d@mail.gmail.com>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>	<40AB8D26.2090408@math.unl.edu>	<604aa7910405191001415bd496@mail.gmail.com>	<40AB9813.4040005@math.unl.edu>	<604aa7910405191035171e88be@mail.gmail.com>	<40AB9E36.6070100@math.unl.edu>
	<604aa7910405191100744f043d@mail.gmail.com>
Message-ID: <40ABA157.5030701@math.unl.edu>

Jeff Spaleta wrote:
> On Wed, 19 May 2004 12:49:42 -0500, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
>>Isn't fedora's policy now, in general, to *not* backport fixes, but to
>>upgrade to the latest upstream version?
> 
> 
> what does "in general" really mean?  

I'm refering to item #3 on http://fedora.redhat.com/about/objectives.html
QUOTE:
"3. Do as much of the development work as possible directly in the 
upstream packages. This includes updates; our default policy will be to 
upgrade to new versions for security as well as for bugfix and new 
feature update releases of packages."

-- Rex




From aoliva at redhat.com  Wed May 19 18:24:00 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 19 May 2004 15:24:00 -0300
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1084981415.2356.163.camel@roque>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
	<1084981415.2356.163.camel@roque>
Message-ID: <orr7tgl1hb.fsf@free.redhat.lsd.ic.unicamp.br>

On May 19, 2004, Rui Miguel Seabra <rms at 1407.org> wrote:

> Look, the phrase I ponted out adds restrictions on distribution.

>    YES or NO ?

Of the whole, yes; of the individual packages released under the GNU
GPL or LGPL, no.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From alan at redhat.com  Wed May 19 18:25:57 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 19 May 2004 14:25:57 -0400
Subject: Upgrading FC1 to FC2: Severe problem with modules
In-Reply-To: <1084988466.6026.7.camel@scriabin.tannenrauch.ch>
References: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>
	<1084986944.23547.111.camel@shahms.mesd.k12.or.us>
	<1084988466.6026.7.camel@scriabin.tannenrauch.ch>
Message-ID: <20040519182557.GA19996@devserv.devel.redhat.com>

On Wed, May 19, 2004 at 07:41:06PM +0200, Gerard Milmeister wrote:
> > tmscsim module isn't included anymore, though.
> Same with initio, though I guess that this driver hasn't been maintained
> anymore.

Lots ofl older scsi drivers either were not ported to 2.6 or where ported
but the patches ignored. I'm working on a couple of cases of the latter at
the moment.




From aoliva at redhat.com  Wed May 19 18:26:36 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 19 May 2004 15:26:36 -0300
Subject: On disttags
In-Reply-To: <40AB8D26.2090408@math.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
	<40AB8D26.2090408@math.unl.edu>
Message-ID: <orn044l1cz.fsf@free.redhat.lsd.ic.unicamp.br>

On May 19, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:

> Alexandre Oliva wrote:
>> How about foo-1-3.fc3 and foo-1-4.fc4
>> How do I issue an errata for fc3?

> foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)

But this breaks foo >= 1-4

> or better, release 2 updates
> foo-1-5.fc3 and foo-1-5.fc4

This breaks because 1-5.fc3 > 1-4.fc4, and 5.fc3 isn't suitable for
FC4 because it doesn't contain the change introduced in 1-4.fc4 that
makes it work on FC4.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From rms at 1407.org  Wed May 19 18:28:44 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Wed, 19 May 2004 19:28:44 +0100
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <orr7tgl1hb.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
	<1084981415.2356.163.camel@roque>
	<orr7tgl1hb.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <1084991324.11811.45.camel@roque>

On Wed, 2004-05-19 at 15:24 -0300, Alexandre Oliva wrote:
> On May 19, 2004, Rui Miguel Seabra <rms at 1407.org> wrote:
> 
> > Look, the phrase I ponted out adds restrictions on distribution.
> 
> >    YES or NO ?
> 
> Of the whole, yes; of the individual packages released under the GNU
> GPL or LGPL, no.

The whole includes GPL and LGPL stuff.

YES or NO ? :)

Restrictions on the whole superimpose on the GPL and LGPL stuff.

YES or NO ?

Objective questions are funny!

Rui
-------------- 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/20040519/dffa8fe2/attachment.sig>

From jspaleta at gmail.com  Wed May 19 18:29:09 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 19 May 2004 14:29:09 -0400
Subject: On disttags
In-Reply-To: <40ABA157.5030701@math.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>	<40AB8D26.2090408@math.unl.edu>	<604aa7910405191001415bd496@mail.gmail.com>	<40AB9813.4040005@math.unl.edu>	<604aa7910405191035171e88be@mail.gmail.com>	<40AB9E36.6070100@math.unl.edu>
	<604aa7910405191100744f043d@mail.gmail.com>
	<40ABA157.5030701@math.unl.edu>
Message-ID: <604aa79104051911296c6b7512@mail.gmail.com>

On Wed, 19 May 2004 13:03:03 -0500, Rex Dieter <rdieter at math.unl.edu> wrote:
> "3. Do as much of the development work as possible directly in the
> upstream packages. This includes updates; our default policy will be to
> upgrade to new versions for security as well as for bugfix and new
> feature update releases of packages."

As much as possible..does not mean its always going to be possible.
A promise to avoid the need for a backport doesn't mean its not going
to be needed...critically needed. Building a general naming policy
that doesn't leave room for package mainters and leadership to provide
critical security backports when moving to upstream latest is not the
right thing to do, is a mistake,


> IMHO, The only reason dist_tags can possibly cause any sort of 
> problems with backported fixes is dealing with rpm < 4.2 (or possibly rpm < 4.1 where is incorrectly sorts numerics vs. alphas in version/release 
> tags). In the scope of *this* discussion, we're dealing only with 
> non-buggy rpm versions, so Fedora Core can safely ignore those 
> problems(*). Futher, in the lack of existing dist_tags, these problems go > away.

You know, i dont think we can assume that at all. I bet the 3rd party
repository maintainers that are pushing hard for distag to be the
policy want to make damn sure, that the policy works for all the
distros they are trying to build packages for including all those old
red hat releases with those older rpm versions because they want their
build system to be as automated as possible.

And of course this makes an assumption that the fedora core
buildsystem wont have to be constrained by the rhel build process
requirements. I can not speak knowledgably about how much of a burden
tagging like this will place on maintainers who have to consider using
a codebase for both fedora and rhel packages. But I don't think we can
assume out of hand that whatever fedora core buildsys does is going to
be without constraint on how rhel packaging building works. So for the
sake of discussion i dont know if we can assume a buggy rpm is outside
the bounds of the problem.
Fedora project policy is not going to live in a vacuum, and we do not
know enough about the Core buildsystem to know if rhel packaging
considerations have to be taken into account in packaging naming or
not.

-jef




From rdieter at math.unl.edu  Wed May 19 18:35:01 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 19 May 2004 13:35:01 -0500
Subject: On disttags
In-Reply-To: <orn044l1cz.fsf@free.redhat.lsd.ic.unicamp.br>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<1084439431.3770.13705.camel@mccallum.corsepiu.local>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>	<40AB8D26.2090408@math.unl.edu>
	<orn044l1cz.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <40ABA8D5.4020307@math.unl.edu>

Alexandre Oliva wrote:
> On May 19, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
> 
>>Alexandre Oliva wrote:
>>
>>>How about foo-1-3.fc3 and foo-1-4.fc4
>>>How do I issue an errata for fc3?
> 
> 
>>foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)
> 
> 
> But this breaks foo >= 1-4

I don't follow.  How exactly does it break?

>>or better, release 2 updates
>>foo-1-5.fc3 and foo-1-5.fc4
> 
> 
> This breaks because 1-5.fc3 > 1-4.fc4, and 5.fc3 isn't suitable for
> FC4 because it doesn't contain the change introduced in 1-4.fc4 that
> makes it work on FC4.

That's what the foo-1-5.fc4 update/release is for.

-- Rex




From rdieter at math.unl.edu  Wed May 19 18:41:25 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 19 May 2004 13:41:25 -0500
Subject: On disttags
In-Reply-To: <604aa79104051911296c6b7512@mail.gmail.com>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>	<40AB8D26.2090408@math.unl.edu>	<604aa7910405191001415bd496@mail.gmail.com>	<40AB9813.4040005@math.unl.edu>	<604aa7910405191035171e88be@mail.gmail.com>	<40AB9E36.6070100@math.unl.edu>	<604aa7910405191100744f043d@mail.gmail.com>	<40ABA157.5030701@math.unl.edu>
	<604aa79104051911296c6b7512@mail.gmail.com>
Message-ID: <40ABAA55.5080707@math.unl.edu>

Jeff Spaleta wrote:
> On Wed, 19 May 2004 13:03:03 -0500, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
>>"3. Do as much of the development work as possible directly in the
>>upstream packages. This includes updates; our default policy will be to
>>upgrade to new versions for security as well as for bugfix and new
>>feature update releases of packages."
> 
> 
> As much as possible..does not mean its always going to be possible.

And that's why I said upstream versions are the default, only in 
general.  Other cases are the exception, not the rule (or the majority 
either).

-- Rex




From shahms at shahms.com  Wed May 19 19:02:46 2004
From: shahms at shahms.com (Shahms King)
Date: Wed, 19 May 2004 12:02:46 -0700
Subject: Upgrading FC1 to FC2: Severe problem with modules
In-Reply-To: <20040519182557.GA19996@devserv.devel.redhat.com>
References: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>
	<1084986944.23547.111.camel@shahms.mesd.k12.or.us>
	<1084988466.6026.7.camel@scriabin.tannenrauch.ch>
	<20040519182557.GA19996@devserv.devel.redhat.com>
Message-ID: <1084993366.23547.115.camel@shahms.mesd.k12.or.us>

On Wed, 2004-05-19 at 11:25, Alan Cox wrote:
> On Wed, May 19, 2004 at 07:41:06PM +0200, Gerard Milmeister wrote:
> > > tmscsim module isn't included anymore, though.
> > Same with initio, though I guess that this driver hasn't been maintained
> > anymore.
> 
> Lots ofl older scsi drivers either were not ported to 2.6 or where ported
> but the patches ignored. I'm working on a couple of cases of the latter at
> the moment.

I added an RFE for the tmscsim module along with the general "missing
SCSI modules shouldn't make an upgrade unbootable" bug.  From skimming
various lists and googling around, it looks as though the tmscsim module
wasn't ported until relatively late in the cycle (2.6.0-rc3, if I
remember correctly).  I'm going to try recompiling the RawHide rpms with
it enabled and see how that goes later today.
-- 
Shahms King <shahms at shahms.com>




From arjanv at redhat.com  Wed May 19 19:22:45 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 19 May 2004 21:22:45 +0200
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1084991324.11811.45.camel@roque>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
	<1084981415.2356.163.camel@roque>
	<orr7tgl1hb.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084991324.11811.45.camel@roque>
Message-ID: <1084994565.2782.10.camel@laptop.fenrus.com>


> Restrictions on the whole superimpose on the GPL and LGPL stuff.
> 
> YES or NO ?
> 
> Objective questions are funny!

you need to read the GPL about what "mere aggregation" implies. You can
put restrictions on stuff on a CD even if other *unrelated* parts are
GPL.

(note the "unrelated"; of course unrelated is a bit vague, but you can't
reasonably argue that the fedora logo image is related to, say db4. You
*could* argue that kernel modules (bin only or not) are related to a
kernel they are compiled against on the same cd).

-------------- 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/20040519/b7667611/attachment.sig>

From arjanv at redhat.com  Wed May 19 19:24:04 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 19 May 2004 21:24:04 +0200
Subject: Upgrading FC1 to FC2: Severe problem with modules
In-Reply-To: <1084993366.23547.115.camel@shahms.mesd.k12.or.us>
References: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>
	<1084986944.23547.111.camel@shahms.mesd.k12.or.us>
	<1084988466.6026.7.camel@scriabin.tannenrauch.ch>
	<20040519182557.GA19996@devserv.devel.redhat.com>
	<1084993366.23547.115.camel@shahms.mesd.k12.or.us>
Message-ID: <1084994644.2782.12.camel@laptop.fenrus.com>

\
> I added an RFE for the tmscsim module along with the general "missing
> SCSI modules shouldn't make an upgrade unbootable" bug.  From skimming
> various lists and googling around, it looks as though the tmscsim module
> wasn't ported until relatively late in the cycle (2.6.0-rc3, if I
> remember correctly).  I'm going to try recompiling the RawHide rpms with
> it enabled and see how that goes later today

if you can let us know...

we disabled a bunch of the "semi/unported" scsi modules, because that is
more benign behavior than randomly crapping all over your important data
on your disk, which is what non or wrongly ported modules do ;(

-------------- 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/20040519/37901e5a/attachment.sig>

From chabotc at 4-ice.com  Wed May 19 20:21:15 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Wed, 19 May 2004 22:21:15 +0200
Subject: FC2 Final can't get to loading kernel.. New bug?
References: <001601c43d95$7e581620$0200a8c0@gandalf>
	<200405191029.28350.kewley@cns.caltech.edu>
Message-ID: <000f01c43dde$d6294740$0200a8c0@gandalf>

Wow thanks!

Yes indeed, a Asus P4P800 SE motherboard.. never would've thought to check
bugzilla for my motherboard type.. thanks again for pointing out the bug!
(Added my specs and comments to it)

    -- Chris

----- Original Message ----- 
From: "David Kewley" <kewley at cns.caltech.edu>
To: "Development discussions related to Fedora Core"
<fedora-devel-list at redhat.com>; "Chris Chabot" <chabotc at 4-ice.com>
Sent: Wednesday, May 19, 2004 19:29
Subject: Re: FC2 Final can't get to loading kernel.. New bug?


> Chris Chabot wrote on Wednesday 19 May 2004 04:36:
> > I've used FC2 test 1 and 2 without any problems previously. However when
i
> > now try to boot the FC2 (release), it won't even load the kernel, but
> > instantly reboots my system
> >
> > It get's to the Loading vmlinuz... then loading initrd.. Then, boom,
> > reboots.. (thats just before the "Uncompressing Kernel.." message)
> >
> > ps i did download the first cd again (from a diff mirror even), burned 2
> > more copies, checked MD5's.. but nothing's wrong with the media. As
> > mentioned, test 1 and 2 worked fine on this machine, and the hardware
> > didn't change in the meantime
> >
> > My system details:
> > P4 3.0 Ghz (HT) Cpu
> > Intel 865PE + ICH5R chipset
> > Maxtor 6Y080P0 80Gb (set to ATA 100) HD
> > 3Com 3c9x Network card
> > ATI 9800XT (8x agp) graphics card
> > SB Audigy (with intergrated IEEE 1394 controller)
> > Plextor DVDR PX-708A dvd/cd drive
>
> Is this by any chance an Asus P4P800 motherboard?  If so, see:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121819
>
> David
>




From aoliva at redhat.com  Wed May 19 20:27:26 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 19 May 2004 17:27:26 -0300
Subject: On disttags
In-Reply-To: <40ABA8D5.4020307@math.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
	<40AB8D26.2090408@math.unl.edu>
	<orn044l1cz.fsf@free.redhat.lsd.ic.unicamp.br>
	<40ABA8D5.4020307@math.unl.edu>
Message-ID: <orad04kvrl.fsf@free.redhat.lsd.ic.unicamp.br>

On May 19, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:

> Alexandre Oliva wrote:
>> On May 19, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:
>> 
>>> Alexandre Oliva wrote:
>>> 
>>>> How about foo-1-3.fc3 and foo-1-4.fc4
>>>> How do I issue an errata for fc3?
>> 
>>> foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)
>> But this breaks foo >= 1-4

> I don't follow.  How exactly does it break?

Your foo-1-4.fc3 won't contain the change made in 1-4.fc4, that
is required for FC4, but must not be present in FC3.

If a package requires foo >= 1-4, it's safe to assume that it requires
that change, and 1-4.fc3 won't have it, so things will break.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From aoliva at redhat.com  Wed May 19 20:30:05 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 19 May 2004 17:30:05 -0300
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1084991324.11811.45.camel@roque>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
	<1084981415.2356.163.camel@roque>
	<orr7tgl1hb.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084991324.11811.45.camel@roque>
Message-ID: <or65askvn6.fsf@free.redhat.lsd.ic.unicamp.br>

On May 19, 2004, Rui Miguel Seabra <rms at 1407.org> wrote:

> On Wed, 2004-05-19 at 15:24 -0300, Alexandre Oliva wrote:
>> On May 19, 2004, Rui Miguel Seabra <rms at 1407.org> wrote:
>> 
>> > Look, the phrase I ponted out adds restrictions on distribution.
>> 
>> >    YES or NO ?
>> 
>> Of the whole, yes; of the individual packages released under the GNU
>> GPL or LGPL, no.

> The whole includes GPL and LGPL stuff.

> YES or NO ? :)

Yes.

> Restrictions on the whole superimpose on the GPL and LGPL stuff.

> YES or NO ?

No.

You're free to distribute the GPL-licensed packages as specified by
the GPL.

You're free to distribute the LGPL-licensed packages as specified by
the LGPL.

You're free to distribute other packages as specified by their
respective licenses.

You're free to distribute the whole as specified by its license.

If the whole license said you can't take individual packages and
distribute them, it would be in violation of the GPL.

If the GPL said you can't aggregate GPL packages with non-GPL
packages, you wouldn't be able to create the bundle, but there's a
`mere aggregation' clause in the GPL that permits this.

So all looks fine to me.

#include <std/IANAL>

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From rdieter at math.unl.edu  Wed May 19 20:48:37 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 19 May 2004 15:48:37 -0500
Subject: On disttags
In-Reply-To: <orad04kvrl.fsf@free.redhat.lsd.ic.unicamp.br>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>	<20040513094057.GF29888@neu.nirvana>	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>	<20040513192800.GS29888@neu.nirvana>	<20040514065752.GA17038@neu.nirvana>	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>	<20040514090709.GA21879@neu.nirvana>	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>	<1084770974.3817.2141.camel@mccallum.corsepiu.local>	<20040517182611.GJ26400@neu.nirvana>	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>	<40AB8D26.2090408@math.unl.edu>	<orn044l1cz.fsf@free.redhat.lsd.ic.unicamp.br>	<40ABA8D5.4020307@math.unl.edu>
	<orad04kvrl.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <40ABC825.4080400@math.unl.edu>

Alexandre Oliva wrote:
> On May 19, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
> 
>>Alexandre Oliva wrote:
>>
>>>On May 19, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:
>>>
>>>
>>>>Alexandre Oliva wrote:
>>>>
>>>>
>>>>>How about foo-1-3.fc3 and foo-1-4.fc4
>>>>>How do I issue an errata for fc3?
>>>
>>>>foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)
>>>
>>>But this breaks foo >= 1-4
> 
> 
>>I don't follow.  How exactly does it break?
> 
> 
> Your foo-1-4.fc3 won't contain the change made in 1-4.fc4, that
> is required for FC4, but must not be present in FC3.

Right.

> If a package requires foo >= 1-4, it's safe to assume that it requires
> that change, and 1-4.fc3 won't have it, so things will break.

OK.  This is part of the minor pain that must be endured to start using 
dist_tags.  No one said it would be 100% seamless.  I consider these 
side-effects to be insignificant next to the major advantages that 
dist_tags bring to the table.

In this case, multiple erratas must be released:

The package that *had* contained:
Requires: foo >= 1-4
now should be:
Requires: foo > 1-4

And release foo-1-4.fc3 and foo-1-4.fc4

-- Rex




From mattdm at mattdm.org  Wed May 19 21:04:07 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 19 May 2004 17:04:07 -0400
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <20040519122435.GL30909@devserv.devel.redhat.com>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
Message-ID: <20040519210407.GA2427@jadzia.bu.edu>

On Wed, May 19, 2004 at 08:24:35AM -0400, Jakub Jelinek wrote:
> Using .i586.rpm's wouldn't buy us anything (-march=i586 -mtune=pentium4
> is almost equivalent to -march=i486 -mtune=pentium4 and not
> many programs really use cmpxchg8b instructions (which is not
> even generated by GCC)) and moving the low bar to
> .i686.rpm (note, i686 for GCC/rpm means i686 with X86_FEATURE_CMOV)
> is probably too early for Fedora Core (there are still too many
> VIA CPUs without cmov and even some Pentium's in use).

I think that if the time isn't FC3, it's very very soon after that. I know
that there are many older systems out there, and that they can have a very
useful life under Linux, but there are other more focused, lightweight
distributions which might be better choices there. Perhaps there could even
be a Fedora Lite project branch, if there's enough interest. (And if there's
not enough interest, that says something too.)

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




From leonard at den.ottolander.nl  Wed May 19 22:36:43 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Thu, 20 May 2004 00:36:43 +0200
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <20040519144308.GA31935@devserv.devel.redhat.com>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
	<1084971308.5614.33.camel@athlon.localdomain>
	<20040519130441.GA2365@devserv.devel.redhat.com>
	<1084973787.5614.41.camel@athlon.localdomain>
	<20040519144308.GA31935@devserv.devel.redhat.com>
Message-ID: <1085006202.4753.21.camel@athlon.localdomain>

Hi Alan,

> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 .
> 
> tsc is pentium and higher. cmov is pentium pro and higher. RPM is just broken
> according to that bug.

And if you look closer it wont be fixed. "Marching orders". Hence my
conclusion i386 CPUs are already no longer supported on Fedora Core.
According to your statement the same is true for anything < pentium.
This would mean we could move to i586 as the minimal architecture just
as well.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From alan at redhat.com  Wed May 19 23:23:13 2004
From: alan at redhat.com (Alan Cox)
Date: Wed, 19 May 2004 19:23:13 -0400
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <1085006202.4753.21.camel@athlon.localdomain>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
	<1084971308.5614.33.camel@athlon.localdomain>
	<20040519130441.GA2365@devserv.devel.redhat.com>
	<1084973787.5614.41.camel@athlon.localdomain>
	<20040519144308.GA31935@devserv.devel.redhat.com>
	<1085006202.4753.21.camel@athlon.localdomain>
Message-ID: <20040519232313.GA13693@devserv.devel.redhat.com>

On Thu, May 20, 2004 at 12:36:43AM +0200, Leonard den Ottolander wrote:
> And if you look closer it wont be fixed. "Marching orders". Hence my
> conclusion i386 CPUs are already no longer supported on Fedora Core.
> According to your statement the same is true for anything < pentium.
> This would mean we could move to i586 as the minimal architecture just
> as well.

tsc is not available in some i686 or higher systems and doesn't do what
anyone expects on things like big summit boxes (IBM x440 and the like)




From leonard at den.ottolander.nl  Wed May 19 23:44:30 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Thu, 20 May 2004 01:44:30 +0200
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <20040519232313.GA13693@devserv.devel.redhat.com>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
	<1084971308.5614.33.camel@athlon.localdomain>
	<20040519130441.GA2365@devserv.devel.redhat.com>
	<1084973787.5614.41.camel@athlon.localdomain>
	<20040519144308.GA31935@devserv.devel.redhat.com>
	<1085006202.4753.21.camel@athlon.localdomain>
	<20040519232313.GA13693@devserv.devel.redhat.com>
Message-ID: <1085010269.5676.13.camel@athlon.localdomain>

Hi Alan,

> tsc is not available in some i686 or higher systems and doesn't do what
> anyone expects on things like big summit boxes (IBM x440 and the like)

Which i686 architectures would that be? The big boxes are not relevant
for this bug as inclusion of the offending code is based on an #ifdef
__i386__. Are you arguing this bug should be reopened? Or is the
conclusion that tsc is the culprit wrong?

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From gemi at bluewin.ch  Wed May 19 23:49:15 2004
From: gemi at bluewin.ch (Gerard Milmeister)
Date: Thu, 20 May 2004 01:49:15 +0200
Subject: Distribution checking tool
Message-ID: <1085010555.17488.11.camel@scriabin.tannenrauch.ch>

There might be a need for distribution checking tool.
This tool would check for packages from older distributions that deemed
obsolete (for example I had still qtcups and cipe hanging around), also
configuration files in /etc and other locations. It would look for
.rpmsave and .rpmnew files. For each of these problems it could offer a
way to fix it or retain it as it is. I have the feeling that a lot of
the problems with upgrading is those files from earlier distributions
interfering.

I think there is also a problem of stale gconf keys. For example I had
at some time several keys of the same name, but the one with a "-" in
it, the other with a "_". Is there a way to clean up the gconf database?
-- 
G?rard Milmeister
Tannenrauchstrasse 35
8038 Z?rich
gemi at bluewin.ch




From wtogami at redhat.com  Thu May 20 01:12:19 2004
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 19 May 2004 15:12:19 -1000
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <20040519144308.GA31935@devserv.devel.redhat.com>
References: <20040519122435.GL30909@devserv.devel.redhat.com>	<1084971308.5614.33.camel@athlon.localdomain>	<20040519130441.GA2365@devserv.devel.redhat.com>	<1084973787.5614.41.camel@athlon.localdomain>
	<20040519144308.GA31935@devserv.devel.redhat.com>
Message-ID: <40AC05F3.5020600@redhat.com>

Alan Cox wrote:
> 
> tsc is pentium and higher. cmov is pentium pro and higher. RPM is just broken
> according to that bug.

RPM ever since RH9 has been shipping with an internalized db4, I think 
for the purpose of working without NPTL.  It works great, and I have 
used it every day since RH9's beta.  In fact fedora.us-buildsys relies 
on it for all RH9 through FC2 packages.

Warren Togami
wtogami at redhat.com




From aoliva at redhat.com  Thu May 20 01:37:05 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 19 May 2004 22:37:05 -0300
Subject: Distribution checking tool
In-Reply-To: <1085010555.17488.11.camel@scriabin.tannenrauch.ch>
References: <1085010555.17488.11.camel@scriabin.tannenrauch.ch>
Message-ID: <orn043khfi.fsf@free.redhat.lsd.ic.unicamp.br>

On May 19, 2004, Gerard Milmeister <gemi at bluewin.ch> wrote:

> This tool would check for packages from older distributions that deemed
> obsolete

up2date --show-orphans

> It would look for .rpmsave and .rpmnew files.

locate .rpmsave

locate .rpmnew


That said, having firstboot run that after an upgrade and ask the user
what to do sounds like a reasonable idea.  Where's the patch? :-)

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From fedora at andrewfarris.com  Thu May 20 07:12:03 2004
From: fedora at andrewfarris.com (Andrew Farris)
Date: Thu, 20 May 2004 00:12:03 -0700
Subject: Release Notes and Package List missing
Message-ID: <1085037122.28373.4.camel@CirithUngol>

FC2 Release Notes not yet posted to the main page.

Package List for FC2 not yet posted.
http://fedora.redhat.com/projects/package-list/  still lists FC1 only.

Just a few details that I am sure someone is looking into... but
shouldn't slip through the cracks for too long.  Neither were mentioned
in the announce-list posting either.. have I missed them?

-- 
Andrew Farris, CPE senior (California Polytechnic State University, SLO)
fedora at andrewfarris.com :: lmorgul on irc.freenode.net





From rms at 1407.org  Wed May 19 22:38:42 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Wed, 19 May 2004 23:38:42 +0100
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1084994565.2782.10.camel@laptop.fenrus.com>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
	<1084981415.2356.163.camel@roque>
	<orr7tgl1hb.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084991324.11811.45.camel@roque>
	<1084994565.2782.10.camel@laptop.fenrus.com>
Message-ID: <1085006322.2547.37.camel@roque>

On Wed, 2004-05-19 at 21:22 +0200, Arjan van de Ven wrote:
> > Restrictions on the whole superimpose on the GPL and LGPL stuff.
> > 
> > YES or NO ?
> > 
> > Objective questions are funny!
> 
> you need to read the GPL about what "mere aggregation" implies. You can
> put restrictions on stuff on a CD even if other *unrelated* parts are
> GPL.

I'm not talking about mere agregation.
Mere aggregation is a CD with software.
Installation is refused. That goes way beyond mere aggregation, IMO.

I don't want this to be a problem, I would like to see this very _very_
cleared up since the EULA mentions pristine AND modified copies are
subject to it.

Rui

-------------- 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/20040519/23e41585/attachment.sig>

From mitr at volny.cz  Thu May 20 09:40:49 2004
From: mitr at volny.cz (Miloslav Trmac)
Date: Thu, 20 May 2004 11:40:49 +0200
Subject: [Fwd: Re: Opinion: NVIDIA drivers are a Good Thing [tm]]
In-Reply-To: <1085006322.2547.37.camel@roque>
References: <1084894131.4105.76.camel@roque>
	<orad05lfih.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084977188.2356.146.camel@roque>
	<604aa791040519075629327003@mail.gmail.com>
	<1084981415.2356.163.camel@roque>
	<orr7tgl1hb.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084991324.11811.45.camel@roque>
	<1084994565.2782.10.camel@laptop.fenrus.com>
	<1085006322.2547.37.camel@roque>
Message-ID: <20040520094049.GA16901@chrys.ms.mff.cuni.cz>

On Wed, May 19, 2004 at 11:38:42PM +0100, Rui Miguel Seabra wrote:
> I'm not talking about mere agregation.
> Mere aggregation is a CD with software.
> Installation is refused. That goes way beyond mere aggregation, IMO.
Exactly. GPL doesn't require that every CD that ships the package must
contain an installation program, so it is also not forbidden for the
installation program to put additional restrictions on the user.

You are still free to install the software packages as you see fit
if you don't use the installation program that is completely out
of scope of GPL requirements of the individual packages.
	Mirek




From leonard at den.ottolander.nl  Thu May 20 09:44:42 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Thu, 20 May 2004 11:44:42 +0200
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <40AC05F3.5020600@redhat.com>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
	<1084971308.5614.33.camel@athlon.localdomain>
	<20040519130441.GA2365@devserv.devel.redhat.com>
	<1084973787.5614.41.camel@athlon.localdomain>
	<20040519144308.GA31935@devserv.devel.redhat.com>
	<40AC05F3.5020600@redhat.com>
Message-ID: <1085046281.4755.4.camel@athlon.localdomain>

Hello Warren,

> RPM ever since RH9 has been shipping with an internalized db4, I think 
> for the purpose of working without NPTL.  It works great, and I have 
> used it every day since RH9's beta.

The built in db4 obviously is not the reason why rpm fails on anything
less than a pentium. NPTL code inside rpm is. Read the bug report for
details.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From leonard at den.ottolander.nl  Thu May 20 10:43:12 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Thu, 20 May 2004 12:43:12 +0200
Subject: midnight commander UTF-8 patches and more
Message-ID: <1085049791.4755.26.camel@athlon.localdomain>

Hi,

Vladimir Nadvornik has made available a few patches to complete / fix
the utf-8 patches for the midnight commander at
http://www.suse.de/~nadvornik/mc.html . The largest of these (utf8-input
patch) does not entirely patch against FC1's mc, but please have a look
anyway. It's probably not too hard to fix these rejects.

Vladimir also helped me fix one and a half issue (hotkey binding /
ampersand badness) with a very simple patch which is inlined in
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120735 .

How about the Red Hat patches for mc? Will these be merged with upstream
before mc-4.6.1? Maybe it's a good idea to join efforts. Vladimir will
work on the patches in a couple of weeks.

Finally a remark on a couple of other mc issues in bugzilla. The issues
below have attached patches and/or are easy fixes and IMO should be
included in the next update of mc for FC1 and FC2. Also see
http://www.ottolander.nl/bughunt/index.php?package=mc for reference.

Two times \0 inserted out of range:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=110771
INFO/OBSOLETES always empty in #rpm view:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=67341
out dated file in the rpm package:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=85073

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research




From leonard at den.ottolander.nl  Thu May 20 10:48:07 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Thu, 20 May 2004 12:48:07 +0200
Subject: pango_layout_iter_next_char: Now is the time?
Message-ID: <1085050087.4755.28.camel@athlon.localdomain>

Hello Owen,

> A) Generally, bug fixes for particular upstream
>    packages are best discussed in the appropriate upstream forum.

Well, I attend a few upstream fora, but I do not intend to attend all
fora for packages I have an issue with.

> B) "Please fix this bug" mails are virtually never useful

I thought I'd give it a try anyway.

> C) Your Pango problem was fixed long ago. The Pango bug is still 
>    open because there are deeper/harder issues that also need
>    to be fixed.

Fixed? I just recreated that crash. Or am I interpreting the following
incorrectly?:

#3  <signal handler called>
#4  0x00aa8548 in pango_layout_iter_get_char_extents ()
   from /usr/lib/libpango-1.0.so.0

Are you sure we are speaking of the same issue? If it was fixed then
where, when and how was it fixed?

Are you telling me the "major amount of work" you mention in
http://bugzilla.gnome.org/show_bug.cgi?id=89541 has already been done?

> D) Your other issues have nothing to do with Pango. 
>    (E.g., the crash you were getting was because the title
>    of the terminal tab was being set to junk characters by
>    MC. Now that the Pango crash is fixed, you see the
>    junk characters...)

No. I've always seen the junk characters. I really believe you are
referring to a different issue. Please check the bug reports for details
to make sure we are speaking of the same issue.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From stan at ccs.neu.edu  Thu May 20 13:39:34 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Thu, 20 May 2004 09:39:34 -0400
Subject: subversion-perl needs missing libswigpl.so
Message-ID: <1085060373.9697.18.camel@duergar>

I was doing a 'yum -y --download-only update' and got this:

Resolving dependencies
.Package subversion-perl needs libswigpl.so, this is not available.
Package subversion needs libswigpy.so, this is not available.

Any idea what package this comes from?

-sb




From jorton at redhat.com  Thu May 20 13:47:31 2004
From: jorton at redhat.com (Joe Orton)
Date: Thu, 20 May 2004 14:47:31 +0100
Subject: subversion-perl needs missing libswigpl.so
In-Reply-To: <1085060373.9697.18.camel@duergar>
References: <1085060373.9697.18.camel@duergar>
Message-ID: <20040520134731.GA18880@redhat.com>

On Thu, May 20, 2004 at 09:39:34AM -0400, Stan Bubrouski wrote:
> I was doing a 'yum -y --download-only update' and got this:
> 
> Resolving dependencies
> .Package subversion-perl needs libswigpl.so, this is not available.
> Package subversion needs libswigpy.so, this is not available.
> 
> Any idea what package this comes from?

It comes from the swig package.  If you're pulling from Raw Hide, there
was an issue with the swig package which could cause this, the fixed
version should show up today.

joe




From Axel.Thimm at ATrpms.net  Thu May 20 14:33:49 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 20 May 2004 16:33:49 +0200
Subject: On disttags
In-Reply-To: <40ABA0E7.7080705@math.unl.edu>
References: <ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
	<40AB8D26.2090408@math.unl.edu>
	<604aa7910405191001415bd496@mail.gmail.com>
	<40AB9813.4040005@math.unl.edu>
	<604aa7910405191035171e88be@mail.gmail.com>
	<40ABA0E7.7080705@math.unl.edu>
Message-ID: <20040520143349.GA21296@neu.nirvana>

On Wed, May 19, 2004 at 01:01:11PM -0500, Rex Dieter wrote:
>  In the scope of *this* discussion, we're dealing only with non-buggy 
> rpm versions, so Fedora Core can safely ignore those problems(*). 

> (*) Or possibly someone (RedHat, fedora.us, or fedoralegacy.org) can 
> release an rpm errata to fix these issues as well.

This has already been done, by Jeff Johnson at rpm.org (the unofficial
never-made-it-to-official-but-why errate), ATrpms, fedora.us,
fedoralegacy, ...

The reason for these errata was not the letters-vs-numbers or
rpm-non-symmetric bug, but the database corruption and locking issues.

So, if you have the numbers-and-letters bug, then this bug will be the
least you care about ...

Ergo: We can now safely assume rpm handles numbers and letters
correctly. Especially in the scope of the Fedora Project, as well as
for Red Hat's other product lines (the RHEL family).

(I hope I didn't lie about RHEL, someone please confirm).
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040520/8d7812b3/attachment.sig>

From buildsys at redhat.com  Thu May 20 14:42:10 2004
From: buildsys at redhat.com (Build System)
Date: Thu, 20 May 2004 10:42:10 -0400
Subject: rawhide report: 20040520 changes
Message-ID: <200405201442.i4KEgAJ10561@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-10.0.1-0.20040519191011
--------------------------------
* Wed May 19 2004 Anaconda team <bugzilla at redhat.com>

- built new version from CVS

* Fri Apr 30 2004 Jeremy Katz <katzj at redhat.com>

- Update description, remove prereq on stuff that was only needed 
  for reconfig mode

* Tue Feb 24 2004 Jeremy Katz <katzj at redhat.com>

- buildrequire libselinux-devel


binutils-2.15.90.0.3-7
----------------------
* Wed May 19 2004 Jakub Jelinek <jakub at redhat.com> 2.15.90.0.3-7

- use lib64 instead of lib directories on ia64 if %{_lib} is
  set to lib64 by rpm

bluez-bluefw-1.0-4
------------------
* Tue May 11 2004 David Woodhouse <dwmw2 at redhat.com> 1.0-4

- Change hotplug script to match new bluefw location.
- Move firmware files to /usr/lib/hotplug/firmware

* Tue May 11 2004 David Woodhouse <dwmw2 at redhat.com> 1.0-3

- Move bluefw to /sbin to fix BZ #120881

* Fri Feb 13 2004 Elliot Lee <sopwith at redhat.com> 1.0-2

- rebuilt


bluez-hcidump-1.8-1
-------------------
* Wed May 12 2004 David Woodhouse <dwmw2 at redhat.com>

- update to bluez-hcidump 1.8

bluez-libs-2.7-1
----------------
* Tue May 11 2004 David Woodhouse <dwmw2 at redhat.com> 2.7-1

- Update to bluez-libs 2.7

bluez-utils-2.7-3
-----------------
* Wed May 19 2004 David Woodhouse <dwmw2 at redhat.com> 2.7-3

- Include bluetooth.conf in sources.
- Make new bluez-utils-cups package for CUPS backend.

* Wed May 12 2004 David Woodhouse <dwmw2 at redhat.com> 2.7-2

- Build PIE

* Tue May 11 2004 David Woodhouse <dwmw2 at redhat.com> 2.7-1

- Update to bluez-utils 2.7


chkconfig-1.3.10-1
------------------
* Sat May 29 2004 Bill Nottingham <notting at redhat.com> 1.3.10-1

- mark alternatives help output for translation (#110526)

* Wed Oct 22 2003 Bill Nottingham <notting at redhat.com> 1.3.9-1

- update translations

* Mon Jul 28 2003 Bill Nottingham <notting at redhat.com> 1.3.8-4

- rebuild


cups-1.1.20-8
-------------
* Wed May 19 2004 Tim Waugh <twaugh at redhat.com> 1:1.1.20-8

- If cupsd fails to start, make it exit with an appropriate code so that
  initlog notifies the user (bug #110135).

* Thu May 13 2004 Tim Waugh <twaugh at redhat.com>

- Fix cups/util.c:get_num_sdests() to use encryption when it is necessary
  or requested (bug #118982).
- Use upstream patch for the HTTP/1.1 Continue bug (from STR716).

cvs-1.11.15-6
-------------
* Tue May 18 2004 Nalin Dahyabhai <nalin at redhat.com> 1.11.15-6

- rebuild

* Thu May 13 2004 Nalin Dahyabhai <nalin at redhat.com> 1.11.15-5

- use revised version of Stefan Esser's patch provided by Derek Robert Price

* Mon May 03 2004 Nalin Dahyabhai <nalin at redhat.com> 1.11.15-4

- rebuild


fetchmail-6.2.5-4
-----------------
* Wed May 19 2004 Nalin Dahyabhai <nalin at redhat.com> 6.2.5-4

- turn on SDPS (#123599) and RPA

* Wed May 19 2004 Joe Orton <jorton at redhat.com> 6.2.5-3

- pass AI_ADDRCONFIG to getaddrinfo to prevent pointless AAAA lookups

glib2-2.4.1-1
-------------
* Wed May 19 2004 Matthias Clasen <mclasen at redhat.com> 2.4.1-1

- Update to 2.4.1

glibc-2.3.3-28
--------------
* Wed May 19 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-28

- update from CVS
  - FUTEX_REQUEUE fixes (#115349)
  - SPARC GCC 3.4 build fix
  - fix handling of undefined TLS symbols on IA32 (RELA only),
    SPARC and SH
  - regex translate fix
  - speed up sprintf
  - x86_64 makecontext alignment fix
  - make POSIX sigpause the default sigpause, unless BSD sigpause
    requested

* Tue May 11 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-27

- remove /lib64/tls/librtkaio-2.3.[23].so in glibc_post_upgrade
  on x86-64, s390x and ppc64 instead of /lib/tls/librtkaio-2.3.[23].so
- build mq_{send,receive} with -fexceptions

* Fri May 07 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-26

- update from CVS
  - fix <tgmath.h>
  - fix memory leaks in nis, getifaddrs, etc. caused by incorrect
    use of realloc
- remove /lib/{tls,i686}/librtkaio-2.3.[23].so in glibc_post_upgrade
  and rerun ldconfig if needed, otherwise after glibc upgrade librt.so.1
  might be a stale symlink


gnome-mag-0.11.2-1
------------------
* Tue May 18 2004 Colin Walters <walters at redhat.com> 0.11.2-1

- Update to 0.11.2

gnopernicus-0.9.2-1
-------------------
* Tue May 18 2004 Colin Walters <walters at redhat.com> 0.9.2-1

- Update to 0.9.2
- BuildRequire latest gnome-mag

gok-0.11.2-2
------------
* Tue May 18 2004 Colin Walters <walters at redhat.com> 0.11.2-2

- Bust out new -devel package, make it depend on various
  other -devel packages.  Note this package is pretty much
  useless, but since upstream ships a .pc file we basically
  have to do it.
- Add BuildRequires on perl-libxml-enno
- Cut down obnoxiously long description

gstreamer-plugins-0.8.1-3
-------------------------
* Wed May 19 2004 Colin Walters <walters at redhat.com> 0.8.1-3

- Don't lose if gst-register isn't installed

ipsec-tools-0.2.5-2
-------------------
* Wed Apr 14 2004 Bill Nottingham <notting at redhat.com> - 0.2.5-2

- add patch for potential remote DoS (CAN-2004-0403)

kdebase-3.2.2-6
---------------
* Tue May 18 2004 Than Ngo <than at redhat.com> 6:3.2.2-6

- fix a bug in keyboard layout with xorg.x11, bug #121950

kernel-2.6.6-1.374
------------------
* Wed May 19 2004 Arjan van de Ven <arjanv at redhat.com>

- put firewire race fix in (datacorruptor)

kudzu-1.1.66-1
--------------
* Wed May 19 2004 Bill Nottingham <notting at redhat.com> 1.1.66-1

- MacIO fixes (#115286, <alex.kiernan at thus.net>)

* Thu May 13 2004 Karsten Hopp <karsten at redhat.de> 1.1.65-1 

- add CTC and Escon detection (mainframe)

* Tue May 11 2004 Karsten Hopp <karsten at redhat.de> 1.1.64-1 

- change QETH module name back, newer kernels have reverted the
  name change


libmng-1.0.7-1
--------------
* Wed May 19 2004 Matthias Clasen <mclasen at redhat.com> 1.0.7-1

- Upgrade to 1.0.7

libpng-1.2.5-1
--------------
* Wed May 19 2004 Matthias Clasen <mclasen at redhat.com> 2:1.2.5-1

- 1.2.5

* Mon May 03 2004 Matthias Clasen <mclasen at redhat.com> 2:1.2.2-22

- Redo the out-of-bounds fix in a slightly better way.

* Wed Apr 21 2004 Matthias Clasen <mclasen at redhat.com>

- Bump release number to disambiguate n-v-rs.


libpng10-1.0.15-2
-----------------
* Wed May 19 2004 Matthias Clasen <mclasen at redhat.com> 1.0.15-2

- Don't provide libpng-devel (#110161)

* Wed May 19 2004 Matthias Clasen <mclasen at redhat.com> 1.0.15-1

- 1.0.15
- Update rhconf2 patch 
- Remove bogus badchunks patch (#89854)

* Mon May 03 2004 Matthias Clasen <mclasen at redhat.com> 1.0.13-13

- Redo the out-of-bounds fix in a slightly better way.


libtiff-3.6.1-1
---------------
* Wed May 19 2004 Matthias Clasen <mclasen at redhat.com> 3.6.1-1

- Upgrade to 3.6.1
- Adjust patches
- Don't install tiffgt man page  (#104864)

libungif-4.1.2-1
----------------
* Wed May 19 2004 Matthias Clasen <mclasen at redhat.com> 4.1.2-1

- Upgrade to 4.1.2
- Cleaned up and updated spec file

mdadm-1.5.0-7
-------------
* Wed May 19 2004 Jeremy Katz <katzj at redhat.com> - 1.5.0-7

- add patch with reallyforce mode on creation to be used by anaconda

* Wed May 12 2004 Doug Ledford <dledford at redhat.com> 2.5.0-6

- Fix a bug in the %postun scriptlet related to downgrading to a version
  of mdadm that doesn't include the mdmpd daemon.

* Fri May 07 2004 Doug Ledford <dledford at redhat.com> 1.5.0-5

- Disable service mdmpd by default to avoid [Failed] messages on
  current 2.6 kernels.  Possibly re-enable it by default once the
  2.6 kernels have the md event interface.


nautilus-media-0.8.0-2
----------------------
* Wed May 19 2004 Colin Walters <walters at redhat.com> 0.8.0-2

- BuildRequire GStreamer 0.8.0 bits (#106132)

nfs-utils-1.0.6-22
------------------
* Tue May 18 2004 <SteveD at RedHat.com>

- Removed the auto option from MOUNTD_NFS_V2 and
  MOUNTD_NFS_V3 variables. Since v2 and v3 are on
  by default, there only needs to be away of 
  turning them off.

* Mon May 10 2004 <SteveD at RedHat.com>

- Rebuilt

policycoreutils-1.12-2
----------------------
* Tue May 18 2004 Dan Walsh <dwalsh at redhat.com> 1.12-2

- have restorecon ingnore <<none>>"
- Hand matchpathcon the file status

* Fri May 14 2004 Dan Walsh <dwalsh at redhat.com> 1.12-1

- Update to match NSA

rhythmbox-0.8.4-1
-----------------
* Tue May 18 2004 Colin Walters <walters at redhat.com> - 0.8.4-1

- New upstream version
- Remove backported patches
- Gratuitiously bump various BuildRequires versions

* Mon May 10 2004 Colin Walters <walters at redhat.com> - 0.8.3-4

- Remove code to unregister GConf schema for now (Closes: #122532)

rpmdb-fedora-2-0.20040520
-------------------------

subversion-1.0.3-1
------------------
* Wed May 19 2004 Joe Orton <jorton at redhat.com> 1.0.3-1

- update to 1.0.3

* Sun May 16 2004 Joe Orton <jorton at redhat.com> 1.0.2-3

- add ldconfig invocations for -perl post/postun (Ville Skytt??)

* Tue May 04 2004 Joe Orton <jorton at redhat.com> 1.0.2-2

- add perl MODULE_COMPAT requirement for -perl subpackage
- move perl man pages into -perl subpackage
- clean up -perl installation and dependencies (Ville Skytt??, #123045)


swig-1.3.21-2
-------------
* Wed May 19 2004 Joe Orton <jorton at redhat.com> 1.3.21-2

- restore missing runtime libraries

vsftpd-1.2.1-6
--------------
* Wed May 19 2004 Bill Nottingham <notting at redhat.com> 1.2.1-6

- fix the logrotate config (#116253)

xosview-1.8.0-21
----------------
* Wed May 19 2004 Than Ngo <than at redhat.com> 1.8.0-21

- fix PAGE/DISK lines with kernel > 2.5, they work again.

* Wed May 19 2004 Than Ngo <than at redhat.com> 1.8.0-20

- fixed build problem with gcc34




From Axel.Thimm at ATrpms.net  Thu May 20 14:47:51 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 20 May 2004 16:47:51 +0200
Subject: On disttags (was: Choosing rpm-release for fc1 and fdr add-on
	rpms)
In-Reply-To: <oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <20040520144751.GB21296@neu.nirvana>

On Wed, May 19, 2004 at 01:27:40PM -0300, Alexandre Oliva wrote:
> On May 18, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
> > On Tue, 18 May 2004, Alexandre Oliva wrote:
> 
> > Besides, the case you mention case easily be avoided.  *Always* use the 
> > same # of significant digits/dots in front of dist tag and/or simply 
> > increment the release, so you end up with either
> > -1.0.foo -> -1.1.foo
> > or
> > -1.foo -> -2.foo
> 
> >> If you use disttags, and you have to patch a package such that the
> >> R number goes in between two R numbers that are already out, and you
> >> can't just append the build number at the end for the reasons Axel
> >> already exposed, and you can't add `.number' before the disttag, what
> >> do you do?
> 
> > No problem.  (-:  Migrating *to* disttags actually helps in this 
> > case, and you avoid the problem you mentioned above because there is no 
> > existing dist_tag.  Example, foo-1-3 and foo-1-5 are released now.  
> > Release patched version as:
> > foo-1-3.0.%{dist_tag}
> 
> How about foo-1-3.fc3 and foo-1-4.fc4
> 
> How do I issue an errata for fc3?

If foo-1-4 is already fixed, e.g. needs no errata, then you must fork
the buggy foo-1-3 into decimals, to place it before foo-1-4,
for example foo-1-3.1

So you get with added disttags:

foo-1-3.fc3
foo-1-3.1.fc3
foo-1-4.fc4

in rpm's sort order.

> 3.1.fc3 (or 3.0.fc3?) won't work, because it causes numbers to be
> compared with letters.

Only for non-updated Red Hat 8.0 and before, which means that your rpm
database is anyway out of order at every second install. So, we can
assume a working rpm.

> 3.fc3.1 won't work because upgrading to 4.fc4 will go backwards (I'm
> not sure I buy that, but it's not my argument, it's Axel's).

Well, would you prefer a buggy/insecure version built for fc4, or the
fixed one for fc3, but built against an older glibc? This preference
defines the rpm sort order you are going to give to the errata
packages.

E.g. you either fix both (if both versions are vulerable) separately
to
foo-1-3.1.fc3 and
foo-1-4.1.fc4

or you release a common erratum like
foo-1-5.fc3
foo-1-5.fc4

You still have both choices.

As you noted (I mean Alexandre), there can be a problem with letters
and numbers mixing, when the _number of_ the segments before the
disttag change (like being done for forked timelines).

But this is only for a buggy rpm. If we would really want to be safe,
we shouldn't also use comparision of equal substrings, e.g. "1" vs
"1.1", as this had been another (older) rpm bug.

We do need to define some basic functionality for rpm to be able to do
anything with it, and IMHO we can and should assume the letter/numbers
mixing bug as fixed.

Otherwise all of fedora.us would suffer from this, as there the
disttags from RHL to FC jumped from letters and numbers. And obviously
this issue has not been observed too often.

Disttags are good, not evil :)

Persuaded? If yes, how many disbelieving Red Hat developers are there
to continue? ;)

If not, let's go on with the discussion in half a year, perhaps the
merger with fedora.us will increase the necessity for disttags.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040520/280a906b/attachment.sig>

From shahms at shahms.com  Thu May 20 14:52:25 2004
From: shahms at shahms.com (Shahms King)
Date: Thu, 20 May 2004 07:52:25 -0700
Subject: Upgrading FC1 to FC2: Severe problem with modules
In-Reply-To: <1084994644.2782.12.camel@laptop.fenrus.com>
References: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>
	<1084986944.23547.111.camel@shahms.mesd.k12.or.us>
	<1084988466.6026.7.camel@scriabin.tannenrauch.ch>
	<20040519182557.GA19996@devserv.devel.redhat.com>
	<1084993366.23547.115.camel@shahms.mesd.k12.or.us>
	<1084994644.2782.12.camel@laptop.fenrus.com>
Message-ID: <1085064744.23547.118.camel@shahms.mesd.k12.or.us>

Trying to send this again...

On Wed, 2004-05-19 at 12:24, Arjan van de Ven wrote:
> \
> > I added an RFE for the tmscsim module along with the general "missing
> > SCSI modules shouldn't make an upgrade unbootable" bug.  From skimming
> > various lists and googling around, it looks as though the tmscsim module
> > wasn't ported until relatively late in the cycle (2.6.0-rc3, if I
> > remember correctly).  I'm going to try recompiling the RawHide rpms with
> > it enabled and see how that goes later today
> 
> if you can let us know...
> 
> we disabled a bunch of the "semi/unported" scsi modules, because that is
> more benign behavior than randomly crapping all over your important data
> on your disk, which is what non or wrongly ported modules do ;(
> 

The current (2.6.6-1.370) RawHide kernel works with the tmscsim module
(from what I can tell).  The only thing I have attached to it is a
CD-ROM drive and so I can't tell if the problems I'm having are related
to that or the driver.  I can mount and read data CDs w/o a problem,
playing audio cds works but ripping them with cdda2wav and cdparanoia
does not (same problems others were having for IDE or USB drives). 
Ripping with cdrdao works, however. Since Sound Juicer uses gstreamer
which uses libcdparanoia to rip, none of those work either.

On a similar note: the firewire modules work wonderfully (YMMV) on my
Sony VAIO laptop, even hotplugging the CD drive works (well, the device
is detected and mountable, updfstab isn't run unless kudzu finds it on
boot).  Haven't tried burning with that yet, but it's on my list.

-- 
--Shahms




From jorton at redhat.com  Thu May 20 13:47:31 2004
From: jorton at redhat.com (Joe Orton)
Date: Thu, 20 May 2004 14:47:31 +0100
Subject: subversion-perl needs missing libswigpl.so
In-Reply-To: <1085060373.9697.18.camel@duergar>
References: <1085060373.9697.18.camel@duergar>
Message-ID: <20040520134731.GA18880@redhat.com>

On Thu, May 20, 2004 at 09:39:34AM -0400, Stan Bubrouski wrote:
> I was doing a 'yum -y --download-only update' and got this:
> 
> Resolving dependencies
> .Package subversion-perl needs libswigpl.so, this is not available.
> Package subversion needs libswigpy.so, this is not available.
> 
> Any idea what package this comes from?

It comes from the swig package.  If you're pulling from Raw Hide, there
was an issue with the swig package which could cause this, the fixed
version should show up today.

joe


-- 
fedora-test-list mailing list
fedora-test-list at redhat.com
To unsubscribe: 
http://www.redhat.com/mailman/listinfo/fedora-test-list




From stan at ccs.neu.edu  Thu May 20 17:22:34 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Thu, 20 May 2004 13:22:34 -0400
Subject: subversion-perl needs missing libswigpl.so
In-Reply-To: <20040520134731.GA18880@redhat.com>
References: <1085060373.9697.18.camel@duergar>
	<20040520134731.GA18880@redhat.com>
Message-ID: <1085073754.9697.27.camel@duergar>

On Thu, 2004-05-20 at 09:47, Joe Orton wrote:
> It comes from the swig package.  If you're pulling from Raw Hide, there
> was an issue with the swig package which could cause this, the fixed
> version should show up today.
> 
> joe
> 
Thanks,
Yeah i quickly figured that out after i sent the message.  Wasn't
feeling hot earlier and looking at my screen wasnt making feel better. 
But now my question would be: why the new dependency on SWIG?

-sb




From stan at ccs.neu.edu  Thu May 20 13:39:34 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Thu, 20 May 2004 09:39:34 -0400
Subject: subversion-perl needs missing libswigpl.so
Message-ID: <1085060373.9697.18.camel@duergar>

I was doing a 'yum -y --download-only update' and got this:

Resolving dependencies
Package subversion-perl needs libswigpl.so, this is not available.
Package subversion needs libswigpy.so, this is not available.

Any idea what package this comes from?

-sb


-- 
fedora-test-list mailing list
fedora-test-list at redhat.com
To unsubscribe: 
http://www.redhat.com/mailman/listinfo/fedora-test-list




From mattdm at mattdm.org  Thu May 20 18:34:58 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 20 May 2004 14:34:58 -0400
Subject: subversion-perl needs missing libswigpl.so
In-Reply-To: <1085073754.9697.27.camel@duergar>
References: <1085060373.9697.18.camel@duergar>
	<20040520134731.GA18880@redhat.com>
	<1085073754.9697.27.camel@duergar>
Message-ID: <20040520183458.GA976@jadzia.bu.edu>

On Thu, May 20, 2004 at 01:22:34PM -0400, Stan Bubrouski wrote:
> Yeah i quickly figured that out after i sent the message.  Wasn't
> feeling hot earlier and looking at my screen wasnt making feel better. 
> But now my question would be: why the new dependency on SWIG?

The older swig packages weirdly only provide versionless .so files --
libswigpl.so, for example. So packages like subversion end up with
dependencies on that directly. Really, there should be something like
libswigpl.so.0, and the other package would have dependencies on that. The
new swig packages fix the problem, but until the old other package are
rebuilt against it, they'll be confused.

At least, that's my understanding. Anyone who knows better, feel free to
correct me. :)

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




From jorton at redhat.com  Thu May 20 20:49:05 2004
From: jorton at redhat.com (Joe Orton)
Date: Thu, 20 May 2004 21:49:05 +0100
Subject: subversion-perl needs missing libswigpl.so
In-Reply-To: <1085073754.9697.27.camel@duergar>
References: <1085060373.9697.18.camel@duergar>
	<20040520134731.GA18880@redhat.com>
	<1085073754.9697.27.camel@duergar>
Message-ID: <20040520204905.GA3233@redhat.com>

On Thu, May 20, 2004 at 01:22:34PM -0400, Stan Bubrouski wrote:
> On Thu, 2004-05-20 at 09:47, Joe Orton wrote:
> > It comes from the swig package.  If you're pulling from Raw Hide, there
> > was an issue with the swig package which could cause this, the fixed
> > version should show up today.
> > 
> > joe
> > 
> Thanks,
> Yeah i quickly figured that out after i sent the message.  Wasn't
> feeling hot earlier and looking at my screen wasnt making feel better. 
> But now my question would be: why the new dependency on SWIG?

It's not actually new, the subversion package has had this dependency
for ages...

joe




From strange at nsk.no-ip.org  Wed May 19 20:45:37 2004
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Wed, 19 May 2004 21:45:37 +0100
Subject: Making NPTL the default for FC3, vanilla i386 support
In-Reply-To: <20040519122435.GL30909@devserv.devel.redhat.com>
References: <20040519122435.GL30909@devserv.devel.redhat.com>
Message-ID: <20040519204537.GB18254@nsk.no-ip.org>

On Wed, May 19, 2004 at 08:24:35AM -0400, Jakub Jelinek wrote:
> 1) statically linked programs, no matter whether threaded or not,
>    will now require a NPTL capable kernel (one from RHL 9, RHEL3,
>    FC1, FC2 or any 2.6.x kernel should be enough), dynamically linked
>    programs using -lpthread in some cases as well (e.g. if they are using
>    the functions present in NPTL but not in LinuxThreads)

When compiling static programs, one can always specify the location for
the LT version. A section about the change in the release notes for the
next FC version could have that information.

> 2) while previously blindly setting LD_ASSUME_KERNEL environment
>    variable at the beginning of large shell scripts around some
>    programs and sometimes even in /etc/profile.d/* often worked,
>    now the chances are lower (any time such shell script
>    runs a program which requires NPTL the program would fail
>    to run).  LD_ASSUME_KERNEL should now be really only used
>    on the command line of the broken program which needs
>    LinuxThreads.  E.g.
>    LD_ASSUME_KERNEL=2.4.19 /opt/FOOW/bin/barx --args xyz

I'd rather be able to set flags on program files with that information:
# setth lt_fs $(find /opt/java -type f -perm -u+x)

So there would be no need for individual users to know when a
LD_ASSUME_KERNEL is needed, no need for sysadmins to create wrapper
scripts, and no need to go through an obscure shell script finding the
place where the final binary is called.

> 3) NPTL has not been ported to i386, only i486+, x86_64,
...
>    This means though that almost no FC3 programs can run
>    on vanilla i386{SX,DX} CPUs.  Is this a problem to anyone?

I don't see myself in need to run FC3 programs on i386. However, as long
as it's possible to do a CC="gcc -I/usr/include/linuxthreads
-L/usr/lib{,64}/linuxthreads" rpmbuild --rebuild package.src.rpm, I'll be
able to.

> Now, the question is, as at least all statically linked programs
> built on Fedora Core 3 and many dynamically linked ones will require
> i486+ atomic instructions (xaddl, cmpxchgl), if we should change
> rpm architecture of FC3 rpms or not.

Well, if those .i386.rpms can't run in a i386, then they shouldn't be
named as such. :)

I'd go with the second alternative.

Regards,
Luciano Rocha




From stan at ccs.neu.edu  Thu May 20 22:19:29 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Thu, 20 May 2004 18:19:29 -0400
Subject: subversion-perl needs missing libswigpl.so
In-Reply-To: <20040520204905.GA3233@redhat.com>
References: <1085060373.9697.18.camel@duergar>
	<20040520134731.GA18880@redhat.com> <1085073754.9697.27.camel@duergar>
	<20040520204905.GA3233@redhat.com>
Message-ID: <1085091569.9697.35.camel@duergar>

On Thu, 2004-05-20 at 16:49, Joe Orton wrote:
> It's not actually new, the subversion package has had this dependency
> for ages...
> 
> joe
> 

See I'm confused because:
[root at duergar download]# rpm -q swig
package swig is not installed

Wonder how it I installed the package before, I never --nodep things
like that...

-sb




From stan at ccs.neu.edu  Thu May 20 23:26:32 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Thu, 20 May 2004 19:26:32 -0400
Subject: safe to remove IPV6 from kernel?
Message-ID: <1085095592.9697.37.camel@duergar>

Quick query, as the title suggests I'm wondering if its safe to remove
ip6 from kernel in FC2 + devel?

-sb




From naoki at valuecommerce.com  Fri May 21 02:08:09 2004
From: naoki at valuecommerce.com (Naoki)
Date: Fri, 21 May 2004 11:08:09 +0900
Subject: Anaconda (kickstart handling) idea.
In-Reply-To: <1084908898.4430.28.camel@roadrash.rdu.redhat.com>
References: <40A96A19.4040302@valuecommerce.com>	<20040518061322.GA803@jadzia.bu.edu>	<1084867633.26603.13.camel@galileo.ckloiber.com>	<1084883861.3697.44.camel@localhost.localdomain>	<40AA30F9.2090208@daimi.au.dk>
	<1084908898.4430.28.camel@roadrash.rdu.redhat.com>
Message-ID: <40AD6489.7090208@valuecommerce.com>

Guys, first off thanks for all the suggestions!

I think I'll investigate the cgi style approach first.




From wtogami at redhat.com  Fri May 21 02:19:50 2004
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 20 May 2004 16:19:50 -1000
Subject: python dependency for packages
In-Reply-To: <mailman.1085075523.14564.cvs-commits-list@redhat.com>
References: <mailman.1085075523.14564.cvs-commits-list@redhat.com>
Message-ID: <40AD6746.40409@redhat.com>

The below is an example of an explicit python dependency to 
automatically Require a compatible version of python at build time, from 
fedora.us python-bsddb for FC1.  Any opinions if this is a good solution 
in general for packages that require python?

<warren> %define pyver %(python -c 'import sys ; print sys.version[:3]')
<warren> %define pynext %(python -c 'print %{pyver} + 0.1')
<warren> Requires:       python >= 0:%{pyver}, python < 0:%{pynext}
<warren> any idea why the < part?
<mschwendt> because it is expected to conflict with next version of python
<mschwendt> ehm, be incompatible, not conflict
<warren> why not python = %{pyver} then?
<mschwendt> because of minor python versions between %pyver and %pynext
<warren> are we talking Version changes?
<warren> 2.3.1 to 2.3.2?
<mschwendt> yes
<warren> And there's no python command that can display the major.minor 
of the current python instead?
<warren> [warren at ibmlaptop warren]$ python -c 'import sys ; print 
sys.version[:3]'
<warren> 2.3
<mschwendt> compare that with rpm -q --provides python
<mschwendt> e.g. python = 2.2.3-7
<warren> mschwendt, your explicit dependency is missing the trailing 
-%{release}, then it compares only the %{version}
<mschwendt> the package requires python version X, with:  2.2 <= X < 2.3
<warren> argh... okay I understand now.

John Dennis wrote:
> Update of /cvs/pkgs/rpms/mailman
> 
> Modified Files:
> 	mailman.spec 
> Log Message:
> make python prereq be at least 2.3
> 
> 
> 
> Index: mailman.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/mailman/mailman.spec,v
> retrieving revision 1.29
> retrieving revision 1.30
> diff -u -r1.29 -r1.30
> --- mailman.spec	19 May 2004 01:25:22 -0000	1.29
> +++ mailman.spec	20 May 2004 17:51:51 -0000	1.30
> @@ -40,7 +40,7 @@
>  Summary: Mailing list manager with built in Web access.
>  Name: mailman
>  Version: 2.1.5
> -Release: 2
> +Release: 3
>  Epoch: 3
>  Group: Applications/Internet
>  Source0: ftp://ftp.gnu.org/pub/gnu/mailman/mailman-%{version}.tgz
> @@ -57,8 +57,8 @@
>  URL: http://www.list.org/
>  BuildRoot: %{_tmppath}/%{name}-root
>  Prereq: shadow-utils, /usr/bin/newaliases, /usr/bin/crontab, /sbin/chkconfig, /sbin/service
> -Requires: webserver, python >= 2.2.1, mktemp
> -BuildPrereq: python-devel >= 2.2.1
> +Requires: webserver, python >= 2.3, mktemp
> +BuildPrereq: python-devel >= 2.3
>  
>  %description 
>  Mailman is software to help manage email discussion lists, much like
> @@ -304,6 +304,9 @@
>  %attr(0755 root root) /etc/rc.d/init.d/mailman
>  
>  %changelog
> +* Thu May 20 2004 John Dennis <jdennis at redhat.com> 3:2.1.5-3
> +- make python prereq be at least 2.3
> +
>  * Tue May 18 2004 Jeremy Katz <katzj at redhat.com> 3:2.1.5-2
>  - rebuild 
>  
> 




From wtogami at redhat.com  Fri May 21 02:28:47 2004
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 20 May 2004 16:28:47 -1000
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085095592.9697.37.camel@duergar>
References: <1085095592.9697.37.camel@duergar>
Message-ID: <40AD695F.4070409@redhat.com>

Stan Bubrouski wrote:
> Quick query, as the title suggests I'm wondering if its safe to remove
> ip6 from kernel in FC2 + devel?
> 

This is not a topic suitable for fedora-devel-list, because you appear 
to be doing something unsupported for yourself and would not otherwise 
contribute any improvement value to development of the Fedora Project. 
It may be on topic for fedora-list.

Warren Togami
wtogami at redhat.com




From stan at ccs.neu.edu  Fri May 21 02:53:36 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Thu, 20 May 2004 22:53:36 -0400
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <40AD695F.4070409@redhat.com>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
Message-ID: <1085108015.9697.46.camel@duergar>

On Thu, 2004-05-20 at 22:28, Warren Togami wrote:
> Stan Bubrouski wrote:
> > Quick query, as the title suggests I'm wondering if its safe to remove
> > ip6 from kernel in FC2 + devel?
> > 
> 
> This is not a topic suitable for fedora-devel-list, because you appear 
> to be doing something unsupported for yourself and would not otherwise 

So I'd be alone in having no use for ipv6?  doubtful.

> contribute any improvement value to development of the Fedora Project. 

So you feel this question is of no value?  Lot's of people have no use
for ipv6 at this point in time.  People rebuild kernels all the time and
ask questions here.  How is this any different?

> It may be on topic for fedora-list.
> 

Or maybe they'll say why aren't you posting it to -devel since I'm using
latest -devel packages.

-sb

> Warren Togami
> wtogami at redhat.com
> 




From wtogami at redhat.com  Fri May 21 03:21:59 2004
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 20 May 2004 17:21:59 -1000
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085108015.9697.46.camel@duergar>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar>
Message-ID: <40AD75D7.1070103@redhat.com>

Stan Bubrouski wrote:
>>>Quick query, as the title suggests I'm wondering if its safe to remove
>>>ip6 from kernel in FC2 + devel?
>>>
>>
>>This is not a topic suitable for fedora-devel-list, because you appear 
>>to be doing something unsupported for yourself and would not otherwise 
> 
> 
> So I'd be alone in having no use for ipv6?  doubtful.
> 

We will not be removing functionality in order to accomodate YOUR needs. 
  I personally don't use 70% of the drivers supplied in the kernel, or 
maybe 40% of the packages in FC, but I realize other people do use and 
appreciate it being there.

That being said, Open Source gives you the freedom to customize and 
optimize the software to your desires, and nobody can stop you.  In most 
cases however, it would be off-topic for this list.

> 
>>contribute any improvement value to development of the Fedora Project. 
> 
> 
> So you feel this question is of no value?  Lot's of people have no use
> for ipv6 at this point in time.  People rebuild kernels all the time and
> ask questions here.  How is this any different?

This is off-topic for fedora-devel-list, because it does not contribute 
anything toward the general improvement of Fedora development.  Many 
other posts and entire threads on fedora-devel-list lower the signal to 
noise ratio, and as a result high level developers have decided to avoid 
reading this list entirely.  That is a loss to overall communication and 
transparency.

As a result, I and other Fedora maintainers will be increasingly frankly 
reminding list membership about proper list usage.

> 
> 
>>It may be on topic for fedora-list.
>>
> 
> 
> Or maybe they'll say why aren't you posting it to -devel since I'm using
> latest -devel packages.
> 

Because it is a devel package that you are talking about, then 
fedora-test-list is the proper place to discuss it.  That list is for 
both rawhide and test release discussion.

Warren Togami
wtogami at redhat.com




From wtogami at redhat.com  Fri May 21 03:30:39 2004
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 20 May 2004 17:30:39 -1000
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <40AD75D7.1070103@redhat.com>
References: <1085095592.9697.37.camel@duergar>
	<40AD695F.4070409@redhat.com>	<1085108015.9697.46.camel@duergar>
	<40AD75D7.1070103@redhat.com>
Message-ID: <40AD77DF.5070605@redhat.com>

Warren Togami wrote:
> We will not be removing functionality in order to accomodate YOUR needs. 

s/needs/desires/

Warren




From tibbs at math.uh.edu  Fri May 21 05:05:07 2004
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 21 May 2004 00:05:07 -0500
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085095592.9697.37.camel@duergar>
References: <1085095592.9697.37.camel@duergar>
Message-ID: <ufay8nm4bgc.fsf@epithumia.math.uh.edu>

>>>>> "SB" == Stan Bubrouski <stan at ccs.neu.edu> writes:

SB> Quick query, as the title suggests I'm wondering if its safe to
SB> remove ip6 from kernel in FC2 + devel?

I thought it was built modular, so you could just not load the modules
or even move them out of the way and see what breaks.

 - J<




From felipe_alfaro at linuxmail.org  Fri May 21 05:11:56 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Fri, 21 May 2004 07:11:56 +0200
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085095592.9697.37.camel@duergar>
References: <1085095592.9697.37.camel@duergar>
Message-ID: <1085116315.1641.0.camel@teapot.felipe-alfaro.com>

On Fri, 2004-05-21 at 01:26, Stan Bubrouski wrote:
> Quick query, as the title suggests I'm wondering if its safe to remove
> ip6 from kernel in FC2 + devel?

Why?




From katzj at redhat.com  Fri May 21 05:18:47 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 21 May 2004 01:18:47 -0400
Subject: python dependency for packages
In-Reply-To: <40AD6746.40409@redhat.com>
References: <mailman.1085075523.14564.cvs-commits-list@redhat.com>
	<40AD6746.40409@redhat.com>
Message-ID: <1085116726.3328.12.camel@bree.local.net>

On Thu, 2004-05-20 at 16:19 -1000, Warren Togami wrote:
> The below is an example of an explicit python dependency to 
> automatically Require a compatible version of python at build time, from 
> fedora.us python-bsddb for FC1.  Any opinions if this is a good solution 
> in general for packages that require python?

misa added a python-abi virtual provide that can be used instead (this
then also makes it so that you can have an, eg, python23 compat package
that would work as well).  The way of querying for it is a little less
than ideal, though, as I'm not sure of a way other than a) hard-coding
or b) running rpm during the build.  I guess you could do Requires:
python-abi = $(python -c "import sys; print sys.ver[:3]), but that seems
a little fragile as well.

Jeremy




From pmatilai at welho.com  Fri May 21 05:52:31 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Fri, 21 May 2004 08:52:31 +0300
Subject: python dependency for packages
In-Reply-To: <1085116726.3328.12.camel@bree.local.net>
References: <mailman.1085075523.14564.cvs-commits-list@redhat.com>
	<40AD6746.40409@redhat.com> <1085116726.3328.12.camel@bree.local.net>
Message-ID: <1085118751.12821.14.camel@weasel.net.laiskiainen.org>

On Fri, 2004-05-21 at 08:18, Jeremy Katz wrote:
> On Thu, 2004-05-20 at 16:19 -1000, Warren Togami wrote:
> > The below is an example of an explicit python dependency to 
> > automatically Require a compatible version of python at build time, from 
> > fedora.us python-bsddb for FC1.  Any opinions if this is a good solution 
> > in general for packages that require python?
> 
> misa added a python-abi virtual provide that can be used instead (this
> then also makes it so that you can have an, eg, python23 compat package
> that would work as well).  The way of querying for it is a little less
> than ideal, though, as I'm not sure of a way other than a) hard-coding
> or b) running rpm during the build.  I guess you could do Requires:
> python-abi = $(python -c "import sys; print sys.ver[:3]), but that seems
> a little fragile as well.

That sounds nice, too bad the provide doesn't exist in FC1 python :(
I've been using 
Requires: %{_bindir}/python%{pyver}
to get the major version dependency there and additional
Requires: python >= 2.0
..to express "this needs at least versio foo to work" where necessary.

	- Panu -




From katzj at redhat.com  Fri May 21 06:21:06 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 21 May 2004 02:21:06 -0400
Subject: python dependency for packages
In-Reply-To: <1085118751.12821.14.camel@weasel.net.laiskiainen.org>
References: <mailman.1085075523.14564.cvs-commits-list@redhat.com>
	<40AD6746.40409@redhat.com> <1085116726.3328.12.camel@bree.local.net>
	<1085118751.12821.14.camel@weasel.net.laiskiainen.org>
Message-ID: <1085120466.3328.54.camel@bree.local.net>

On Fri, 2004-05-21 at 08:52 +0300, Panu Matilainen wrote:
> That sounds nice, too bad the provide doesn't exist in FC1 python :(

That's because it was only added in January or thereabouts, IIRC.  At
the same time, retrofitting a less good solution just because it isn't
in older releases basically means no progress can be made except on
glacial time scales

Jeremy




From dwmw2 at infradead.org  Fri May 21 09:08:06 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 21 May 2004 10:08:06 +0100
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <ufay8nm4bgc.fsf@epithumia.math.uh.edu>
References: <1085095592.9697.37.camel@duergar>
	<ufay8nm4bgc.fsf@epithumia.math.uh.edu>
Message-ID: <1085130486.24397.74.camel@imladris.demon.co.uk>

On Fri, 2004-05-21 at 00:05 -0500, Jason L Tibbitts III wrote:
> >>>>> "SB" == Stan Bubrouski <stan at ccs.neu.edu> writes:
> 
> SB> Quick query, as the title suggests I'm wondering if its safe to
> SB> remove ip6 from kernel in FC2 + devel?
> 
> I thought it was built modular, so you could just not load the modules
> or even move them out of the way and see what breaks.

It is built modular, but CONFIG_IPV6 is one of those broken config
options where setting it to 'm' actually changes things inside the
_main_ kernel image. It doesn't _just_ cause the extra module to be
built.

I don't understand which of those changes is causing a problem for Stan,
but it's probably best to try to fix that directly so that having the
ipv6 module available but unloaded is no longer a problem.

Stan, can you elaborate?

-- 
dwmw2





From pmatilai at welho.com  Fri May 21 11:00:08 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Fri, 21 May 2004 14:00:08 +0300 (EEST)
Subject: python dependency for packages
In-Reply-To: <1085120466.3328.54.camel@bree.local.net>
References: <mailman.1085075523.14564.cvs-commits-list@redhat.com>
	<40AD6746.40409@redhat.com> <1085116726.3328.12.camel@bree.local.net>
	<1085118751.12821.14.camel@weasel.net.laiskiainen.org>
	<1085120466.3328.54.camel@bree.local.net>
Message-ID: <Pine.LNX.4.58.0405211358110.13463@chip.laiskiainen.org>

On Fri, 21 May 2004, Jeremy Katz wrote:

> On Fri, 2004-05-21 at 08:52 +0300, Panu Matilainen wrote:
> > That sounds nice, too bad the provide doesn't exist in FC1 python :(
> 
> That's because it was only added in January or thereabouts, IIRC.  At
> the same time, retrofitting a less good solution just because it isn't
> in older releases basically means no progress can be made except on
> glacial time scales

Sure, but as long as people are packaging for FC1 it has to be taken into 
account. For FC2-only and beyond by all means lets use the new provide.

	- Panu -




From pnasrat at redhat.com  Fri May 21 11:51:12 2004
From: pnasrat at redhat.com (Paul Nasrat)
Date: Fri, 21 May 2004 07:51:12 -0400
Subject: FC 2 - RPM virtual provides on PIE broken (odd conflicts/triggers)
Message-ID: <20040521115111.GA32686@devserv.devel.redhat.com>

Some people will be experiencing  odd behaviour due to the way rpm adds library provides - this can causes any PIE executables to be added as 

Provides: $(basename /path/to/foo)

A name level provides matches all EVR so known issues - spurious conflicts,
misfired triggers, etc occur. As more things in rawhide get built -fPIE it's something to be aware of untill an errata can be issued.

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

Paul




From akabi at speakeasy.net  Fri May 21 12:14:26 2004
From: akabi at speakeasy.net (ne...)
Date: Fri, 21 May 2004 08:14:26 -0400 (EDT)
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <40AD75D7.1070103@redhat.com>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar> <40AD75D7.1070103@redhat.com>
Message-ID: <Pine.LNX.4.53.0405210813080.900@mach1.guhvies.org>

On May 20, 2004 at 17:21, Warren Togami in a soothing rage wrote:

[...]
>This is off-topic for fedora-devel-list, because it does not contribute 
>anything toward the general improvement of Fedora development.  Many 
>other posts and entire threads on fedora-devel-list lower the signal to 
>noise ratio, and as a result high level developers have decided to avoid 
>reading this list entirely.  That is a loss to overall communication and 
>transparency.
>
>As a result, I and other Fedora maintainers will be increasingly frankly 
>reminding list membership about proper list usage.
Warren, could please also do this on the fedora-test-list?
It is sorely needed there.

N.Emile...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Switch to: http://www.speakeasy.net/refer/190653
Not to laugh, not to lament, not to curse, but to understand.
		-- Spinoza
 08:13:08  up 3 days, 13:03,  3 users,  load average: 0.00, 0.00, 0.00




From buildsys at redhat.com  Fri May 21 13:10:22 2004
From: buildsys at redhat.com (Build System)
Date: Fri, 21 May 2004 09:10:22 -0400
Subject: rawhide report: 20040521 changes
Message-ID: <200405211310.i4LDAMW24588@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-10.0.1-0.20040521022655
--------------------------------
* Fri May 21 2004 Anaconda team <bugzilla at redhat.com>

- built new version from CVS

* Fri Apr 30 2004 Jeremy Katz <katzj at redhat.com>

- Update description, remove prereq on stuff that was only needed 
  for reconfig mode

* Tue Feb 24 2004 Jeremy Katz <katzj at redhat.com>

- buildrequire libselinux-devel


findutils-4.1.7-26
------------------
* Thu May 20 2004 Tim Waugh <twaugh at redhat.com> 4.1.7-26

- Fixed build requirements (bug #123746).

flim-1.14.6-1
-------------
* Thu May 20 2004 Jens Petersen <petersen at redhat.com> - 1.14.6-1

- update to 1.14.6
- add flim-1.14.6-mel-u-tempfile.patch to fix CAN-2004-0422
- move redundant %emacsver and %xemacsver into requirements
- better url and summary

gcc34-3.4.0-2
-------------
* Thu May 20 2004 Jakub Jelinek  <jakub at redhat.com> 3.4.0-2

- update from gcc-3_4-branch
  - PRs libgcj/14695, preprocessor/15067, 11591, bootstrap/14671,
	bootstrap/15120, c++/14962, c/15004, c++/15064, debug/14829,
	libstdc++/12077, libstdc++/14220, libstdc++/14245, libstdc++/14340,
	libstdc++/14775, libstdc++/14975, libstdc++/15002, libstdc++/15046,
	libstdc++/15047, libstdc++/11610, libstdc++/15074, libstdc++/15090,
	libstdc++/15361, libstdc++/15412, libstdc++/15488, libstdc++/15489,
	middle-end/15054, optimization/13985, optimization/15100,
	optimization/15112, other/1963, target/14715, target/14723,
	target/14813, target/14857, target/15084, target/15130, target/15189,
	target/15202, target/15290, target/15301, target/15302, target/15331
- fix libgcc build on SPARC*
- fix SPARC* bi-arch compiler

glibc-2.3.3-29
--------------
* Thu May 20 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-29

- use lib64 instead of lib on ia64 if %{_lib} is defined to lib64

kudzu-1.1.67-1
--------------
* Fri May 21 2004 Jeremy Katz <katzj at redhat.com> - 1.1.67-1

- look for module.usbmap under /modules also for anaconda usage

libcroco-0.5.1-1
----------------

libglade2-2.4.0-1
-----------------
* Thu May 20 2004 Matthias Clasen <mclasen at redhat.com> - 2.4.0-1

- Upgrade to 2.4.0

libgnomecanvas-2.6.1.1-1
------------------------
* Thu May 20 2004 Matthias Clasen <mclasen at redhat.com> 2.6.1.1-1

- update to 2.6.1.1

libtiff-3.6.1-2
---------------
* Thu May 20 2004 Matthias Clasen <mclasen at redhat.com> 3.6.1-2

- Fix and use the makeflags patch

libungif-4.1.2-2
----------------
* Thu May 20 2004 Matthias Clasen <mclasen at redhat.com> - 4.1.2-2

- Add some forgotten doc files back

mailman-2.1.5-3
---------------
* Thu May 20 2004 John Dennis <jdennis at redhat.com> 3:2.1.5-3

- make python prereq be at least 2.3

mdadm-1.5.0-8
-------------
* Thu May 20 2004 Jeremy Katz <katzj at redhat.com> - 1.5.0-8

- remove unneeded patch, can use --run instead

openoffice.org-1.1.1-5
----------------------
* Thu May 20 2004 Dan Williams <dcbw at redhat.com> 1.1.1-5

- Update to ooo-build 1.1.56-pre (CVS snapshot)
- Fix more malformed TrueType fonts (RH #123441, OOo #24286)
- Fix some UI font issues caused by missing patch in 1.1.1
    (120494, 123685, 122361)

oprofile-0.8-20040511.10
------------------------
* Thu May 20 2004 Will Cohen <wcohen at redhat.com>

- Eliminate AUTOMAKE and ACLOCAL definitions.
- Correct QTDIR and add oprof_start to file manifests.

prelink-0.3.2-3
---------------
* Thu May 20 2004 Jakub Jelinek <jakub at redhat.com> 0.3.2-3

- 4 SPARC 64-bit fixes
- use $CC instead of gcc when checking for TLS support in tls*.sh

* Thu May 20 2004 Jakub Jelinek <jakub at redhat.com> 0.3.2-2

- add 2 new TLS testcases (one that fails e.g. with glibc < 2.3.3-28
  on IA-32)
- SPARC TLS support

psgml-1.2.5-3
-------------
* Thu May 20 2004 Tim Waugh <twaugh at redhat.com> 1.2.5-3

- Build requires emacs (bug #123781).

pydict-0.3.0-7
--------------
* Fri May 21 2004 Leon Ho <llch at redhat.com>

- fix the problem on python

rpmdb-fedora-2-0.20040521
-------------------------

vnc-4.0-1.beta5.1
-----------------
* Thu May 20 2004 Tim Waugh <twaugh at redhat.com> 4.0-1.beta5.1

- 4.0beta5.
- Removed compat, f8 and crash patches.
- Fixed via patch now that NULL is not a valid parameter default.
- Updated gcc34 patch.

xemacs-sumo-20040517-1
----------------------
* Thu May 20 2004 Jens Petersen <petersen at redhat.com> 20040517-1

- update to 2004-05-17 release

xferstats-2.16-10
-----------------
* Thu May 20 2004 Than Ngo <than at redhat.com> 2.16-10

- add BuildRequires on glib-devel, bug #123761




From bpm at ec-group.com  Fri May 21 13:30:01 2004
From: bpm at ec-group.com (Brian Millett)
Date: Fri, 21 May 2004 08:30:01 -0500 (CDT)
Subject: rawhide report: 20040521 changes
In-Reply-To: <200405211310.i4LDAMW24588@porkchop.devel.redhat.com>
References: <200405211310.i4LDAMW24588@porkchop.devel.redhat.com>
Message-ID: <38121.12.41.112.51.1085146201.squirrel@webmail.ec-group.com>


>
>
>
> Updated Packages:
>
> libcroco-0.5.1-1
> ----------------

.Package librsvg2 needs libcrlayeng.so.1, this is not available.
Package nautilus needs libcrlayeng.so.1, this is not available.
Package gnome-games needs libcrlayeng.so.1, this is not available.
Package gimp needs libcrlayeng.so.1, this is not available.
Package gdm needs libcrlayeng.so.1, this is not available.
Package librsvg2 needs libcroco.so.1, this is not available.
Package nautilus needs libcroco.so.1, this is not available.
Package gnome-games needs libcroco.so.1, this is not available.
Package gimp needs libcroco.so.1, this is not available.
Package gdm needs libcroco.so.1, this is not available.
Package librsvg2 needs libcrseleng.so.2, this is not available.
Package nautilus needs libcrseleng.so.2, this is not available.
Package gnome-games needs libcrseleng.so.2, this is not available.
Package gimp needs libcrseleng.so.2, this is not available.
Package gdm needs libcrseleng.so.2, this is not available.

Looks like a few dependencies for libcroco.

-- 
Brian Millett
Enterprise Consulting Group  "Shifts in paradigms
(314) 205-9030           often cause nose bleeds."
bpmATec-groupDOTcom                     Greg Glenn






From thomas at apestaart.org  Fri May 21 15:36:27 2004
From: thomas at apestaart.org (Thomas Vander Stichele)
Date: Fri, 21 May 2004 17:36:27 +0200
Subject: GStreamer packages for Fedora Core 2
Message-ID: <1085153787.7185.129.camel@otto.amantes>

The GStreamer repository for FC2 has been created.

The repository includes most GStreamer plugins, the editor, the player,
the python bindings, gstreamer-ffmpeg and gstreamer-monkeysaudio.

Check out http://gstreamer.freedesktop.org/download/fedora.html for
instructions.  These packages are built against fedora.us and livna.org
packages, and will be submitted to those repositories as well.

Feel free to report bugs to me personally if they're packaging-related,
or in bugzilla.gnome.org if they're code-related.

Enjoy
Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
If you don't ask me out to dinner
I don't eat
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/





From tack at sault.org  Fri May 21 15:52:09 2004
From: tack at sault.org (Jason Tackaberry)
Date: Fri, 21 May 2004 11:52:09 -0400
Subject: VPN solution(s) for Fedora Core
Message-ID: <1085154729.6414.44.camel@draco.sault.org>

Hello Fedora hackers,

Since CIPE's removal from Fedora Core, there is a noticeable void that
still needs to be filled.  I'd like to raise the issue here and spark a
discussion in the hope that we can find consensus on one or more pieces
of VPN software to include in Fedora Core 3.

There seem to be two general approaches to VPNs, each with their own
advantages and disadvantages: kernel space, and user space.  I feel the
only kernel solutions worth considering are those which implement IPsec.
There exist several packages implementing VPN solutions in userspace,
such as vtun, tinc, and OpenVPN.

I have been using and reading about OpenVPN (http://openvpn.sf.net).  It
is intuitive, well designed [1], and has excellent documentation.  It is
released under the GPL, with a special exception clause to allow linking
with OpenSSL. OpenVPN is quality software, and we would be remiss not to
consider it for inclusion in FC3.

CIPE, vtun, and tinc, at least, have known and published flaws.  Last
year Peter Gutmann wrote a paper detailing a number of problems with
these packages [2].  While Gutmann did not review OpenVPN in depth, he
did have this to say about it:

        The key management step (that is, how to get from the SSL
        control channel to the data channel) is documented only in the
        source code, which I don't feel like reverse-engineering, but a
        quick look through it indicates that the author knows what he's
        doing.
        
I've done some googling and unfortunately I can't find a thorough,
independent audit of OpenVPN's design.  However, I've also not been able
to find much in way of vulnerabilities, so it appears to have a good
track record.  This, in combination with Gutmann's remarks in his paper,
as well as my own understanding of its design, gives me a reasonable
amount of confidence in OpenVPN.  (Vastly more than CIPE, at least,
which was included in RHL in the past.)

OpenVPN is released for most unices (including OS X), as well as Windows
2000/XP.  It relies on the kernel only for the tun/tap device.  I have
toyed with other VPN software (notable CIPE, vtun, and freeswan), and
OpenVPN was the only one that Just Worked, and worked intuitively.
                    
I think the other main contender for VPN software in Fedora Core would
be Openswan.  OpenVPN is portable, comfortable (being in userspace),
flexible, and easy, but Openswan implements IPsec which is (mostly)
standardized across vendors, and that's certainly a strong selling
point, in spite of its complexity.

I don't know much about Openswan, but I do feel that there is room for
both an IPsec and user space VPN solution in FC.

So, let the discussions begin!

Cheers,
Jason.


[1]  I am not a cryptographer, and so my opinion of OpenVPN's
     design is meaningless in practice.
[2]  http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt


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

From ville.skytta at iki.fi  Fri May 21 17:10:03 2004
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Fri, 21 May 2004 20:10:03 +0300
Subject: python dependency for packages
In-Reply-To: <1085118751.12821.14.camel@weasel.net.laiskiainen.org>
References: <mailman.1085075523.14564.cvs-commits-list@redhat.com>
	<40AD6746.40409@redhat.com> <1085116726.3328.12.camel@bree.local.net>
	<1085118751.12821.14.camel@weasel.net.laiskiainen.org>
Message-ID: <1085159403.3919.93.camel@bobcat.mine.nu>

On Fri, 2004-05-21 at 08:52, Panu Matilainen wrote:
> On Fri, 2004-05-21 at 08:18, Jeremy Katz wrote:
> > On Thu, 2004-05-20 at 16:19 -1000, Warren Togami wrote:
> > > The below is an example of an explicit python dependency to 
> > > automatically Require a compatible version of python at build time, from 
> > > fedora.us python-bsddb for FC1.  Any opinions if this is a good solution 
> > > in general for packages that require python?
> > 
> > misa added a python-abi virtual provide that can be used instead (this
> > then also makes it so that you can have an, eg, python23 compat package
> > that would work as well).  The way of querying for it is a little less
> > than ideal, though, as I'm not sure of a way other than a) hard-coding
> > or b) running rpm during the build.  I guess you could do Requires:
> > python-abi = $(python -c "import sys; print sys.ver[:3]), but that seems
> > a little fragile as well.
> 
> That sounds nice, too bad the provide doesn't exist in FC1 python :(
> I've been using 
> Requires: %{_bindir}/python%{pyver}
> to get the major version dependency there and additional
> Requires: python >= 2.0
> ..to express "this needs at least versio foo to work" where necessary.

One more approach in the fedora.us spectemplate-python.spec: require the
site library dir and "python".
http://cvs.fedora.us/cgi-bin/cvsweb.cgi/pkg/fedora-rpmdevtools/spectemplate-python.spec?rev=.

See also https://bugzilla.redhat.com/120635




From jjneely at pams.ncsu.edu  Fri May 21 17:16:06 2004
From: jjneely at pams.ncsu.edu (Jack Neely)
Date: Fri, 21 May 2004 13:16:06 -0400
Subject: Anaconda (kickstart handling) idea.
In-Reply-To: <40AD6489.7090208@valuecommerce.com>
References: <40A96A19.4040302@valuecommerce.com>
	<20040518061322.GA803@jadzia.bu.edu>
	<1084867633.26603.13.camel@galileo.ckloiber.com>
	<1084883861.3697.44.camel@localhost.localdomain>
	<40AA30F9.2090208@daimi.au.dk>
	<1084908898.4430.28.camel@roadrash.rdu.redhat.com>
	<40AD6489.7090208@valuecommerce.com>
Message-ID: <20040521171606.GW7552@anduril.pams.ncsu.edu>

You guys might be interested in a web-based kickstart system I have
developed for NC State University.  Its called Web-Kickstart:

    http://linux.ncsu.edu/projects/web-kickstart/

The idea is that hudge numbers of machines need to be installed in a
completely automated fashion.  Kickstarts are very complex and are
therefore replaced with small, simple config files.  (Similar to
Solaris's Jump Start.)  The collection of config files are kept on one
central server and can be changed at will.

Basically, this is a python system that generates a kickstart when
Anaconda grabs for a special URL.

It does require a bit of customization for each site, but I'm willing
and trying to make it more portable.  Any comments, questions are
welcome.

Jack Neely
-- 
Jack Neely <slack at quackmaster.net>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89




From steve at silug.org  Fri May 21 17:25:38 2004
From: steve at silug.org (Steven Pritchard)
Date: Fri, 21 May 2004 12:25:38 -0500
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <1085154729.6414.44.camel@draco.sault.org>
References: <1085154729.6414.44.camel@draco.sault.org>
Message-ID: <20040521172538.GA7363@osiris.silug.org>

On Fri, May 21, 2004 at 11:52:09AM -0400, Jason Tackaberry wrote:
> I'd like to raise the issue here and spark a discussion in the hope
> that we can find consensus on one or more pieces of VPN software to
> include in Fedora Core 3.

Well, FC2 includes ipsec-tools, so I wouldn't say it includes no VPN
software.

> I have been using and reading about OpenVPN (http://openvpn.sf.net).  It
> is intuitive, well designed [1], and has excellent documentation.  It is
> released under the GPL, with a special exception clause to allow linking
> with OpenSSL. OpenVPN is quality software, and we would be remiss not to
> consider it for inclusion in FC3.

There's a OpenVPN package in fedora.us QA:

  https://bugzilla.fedora.us/show_bug.cgi?id=1531

(Which reminds me, I never did submit a couple of minor fixes I made.
Oops.)

> OpenVPN is released for most unices (including OS X), as well as Windows
> 2000/XP.  It relies on the kernel only for the tun/tap device.  I have
> toyed with other VPN software (notable CIPE, vtun, and freeswan), and
> OpenVPN was the only one that Just Worked, and worked intuitively.

I can second that.  I've used it Linux-to-Linux and Windows-to-Linux
and it Just Worked.  It has also Just Worked behind a bunch of random
firewalls.

> I think the other main contender for VPN software in Fedora Core would
> be Openswan.  OpenVPN is portable, comfortable (being in userspace),
> flexible, and easy, but Openswan implements IPsec which is (mostly)
> standardized across vendors, and that's certainly a strong selling
> point, in spite of its complexity.

Like I said, FC2 can already to IPsec.  Regardless, I have also been
working on an openswan package for fedora.us:

  https://bugzilla.fedora.us/show_bug.cgi?id=1271

It still needs work, and I haven't even thought about getting it
working with the built-in 2.6 IPsec stuff yet.

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)398-7360               Mobile: (618)567-7320




From jjneely at pams.ncsu.edu  Fri May 21 17:32:19 2004
From: jjneely at pams.ncsu.edu (Jack Neely)
Date: Fri, 21 May 2004 13:32:19 -0400
Subject: Anaconda (kickstart handling) idea.
In-Reply-To: <20040521171606.GW7552@anduril.pams.ncsu.edu>
References: <40A96A19.4040302@valuecommerce.com>
	<20040518061322.GA803@jadzia.bu.edu>
	<1084867633.26603.13.camel@galileo.ckloiber.com>
	<1084883861.3697.44.camel@localhost.localdomain>
	<40AA30F9.2090208@daimi.au.dk>
	<1084908898.4430.28.camel@roadrash.rdu.redhat.com>
	<40AD6489.7090208@valuecommerce.com>
	<20040521171606.GW7552@anduril.pams.ncsu.edu>
Message-ID: <20040521173219.GZ7552@anduril.pams.ncsu.edu>

In reply to my own message...just wanted to give you a heads up that my
webserver linux.ncsu.edu will be down from 5:00 PM today until Monday
morning.  Major power outage.  *sigh*  But since I just told y'all to go
there....

Jack
-- 
Jack Neely <slack at quackmaster.net>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89




From jmorris at redhat.com  Fri May 21 17:45:08 2004
From: jmorris at redhat.com (James Morris)
Date: Fri, 21 May 2004 13:45:08 -0400 (EDT)
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <1085154729.6414.44.camel@draco.sault.org>
Message-ID: <Xine.LNX.4.44.0405211339200.23113-100000@thoron.boston.redhat.com>

On Fri, 21 May 2004, Jason Tackaberry wrote:

> I've done some googling and unfortunately I can't find a thorough,
> independent audit of OpenVPN's design.  However, I've also not been able
> to find much in way of vulnerabilities, so it appears to have a good
> track record.  This, in combination with Gutmann's remarks in his paper,
> as well as my own understanding of its design, gives me a reasonable
> amount of confidence in OpenVPN.  (Vastly more than CIPE, at least,
> which was included in RHL in the past.)

Yes, Gutmann's comments in general are very positive about OpenVPN.

> I don't know much about Openswan, but I do feel that there is room for
> both an IPsec and user space VPN solution in FC.

Openswan is likely to be very useful to folk who need to use IPSec with
NAT-T, xauth etc.


- James
-- 
James Morris
<jmorris at redhat.com>





From felipe_alfaro at linuxmail.org  Fri May 21 19:04:17 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Fri, 21 May 2004 21:04:17 +0200
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <1085154729.6414.44.camel@draco.sault.org>
References: <1085154729.6414.44.camel@draco.sault.org>
Message-ID: <1085166256.1765.12.camel@teapot.felipe-alfaro.com>

On Fri, 2004-05-21 at 17:52, Jason Tackaberry wrote:

> There seem to be two general approaches to VPNs, each with their own
> advantages and disadvantages: kernel space, and user space.  I feel the
> only kernel solutions worth considering are those which implement IPsec.
> There exist several packages implementing VPN solutions in userspace,
> such as vtun, tinc, and OpenVPN.

I would stick with industry-standard technologies, like IPSec, as much
as possible. I have used IPSec in tunnel mode to setup VPN tunnels
between several branch offices.

--- BEGIN ADVICE ---

However, I must say there are some problems with automatic keying and
2.6 kernels regarding the use of ISAKMP/IKE. The problem is that
settings an SPD between both tunnel end-points causes the first packet
between any of them to start negotiating the Security Association. But
the kernel, instead of queueing the packet that triggered the ISAKMP/IKE
exchange (in order to set up the SA), discards it and returns -EGAIN
error to the userspace caller which, in turn, translates into "Resource
temporarily unavailable" for user space programs.

This happened to me when using "racoon" to manage an automatically keyed
SA, based on X.509 certificates. Doing a ping to force the ISAKMP/IKE
exchange, and to set up the SA, caused the first ping packet to fail
with "Resource temporarily unavailable". Once the SA had been set up, no
more packets were discared.

--- END ADVICE ---

Don't know if this behavior is applicable to 2.4 kernels, Free/SWAN or
Open/SWAP IPSec stacks.





From jim at yonan.net  Fri May 21 19:11:36 2004
From: jim at yonan.net (James Yonan)
Date: Fri, 21 May 2004 19:11:36 -0000
Subject: VPN solution(s) for Fedora Core
Message-ID: <twig.1085166696.76843@yonan.net>

James Morris alerted me to the presence of this thread.  I'm the developer of
OpenVPN and I'd be happy to answer any of your questions about it.

One point I'd like to add to the thread is that there are really two classes
of VPNs in active development today, SSL/TLS VPNs and IPSec, and that it
probably makes sense for a distro to include at least one implementation from
each class.

SSL/TLS VPNs implement the bulk of the VPN function in user-space, use SSL/TLS
as the security layer, use an application-level protocol over TCP or UDP as
the transport layer, and use virtual networking interfaces such as TUN/TAP
interfaces as their hook into the network stack.  Some commercial SSL/TLS VPNs
also provide the ability to use a web browser as the client, though this tends
to be more of a marketing twist to sell secure web apps.

IPSec VPNs take a different approach and attempt to tightly couple the
security function with the transport protocols being secured.  For this
reason, IPSec implementations have a much larger kernel footprint and tend to
have a separate implementation for each OS.

Each class really has its own strengths and weaknesses.  SSL/TLS VPNs tend to
be more flexible as far as configuration options are concerned.  For example
OpenVPN supports IPv4 or IPv6 routed VPNs or Ethernet 802.3 bridged VPNs, can
use UDP or TCP as the transport layer protocol, and runs on most OSes in
current use including Linux, Windows (2000 and above), *BSD, Solaris, and OS
X.  OpenVPN is also very flexible in terms of transport protocols, allowing
TCP, UDP, SOCKS, or TCP proxying using the HTTP connect method.  This latter
flexibility allows OpenVPN to work well with both NAT and restrictive firewall
policies.

IPSec wins in the multi-vendor support category, and in the availability of
dedicated hardware.  One would also expect IPSec to have a potential advantage
in the speed department, given that a kernel VPN implemenation doesn't need as
many context switches between kernel and user space for each VPN packet.  In
practice, however, I have not seen this to be a  critical foci for VPN users
simply because network bandwidth and the CPU cost of crypto operations tend to
be the limiting factor in VPN performance.

On the security side, OpenVPN uses SSL/TLS as the authentication and key
exchange protocol, and then uses the ESP protocol derived from IPSec to secure
the IP stream itself (because IP is an "unreliable" protocol, ESP makes more
sense than SSL/TLS to tunnel the actual IP stream over UDP).

While my personal expertise is more in crypto implementation than in crypto
theory, I understand that crypto implementations don't usually succeed unless
implementors and crytography experts can work together at a certain level. 
And I think that by and large this has occurred with OpenVPN, especially in
the way that crypto experts such as Peter Gutmann have had a hand in guiding
the development of the crypto layer.

One point I would make as well when comparing OpenVPN's security to an
in-kernel implemenation such as IPSec, is that as a user-space daemon, OpenVPN
can be run as user/group nobody or in a chroot jail, providing a certain
degree of containment of code injection exploits, should they be discovered.

For a higher level overview of OpenVPN, you might want to take a look at the
slides for the talk I gave at Linux Fest Northwest this year:

http://openvpn.sourceforge.net/papers/BLUG-talk/

James




From mattdm at mattdm.org  Fri May 21 19:17:31 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 21 May 2004 15:17:31 -0400
Subject: patch to initscripts: configure rc.modules for PC speaker (and
	others)
Message-ID: <20040521191731.GA4139@jadzia.bu.edu>


As probably everyone knows by now, the PC speaker beep module isn't
something that you just _have_. You need to manually insert the pcspkr
module.

Which is annoying, if you want to have it. And, this is a general problem --
there's several other things (some laptop special-feature modules, webcam
support, etc) which don't get loaded automatically even though it'd be nice
for them to.

As someone pointed out on one of the fedora lists (this one, maybe),
rc.sysinit calls /etc/rc.modules if it exists, which it doesn't, by default.
My first cut of this added that file, but then I decided it'd probably be
better to leave that alone and just insert the code into rc.sysinit, both
for backwards-compatibility (who knows what various installations have done)
and because in general the current rc.sysinit isn't broken out like that
elsewhere.

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123927>

Comments?

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




From jmorris at redhat.com  Fri May 21 19:22:40 2004
From: jmorris at redhat.com (James Morris)
Date: Fri, 21 May 2004 15:22:40 -0400 (EDT)
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <1085166256.1765.12.camel@teapot.felipe-alfaro.com>
Message-ID: <Xine.LNX.4.44.0405211521030.23419-100000@thoron.boston.redhat.com>

On Fri, 21 May 2004, Felipe Alfaro Solana wrote:

> However, I must say there are some problems with automatic keying and
> 2.6 kernels regarding the use of ISAKMP/IKE. The problem is that
> settings an SPD between both tunnel end-points causes the first packet
> between any of them to start negotiating the Security Association. But
> the kernel, instead of queueing the packet that triggered the ISAKMP/IKE
> exchange (in order to set up the SA), discards it and returns -EGAIN
> error to the userspace caller which, in turn, translates into "Resource
> temporarily unavailable" for user space programs.

This is a known issue which needs to be fixed in the upstream kernel.


- James
-- 
James Morris
<jmorris at redhat.com>






From smoogen at lanl.gov  Fri May 21 19:23:57 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Fri, 21 May 2004 13:23:57 -0600 (MDT)
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <40AD75D7.1070103@redhat.com>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar> <40AD75D7.1070103@redhat.com>
Message-ID: <Pine.LNX.4.58.0405211316470.9222@smoogen1.lanl.gov>

On Thu, 20 May 2004, Warren Togami wrote:

>Stan Bubrouski wrote:
>>>>Quick query, as the title suggests I'm wondering if its safe to remove
>>>>ip6 from kernel in FC2 + devel?
>>>>
>>>
>>>This is not a topic suitable for fedora-devel-list, because you appear 
>>>to be doing something unsupported for yourself and would not otherwise 
>> 
>> 
>> So I'd be alone in having no use for ipv6?  doubtful.
>> 
>
>We will not be removing functionality in order to accomodate YOUR needs. 
>  I personally don't use 70% of the drivers supplied in the kernel, or 
>maybe 40% of the packages in FC, but I realize other people do use and 
>appreciate it being there.
>
>That being said, Open Source gives you the freedom to customize and 
>optimize the software to your desires, and nobody can stop you.  In most 
>cases however, it would be off-topic for this list.
>

To put it another way.. if you are wanting to work on an IPV6-free
kernel RPM for long term inclusion in the fedora project this may be the
list for you. If you are wanting to know how to compile a kernel on your
system for yourself..  there are lists that are more in-line for that
question. If you are wanting to complain about how the internet would 
have been better if we had just stayed with IPv1.. fedora-loons is 
probably the list for you.

>other posts and entire threads on fedora-devel-list lower the signal to 
>noise ratio, and as a result high level developers have decided to avoid 
>reading this list entirely.  That is a loss to overall communication and 
>transparency.

I definately /dev/null most of the crap erm mail on here. I got off 
fedora-list for that reason.


-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From jim at yonan.net  Fri May 21 20:32:35 2004
From: jim at yonan.net (James Yonan)
Date: Fri, 21 May 2004 20:32:35 -0000
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <1085166256.1765.12.camel@teapot.felipe-alfaro.com>
References: <1085154729.6414.44.camel@draco.sault.org>,
	<1085154729.6414.44.camel@draco.sault.org>
Message-ID: <twig.1085171555.74153@yonan.net>

Felipe Alfaro Solana <felipe_alfaro at linuxmail.org> said:

> On Fri, 2004-05-21 at 17:52, Jason Tackaberry wrote:
> 
> > There seem to be two general approaches to VPNs, each with their own
> > advantages and disadvantages: kernel space, and user space.  I feel the
> > only kernel solutions worth considering are those which implement IPsec.
> > There exist several packages implementing VPN solutions in userspace,
> > such as vtun, tinc, and OpenVPN.
> 
> I would stick with industry-standard technologies, like IPSec, as much
> as possible. I have used IPSec in tunnel mode to setup VPN tunnels
> between several branch offices.

While IPSec tends to work fine for static VPNs in cases where you have full
control over all firewalls, there are cases that come up where IPSec cannot be
used, such as

* Mobile (i.e. road-warrior) usage.  Road warriors running a VPN client on a
laptop may need to securely connect from untrusted networks such as client
sites, internet cafes, LANs behind NAT, etc., where the VPN user does not have
control over the firewall policy on the local network.  A user-space VPN such
as OpenVPN can connect via TCP, UDP, HTTP, socks, etc, and can do it over NAT.

* VPNs between machines which don't have a static IP address, such as cable
modem or DSL clients which have a DHCP assigned address.  OpenVPN has the
ability to "follow" its peer if it changes its address due to a DHCP reassignment.

* IPSec is tightly coupled with IP and therefore is principally suited for
securing IP-based routed networks.  However an extremely common VPN
application is in securing ethernet 202.3 bridges.  User space VPNs which
utilize TUN or TAP type virtual network interfaces can tunnel or bridge
arbitrary application or transport protocols transparently.

As far as the issue of industry standarization is concerned, there is not yet
an RFC to standardize SSL/TLS VPN usage.  This is certainly a valid issue,
though movement is occuring toward drafting a standard.  A key point to
recognize is that even though SSL/TLS VPN protocols have not been canonized by
RFC, the security technologies being utilized HAVE been.  OpenVPN for example
uses SSL/TLS for authentication and key exchange, and IPSec's ESP for datagram
security.

The other issue concerning standardization is that VPNs with extreme
cross-platform portability have less of a need for multi-vendor
interoperability simply because they can be run on almost any platform.

James




From sdhmis at sheratondover.com  Fri May 21 21:42:21 2004
From: sdhmis at sheratondover.com (Kenneth Benson)
Date: Fri, 21 May 2004 17:42:21 -0400
Subject: FC2 Final can't get to loading kernel.. New bug?
Message-ID: <E464EB52A756C148A8F6CDD01B8584151C6E85@2k00893a.sheratondover.net>

As a note to the P4P800 owners on this list, there is a 1017 beta bios at
the ASUS web site.
I intend to update to it (saving my 1016, of course) and try to do an
install during the
next week. I will add a comment to the bugzilla concerning this and update
that and the
list on the results.

Ken Benson

> -----Original Message-----
> From: Chris Chabot [mailto:chabotc at 4-ice.com]
> Sent: Wednesday, May 19, 2004 4:21 PM
> To: David Kewley; Development discussions related to Fedora Core
> Subject: Re: FC2 Final can't get to loading kernel.. New bug?
> 
> 
> Wow thanks!
> 
> Yes indeed, a Asus P4P800 SE motherboard.. never would've 
> thought to check
> bugzilla for my motherboard type.. thanks again for pointing 
> out the bug!
> (Added my specs and comments to it)
> 
>     -- Chris
> 
> ----- Original Message ----- 
> From: "David Kewley" <kewley at cns.caltech.edu>
> To: "Development discussions related to Fedora Core"
> <fedora-devel-list at redhat.com>; "Chris Chabot" <chabotc at 4-ice.com>
> Sent: Wednesday, May 19, 2004 19:29
> Subject: Re: FC2 Final can't get to loading kernel.. New bug?
> 
> 
> > Chris Chabot wrote on Wednesday 19 May 2004 04:36:
> > > I've used FC2 test 1 and 2 without any problems 
> previously. However when
> i
> > > now try to boot the FC2 (release), it won't even load the 
> kernel, but
> > > instantly reboots my system
> > >
> > > It get's to the Loading vmlinuz... then loading initrd.. 
> Then, boom,
> > > reboots.. (thats just before the "Uncompressing Kernel.." message)
> > >
> > > ps i did download the first cd again (from a diff mirror 
> even), burned 2
> > > more copies, checked MD5's.. but nothing's wrong with the 
> media. As
> > > mentioned, test 1 and 2 worked fine on this machine, and 
> the hardware
> > > didn't change in the meantime
> > >
> > > My system details:
> > > P4 3.0 Ghz (HT) Cpu
> > > Intel 865PE + ICH5R chipset
> > > Maxtor 6Y080P0 80Gb (set to ATA 100) HD
> > > 3Com 3c9x Network card
> > > ATI 9800XT (8x agp) graphics card
> > > SB Audigy (with intergrated IEEE 1394 controller)
> > > Plextor DVDR PX-708A dvd/cd drive
> >
> > Is this by any chance an Asus P4P800 motherboard?  If so, see:
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121819
> >
> > David
> >
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://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/20040521/64e9b6d6/attachment.htm>

From felipe_alfaro at linuxmail.org  Fri May 21 21:57:12 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Fri, 21 May 2004 23:57:12 +0200
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <twig.1085171555.74153@yonan.net>
References: <1085154729.6414.44.camel@draco.sault.org>
	, <1085154729.6414.44.camel@draco.sault.org>
	<twig.1085171555.74153@yonan.net>
Message-ID: <1085176631.1765.48.camel@teapot.felipe-alfaro.com>

On Fri, 2004-05-21 at 22:32, James Yonan wrote:
> > 
> > I would stick with industry-standard technologies, like IPSec, as much
> > as possible. I have used IPSec in tunnel mode to setup VPN tunnels
> > between several branch offices.
> 
> While IPSec tends to work fine for static VPNs in cases where you have full
> control over all firewalls, there are cases that come up where IPSec cannot be
> used, such as
> 
> * Mobile (i.e. road-warrior) usage.  Road warriors running a VPN client on a
> laptop may need to securely connect from untrusted networks such as client
> sites, internet cafes, LANs behind NAT, etc., where the VPN user does not have
> control over the firewall policy on the local network.  A user-space VPN such
> as OpenVPN can connect via TCP, UDP, HTTP, socks, etc, and can do it over NAT.

I think this can/will be solved by implementing Mobile IPv4 or Mobile
IPv6 and using Home Agents that are able to proxy the mobile host and
thus masquerade the fact that it has changed its network attachment and,
with high probability, its IP address. In fact, I think there are Mobile
IPSec extensions currently in draft status.

However, it's probably more difficult to implement a solution based on
Mobile IPSec at the moment than using a solution like OpenVPN.

> * VPNs between machines which don't have a static IP address, such as cable
> modem or DSL clients which have a DHCP assigned address.  OpenVPN has the
> ability to "follow" its peer if it changes its address due to a DHCP reassignment.

I think the previous paragraph still applies here.

> * IPSec is tightly coupled with IP and therefore is principally suited for
> securing IP-based routed networks.  However an extremely common VPN
> application is in securing ethernet 202.3 bridges.  User space VPNs which
> utilize TUN or TAP type virtual network interfaces can tunnel or bridge
> arbitrary application or transport protocols transparently.

I agree.

> As far as the issue of industry standarization is concerned, there is not yet
> an RFC to standardize SSL/TLS VPN usage.  This is certainly a valid issue,
> though movement is occuring toward drafting a standard.

There are several drafts related to VPN technologies, like MPLS VPNs,
IPSec + L2TP for end-user and machine authentication, and SSL/TLS/SSH
tunneling. They will take time to reach the standard status, but I think
this will happen sooner or later.




From shahms at shahms.com  Thu May 20 23:57:06 2004
From: shahms at shahms.com (Shahms E. King)
Date: Thu, 20 May 2004 16:57:06 -0700
Subject: Cannot rip with *actual* SCSI CD-ROM drives
In-Reply-To: <1085064744.23547.118.camel@shahms.mesd.k12.or.us>
References: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>
	<1084986944.23547.111.camel@shahms.mesd.k12.or.us>
	<1084988466.6026.7.camel@scriabin.tannenrauch.ch>
	<20040519182557.GA19996@devserv.devel.redhat.com>
	<1084993366.23547.115.camel@shahms.mesd.k12.or.us>
	<1084994644.2782.12.camel@laptop.fenrus.com>
	<1085064744.23547.118.camel@shahms.mesd.k12.or.us>
Message-ID: <1085097426.4083.19.camel@localhost.localdomain>

I'm inclined to think that the tmscsim module works as well as at least
one other module included in the Fedora kernel.  I swapped out my Tekram
adapter for an Adaptec AHA-7850 and am seeing exactly the same problems
ripping CDs.  To summarize:

1) The CD ROM drive shows up in everything (except /proc/scsi/scsi) as
"Unknown CD Drive"
2) Ripping from it in any program other than cdrdao doesn't work.

Even with the sg module loaded, the drives aren't seen by it. It must be
possible to rip from these drives, but I certainly can't figure out how
w/o sg.  Are more/different patches for cdparanoia needed to handle
this?  It sucks because the only reason I have the SCSI card at all is
for my Plextor CD-ROM drive which *still* rips 10 times faster than even
the fastest IDE CD drive I've found (and it's almost 8 years old).  It's
a lot better with the 2.6 kernel than it was with 2.4, but is still
significantly slower than the SCSI drive.

Using strace on cdparanoia and cdda2wav, it appears as though they both
fail when attempting to open the "sg" device O_RDWR|O_EXCL whereas
cdrdao only ever opens it O_READ|O_EXCL. Don't know if that helps at
all, but there it is.
-- 
--Shahms




From dcmwai at pl.jaring.my  Fri May 21 17:09:14 2004
From: dcmwai at pl.jaring.my (Chan Min Wai)
Date: Sat, 22 May 2004 01:09:14 +0800
Subject: The Fedora Hardware Project
In-Reply-To: <1085044931.21879.19.camel@max.localdomain>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
Message-ID: <40AE37BA.3000509@pl.jaring.my>

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

Max K-A ??:

>> How is this hardware Project working? any plane?
>
>
> Hey. I never had a chance to actually *work* on the Fedora Hardware
> Project. If somebody wants to take it over, using that specification,
> that's fine with me. :-)
>
> -Max


I do really hope that I'm capable and possible to help these development
as it is really a obstruction when People asking if what hardware is
supported.
I do actually suggest we do it the simple way, When time go by, let
people rewrite it somehow.

At lease we got something running. (Isn't that nice)

Maybe you think that my idea is too myopia but at least we get something
running and will not stop the people enjoying linux.

My idea is simple.
Just a Web Page with DB that can be short by Brand, Chipset, Disto and
kernel version. And add or a view.

I'm not sure...

Thank You
Chan Min Wai

P.s I don't think that I can help much there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFArje5V0p9slMZLW4RAgroAJ9hsJAJclPFzNFJ5ih2YpFKFg7H8QCggNJh
HmTdxzpgXCp/D0CumPCz/y0=
=iEHn
-----END PGP SIGNATURE-----





From shahms at shahms.com  Thu May 20 23:17:51 2004
From: shahms at shahms.com (Shahms E. King)
Date: Thu, 20 May 2004 16:17:51 -0700
Subject: Cannot rip with *actual* SCSI CD-ROM drives
In-Reply-To: <1085064744.23547.118.camel@shahms.mesd.k12.or.us>
References: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>
	<1084986944.23547.111.camel@shahms.mesd.k12.or.us>
	<1084988466.6026.7.camel@scriabin.tannenrauch.ch>
	<20040519182557.GA19996@devserv.devel.redhat.com>
	<1084993366.23547.115.camel@shahms.mesd.k12.or.us>
	<1084994644.2782.12.camel@laptop.fenrus.com>
	<1085064744.23547.118.camel@shahms.mesd.k12.or.us>
Message-ID: <1085095071.4083.9.camel@localhost.localdomain>

I'm inclined to think that the tmscsim module works as well as at least
one other module included in the Fedora kernel.  I swapped out my Tekram
adapter for an Adaptec AHA-7850 and am seeing exactly the same problems
ripping CDs.  To summarize:

1) The CD ROM drive shows up in everything (except /proc/scsi/scsi) as
"Unknown CD Drive"
2) Ripping from it in any program other than cdrdao doesn't work.

Even with the sg module loaded, the drives aren't seen by it. It must be
possible to rip from these drives, but I certainly can't figure out how
w/o sg.  Are more/different patches for cdparanoia needed to handle
this?  It sucks because the only reason I have the SCSI card at all is
for my Plextor CD-ROM drive which *still* rips 10 times faster than even
the fastest IDE CD drive I've found (and it's almost 8 years old).  It's
a lot better with the 2.6 kernel than it was with 2.4, but is still
significantly slower than the SCSI drive.

Using strace on cdparanoia and cdda2wav, it appears as though they both
fail when attempting to open the "sg" device O_RDWR|O_EXCL whereas
cdrdao only ever opens it O_READ|O_EXCL. Don't know if that helps at
all, but there it is.
-- 
--Shahms
-------------- 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/20040520/3302c054/attachment.sig>

From shahms at shahms.com  Thu May 20 23:45:32 2004
From: shahms at shahms.com (Shahms E. King)
Date: Thu, 20 May 2004 16:45:32 -0700
Subject: Testing (disregard)
Message-ID: <1085096732.4083.15.camel@localhost.localdomain>

I've been having problems sending messages to the list, just trying to
find out why.
-- 
--Shahms




From dwmw2 at infradead.org  Sat May 22 00:25:25 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 22 May 2004 01:25:25 +0100
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <Pine.LNX.4.58.0405211316470.9222@smoogen1.lanl.gov>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar> <40AD75D7.1070103@redhat.com>
	<Pine.LNX.4.58.0405211316470.9222@smoogen1.lanl.gov>
Message-ID: <1085185525.28401.1.camel@imladris.demon.co.uk>

On Fri, 2004-05-21 at 13:23 -0600, Stephen Smoogen wrote:
> To put it another way.. if you are wanting to work on an IPV6-free
> kernel RPM for long term inclusion in the fedora project this may be the
> list for you. 

No actually that would be fedora-loons too :)

> If you are wanting to know how to compile a kernel on your
> system for yourself..  there are lists that are more in-line for that
> question. If you are wanting to complain about how the internet would 
> have been better if we had just stayed with IPv1.. fedora-loons is 
> probably the list for you.

Can we make FC3 do 6to4 by default on all interfaces with non-RFC1918
IPv4 addresses? :)

-- 
dwmw2





From alan at redhat.com  Sat May 22 00:28:14 2004
From: alan at redhat.com (Alan Cox)
Date: Fri, 21 May 2004 20:28:14 -0400
Subject: Cannot rip with *actual* SCSI CD-ROM drives
In-Reply-To: <1085097426.4083.19.camel@localhost.localdomain>
References: <1084973850.3365.5.camel@scriabin.tannenrauch.ch>
	<1084986944.23547.111.camel@shahms.mesd.k12.or.us>
	<1084988466.6026.7.camel@scriabin.tannenrauch.ch>
	<20040519182557.GA19996@devserv.devel.redhat.com>
	<1084993366.23547.115.camel@shahms.mesd.k12.or.us>
	<1084994644.2782.12.camel@laptop.fenrus.com>
	<1085064744.23547.118.camel@shahms.mesd.k12.or.us>
	<1085097426.4083.19.camel@localhost.localdomain>
Message-ID: <20040522002814.GA1507@devserv.devel.redhat.com>

On Thu, May 20, 2004 at 04:57:06PM -0700, Shahms E. King wrote:
> fail when attempting to open the "sg" device O_RDWR|O_EXCL whereas
> cdrdao only ever opens it O_READ|O_EXCL. Don't know if that helps at
> all, but there it is.

The sg driver is somewhat broken in the FC2 kernel. It needs an errata.
(or just replace it with the generic kernel.org 2.6.6 and it will be 
happy)




From Fred.New at microlink.ee  Thu May 20 13:44:52 2004
From: Fred.New at microlink.ee (Fred New)
Date: Thu, 20 May 2004 16:44:52 +0300
Subject: subversion-perl needs missing libswigpl.so
Message-ID: <345764DCB65C0C4FACC44529DE273C18615E3B@eemail1.microlink.lan>

On May 20, 2004, at 16:40 Stan Bubrouski wrote: 

> I was doing a 'yum -y --download-only update' and got this:
> 
> Resolving dependencies
> .Package subversion-perl needs libswigpl.so, this is not available.
> Package subversion needs libswigpy.so, this is not available.
> 
> Any idea what package this comes from?

How about swig?

Maybe questions like this should be on the fedora-list.

Fred




From fedora at wir-sind-cool.org  Wed May 19 17:51:42 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 19 May 2004 19:51:42 +0200
Subject: On disttags
In-Reply-To: <40AB9813.4040005@math.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<1084439431.3770.13705.camel@mccallum.corsepiu.local>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
	<40AB8D26.2090408@math.unl.edu>
	<604aa7910405191001415bd496@mail.gmail.com>
	<40AB9813.4040005@math.unl.edu>
Message-ID: <20040519195142.6fe0da2d.fedora@wir-sind-cool.org>

On Wed, 19 May 2004 12:23:31 -0500, Rex Dieter wrote:

> Speaking of useless large package updates, why does redhat bundle 
> koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice 
> and k3b rpms, so that any updates to koffice and k3b will also "force 
> users to eat useless large updates"?

Avoiding special hooks in the installer and in post-install package
tools. Consider "Add Languages" functionality.

For extra repositories this is also an issue, but a less important one
currently as one can obsolete i18n packages in an update any time.




From stan at ccs.neu.edu  Sat May 22 02:50:38 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Fri, 21 May 2004 22:50:38 -0400
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <40AD75D7.1070103@redhat.com>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar>  <40AD75D7.1070103@redhat.com>
Message-ID: <1085194238.9697.1004.camel@duergar>

On Thu, 2004-05-20 at 23:21, Warren Togami wrote:
> Stan Bubrouski wrote:
> >>>Quick query, as the title suggests I'm wondering if its safe to remove
> >>>ip6 from kernel in FC2 + devel?
> >>>
> >>
> >>This is not a topic suitable for fedora-devel-list, because you appear 
> >>to be doing something unsupported for yourself and would not otherwise 
> > 
> > 
> > So I'd be alone in having no use for ipv6?  doubtful.
> > 
> 
> We will not be removing functionality in order to accomodate YOUR needs. 

First of all I'm sick of this attitude Warren.  I wasn't asking YOU to
remove IPv6 from the kernel.  My question was if I remove it, am I going
to face problems...

>   I personally don't use 70% of the drivers supplied in the kernel, or 
> maybe 40% of the packages in FC, but I realize other people do use and 
> appreciate it being there.
> 

Yeah again you miss the point.

> That being said, Open Source gives you the freedom to customize and 
> optimize the software to your desires, and nobody can stop you.  In most 
> cases however, it would be off-topic for this list.
> 

Yeah I get how opensource works.  That wasn't my question.

> > 
> >>contribute any improvement value to development of the Fedora Project. 
> > 
> > 
> > So you feel this question is of no value?  Lot's of people have no use
> > for ipv6 at this point in time.  People rebuild kernels all the time and
> > ask questions here.  How is this any different?
> 
> This is off-topic for fedora-devel-list, because it does not contribute 
> anything toward the general improvement of Fedora development.  Many 
> other posts and entire threads on fedora-devel-list lower the signal to 
> noise ratio, and as a result high level developers have decided to avoid 
> reading this list entirely.  That is a loss to overall communication and 
> transparency.
> 

Maybe it is because when they ask a legitimate question you send them
away?

> As a result, I and other Fedora maintainers will be increasingly frankly 
> reminding list membership about proper list usage.
> 

All I asked was if it was safe for me to remove IPv6 from latest test
kernel, I don't see how asking a question about development kernel is
suited for the fedora-list...

> > 
> > 
> >>It may be on topic for fedora-list.
> >>
> > 
> > 
> > Or maybe they'll say why aren't you posting it to -devel since I'm using
> > latest -devel packages.
> > 
> 
> Because it is a devel package that you are talking about, then 
> fedora-test-list is the proper place to discuss it.  That list is for 
> both rawhide and test release discussion.
> 

You just told me in your previous e-mail to use the fedora-list when I
clearly stated I was talking about a development kernel.  I can see why
people don't post questions to these lists when all they get is attitude
and a never-ending run around.  You don't seem to know where I should
post this question, how am I suppost to?

> Warren Togami
> wtogami at redhat.com
> 

All I was looking for was a Yes or No not your opinion on everything
except what I actually ask.  This could have a been a *2* message
thread...instead you turned into a crapfest by not reading my e-mails
carefully and being rude for me asking a VERY SIMPLE question.

Good Day,

Stan




From stan at ccs.neu.edu  Sat May 22 03:20:24 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Fri, 21 May 2004 23:20:24 -0400
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085130486.24397.74.camel@imladris.demon.co.uk>
References: <1085095592.9697.37.camel@duergar>
	<ufay8nm4bgc.fsf@epithumia.math.uh.edu>
	<1085130486.24397.74.camel@imladris.demon.co.uk>
Message-ID: <1085196024.9697.1046.camel@duergar>

On Fri, 2004-05-21 at 05:08, David Woodhouse wrote:
> On Fri, 2004-05-21 at 00:05 -0500, Jason L Tibbitts III wrote:
> > >>>>> "SB" == Stan Bubrouski <stan at ccs.neu.edu> writes:
> > 
> > SB> Quick query, as the title suggests I'm wondering if its safe to
> > SB> remove ip6 from kernel in FC2 + devel?
> > 
> > I thought it was built modular, so you could just not load the modules
> > or even move them out of the way and see what breaks.
> 
> It is built modular, but CONFIG_IPV6 is one of those broken config
> options where setting it to 'm' actually changes things inside the
> _main_ kernel image. It doesn't _just_ cause the extra module to be
> built.
> 

Exactly... at the current time IPv6 isn't totally modular, because other
sections of the kernel use it which are usually built into the kernel,
thus adding to the size of the kernel, which is what I'm trying to
reduce for the time being.  The reason I didn't just pull out it last
rebuild was because tons of userspace tools are compiled to use IPv6 and
I was wondering if by removing it I would break anything key...

> I don't understand which of those changes is causing a problem for Stan,
> but it's probably best to try to fix that directly so that having the
> ipv6 module available but unloaded is no longer a problem.
> 

I'm having a plethora of problems with 2.6.4+ kernels on my hardware at
the moment, mostly lockups.  I'm trying to narrow things down a bit, but
atm I don't have any use for IPv6 and IPv6 iptables support, so its
going to the bitbucket for now.


> Stan, can you elaborate?
> 

See above.  I think Warren misunderstood what I was asking.  I wasn't
asking anyone to do anything on your side, I was just wondering if *I*
personally remove it, will fc2+devel go nanners...that's all. 

> -- 
> dwmw2
> 

-sb




From stan at ccs.neu.edu  Sat May 22 03:20:24 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Fri, 21 May 2004 23:20:24 -0400
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085130486.24397.74.camel@imladris.demon.co.uk>
References: <1085095592.9697.37.camel@duergar>
	<ufay8nm4bgc.fsf@epithumia.math.uh.edu>
	<1085130486.24397.74.camel@imladris.demon.co.uk>
Message-ID: <1085196024.9697.1046.camel@duergar>

On Fri, 2004-05-21 at 05:08, David Woodhouse wrote:
> On Fri, 2004-05-21 at 00:05 -0500, Jason L Tibbitts III wrote:
> > >>>>> "SB" == Stan Bubrouski <stan at ccs.neu.edu> writes:
> > 
> > SB> Quick query, as the title suggests I'm wondering if its safe to
> > SB> remove ip6 from kernel in FC2 + devel?
> > 
> > I thought it was built modular, so you could just not load the modules
> > or even move them out of the way and see what breaks.
> 
> It is built modular, but CONFIG_IPV6 is one of those broken config
> options where setting it to 'm' actually changes things inside the
> _main_ kernel image. It doesn't _just_ cause the extra module to be
> built.
> 

Exactly... at the current time IPv6 isn't totally modular, because other
sections of the kernel use it which are usually built into the kernel,
thus adding to the size of the kernel, which is what I'm trying to
reduce for the time being.  The reason I didn't just pull out it last
rebuild was because tons of userspace tools are compiled to use IPv6 and
I was wondering if by removing it I would break anything key...

> I don't understand which of those changes is causing a problem for Stan,
> but it's probably best to try to fix that directly so that having the
> ipv6 module available but unloaded is no longer a problem.
> 

I'm having a plethora of problems with 2.6.4+ kernels on my hardware at
the moment, mostly lockups.  I'm trying to narrow things down a bit, but
atm I don't have any use for IPv6 and IPv6 iptables support, so its
going to the bitbucket for now.


> Stan, can you elaborate?
> 

See above.  I think Warren misunderstood what I was asking.  I wasn't
asking anyone to do anything on your side, I was just wondering if *I*
personally remove it, will fc2+devel go nanners...that's all. 

> -- 
> dwmw2
> 

-sb




From jkeating at j2solutions.net  Sat May 22 06:21:59 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 21 May 2004 23:21:59 -0700
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085194238.9697.1004.camel@duergar>
References: <1085095592.9697.37.camel@duergar> <40AD75D7.1070103@redhat.com>
	<1085194238.9697.1004.camel@duergar>
Message-ID: <200405212322.02391.jkeating@j2solutions.net>

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

On Friday 21 May 2004 19:50, Stan Bubrouski wrote:
> First of all I'm sick of this attitude Warren.  I wasn't asking YOU to
> remove IPv6 from the kernel.  My question was if I remove it, am I going
> to face problems...

He wasn't answering your question, he was pointing out that this is not the 
proper list for such discussion.  This is something we as a community need 
to crack down on.  Specific lists were set up for specific tasks.  Unless 
we want all the developers and Red Hat folk to run back to internal hidden 
lists where they are free from the "2 second questions" that are not 
related to Fedora Core development, we need to keep on topic on this list 
and stress this to others that stray.

> >   I personally don't use 70% of the drivers supplied in the kernel, or
> > maybe 40% of the packages in FC, but I realize other people do use and
> > appreciate it being there.
>
> Yeah again you miss the point.

Actually you both kind of do.  Warren somewhat misread your comments when 
you stated that other people wouldn't want to hear.  He thought you meant 
that ipv6 should be removed to service these other people, while you 
thought that other people would want to hear the answer.  Other people can 
hear the answer in fedora-list or fedora-test (depending on if you're 
using a released kernel or a test/development kernel).  Issues regarding 
mainline Fedora and the future/current development of upstream Fedora Core 
is the topic of this list, not personal customization of Fedora.

> Maybe it is because when they ask a legitimate question you send them
> away?

Legitimate questions are addressed.  Off-topic posts will be redirected.  
Hopefully most don't react the way that you do, but it is an unfortunate 
side effect of trying to straighten out the lists.

> All I asked was if it was safe for me to remove IPv6 from latest test
> kernel, I don't see how asking a question about development kernel is
> suited for the fedora-list...

If it is a development or test kernel, direct your attention to 
fedora-test.  If it is an issue you wish to address for upstream Fedora, 
by all means bring it up here.  What you ask may seem very important to 
you and your install, others may find it important to their install, 
Fedora developers do not find it important to upstream Fedora.  Please 
don't take offense to topic redirection, as you can see things will 
quickly get out of hand.

> You just told me in your previous e-mail to use the fedora-list when I
> clearly stated I was talking about a development kernel.  I can see why
> people don't post questions to these lists when all they get is attitude
> and a never-ending run around.  You don't seem to know where I should
> post this question, how am I suppost to?

I didn't even see that you were using a development kernel.  The version 
wasn't given that I could see.  Easy mistake.

> All I was looking for was a Yes or No not your opinion on everything
> except what I actually ask.  This could have a been a *2* message
> thread...instead you turned into a crapfest by not reading my e-mails
> carefully and being rude for me asking a VERY SIMPLE question.

What may seem like a simple question spawns a long discussion that is off 
topic.  Many such noise threads start here and spew into never ending 
noise that drives off valid and proper discussion.  Was the question 
simple?  Yes.... in a ways.  Was it on topic?  No.  Did it spawn even 
further discussion on the subject which is even further off topic?  Yes, 
and probably will so for at least another few days.

Please don't take offense and help us redirect discussion to their proper 
locations.  Yes I know the documentation is horrible for what subjects go 
to which lists, so please bear that in mind when you get redirected, or 
when you redirect somebody else.

Thanks.

- -- 
Jesse Keating RHCE	(http://geek.j2solutions.net)
Fedora Legacy Team	(http://www.fedoralegacy.org)
GPG Public Key		(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFArvGK4v2HLvE71NURAhdWAJ0eAP+zhgSLQRVcec1xwJRPvWrttwCgw/h3
+bYw5dyqmwDdh993O2H+6PM=
=9voo
-----END PGP SIGNATURE-----




From makgab at freemail.hu  Sat May 22 07:36:18 2004
From: makgab at freemail.hu (MG)
Date: Sat, 22 May 2004 09:36:18 +0200
Subject: FC2 - init level 5...
Message-ID: <40AF02F2.2060807@freemail.hu>

Hi!

I updated a machine with FC1. It seems okay, but the init level 5 (X11)
doesn't work properly.
When the X11 begins to start then it show up a message in console:
"...It seems the X11 runnig in :0 ..."

What is the problem?
If I set the init level to "3" in the /etc/inittab then the system 
starts properly and I can start the X11 with "startx"!

Bye!
Gabor







From makgab at freemail.hu  Sat May 22 07:43:06 2004
From: makgab at freemail.hu (MG)
Date: Sat, 22 May 2004 09:43:06 +0200
Subject: FC2 cyrus-imapd...
Message-ID: <40AF048A.9000609@freemail.hu>

Hi!

FC2 contains the cyrus-imapd. It cannot use the old mailbox format.
How can I migrate it?
If the users like to download their mails with pop3 then they get 
message: "Unable to locate maildrop."

Now I must use the old imap package (wu-imap) from FC1.

Bye!
Gabor







From lorenzo at reality.it  Sat May 22 09:26:51 2004
From: lorenzo at reality.it (Lorenzo Luconi Trombacchi)
Date: Sat, 22 May 2004 11:26:51 +0200
Subject: FC2 cyrus-imapd...
In-Reply-To: <40AF048A.9000609@freemail.hu>
References: <40AF048A.9000609@freemail.hu>
Message-ID: <40AF1CDB.5000301@reality.it>

MG wrote:

> Hi!
>
> FC2 contains the cyrus-imapd. It cannot use the old mailbox format.
> How can I migrate it?
> If the users like to download their mails with pop3 then they get 
> message: "Unable to locate maildrop."
>
> Now I must use the old imap package (wu-imap) from FC1.
>
> Bye!
> Gabor
>
>
>
>
>
You can use dovecot imap server. This imap server is present in Fedora 
Core 2 (and in Core 1 too).
It supports either maildir and 'older' mailbox format.
Cyrus-imapd uses a different maildir format not compatible to other 
maildir system (different to
the maildir format of  postfix, dovecot, courrier etc...). The migration 
from mailbox to cyrus-imapd maildir is possibile
but not easy.

Lorenzo




From felipe_alfaro at linuxmail.org  Sat May 22 09:51:23 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Sat, 22 May 2004 11:51:23 +0200
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085194238.9697.1004.camel@duergar>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar>  <40AD75D7.1070103@redhat.com>
	<1085194238.9697.1004.camel@duergar>
Message-ID: <1085219482.1706.2.camel@teapot.felipe-alfaro.com>

On Sat, 2004-05-22 at 04:50, Stan Bubrouski wrote:

> All I asked was if it was safe for me to remove IPv6 from latest test
> kernel, I don't see how asking a question about development kernel is
> suited for the fedora-list...

I think there should be no problems at all... I started using IPv6 at
2.5.70+ kernels, but previously, I haven't used it at all. I can't think
of any reason that disabling IPv6 could break something. In fact, when I
take my laptop away to IPv4-only networks, I usually remove the
link-local IPv6 address from eth0.




From mr700 at globalnet.bg  Sat May 22 11:08:22 2004
From: mr700 at globalnet.bg (Doncho N. Gunchev)
Date: Sat, 22 May 2004 14:08:22 +0300
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <1085166256.1765.12.camel@teapot.felipe-alfaro.com>
References: <1085154729.6414.44.camel@draco.sault.org>
	<1085166256.1765.12.camel@teapot.felipe-alfaro.com>
Message-ID: <200405221408.22941@-mr700>

On 2004-05-21 (Friday) 22:04, Felipe Alfaro Solana wrote:
> On Fri, 2004-05-21 at 17:52, Jason Tackaberry wrote:
> 
> > There seem to be two general approaches to VPNs, each with their own
> > advantages and disadvantages: kernel space, and user space.  I feel the
> > only kernel solutions worth considering are those which implement IPsec.
> > There exist several packages implementing VPN solutions in userspace,
> > such as vtun, tinc, and OpenVPN.
> 
> I would stick with industry-standard technologies, like IPSec, as much
> as possible. I have used IPSec in tunnel mode to setup VPN tunnels
> between several branch offices.

    In my case, here in Bulgaria, I can't - we have clients with dynamic IP addresses
and behind NAT. I use OpenVPN last two months without any problem (except I had to
add alternative ports 'cause in some places 5000/TCP was filtered). I would love to
see OpenVPN and XCA (both available for linux and windows) in Fedora (maybe FC3).
With FC2 I'll surely add IPSec too, but I prefer having them both up and running just
in case (OpenVPN can connect even when you have http proxy only)...

> ...

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040522/e7276181/attachment.sig>

From alexander.dalloz at uni-bielefeld.de  Sat May 22 12:02:48 2004
From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz)
Date: Sat, 22 May 2004 14:02:48 +0200
Subject: FC2 cyrus-imapd...
In-Reply-To: <40AF048A.9000609@freemail.hu>
References: <40AF048A.9000609@freemail.hu>
Message-ID: <1085227368.8524.30.camel@sirendipity.dogma.lan>

Am Sa, den 22.05.2004 schrieb MG um 09:43:

> FC2 contains the cyrus-imapd. It cannot use the old mailbox format.
> How can I migrate it?
> If the users like to download their mails with pop3 then they get 
> message: "Unable to locate maildrop."
> 
> Now I must use the old imap package (wu-imap) from FC1.
> 
> Bye!
> Gabor

You are posting on the wrong mailing list. If you have problems and
questions using FC2 then subscribe fedora-list at redhat.com. This list is
for development discussions and not user help. Ask your other question
about runlevel 5 there too.

For mailbox migration see i.e.

http://www.oreilly.de/catalog/mimap/chapter/ch09.html#92594

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 1 (Yarrow) on Athlon CPU kernel 2.4.22-1.2188.nptl
Sirendipity 14:00:06 up 9 days, 11:44, load average: 0.43, 0.17, 0.05 
                   [ ????? ?'????? - gnothi seauton ]
             my life is a planetarium - and you are the stars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040522/46214dab/attachment.sig>

From rdieter at math.unl.edu  Sat May 22 12:25:13 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sat, 22 May 2004 07:25:13 -0500 (CDT)
Subject: On disttags
In-Reply-To: <20040519195142.6fe0da2d.fedora@wir-sind-cool.org>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040513094057.GF29888@neu.nirvana>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
	<40AB8D26.2090408@math.unl.edu>
	<604aa7910405191001415bd496@mail.gmail.com>
	<40AB9813.4040005@math.unl.edu>
	<20040519195142.6fe0da2d.fedora@wir-sind-cool.org>
Message-ID: <Pine.LNX.4.58.0405220724450.6217@math.unl.edu>

On Wed, 19 May 2004, Michael Schwendt wrote:

> On Wed, 19 May 2004 12:23:31 -0500, Rex Dieter wrote:
> 
> > Speaking of useless large package updates, why does redhat bundle 
> > koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice 
> > and k3b rpms, so that any updates to koffice and k3b will also "force 
> > users to eat useless large updates"?
> 
> For extra repositories this is also an issue, but a less important one
> currently as one can obsolete i18n packages in an update any time.

But difficult to the other direction.

--Rex




From lfarkas at bppiac.hu  Sat May 22 12:59:09 2004
From: lfarkas at bppiac.hu (Farkas Levente)
Date: Sat, 22 May 2004 14:59:09 +0200
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <1085166256.1765.12.camel@teapot.felipe-alfaro.com>
References: <1085154729.6414.44.camel@draco.sault.org>
	<1085166256.1765.12.camel@teapot.felipe-alfaro.com>
Message-ID: <40AF4E9D.6020101@bppiac.hu>

Felipe Alfaro Solana wrote:
> On Fri, 2004-05-21 at 17:52, Jason Tackaberry wrote:
> 
> 
>>There seem to be two general approaches to VPNs, each with their own
>>advantages and disadvantages: kernel space, and user space.  I feel the
>>only kernel solutions worth considering are those which implement IPsec.
>>There exist several packages implementing VPN solutions in userspace,
>>such as vtun, tinc, and OpenVPN.
> 
> 
> I would stick with industry-standard technologies, like IPSec, as much
> as possible. I have used IPSec in tunnel mode to setup VPN tunnels
> between several branch offices.
> 
> --- BEGIN ADVICE ---
> 
> However, I must say there are some problems with automatic keying and
> 2.6 kernels regarding the use of ISAKMP/IKE. The problem is that
> settings an SPD between both tunnel end-points causes the first packet
> between any of them to start negotiating the Security Association. But
> the kernel, instead of queueing the packet that triggered the ISAKMP/IKE
> exchange (in order to set up the SA), discards it and returns -EGAIN
> error to the userspace caller which, in turn, translates into "Resource
> temporarily unavailable" for user space programs.
> 
> This happened to me when using "racoon" to manage an automatically keyed
> SA, based on X.509 certificates. Doing a ping to force the ISAKMP/IKE
> exchange, and to set up the SA, caused the first ping packet to fail
> with "Resource temporarily unavailable". Once the SA had been set up, no
> more packets were discared.
> 
> --- END ADVICE ---
> 
> Don't know if this behavior is applicable to 2.4 kernels, Free/SWAN or
> Open/SWAP IPSec stacks.

we've about 80 vpn endpoints. at the begining we try to use freeswan and 
ipsec, than racoon, but after a few mounts we give it up. they 
(currently) all has such bugs and missing features that are essential in 
a real enviroment. may be ipsec is the future, but still not know. at 
the sam time openvpn has all the required features and even more! 
reliable, fast and easy to install and manage! I already ask it for last 
year but:
http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00927.html

-- 
   Levente                               "Si vis pacem para bellum!"




From buildsys at redhat.com  Sat May 22 13:42:15 2004
From: buildsys at redhat.com (Build System)
Date: Sat, 22 May 2004 09:42:15 -0400
Subject: rawhide report: 20040522 changes
Message-ID: <200405221342.i4MDgFT26192@porkchop.devel.redhat.com>

 

 
Updated Packages:

checkpolicy-1.10-2
------------------
* Thu Apr 08 2004 Dan Walsh <dwalsh at redhat.com> 1.10-2

- Add BuildRequires byacc

gdm-2.6.0.0-5
-------------
* Fri May 21 2004 Matthias Clasen <mclasen at redhat.com> 1:2.6.0.0-5

- rebuild

gimp-2.0.1-4
------------
* Fri May 21 2004 Matthias Clasen <mclasen at redhat.com>

- rebuild

glibc-2.3.3-30
--------------
* Fri May 21 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-30

- fix pthread_cond_wait on architectures other than IA-32 and
  x86_64

gnome-games-2.6.0.1-3
---------------------
* Fri May 21 2004 Matthias Clasen <mclasen at redhat.com> 2.6.0.1-3 

- rebuild

gtk2-2.4.1-1
------------
* Thu May 20 2004 Matthias Clasen <mclasen at redhat.com> - 2.4.1-1

- Upgrade to 2.4.1

* Wed Mar 17 2004 Alex Larsson <alexl at redhat.com> 2.4.0-1

- update to 2.4.0
- update bin_version to 2.4.0

* Wed Mar 10 2004 Mark McLoughlin <markmc at redhat.com> 2.3.6-1

- Update to 2.3.6
- Remove 2.3.5 buildfix patch
- Remove gdk-pixbuf-xlib dependancy fix


kernel-2.6.6-1.376
------------------

lha-1.14i-15
------------
* Fri May 21 2004 Than Ngo <than at redhat.com> 1.14i-15

- fix segmentation fault on ia64

librsvg2-2.6.4-3
----------------
* Fri May 21 2004 Matthias Clasen <mclasen at redhat.com> 2.6.4-3

- rebuild

nautilus-2.6.0-5
----------------
* Fri May 21 2004 Matthias Clasen <mclasen at redhat.com> 2.6.0-5

- rebuild

* Wed Apr 14 2004 Alexander Larsson <alexl at redhat.com> 2.6.0-4

- update cvs backport, now handles kde trash dir better

* Wed Apr 14 2004 Alexander Larsson <alexl at redhat.com> 2.6.0-3

- add cvs backport


openldap-2.1.29-3
-----------------
* Thu May 13 2004 Thomas Woerner <twoerner at redhat.com> 2.1.29-3

- removed rpath
- added pie patch: slapd and slurpd are now pie
- requires libtool >= 1.5.6-2 (PIC libltdl.a)

policycoreutils-1.13-1
----------------------
* Fri May 21 2004 Dan Walsh <dwalsh at redhat.com> 1.13-1

- Update to latest from NSA
- Change fixfiles to prompt before deleteing /tmp files

rpmdb-fedora-2-0.20040522
-------------------------

sharutils-4.2.1-19
------------------
* Fri May 21 2004 Than Ngo <than at redhat.com> 4.2.1-19

- add suse patch, which fixes buffer overflow in handling of -o option, #123230

slocate-2.7-10
--------------
* Fri May 21 2004 Bill Nottingham <notting at redhat.com> 2.7-10

- exclude cifs (#122499)

system-config-securitylevel-1.3.13-1
------------------------------------
* Fri May 21 2004 Bill Nottingham <notting at redhat.com> 1.3.13-1

- fix typo (#122907)




From fedora at wir-sind-cool.org  Sat May 22 13:57:03 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Sat, 22 May 2004 15:57:03 +0200
Subject: On disttags
In-Reply-To: <Pine.LNX.4.58.0405220724450.6217@math.unl.edu>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<orr7top2vg.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
	<40AB8D26.2090408@math.unl.edu>
	<604aa7910405191001415bd496@mail.gmail.com>
	<40AB9813.4040005@math.unl.edu>
	<20040519195142.6fe0da2d.fedora@wir-sind-cool.org>
	<Pine.LNX.4.58.0405220724450.6217@math.unl.edu>
Message-ID: <20040522155703.21139e2a.fedora@wir-sind-cool.org>

On Sat, 22 May 2004 07:25:13 -0500 (CDT), Rex Dieter wrote:

> On Wed, 19 May 2004, Michael Schwendt wrote:
> 
> > On Wed, 19 May 2004 12:23:31 -0500, Rex Dieter wrote:
> > 
> > > Speaking of useless large package updates, why does redhat bundle 
> > > koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice 
> > > and k3b rpms, so that any updates to koffice and k3b will also "force 
> > > users to eat useless large updates"?
> > 

[some part of the quote is missing here]

> > For extra repositories this is also an issue, but a less important one
> > currently as one can obsolete i18n packages in an update any time.
> 
> But difficult to the other direction.

That's the same problem as referred to in the part that's missing
in above quote. [Unless package tools are tuned to "know about" i18n
packages and pull them in when necessary.]




From alan at redhat.com  Sat May 22 14:25:21 2004
From: alan at redhat.com (Alan Cox)
Date: Sat, 22 May 2004 10:25:21 -0400
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085194238.9697.1004.camel@duergar>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar> <40AD75D7.1070103@redhat.com>
	<1085194238.9697.1004.camel@duergar>
Message-ID: <20040522142521.GA24751@devserv.devel.redhat.com>

On Fri, May 21, 2004 at 10:50:38PM -0400, Stan Bubrouski wrote:
> First of all I'm sick of this attitude Warren.  I wasn't asking YOU to
> remove IPv6 from the kernel.  My question was if I remove it, am I going
> to face problems...

gftp might break. There was a bug with gftp and ipv6 aware sites that
Im not sure was fixed by gftp updates, by the fact with have ipv6 or
in both.

Alan




From thomas at apestaart.org  Sat May 22 15:56:49 2004
From: thomas at apestaart.org (Thomas Vander Stichele)
Date: Sat, 22 May 2004 17:56:49 +0200
Subject: building packages for FC2 for external kernel modules
Message-ID: <1085241408.2861.44.camel@otto.amantes>

Hi all,

I'd like to spark some discussion on how to properly package kernel
modules for FC2.  I have personally packaged a few kernel module
packages for FC1 for fedora.us (see
http://thomas.apestaart.org/download/pkg/fedora-1-i386-fedora-stable/),
and Ville Skytta has packaged some others using a different technique.

I have spent some time this week getting more familiar with the linux
2.6 buildsystem, and have come up with a similar system to what I had
for 2.4.  I'd like to explain the various parts of the problem and
solution and get some feedback so I can fix the procedure and propose it
to fedora.us

First of all, a few things are different with 2.6 and FC2:
- you cannot use kernel-source anymore to build for all archs (i586,
i686 - athlon is dropped) and types (regular and -smp)  This is because
you need a bunch of different headers and built files
- these built files are packaged in the kernel rpm and install in
/lib/modules/`uname -r`/build which is now no longer a symlink to
/usr/src/linux-(rel) but a real directory.  This effectively prevents
you from building kernel modules for more than one arch at the same time
on your system, since there's no way to install the same kernel rpm for
different archs.
- afaict the FC2 kernel no longer uses symbol versioning (MODVERSIONS
not defined, and Module.symvers only contains "0" versions.  I have no
idea why this change has been made.
- 2.6 has a new kbuild system that makes it possible to build
out-of-source kernel modules more reliably/easily

So, how does the current procedure work ?

- I wrote a script (http://thomas.apestaart.org/download/tmp/kmd.py)
which takes a set of kernel rpms for the same-version release, but
different arch/types, extracts them, then creates a symlink/copy forest
that produces a tree of dirs with the same contents as each of the four
rpms
(http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/kernel-module-devel-2.6.5-1.358-0.1-0.fdr.1.2/)
The reason for doing this is so that modules for each arch/target combo
can again be built on one kernel, and the resulting rpm is smaller than
four copies of the other rpms.
Currently, this rpm puts files in

/usr/share/kernel-module-devel-2.6.5-1.358 :

common                       kernel-smp-2.6.5-1.358.i586.rpm
kernel-2.6.5-1.358.i586.rpm  kernel-smp-2.6.5-1.358.i686.rpm
kernel-2.6.5-1.358.i686.rpm

common is a symlink to /lib/modules/`uname -r` (which can be regular or
smp, and is symlinked at %post time by the rpm).
the four other directories are named exactly like the rpm they were part
of, and contains a tree of files that are different to the others, and
symlinks to the common directory.

- In the autostars project, we have come up with a set of scripts and a
sample project to package kernel modules and build them reliably and
reproducably against any kernel build tree
(http://cvs.sourceforge.net/viewcvs.py/autostars/autostars/linux/)
This has been updated with a full set of procedures to build for 2.6 as
well.  Given only the argument
--with-linuxdir=/usr/share/kernel-module-devel-(ver-rel)/(rpm dir), it
can build the correct kernel module.  (This same project can still be
used to build 2.4 modules correctly as well, including redhat's special
defines for boot,enterprise,smp,bigmem from /boot/kernel.h)
For 2.6, it includes a libtool-like script that takes care of installing
modules and taking into account symbol versions.

- like before, I have created patches to hostap and ipw2100 drivers to
autotoolize them using this setup.  This only takes ten minutes if
you're used to autotools, and ten more if you want it to work out of the
box for both 2.4 and 2.6 (assuming the source allows this).

- Since ipw2100 needs symbol versions and include files from hostap,
I've made the hostap rpm install these files as part of a
kernel-module-devel-hostap-(ver-rel) rpm, in the same tree as the
original kernel-module-devel rpm.  all hostap*.symvers files end up in
e.g.
/usr/share/kernel-module-devel-2.6.5-1.358/kernel-2.6.5-1.358.i686.rpm
(which is where Modules.symvers lives).
The .h files I have for now put in
/usr/share/kernel-module-devel-2.6.5-1.358/kernel-2.6.5-1.358.i686.rpm/include/modules/hostap

- the spec files for ipw2100 and hostap need some small tweaks to build
both on pre-fc2 (with 2.4) and post-fc2.  It mainly consists of the
first buildrequire'ing kernel-source and kernel, and the second
buildrequiring kernel-module-devel-(ver-rel).  For hostap, depending on
2.4 or 2.6, different symbol versioning files are installed
(builddir/include/linux/modules/*.ver versus builddir/*.symvers)
Currently the configure invocation is slightly different too, but this
could be fixed.

The resulting rpms are up at
http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/kernel-module-hostap-0.1.2-0.fdr.6.2/
and
http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/kernel-module-ipw2100-0.45-0.fdr.1.2/
and are of course built with mach.

I'd appreciate it if some other people (particularly on smp, though I
don't even know if there are people with an ipw2100 AND dual cpu's) try
them out and let me know if it works.

I'll work on some other kernel module projects as well (I've done the
qc-usb module too, but the resulting module doesn't seem to work
correctly.  The original upstream build against my /lib/modules tree
doesn't work either, so I'm sure it's not my changes that break it :))

Here is a list of things I still need to decide or fix and would like to
have input on:
- the devel rpm containst the kernel's version and release as part of
the name, in accordance with fedora.us's policy for actual kernel
modules.  It's not possible to have a "-" in the version number, so I
can't put kernel ver/rel in that, and I don't want to stick it in the
release tag since then it's impossible to buildrequire: it properly
since on fedora.us the resulting rpm gets a 0.fdr.2 appended to the
release tag.  Is this ok ?

- the devel rpm currently stores its files in
/usr/share/kernel-module-devel-(ver-rel)
Would it be more appropriate to put stuff in
/usr/lib/kernel-module-devel-(ver-rel) instead ?

- the devel rpm is currently set with arch i386.  I've considered making
it noarch, since it contains files for more than one arch.  But I assume
it's not possible anyway to easily build for x86, ppc and ia64 on the
same machine (though the -devel rpm could still be created for all of
them since it just unpacks rpms and compares files).  Which of the two
would be preferable in this case ?

- the hostap rpm does the following:
  - when built with --target i386, it does the build for the four
arch/type combos and packages only the devel files (symbol versions +
headers), installing them in the same dir as the kernel-module-devel
rpm.
  - when built with --target i586 or i686, it does only one build for
the given 'kernel' uname -r define, and removes the devel files.
This would be an argument in favour of having the -devel packages be
i386; I don't think it's possible to build a -devel rpm for ppc, x86 and
ia64 at the same time if you have to actually build the files.

- currently, .symvers files are installed in the root of the builddir,
and include files are installed in builddir/include/modules/(basename of
module).  For the .symvers, I think this is an ok location.  For the
headers, I'm not sure yet.  Of course, this needs to be a location we
need to agree on so interdependent modules can be built correctly.
For building ipw2100, an extra include directive is given in the
Makefile.am patch that points to builddir/include/modules/hostap
Any suggestions on standardizing this or is this ok ? What would
projects like these be expected to install them to normally ?

- the module spec files could be made to work with fc2 and pre-fc2.  I
normally use a check to scan /etc/fedora-release and build a conditional
based on that.  Maybe it should check for the kernel version instead ?
If so, can that be done reliably without invoking rpm as part of the
check ? Is it worth it to try and integrate, or would it make more sense
to just do 2.4 and 2.6 spec files separately ?

- I cannot test the smp versions because my machine cannot boot the smp
kernel.  For all 2.4 kernels this worked fine.  Has it become impossible
to run smp kernels on up machines ? Does anyone know more about this ?

- Anyone know why FC2 module versioning is turned off ? AFAIK the build
setup we've come up with would take symbol versioning into account
correctly if it were turned on.

- any other suggestions/questions/objections ?

Thanks,
Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
yes i am
a long way
from home
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/





From max_list at fedorafaq.org  Sat May 22 16:15:51 2004
From: max_list at fedorafaq.org (Max K-A)
Date: Sat, 22 May 2004 09:15:51 -0700
Subject: The Fedora Hardware Project
In-Reply-To: <40AE37BA.3000509@pl.jaring.my>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
Message-ID: <1085242551.6867.19.camel@max.localdomain>

> My idea is simple.
> Just a Web Page with DB that can be short by Brand, Chipset, Disto and
> kernel version. And add or a view.

	I think that's a good idea. :-)

> P.s I don't think that I can help much there.

	OK. I hope you find somebody that can help you out. :-) I'm too busy to
work on the Fedora Hardware Project. :-)

	-Max





From arjanv at redhat.com  Sat May 22 16:19:06 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sat, 22 May 2004 18:19:06 +0200
Subject: building packages for FC2 for external kernel modules
In-Reply-To: <1085241408.2861.44.camel@otto.amantes>
References: <1085241408.2861.44.camel@otto.amantes>
Message-ID: <1085242745.14486.6.camel@laptop.fenrus.com>

On Sat, 2004-05-22 at 17:56, Thomas Vander Stichele wrote:

> - Anyone know why FC2 module versioning is turned off ? AFAIK the build
> setup we've come up with would take symbol versioning into account
> correctly if it were turned on.

in 2.6 it makes it really hard to build external modules with, in addition the thing we had symbol versioning for
(preventing wrong modules to be inserted) now gets caught by the module version magic.

-------------- 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/20040522/cf1dab7d/attachment.sig>

From stevelist at silverorange.com  Sat May 22 16:26:22 2004
From: stevelist at silverorange.com (Steven Garrity)
Date: Sat, 22 May 2004 13:26:22 -0300
Subject: The Fedora Hardware Project
In-Reply-To: <1085242551.6867.19.camel@max.localdomain>
References: <40A67456.2010703@pl.jaring.my>	<1085044931.21879.19.camel@max.localdomain>	<40AE37BA.3000509@pl.jaring.my>
	<1085242551.6867.19.camel@max.localdomain>
Message-ID: <40AF7F2E.8060406@silverorange.com>

Max K-A wrote:
>>My idea is simple.
>>Just a Web Page with DB that can be short by Brand, Chipset, Disto and
>>kernel version. And add or a view.
> 
> 	I think that's a good idea. :-)
> 
>>P.s I don't think that I can help much there.
> 
> 	OK. I hope you find somebody that can help you out. :-) I'm too busy to
> work on the Fedora Hardware Project. :-)

While this gets under way, I have setup a simple page on the Fedora Wiki 
where people can post information about FC2 on their hardware: 
http://www.fedora.us/wiki/FedoraHardwareInfo

Steven Garrity




From stan at ccs.neu.edu  Sat May 22 16:46:26 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Sat, 22 May 2004 12:46:26 -0400
Subject: Sorry...
Message-ID: <1085244385.9697.1059.camel@duergar>

Hey,

Sorry I haven't been very polite on these lists lately, and I've been
more than a little unfair to Warren Togami specifically.  And I know its
totally my fault.  I'm man enough to admit it.

But can someone point me to a place where it tells with specificity what
should be asked on what list?  Seems like even people who run the lists
are sometimes unclear on where certain topics should end up.  I realize
that not everything is appropriate for these lists, but I'd like to have
my questions answered and so I'd like to know for certain what list is
for what...

Are their charters or anything anywhere?

Best Regards,

Stan Bubrouski

PS. Sorry again Warren, I know I'm a complete tool sometimes.




From stan at ccs.neu.edu  Sat May 22 16:55:03 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Sat, 22 May 2004 12:55:03 -0400
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <20040522142521.GA24751@devserv.devel.redhat.com>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar> <40AD75D7.1070103@redhat.com>
	<1085194238.9697.1004.camel@duergar>
	<20040522142521.GA24751@devserv.devel.redhat.com>
Message-ID: <1085244903.9697.1073.camel@duergar>

On Sat, 2004-05-22 at 10:25, Alan Cox wrote:
> On Fri, May 21, 2004 at 10:50:38PM -0400, Stan Bubrouski wrote:
> > First of all I'm sick of this attitude Warren.  I wasn't asking YOU to
> > remove IPv6 from the kernel.  My question was if I remove it, am I going
> > to face problems...
> 
> gftp might break. There was a bug with gftp and ipv6 aware sites that
> Im not sure was fixed by gftp updates, by the fact with have ipv6 or
> in both.
> 

Thank you.  That would bother me ;-)

Can you give me any further details on this?  I looked at the bugzilla
post https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122268

It states gftp-2.0.14-5 is ok, but gftp-2.0.17-0-FC1 can't deal with
sites with IPv6 name servers.  Obviously going back to 2.0.14 is not
very feasible due to a number of other bugs.  I'm gonna grab some old
packages and see if I can see where this broke and what broke it
upstream.

Regards,

Stan


> Alan
> 




From hp at redhat.com  Sat May 22 18:43:52 2004
From: hp at redhat.com (Havoc Pennington)
Date: Sat, 22 May 2004 14:43:52 -0400
Subject: Prepackaged configurations
Message-ID: <1085251432.16339.53.camel@localhost.localdomain>

Hi,

Something that's missing in the OS is an "out of the box" experience
for the different ways one might use the operating system.
 
For example, if you want an X terminal server and some X terminal
clients, then you have to read a fair bit of docs and modify all the
relevant config files, which may be in a number of formats. Other use
cases that require custom setup might include router/firewall,
clustering, locked-down desktop, or whatever.

In an ideal world, someone could maintain the canonical best practice
setup for say a locked-down desktop lab, and everyone else just
clicks/types "install me a locked down desktop lab system," applies any
site-local tweaks, and that's it.

I'm calling this a canned or prepackaged configuration.

This would be useful because:

 - developers could encode the recommended best practices
   in these canned configurations
 - QA and testers could then easily install and test the 
   OS for each canned use case
 - docs authors could easily get things working for 
   each use case
 - users and admins would have a nice "out of the box" 
   experience getting things going very quickly, and 
   avoiding a lot of custom engineering that tends to 
   break on upgrade
 - allows developers to coordinate the whole network
   environment; e.g. the canned config for LDAP/Kerberos 
   server should automatically work with all the client
   installs, same for print server etc.
 - we probably need different defaults for desktop and server
   in some cases, e.g. for how hardware is handled

Some of the things that _might_ change across canned configurations:

 - the package set (the only thing we can change now, via 
   the Workstation or Server split in the comps file for example)
 - specific parts of a config file, e.g. enabling xdmcp in gdm
 - default settings in gconf (e.g. each canned config might 
   add a new config source in /etc/gconf/2/path)
 - contents of /etc/skel
 - optimum partitioning scheme
 - first boot screens, e.g. asking for site-specific info to 
   go into the configuration
 - kernel boot options

Some baseline considerations for how to approach this problem:

 - we should approach it consistently, such that there's one place 
   to browse a list of available configurations, a general pattern 
   followed for how they are implemented, and so forth

 - ideally, it's dynamic instead of only install-time, i.e. 
   you can change a machine from config A to config B post-install.
   Easier for some things than others (e.g. partitioning scheme 
   impossible to change post-install, config files perhaps easier,
   package set relatively simple)

 - ideally, third parties can provide their own canned 
   configurations maintained separately from the main OS.
   You can imagine whole open source projects that basically 
   just maintain a configuration.

 - ideally, these configurations can be in the installer in the 
   same list as Workstation vs. Server choice; it would be strange
   to choose between Workstation and Server then later choose 
   between canned configurations

 - ideally, local or site-specific tweaks can be kept separate from 
   and "override" the canned settings, so that on upgrade you 
   inherit new updates to the canned config

 - Jeremy does not want to maintain this stuff in the installer

 - selecting a given canned config has to be possible via kickstart

Some possible approaches:

 A. documentation. We just write down how to build each 
    configuration, possibly providing an example kickstart file.
    Put these documents in a common location with a standard
    naming scheme, etc.

    Downsides: doesn't provide the automation, so no "out of the box"
    experience; doesn't clearly make one developer/maintainer 
    responsible for whether the config works and what it's like.

    Upside: relatively easy

 B. kickstart files. We provide a kickstart file for each 
    configuration, probably there's a package naming convention
    like kickstart-x-terminal-client, and a convention for 
    where the kickstart file is installed. 

    Downsides: user has to install the OS, set up a kickstart server
    or make a boot disk, learn about kickstart, etc.; kickstart files
    contain incidental noise such as partitioning and so forth that 
    will usually be unrelated to the canned config

    Upside: does not affect the installer, and again relatively 
    easy

 C. kickstart profiles. Introduce something like "%profile 
    x-terminal-client" that can go in a kickstart file. 
    Could implement an XML description of each profile, 
    support something like:
$ kickstart-profile --list
vnc-terminal          Remote Desktop Terminal       VNC based thin client terminal...
x-terminal            X Terminal                    X based thing client terminal...
....
    
    This is somewhat nicer than just providing a collection of 
    kickstart files.
   
 D. config profiles usable by the installer. Same as above, but
    offer them in the installer rather than just package sets
    in the installer. 

 E. dynamic "alternatives" system for configurations. Direction 
    suggested by Owen, haven't sorted out how this would work 
    precisely, perhaps symlink-based.

 F. write a simple library for redirecting config file lookup 
    depending on a global "what this system is for" setting. 
    e.g. you might have gdm.conf.normal and gdm.conf.xterminalclient
    and gdm would use a simple library that keys off of 
    /etc/sysconfig/system-profile to locate the right config file?

 G. meta-packages. e.g. have a package x-terminal-client that depends
    on some set of other packages, provides certain config files, 
    etc.
   
    The obvious problem is that the gdm package provides 
    gdm.conf, so how does a meta-package install a different 
    gdm.conf. If every important daemon/feature supported a 
    conf.d with override files in it, that might answer the 
    question, but sadly that isn't the norm.

 H. Some sort of RPM changes. Presumably we could make RPM smart
    about this problem in some way. I don't have concrete ideas.

Obviously, this is far from fully thought-out at this point, I'm just
trying to start the thread. It looks pretty likely to me that our
solution will be a pragmatic compromise that isn't quite ideal. But
which compromise is the best one?

Havoc


 








From gauret at free.fr  Sat May 22 19:27:54 2004
From: gauret at free.fr (Aurelien Bompard)
Date: Sat, 22 May 2004 21:27:54 +0200
Subject: RFC: Fedora.us "unstable" section
Message-ID: <c8o9j6$mod$1@sea.gmane.org>

Hello,

I have a proposal for the redefinition of fedora.us' "unstable" section.
Right now, it contains "add-ons with severe known defects or that may
interfere with other software" (from FedoraChannels). It currently contains
a dozen of packages.
I think it could be used for software which have been checked for packaging
errors, which build, but which haven't been deeply tested to work properly
(at run-time).
This would solve the problem we currently have in the QA queue with the pile
of programming languages. They could be spec-checked, built, tested with
"language --version" just to make sure they don't segfault, and put in
unstable. This would adress the problem we have with packages in QA which
are used by too few people or are too complex to be correctly tested at
run-time.

But we don't want to turn the unstable section into a second "pending"
repository: there must be a way for packages to move into "testing" after
being tested. For this task, we could require the usual 2 GPG-signed votes
by people who use the packages. Since this type of vote doesn't imply
checking the package for errors, there are more chances that people do it.
It's just a "Yes, it runs properly". We could even drop the GPG requirement
if we have to.

There must be some place to put the vote. The voter could open a bug against
the new component, but I don't think that would happen. We could also add
another step between "Verified" and "Closed" but I don't know if it is
possible in bugzilla. This other step would only be used for packages in the
"unstable" section. Third option: we could use a specific keyword in
bugzilla, and leave the package in "Verified" state (or another one, like
"Reopened" for example). This would define a new queue (again). I think
that the main objective is to make it as easy as possible to vote for a
package in the "unstable" section, because by definition these packages are
used by few people.
There are probably other options, but that's all I can see right now.

What do you think of that ? 


Aur?lien
-- 
http://gauret.free.fr   ~~~~   Jabber : gauret at amessage.info
In God we Trust. All others must submit an X.509 certificate.





From john.hearns at clustervision.com  Sat May 22 21:33:46 2004
From: john.hearns at clustervision.com (John Hearns)
Date: Sat, 22 May 2004 22:33:46 +0100
Subject: Prepackaged configurations
In-Reply-To: <1085251432.16339.53.camel@localhost.localdomain>
References: <1085251432.16339.53.camel@localhost.localdomain>
Message-ID: <1085261625.26350.9.camel@vigor12>

On Sat, 2004-05-22 at 19:43, Havoc Pennington wrote:
> Hi,
> 
> Something that's missing in the OS is an "out of the box" experience
> for the different ways one might use the operating system.
>  
> In an ideal world, someone could maintain the canonical best practice
> setup for say a locked-down desktop lab, and everyone else just
> clicks/types "install me a locked down desktop lab system," applies any
> site-local tweaks, and that's it.
> 

Do things like LCFG http://www.lcfg.org/ help?
With lcfg you hold system profiles on a central server.

>From the FAQ:
"Configuration parameters ("resources") for all machines on a site are
stored in a number of "LCFG source files" on a central server. The files
describe "aspects" of the site configuration, such as "a web server", or
a "Dell Optiplex". "

"New machines can be installed automatically by creating the appropriate
source files and booting... The required package set is installed
according to the profile, and the components configure the system in
exactly the same way as a fully-installed machine."


Also look at the related Quattor project from CERN.
http://quattor.web.cern.ch/quattor/
This is being developed for the automatic installs of heterogenous
machines on a Grid.
I don't see why the PAN language developed there couldn't be used ofr
these canonical machine types.










From smoogen at lanl.gov  Sat May 22 22:01:22 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Sat, 22 May 2004 16:01:22 -0600 (MDT)
Subject: Sorry...
In-Reply-To: <1085244385.9697.1059.camel@duergar>
References: <1085244385.9697.1059.camel@duergar>
Message-ID: <Pine.LNX.4.58.0405221548100.11520@smoogen1.lanl.gov>

On Sat, 22 May 2004, Stan Bubrouski wrote:

>Hey,
>
>Sorry I haven't been very polite on these lists lately, and I've been
>more than a little unfair to Warren Togami specifically.  And I know its
>totally my fault.  I'm man enough to admit it.

Thanks for saying this.. may it be used as an example to the rest of us
when we are tools too. I probably need it at least once every 3 months.

I am not sure that there is a proper charter for what the mailing lists
say or do. A general posting to each of the lists from Red Hat or an
appointed stuckee of a FAQ and rules of use would probably be a good
thing.. even if it just starts with:

Q. What the f#$@# is going on with Fedora?
A. Hmmm.. we are still dealing with our heads being cut off. Please let 
   us run around for another 20 minutes before we fall down. After that 
   we will have a FAQ, CVS, build-system, documentation server, WIKI, IM
   server, IRC, NNTP, mailing lists, license agreement, trademark rules, 
   and oh about 2000 other things that have all been said have to be 
   done RIGHT NOW.

Q. What are each of the lists for?
A. Hmmm.. we would like the lists to be like the following:
  fedora-devel:  long term development of the Fedora project
  fedora-docs:   documenting the madness erm project.
  fedora-list:   question and answers of current Fedora releases
  fedora-legacy: question and answers about past Fedora releases
  fedora-test:   question and answers about current rawhide status.
  fedora-legal:  also known as fedora-loons. its a place where we let
                 the clove smoking, living in their parents basement,
                 idealists hang out and harang everyone for not using
                 the strictest interpretation of the GPL in everything
                 we do. [Sometimes we like to post something there to 
                 just get a rise out of them too.]

Q. Is Fedora just a front for people to beta test Red Hat Enterprise 
   without knowing it or even getting cool t-shirts?
A. Yes. But to tell you the truth, when you use Debian, Gentoo, or even 
   FreeBSD.. you are doing that in some part too. We even were able to 
   use a found bug in Hurd to help us make Red Hat Enterprise better, 
   but please dont post that to fedora-legal.. it will just work them up 
   again.

Q. Are you making fun of us?
A. Yes. But please realize that we are also a part of us, and without 
   laughing at ourselves... we would have to realize we were insane, and
   where is the fun in that?

Anyway, here is my first attempt at chronicalling the madness, erm, 
project.

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From smoogen at lanl.gov  Sat May 22 22:07:21 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Sat, 22 May 2004 16:07:21 -0600 (MDT)
Subject: Prepackaged configurations
In-Reply-To: <1085251432.16339.53.camel@localhost.localdomain>
References: <1085251432.16339.53.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0405221602320.11520@smoogen1.lanl.gov>

On Sat, 22 May 2004, Havoc Pennington wrote:

> G. meta-packages. e.g. have a package x-terminal-client that depends
>    on some set of other packages, provides certain config files, 
>    etc.
>   
>    The obvious problem is that the gdm package provides 
>    gdm.conf, so how does a meta-package install a different 
>    gdm.conf. If every important daemon/feature supported a 
>    conf.d with override files in it, that might answer the 
>    question, but sadly that isn't the norm.
>
> H. Some sort of RPM changes. Presumably we could make RPM smart
>    about this problem in some way. I don't have concrete ideas.
>
>Obviously, this is far from fully thought-out at this point, I'm just
>trying to start the thread. It looks pretty likely to me that our
>solution will be a pragmatic compromise that isn't quite ideal. But
>which compromise is the best one?
>

I will say:

Here, here! This is definately would be very useful. I think it will 
take a bit of many of the items you have listed above, and should be 
approached also in a systematic way.

FC3 -- documentation (complete by FC6)
FC4 -- breaking RPMS more into seperate
         executables
           bare-essentials, but requires some sort of config.
         documentation
         configuration
           bare-config, specific1-config, specific2-config, etc
            all provide package-config which is required by bare 
       (complete by FC7)
FC5 -- better metapackage groupings (complete by FC8)


-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From carwyn at carwyn.com  Sat May 22 22:37:45 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Sat, 22 May 2004 23:37:45 +0100
Subject: Prepackaged configurations
In-Reply-To: <1085261625.26350.9.camel@vigor12>
References: <1085251432.16339.53.camel@localhost.localdomain>
	<1085261625.26350.9.camel@vigor12>
Message-ID: <40AFD639.5010202@carwyn.com>

John Hearns wrote:

>>In an ideal world, someone could maintain the canonical best practice
>>setup for say a locked-down desktop lab, and everyone else just
>>clicks/types "install me a locked down desktop lab system," applies any
>>site-local tweaks, and that's it.

> Do things like LCFG http://www.lcfg.org/ help?

Yes, this is exatly what it does (and has been for many many years).

Our technicans only have to define things like this in the master config 
for a machine:

/* mymachine's config profile  */
 

#include <lcfg/os/redhat9.h>
#include <lcfg/hwbase/dell_optiplex_gx240.h>
#include <inf/sitedefs.h>
#include <inf/wire_c.h>
#include <inf/officedesktop.h> 


#include <inf/postgresql_rh9.h>
 

dhclient.mac 00:06:5B:34:F5:7E
 

inv.sno                 <snip>
inv.allocated           cedward1
inv.location            JCMB-<snip>
inv.manager             cedward1
 

/* End of file */


.. then shove in a CD or PXE boot. The whole point of it is that _it 
does_ just "install me a locked down desktop lab system".

The key to LCFG is that its actions work beyond initial install. Any 
changes made to the config post install are then communicated to the 
client and acted upon. For example if I remove the line:

#include <inf/postgresql_rh9.h>

Then the machine will remove all the packages associated with being a 
postgresql server. It might also stop the daemon and do some cleanup 
depending on how the configration component is written (see the docs for 
terminology).

Another example is the "dhcpclient.mac" entry above. It does more than 
associate the mac to the machine for example. Defining it in the 
_client_ profile makes the dhcp server's profile pick it up and triggers 
a rewrite of the dhcpd.conf on the dhcp server that's running on the 
"wire_c" subnet.

I'll reply to Havoc's post in more detail in a minute.

Carwyn




From noa at resare.com  Sat May 22 22:55:51 2004
From: noa at resare.com (Noa Resare)
Date: Sun, 23 May 2004 00:55:51 +0200
Subject: Self-Introduction: Noa Resare
Message-ID: <1085266551.10894.20.camel@c-1c1d72d5.01-60-6c6b701.cust.bredbandsbolaget.se>

Full legal name: Noa Daniel Johannes Resare
Country, City: Sweden, Link?ping
Profession or Student status: Currently unemployed :/

My goals in the Fedora project:
* I intend to package software that I use that is missing from
* fedora.us or fc core.
* Yes, QA is ok with me.

Historical qualifications:
My contributions to linux/redhat/fedora has been up and down depending
on my work and family situation. Thins I've done.
* Some translation work to Swedish, notably grep and parts of gpg.
* I did corefonts.sf.net
* Set up http://bugzilla.fedora.us/

pub  1024D/A1906F09 2004-02-14 Noa Resare <noa at resare.com>
  Key fingerprint = F3C4 AC90 B885 FE15 344B  4D05 220B 7662 A190 6F09

cheers/noa

Ps. A while ago i changed first name from Daniel to Noa (actually I
added Noa). When doing so I created a new gpg key. The old one, with id
0x9B8DEC2A is signed by Warrren Togami, and that one signs my new one so
I suppose I'm already in the web of trust.




From carwyn at carwyn.com  Sun May 23 00:02:14 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Sun, 23 May 2004 01:02:14 +0100
Subject: Prepackaged configurations
In-Reply-To: <1085251432.16339.53.camel@localhost.localdomain>
References: <1085251432.16339.53.camel@localhost.localdomain>
Message-ID: <40AFEA06.2050105@carwyn.com>

Havoc Pennington wrote:

In LCFG (http://www.lcfg.org/) you can do:

> Some of the things that _might_ change across canned configurations:
> 
>  - the package set (the only thing we can change now, via 
>    the Workstation or Server split in the comps file for example)
>  - specific parts of a config file, e.g. enabling xdmcp in gdm
>  - optimum partitioning scheme
>  - kernel boot options

.. control all the above in a centrally managed way ...

> 
>  - ideally, it's dynamic instead of only install-time, i.e. 
>    you can change a machine from config A to config B post-install.
>    Easier for some things than others (e.g. partitioning scheme 
>    impossible to change post-install, config files perhaps easier,
>    package set relatively simple)

.. and that, i.e. it's a dynamic reconfiguration framework.

(I don't think we've ever done dynamic partition changing though).

I was going to reply to specific parts of Havoc's mail in more detail 
but it's probably best if those that are interested read the docs at 
http://www.lcfg.org/doc/. Instead I'll give a summary here.

LCFG is the configuration management system that's been used at the 
School of Infomrmatics (http://www.inf.ed.ac.uk/) for over a decade now. 
It's based on a lot of research and theory into configuration management 
systems, but, unlike many research vehicles it's also what we use to 
configure our 800+ Linux desktops (we eat our own dog food).

It basically allows one to abstract configuration by extracting what is 
"interesting" about a particular daemon or application into a higher 
level representation. This higher level representation is a 
configuration language that is used to describe a host in a central 
database. One key aspect of this representation is that it is prototype 
based and declarative (not procedural) i.e. you take a base template and 
add successive specializations using other templates to describe a machine.

Each host is described on the central configuration server as a 
composition of templates (see my last post to this list). This 
composition is evaluated into a profile (XML in our case) that is then 
sucked over onto the client where the configuration agents (components 
in LCFG terminology) use this state description to enact the 
configuration. There is one component for each "thing" that needs to be 
dynamically configured on the client.

Install time is considered to be just a slightly special case of a 
"configuration action". To this end we have our own installation 
technology that uses the same components that are used for day to day 
dynamic configuration to do the installations (CD or PXE based).

Within our implementation this concept has been extended to not only 
describe a machine but also, to a certain extent, relationships between 
machines. Specifically there is the notion of a publisher and subscriber 
model for maps of resources. The best examples of this are in the 
network configuration components. For example, while in most networks 
the definition of what holes should be punched in the firewall are 
defined in the configuration for the firewall host. In LCFG the 
definition is in the profile of the host that needs the hole opened. The 
  combination of composition and component (agent) actions then does the 
rest.

At the moment LCFG is used mainly within our department and other 
departments within the University of Edinburgh. Various grid research 
installations and configuration management based research projects are 
also using it.

It's not something that can be dropped into an existing RH/Fedora 
network. Our implementation uses RH/Fedora as a base (rpms mainly), but 
then takes on a life of its own. The learning curve for people wanting 
to implement a network based on it is tough (although I'm not sure why).

What is worth looking at though are the lessons learned from 10+ years 
of using a system that already does much of what has been asked for. I'm 
sure the main authors would be very interested to talk to people on 
their thoughts relating to this.

Follow the following resources for more info:

http://www.lcfg.org/doc, specifically this paper: 
http://www.lcfg.org/doc/ukuug2002.pdf



Carwyn

--
Carwyn Edwards
Computing Officer
School of Informatics
University of Edinburgh




From stan at ccs.neu.edu  Sun May 23 00:39:58 2004
From: stan at ccs.neu.edu (Stan Bubrouski)
Date: Sat, 22 May 2004 20:39:58 -0400
Subject: Sorry...
In-Reply-To: <Pine.LNX.4.58.0405221548100.11520@smoogen1.lanl.gov>
References: <1085244385.9697.1059.camel@duergar>
	<Pine.LNX.4.58.0405221548100.11520@smoogen1.lanl.gov>
Message-ID: <1085272798.1393.5.camel@duergar>

On Sat, 2004-05-22 at 18:01, Stephen Smoogen wrote:
> On Sat, 22 May 2004, Stan Bubrouski wrote:
> 
> >Hey,
> >
> >Sorry I haven't been very polite on these lists lately, and I've been
> >more than a little unfair to Warren Togami specifically.  And I know its
> >totally my fault.  I'm man enough to admit it.
> 
> Thanks for saying this.. may it be used as an example to the rest of us
> when we are tools too. I probably need it at least once every 3 months.
>
> I am not sure that there is a proper charter for what the mailing lists
> say or do. A general posting to each of the lists from Red Hat or an
> appointed stuckee of a FAQ and rules of use would probably be a good
> thing.. even if it just starts with:

Totally.  As it stands its more than just difficult to figure what
should be posted where.  You could probably post the same question twice
to the list and illicit entirely different responses entailing things
like "This is the solution..." where other times you will get "Don't be
a jerk and post questions like this to the this list" it doesn't evoke a
spirit of community.  When people don't where to ask a question, then
there is a problem that deserves clarification.

<SNIP>
> 
> Anyway, here is my first attempt at chronicalling the madness, erm, 
> project.
> 

Madness.  That i understand.

-sb

> -- 
> Stephen John Smoogen		smoogen at lanl.gov
> Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
> Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
> -- You should consider any operational computer to be a security problem --
> 




From smoogen at lanl.gov  Sun May 23 00:53:01 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Sat, 22 May 2004 18:53:01 -0600 (MDT)
Subject: Prepackaged configurations
In-Reply-To: <40AFEA06.2050105@carwyn.com>
References: <1085251432.16339.53.camel@localhost.localdomain>
	<40AFEA06.2050105@carwyn.com>
Message-ID: <Pine.LNX.4.58.0405221825100.11520@smoogen1.lanl.gov>

On Sun, 23 May 2004, Carwyn Edwards wrote:

>Havoc Pennington wrote:
>
>In LCFG (http://www.lcfg.org/) you can do:
>
>> Some of the things that _might_ change across canned configurations:
>> 
>>  - the package set (the only thing we can change now, via 
>>    the Workstation or Server split in the comps file for example)
>>  - specific parts of a config file, e.g. enabling xdmcp in gdm
>>  - optimum partitioning scheme
>>  - kernel boot options
>

We do many of the same things with CFengine. The one thing I have found 
is that the syntax of CFengine really needs a good washing. It is 
somewhat inconsistant as the authors have added features and not fixed 
the parser any. 

Before I got blindsided by work, I was going to try manipulating CFegine 
a bit to try and work out those warts. Getting it more integrated into a 
packaging system and version control system were also on the list. I 
also see as you do with LCFG that it couldnt be dropped into 
Fedora/RH/Debian, but would need to be adapted or re-written to meet all 
the needs.


-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From carwyn at carwyn.com  Sun May 23 01:18:03 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Sun, 23 May 2004 02:18:03 +0100
Subject: Prepackaged configurations
In-Reply-To: <Pine.LNX.4.58.0405221825100.11520@smoogen1.lanl.gov>
References: <1085251432.16339.53.camel@localhost.localdomain>
	<40AFEA06.2050105@carwyn.com>
	<Pine.LNX.4.58.0405221825100.11520@smoogen1.lanl.gov>
Message-ID: <40AFFBCB.7030301@carwyn.com>

Stephen Smoogen wrote:

> We do many of the same things with CFengine.

CFengine is one of the few other "good" solutions. We're optimistic 
about the Ximian/Novell/Suse merger producing something nice in this 
area too.

> The one thing I have found is that the syntax of CFengine really needs a good washing.

Same with LCFG :-( We're in the thinktank stage prior to a rewrite.

Carwyn




From smoogen at lanl.gov  Sun May 23 01:56:54 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Sat, 22 May 2004 19:56:54 -0600 (MDT)
Subject: Prepackaged configurations
In-Reply-To: <40AFFBCB.7030301@carwyn.com>
References: <1085251432.16339.53.camel@localhost.localdomain>
	<40AFEA06.2050105@carwyn.com>
	<Pine.LNX.4.58.0405221825100.11520@smoogen1.lanl.gov>
	<40AFFBCB.7030301@carwyn.com>
Message-ID: <Pine.LNX.4.58.0405221946450.11936@smoogen1.lanl.gov>

On Sun, 23 May 2004, Carwyn Edwards wrote:

>Stephen Smoogen wrote:
>
>> We do many of the same things with CFengine.
>
>CFengine is one of the few other "good" solutions. We're optimistic 
>about the Ximian/Novell/Suse merger producing something nice in this 
>area too.
>

It would be useful to get an idea of the other ones are. I started to do
some research on it a couple of months ago, but work has been constant
for a bit. [I am just hoping that the Ximian+Novell+SuSE merger doesnt
end up a bad case of heart-burn.]


>> The one thing I have found is that the syntax of CFengine really
>>needs a good washing.
>
>Same with LCFG :-( We're in the thinktank stage prior to a rewrite.
>

My thinking has been something a bit more pythonish to try and use 
something that people might be familiar with. [Plus it gets in the craw 
of the fellow here who says to write it in Guile/LISP syntax so that it 
would be so obvious to use.] 

There are parts of cfengine that I really like as most of my interests
are in dependable secure services and configuration management. The idea
of working towards a computer immunology sort of appeals to that.  
However, my years at company <name withheld> also make me want
something that can be implemented and commercially acceptable.

I do know of someone who is trying to do a 'clean-up' of the CFengine
syntax at the moment to try and make the parser smarter. 

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --




From robert at it4texas.com  Sun May 23 01:58:01 2004
From: robert at it4texas.com (Robert Trembath)
Date: Sat, 22 May 2004 20:58:01 -0500
Subject: How do I configure the kernel for the nvidia drivers
Message-ID: <40B00529.9080508@it4texas.com>

How do I reconfigure my kernel in FC2 final so I can use the nvidia 
drivers. I know it has to do with 4KStacks but how do I go about 
changing it to work.
Thanks in advance,
Robert




From nathanr at nathanr.net  Sun May 23 02:06:21 2004
From: nathanr at nathanr.net (Nathan Robertson)
Date: Sun, 23 May 2004 12:06:21 +1000
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <1085154729.6414.44.camel@draco.sault.org>
References: <1085154729.6414.44.camel@draco.sault.org>
Message-ID: <C8EE3636-AC5D-11D8-A0E1-000D935221F2@nathanr.net>

On 22/05/2004, at 1:52 AM, Jason Tackaberry wrote:

> Since CIPE's removal from Fedora Core, there is a noticeable void that
> still needs to be filled.  I'd like to raise the issue here and spark a
> discussion in the hope that we can find consensus on one or more pieces
> of VPN software to include in Fedora Core 3.

I know this will leave a bad taste in peoples mouths, but from a 
practicality point of view the Microsoft VPN (MPPE and friends, iirc) 
is implemented by a kernel patch in ppp CVS (providing the ppp_mppe 
module). I've got that patch in my kernel at the moment and it works 
well. The great thing is that it works with everything - Linux, Mac OS 
X and Windows, and works over a masquerade for the client. I think 
these two points are important (particularly useful for RHEL customers, 
I would have thought) - range of client compatibility, and the client 
working over a masquerade.

The patch has been around for a fair while (I've had it patched in for 
about 6 months now, god knows how long it's been around before that). I 
haven't bothered looking into why Linus hasn't merged it, since crypto 
is now in the kernel. Maybe patent issues in the US?

Nathan.




From walrus at bellsouth.net  Sun May 23 02:10:37 2004
From: walrus at bellsouth.net (William M. Quarles)
Date: Sat, 22 May 2004 22:10:37 -0400
Subject: How do I configure the kernel for the nvidia drivers
In-Reply-To: <40B00529.9080508@it4texas.com>
References: <40B00529.9080508@it4texas.com>
Message-ID: <40B0081D.6060701@bellsouth.net>

Robert Trembath wrote:
> How do I reconfigure my kernel in FC2 final so I can use the nvidia 
> drivers. I know it has to do with 4KStacks but how do I go about 
> changing it to work.
> Thanks in advance,
> Robert
> 
> 
You're writing to the wrong mailing list.  I suggest 
<fedora-list at redhat.com>

And I would help, but I don't know the answer.  Try the other list.




From carwyn at carwyn.com  Sun May 23 02:51:45 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Sun, 23 May 2004 03:51:45 +0100
Subject: Prepackaged configurations
In-Reply-To: <Pine.LNX.4.58.0405221946450.11936@smoogen1.lanl.gov>
References: <1085251432.16339.53.camel@localhost.localdomain>
	<40AFEA06.2050105@carwyn.com>
	<Pine.LNX.4.58.0405221825100.11520@smoogen1.lanl.gov>
	<40AFFBCB.7030301@carwyn.com>
	<Pine.LNX.4.58.0405221946450.11936@smoogen1.lanl.gov>
Message-ID: <40B011C1.5080502@carwyn.com>

Stephen Smoogen wrote:

> It would be useful to get an idea of the other ones are.

http://www.epcc.ed.ac.uk/gridweaver/WP1/report1.pdf

.. there are a fair few of them in there. It's a very high level pass 
that was gathered to set the context for the Gridweaver Project we did 
with HP and EPCC (See: http://www.gridweaver.org/).

> My thinking has been something a bit more pythonish

Ditto, something like Cheetah (http://www.cheetahtemplate.org/) caught 
my eye as being useful for writing the config files at the client end.

Carwyn




From skvidal at phy.duke.edu  Sun May 23 03:05:48 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 22 May 2004 23:05:48 -0400
Subject: Prepackaged configurations
In-Reply-To: <Pine.LNX.4.58.0405221825100.11520@smoogen1.lanl.gov>
References: <1085251432.16339.53.camel@localhost.localdomain>
	<40AFEA06.2050105@carwyn.com>
	<Pine.LNX.4.58.0405221825100.11520@smoogen1.lanl.gov>
Message-ID: <1085281548.24997.29.camel@binkley>


> We do many of the same things with CFengine. The one thing I have found 
> is that the syntax of CFengine really needs a good washing. It is 
> somewhat inconsistant as the authors have added features and not fixed 
> the parser any. 

Something we started working on at duke but kinda got sidetracked as
other work tookover was an xml format for describing some of things w/i
a machine configuration and running certain processes.

The goal was then you could easily design an interface to take those xml
descriptions and manufacture a configuration.

xml is nice for making a configuration files that programs can
consistently edit and re-read.

There is also a short format for something I'd like to include in the
next version of yum - it's just a way to build queues of processes to
run as a single transaction.
ex:
 install foo
 remove bar
 update baz
 groupinstall foogroup

so it can compile all of those into one transaction and run them.

David Christian worked on the format and commands and I want to make it
(and a bunch of other things) in there.

so a thought to a format that easily configured and managed by a program
and also human editable is a good idea.

no need to create a new file format like cfengine did.

-sv





From mattdm at mattdm.org  Sun May 23 03:21:27 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 22 May 2004 23:21:27 -0400
Subject: Prepackaged configurations
In-Reply-To: <1085251432.16339.53.camel@localhost.localdomain>
References: <1085251432.16339.53.camel@localhost.localdomain>
Message-ID: <20040523032127.GA15166@jadzia.bu.edu>

On Sat, May 22, 2004 at 02:43:52PM -0400, Havoc Pennington wrote:
[selectively quoted throughout]
> I'm calling this a canned or prepackaged configuration.

I'd really like to see this.


>  - the package set (the only thing we can change now, via 
>    the Workstation or Server split in the comps file for example)

Actually, more than that can be changed in the install classes -- default
partitioning scheme, for example.


>  - default settings in gconf (e.g. each canned config might 
>    add a new config source in /etc/gconf/2/path)

This could be simply which packages get installed, right?

>  - contents of /etc/skel

And this already _is_ that. But unfortunately it can lead to confusion, if
some of the relevant packages are installed before some user accounts are
created and after others....


>  - kernel boot options

And this'd be easy to do in anaconda too. I think probably pretty easily
through just the installclasses files....


>  - ideally, it's dynamic instead of only install-time, i.e. 
>    you can change a machine from config A to config B post-install.
>    Easier for some things than others (e.g. partitioning scheme 
>    impossible to change post-install, config files perhaps easier,
>    package set relatively simple)

Apt for RPM has a nice script in contrib that can add or remove package
groups (as definied in the comps file). So if the config types could be
definied as sets of packages, that'd be really handy.


>  - ideally, third parties can provide their own canned 
>    configurations maintained separately from the main OS.
>    You can imagine whole open source projects that basically 
>    just maintain a configuration.

I'd like that. :)

> 
>  - ideally, these configurations can be in the installer in the 
>    same list as Workstation vs. Server choice; it would be strange
>    to choose between Workstation and Server then later choose 
>    between canned configurations

Definitely. If it's not there (and I think it should be), the
workstation/server/personal desktop choice should also be removed.

>  - ideally, local or site-specific tweaks can be kept separate from 
>    and "override" the canned settings, so that on upgrade you 
>    inherit new updates to the canned config

This can already be done with install classes already --
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=66634>. It could maybe
be made even simpler, and perhaps the comps file extended to be able to
include other files (and maybe have overrides).

In fact, maybe the comps file should be entirely subsumed into the install
classes -- they're already very tightly linked anyway.

>  - Jeremy does not want to maintain this stuff in the installer

Yes, that's fair -- the installer is insane enough already. 

But luckily, the installer has most of what's needed already done. With some
basic improvements to comps/installclasses handling, all of the long-term
maintenance could go elsewhere.


>  - selecting a given canned config has to be possible via kickstart

Definitely. Leveraging the existing install classes would work nicely for
that, too.



>  B. kickstart files. We provide a kickstart file for each 
>     configuration, probably there's a package naming convention
>     like kickstart-x-terminal-client, and a convention for 
>     where the kickstart file is installed. 
> 
>     Downsides: user has to install the OS, set up a kickstart server
>     or make a boot disk, learn about kickstart, etc.; kickstart files
>     contain incidental noise such as partitioning and so forth that 
>     will usually be unrelated to the canned config
> 
>     Upside: does not affect the installer, and again relatively 
>     easy

These sample kickstart files could be on the install disk by default, and
syslinux entries created for them....


>  D. config profiles usable by the installer. Same as above, but
>     offer them in the installer rather than just package sets
>     in the installer. 

I think this is The Way. There's already a lot more than package sets that
installclasses can do. You can even hook up a post-install script.


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




From jhogan at redhat.com  Sun May 23 03:40:19 2004
From: jhogan at redhat.com (Jeremy Hogan)
Date: Sat, 22 May 2004 23:40:19 -0400
Subject: Sorry...
In-Reply-To: <1085272798.1393.5.camel@duergar>
References: <1085244385.9697.1059.camel@duergar>
	<Pine.LNX.4.58.0405221548100.11520@smoogen1.lanl.gov>
	<1085272798.1393.5.camel@duergar>
Message-ID: <1085283619.4060.2.camel@localhost.localdomain>

On Sat, 2004-05-22 at 20:39, Stan Bubrouski wrote:

> When people don't where to ask a question, then
> there is a problem that deserves clarification.

I can't say you won't get the same hit and miss help, but here's the
list of lists and what they're supposed to focus on:

http://fedora.redhat.com/participate/communicate/

      * fedora-announce-list - Announcements of Fedora Core changes and
        events. To stay aware of Fedora Core news, subscribe to this
        list.
      * fedora-list - For users of Fedora Core releases. If you want
        help with a problem installing or using Fedora Core, this is the
        list for you.
      * fedora-test-list - For testers of Fedora Core test releases. If
        you would like to discuss experiences using Fedora Core TEST
        releases, this is the list for you.
      * fedora-devel-list - For developers, developers, developers. If
        you are interested in helping create Fedora Core releases, this
        is the list for you.
      * fedora-docs-list - For participants of the docs project
      * fedora-desktop-list - For discussions about desktop issues such
        as user interfaces, artwork, and usability
      * fedora-config-list - For discussions about the development of
        configuration tools
      * fedora-legacy-announce - For announcements about the Fedora
        Legacy Project
      * fedora-legacy-list - For discussions about the Fedora Legacy
        Project
      * fedora-selinux-list - For discussions about the Fedora SELinux
        Project
      * fedora-de-list - For discussions about Fedora in the German
        language
      * fedora-ja-list - For discussions about Fedora in the Japanese
        language
      * fedora-i18n-list - For discussions about the
        internationalization of Fedora Core
      * fedora-trans-list - For discussions about translating the
        software and documentation associated with the Fedora Project 
              * German: fedora-trans-de
              * French: fedora-trans-fr
              * Spanish: fedora-trans-es
              * Italian: fedora-trans-it
              * Brazilian Portuguese: fedora-trans-pt_br
              * Japanese: fedora-trans-ja
              * Korean: fedora-trans-ko
              * Simplified Chinese: fedora-trans-zh_cn
              * Traditional Chinese: fedora-trans-zh_tw




From jkeating at j2solutions.net  Sun May 23 04:10:10 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 22 May 2004 21:10:10 -0700
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <C8EE3636-AC5D-11D8-A0E1-000D935221F2@nathanr.net>
References: <1085154729.6414.44.camel@draco.sault.org>
	<C8EE3636-AC5D-11D8-A0E1-000D935221F2@nathanr.net>
Message-ID: <200405222110.11008.jkeating@j2solutions.net>

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

On Saturday 22 May 2004 19:06, Nathan Robertson wrote:
> I know this will leave a bad taste in peoples mouths, but from a
> practicality point of view the Microsoft VPN (MPPE and friends, iirc)
> is implemented by a kernel patch in ppp CVS (providing the ppp_mppe
> module). I've got that patch in my kernel at the moment and it works
> well. The great thing is that it works with everything - Linux, Mac
> OS X and Windows, and works over a masquerade for the client. I think
> these two points are important (particularly useful for RHEL
> customers, I would have thought) - range of client compatibility, and
> the client working over a masquerade.
>
> The patch has been around for a fair while (I've had it patched in
> for about 6 months now, god knows how long it's been around before
> that). I haven't bothered looking into why Linus hasn't merged it,
> since crypto is now in the kernel. Maybe patent issues in the US?

I do believe the biggest thing is that the module taints your kernel.  
Non GPL compliant I do believe.

- -- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key          
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAsCQi4v2HLvE71NURAvt5AKCV95mNps8qJbMdiF3jWilv//81uACgoQag
uDKtgNWas3kAW4a5N7VkbbE=
=kXZF
-----END PGP SIGNATURE-----




From pekkas at netcore.fi  Sun May 23 05:43:18 2004
From: pekkas at netcore.fi (Pekka Savola)
Date: Sun, 23 May 2004 08:43:18 +0300 (EEST)
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085185525.28401.1.camel@imladris.demon.co.uk>
Message-ID: <Pine.LNX.4.44.0405230840560.3647-100000@netcore.fi>

On Sat, 22 May 2004, David Woodhouse wrote:
> > If you are wanting to know how to compile a kernel on your
> > system for yourself..  there are lists that are more in-line for that
> > question. If you are wanting to complain about how the internet would 
> > have been better if we had just stayed with IPv1.. fedora-loons is 
> > probably the list for you.
> 
> Can we make FC3 do 6to4 by default on all interfaces with non-RFC1918
> IPv4 addresses? :)

If we're going to do this, it would be useful to have a look at for
things which may happen, or things which should be changed first:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-misbehavior-against-aaaa-01.txt

-- 
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 mandreiana at rdslink.ro  Sun May 23 08:37:17 2004
From: mandreiana at rdslink.ro (Marius Andreiana)
Date: Sun, 23 May 2004 11:37:17 +0300
Subject: Prepackaged configurations
In-Reply-To: <1085251432.16339.53.camel@localhost.localdomain>
References: <1085251432.16339.53.camel@localhost.localdomain>
Message-ID: <1085301436.2968.37.camel@marte.biciclete.ro>

On Sat, 2004-05-22 at 21:43, Havoc Pennington wrote:
> Some possible approaches:
> 
>  A. documentation. We just write down how to build each 
>     configuration, possibly providing an example kickstart file.
>     Put these documents in a common location with a standard
>     naming scheme, etc.
a steb-by-step howto and including config files for current release will
make it quite easy.

this would be good to have because
- easy to implement now and have it in FC3 
- needed anyway for all other approaches? One needs to know the
difference from default setup to a prepackaged configuration, and it can
be seen from the step-by-step docs.

>     Downsides: doesn't provide the automation, so no "out of the box"
>     experience; 
perfect "out of the box" would be hard I think, as user might need some
custom configuration changes. With step-by-step, he can learn about the
system and adjust settings along the way.

> doesn't clearly make one developer/maintainer 
>     responsible for whether the config works and what it's like.
why not? One person will maintain each prepackage config docs, as one
maintains a rpm now.

>     Upside: relatively easy
yes, and doable now. If we aim for an  out-of-the-box working config,
it'll take several releases to have it working properly. Let's keep it
simple, this is an excelent step forward!

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




From nathanr at nathanr.net  Sun May 23 08:53:23 2004
From: nathanr at nathanr.net (Nathan Robertson)
Date: Sun, 23 May 2004 18:53:23 +1000
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <200405222110.11008.jkeating@j2solutions.net>
References: <1085154729.6414.44.camel@draco.sault.org>
	<C8EE3636-AC5D-11D8-A0E1-000D935221F2@nathanr.net>
	<200405222110.11008.jkeating@j2solutions.net>
Message-ID: <A5C63680-AC96-11D8-BCDA-000D935221F2@nathanr.net>


On 23/05/2004, at 2:10 PM, Jesse Keating wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 22 May 2004 19:06, Nathan Robertson wrote:
>> I know this will leave a bad taste in peoples mouths, but from a
>> practicality point of view the Microsoft VPN (MPPE and friends, iirc)
>> is implemented by a kernel patch in ppp CVS (providing the ppp_mppe
>> module). [...]
>
> I do believe the biggest thing is that the module taints your kernel.
> Non GPL compliant I do believe.

cobra:~# lsmod
Module                  Size  Used by    Tainted: P
[...]
ppp_mppe               12320   0  (unused)
[...]

Damn. It's tainted, yes. Never noticed. I'm looking at the patch and 
don't see any nasty license issues - just a lack of a explicit GPL 
compatible flag set. It consists of:

- a patch to the current ppp (derived work, hence GPL).
- sha1.[ch] - in comments at the top -- "100% Public Domain"
- ppp_mppe_compress.c - "Permission to use, copy, modify, and 
distribute this software and its documentation is hereby granted, 
provided that the above copyright notice appears in all copies."

So in my view it's actually a mix between GPL, public domain and a BSD 
style license. Looks GPL compatible to me. Just needs to be noted as 
explicitly so, so it doesn't taint the kernel. Am I right?

Having said that, I haven't tested it with 2.6 kernel, and the headers 
say 2.2 and 2.4 (presumably because it hasn't been tested).

Nathan.




From pnasrat at redhat.com  Sun May 23 09:22:13 2004
From: pnasrat at redhat.com (Paul Nasrat)
Date: Sun, 23 May 2004 05:22:13 -0400
Subject: Prepackaged configurations
In-Reply-To: <1085251432.16339.53.camel@localhost.localdomain>
References: <1085251432.16339.53.camel@localhost.localdomain>
Message-ID: <20040523092212.GA14053@devserv.devel.redhat.com>

On Sat, May 22, 2004 at 02:43:52PM -0400, Havoc Pennington wrote:
> Hi,
> 
> Something that's missing in the OS is an "out of the box" experience
> for the different ways one might use the operating system.

Certainly one of the things I'm looking at atm is config preservation across
upgrades, I think that a lot there is a lot of correlation between config
management and "profiles".

An intresting approach is that of config intent preservation - enabling
switching between alternatives simply, and smooth upgrade across incompatible
conf file syntax change, but that's not going to happen overnight

>  H. Some sort of RPM changes. Presumably we could make RPM smart about this
>  problem in some way. I don't have concrete ideas.

One potential is to use the fact that %config already provides a virtual
provides in rpm. Speaking with Jeff the is some underlying work related to
ts.check to enable a split out for the config packages, then a seperate
foo-config package could be maintained and also potential for local repository
config splits.

Paul




From nathanr at nathanr.net  Sun May 23 09:43:33 2004
From: nathanr at nathanr.net (Nathan Robertson)
Date: Sun, 23 May 2004 19:43:33 +1000
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <A5C63680-AC96-11D8-BCDA-000D935221F2@nathanr.net>
References: <1085154729.6414.44.camel@draco.sault.org>
	<C8EE3636-AC5D-11D8-A0E1-000D935221F2@nathanr.net>
	<200405222110.11008.jkeating@j2solutions.net>
	<A5C63680-AC96-11D8-BCDA-000D935221F2@nathanr.net>
Message-ID: <A7C0C5C2-AC9D-11D8-A3E6-000D935221F2@nathanr.net>

On 23/05/2004, at 6:53 PM, Nathan Robertson wrote:

>
> On 23/05/2004, at 2:10 PM, Jesse Keating wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Saturday 22 May 2004 19:06, Nathan Robertson wrote:
>>> I know this will leave a bad taste in peoples mouths, but from a
>>> practicality point of view the Microsoft VPN (MPPE and friends, iirc)
>>> is implemented by a kernel patch in ppp CVS (providing the ppp_mppe
>>> module). [...]
>>
>> I do believe the biggest thing is that the module taints your kernel.
>> Non GPL compliant I do believe.
>
> cobra:~# lsmod
> Module                  Size  Used by    Tainted: P
> [...]
> ppp_mppe               12320   0  (unused)
> [...]
>
> Damn. It's tainted, yes. Never noticed. I'm looking at the patch and 
> don't see any nasty license issues - just a lack of a explicit GPL 
> compatible flag set. It consists of:
>
> - a patch to the current ppp (derived work, hence GPL).
> - sha1.[ch] - in comments at the top -- "100% Public Domain"
> - ppp_mppe_compress.c - "Permission to use, copy, modify, and 
> distribute this software and its documentation is hereby granted, 
> provided that the above copyright notice appears in all copies."
>
> So in my view it's actually a mix between GPL, public domain and a BSD 
> style license. Looks GPL compatible to me. Just needs to be noted as 
> explicitly so, so it doesn't taint the kernel. Am I right?
>
> Having said that, I haven't tested it with 2.6 kernel, and the headers 
> say 2.2 and 2.4 (presumably because it hasn't been tested).

PS. Source is in a cvs-web as well -- 
http://cvs.samba.org/cgi-bin/cvsweb/ppp/linux/mppe

Nathan.




From dlesage at iprimus.com.au  Sun May 23 09:55:18 2004
From: dlesage at iprimus.com.au (David Le Sage)
Date: Sun, 23 May 2004 19:55:18 +1000
Subject: Request for Packages in Fedora Core 3
Message-ID: <40B07506.8060407@iprimus.com.au>

Hello All,

I am really enjoying my use fo Fedora Core 2.  To make the next release 
even better, I humbly request the following packages be considered for 
inclusion:

Scribus - The first modern DTP package for Linux.  This is an 
essential 	for myself and many others moving from commercial 
operating 		systems.  More than any other package, I would love to see 
this included.  It will help you win converts...

KIllustrator or Sketch - Vector graphics would be very good.  I 
understand one of these products has as much functionality as GIMP but I 
am not sure which.  Open Office's drawings do not suffice.

Ardour or Audacity for audio manipulation.

Please keep up the excellent work.


Regards,

David




From alan at redhat.com  Sun May 23 10:50:25 2004
From: alan at redhat.com (Alan Cox)
Date: Sun, 23 May 2004 06:50:25 -0400
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <C8EE3636-AC5D-11D8-A0E1-000D935221F2@nathanr.net>
References: <1085154729.6414.44.camel@draco.sault.org>
	<C8EE3636-AC5D-11D8-A0E1-000D935221F2@nathanr.net>
Message-ID: <20040523105025.GA25746@devserv.devel.redhat.com>

On Sun, May 23, 2004 at 12:06:21PM +1000, Nathan Robertson wrote:
> The patch has been around for a fair while (I've had it patched in for 
> about 6 months now, god knows how long it's been around before that). I 
> haven't bothered looking into why Linus hasn't merged it, since crypto 

It may just be stuff that never got in due to the crypto thing originally.
Linus is however not omniescent so you could send him a copy and ask.
Probably Paul Mackerras is the right man to ask in fact as its ppp stuff




From buildsys at redhat.com  Sun May 23 12:07:33 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 23 May 2004 08:07:33 -0400
Subject: rawhide report: 20040523 changes
Message-ID: <200405231207.i4NC7XT03484@porkchop.devel.redhat.com>

 

 
Updated Packages:

kernel-2.6.6-1.377
------------------

mdadm-1.5.0-9
-------------
* Sat May 22 2004 Doug Ledford <dledford at redhat.com> - 1.5.0-9

- Fix Makefile and build method to satisfy bz #123769
- Add mdmpd man page, update mdmpd version to 0.3 - bz #117160
- Make sure mdadm --monitor closes all md device files so that md devices
  can be stopped while mdadm is still running - bz #119532

rpmdb-fedora-2-0.20040523
-------------------------




From rdieter at math.unl.edu  Sun May 23 14:17:56 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 23 May 2004 09:17:56 -0500 (CDT)
Subject: On disttags
In-Reply-To: <20040522155703.21139e2a.fedora@wir-sind-cool.org>
References: <orhdul2qt7.fsf@free.redhat.lsd.ic.unicamp.br>
	<20040513192800.GS29888@neu.nirvana>
	<20040514065752.GA17038@neu.nirvana>
	<1084524138.3413.53.camel@gibraltar.stuttgart.redhat.com>
	<20040514090709.GA21879@neu.nirvana>
	<1084534665.3413.251.camel@gibraltar.stuttgart.redhat.com>
	<1084770974.3817.2141.camel@mccallum.corsepiu.local>
	<20040517182611.GJ26400@neu.nirvana>
	<or8yfqnepc.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405180810220.1248@sting.unl.edu>
	<ork6z9lfzk.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181400080.30778@math.unl.edu>
	<orr7thjz9r.fsf@free.redhat.lsd.ic.unicamp.br>
	<Pine.LNX.4.58.0405181519370.18107@sting.unl.edu>
	<oru0ycmlfn.fsf@free.redhat.lsd.ic.unicamp.br>
	<40AB8D26.2090408@math.unl.edu>
	<604aa7910405191001415bd496@mail.gmail.com>
	<40AB9813.4040005@math.unl.edu>
	<20040519195142.6fe0da2d.fedora@wir-sind-cool.org>
	<Pine.LNX.4.58.0405220724450.6217@math.unl.edu>
	<20040522155703.21139e2a.fedora@wir-sind-cool.org>
Message-ID: <Pine.LNX.4.58.0405230914460.24770@math.unl.edu>

On Sat, 22 May 2004, Michael Schwendt wrote:

> On Sat, 22 May 2004 07:25:13 -0500 (CDT), Rex Dieter wrote:
> 
> > On Wed, 19 May 2004, Michael Schwendt wrote:
> > 
> > > On Wed, 19 May 2004 12:23:31 -0500, Rex Dieter wrote:
> > > 
> > > > Speaking of useless large package updates, why does redhat bundle 
> > > > koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice 
> > > > and k3b rpms, so that any updates to koffice and k3b will also "force 
> > > > users to eat useless large updates"?
> > > 
> 
> [some part of the quote is missing here]
> 
> > > For extra repositories this is also an issue, but a less important one
> > > currently as one can obsolete i18n packages in an update any time.
> > 
> > But difficult to the other direction.
> 
> That's the same problem as referred to in the part that's missing
> in above quote. [Unless package tools are tuned to "know about" i18n
> packages and pull them in when necessary.]

I personally could care less about lacking features in the 
installer/package-manager.  I care more about removing the "choice" and 
forcing the installation of these i18n files/pkgs upon all users, whether 
they want/need it or not.

-- Rex




From ville.skytta at iki.fi  Sun May 23 15:16:11 2004
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Sun, 23 May 2004 18:16:11 +0300
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <1083498673.5261.495.camel@bobcat.mine.nu>
References: <200405021037.22538.dennis@ausil.us>
	<200405021518.09927.dennis@ausil.us>
	<20040502052940.GA1032@nostromo.devel.redhat.com>
	<200405021538.43398.dennis@ausil.us>
	<1083498673.5261.495.camel@bobcat.mine.nu>
Message-ID: <1085325371.3919.477.camel@bobcat.mine.nu>

On Sun, 2004-05-02 at 14:51, Ville Skytt? wrote:

> As long as gnupg2 (when it's time) will have "Obsoletes: newpg", I
> believe we can find a clean solution by packaging libgcrypt1 and
> changing gpgme and gpgme03 to require %{_bindir}/gpgsm instead of newpg.

A quick followup: there are now libgcrypt1, gpgme and gpgme03 packages
in fedora.us which have been "fixed" according to the above.




From Axel.Thimm at ATrpms.net  Sun May 23 15:51:42 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sun, 23 May 2004 17:51:42 +0200
Subject: gnupg newpg gpgme gpgme03 cryptplug isuses
In-Reply-To: <1085325371.3919.477.camel@bobcat.mine.nu>
References: <200405021037.22538.dennis@ausil.us>
	<200405021518.09927.dennis@ausil.us>
	<20040502052940.GA1032@nostromo.devel.redhat.com>
	<200405021538.43398.dennis@ausil.us>
	<1083498673.5261.495.camel@bobcat.mine.nu>
	<1085325371.3919.477.camel@bobcat.mine.nu>
Message-ID: <20040523155142.GG29809@neu.nirvana>

On Sun, May 23, 2004 at 06:16:11PM +0300, Ville Skytt? wrote:
> On Sun, 2004-05-02 at 14:51, Ville Skytt? wrote:
> 
> > As long as gnupg2 (when it's time) will have "Obsoletes: newpg", I
> > believe we can find a clean solution by packaging libgcrypt1 and
> > changing gpgme and gpgme03 to require %{_bindir}/gpgsm instead of newpg.
> 
> A quick followup: there are now libgcrypt1, gpgme and gpgme03 packages
> in fedora.us which have been "fixed" according to the above.

newpg has been obsoleted in favour of gnupg2 by its own authors, and
since it is a security crucial package I would make the jump to gnupg2
now, otherwise you may have security maintenance problems with newpg.

Have a look at ATrpms.net, if you like.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040523/9c6d5012/attachment.sig>

From ivg2 at cornell.edu  Sun May 23 15:08:57 2004
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Sun, 23 May 2004 11:08:57 -0400
Subject: Release Notes
Message-ID: <40B0BE89.7060002@cornell.edu>

Where can I find the release notes for Fedora Core 2?
The ones at
http://fedora.redhat.com/docs/release-notes/
seem to be for FC1.

Will there be release notes for FC2?





From noa at resare.com  Sun May 23 17:18:39 2004
From: noa at resare.com (Noa Resare)
Date: Sun, 23 May 2004 19:18:39 +0200
Subject: Release Notes
In-Reply-To: <40B0BE89.7060002@cornell.edu>
References: <40B0BE89.7060002@cornell.edu>
Message-ID: <1085332719.10894.24.camel@c-1c1d72d5.01-60-6c6b701.cust.bredbandsbolaget.se>

s?n 2004-05-23 klockan 17.08 skrev Ivan Gyurdiev:
> Where can I find the release notes for Fedora Core 2?
> The ones at
> http://fedora.redhat.com/docs/release-notes/
> seem to be for FC1.

You can find the release notes on one of the fedora mirrors, for example
http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/RELEASE-NOTES-en.html

The webpage you mention should obviously be updated.

/noa

ps. in the future such questions should be directed to the fedora users
list, fedora-list at redhat.com




From b.j.smith at ieee.org  Sun May 23 18:37:13 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Sun, 23 May 2004 14:37:13 -0400
Subject: GRUB, fdisk/installers need to support the LDM disk label
Message-ID: <1085337433.18635.99.camel@bitman.oviedo.smithconcepts.com>

[ Before you trash this e-mail, please read it.
If you don't want to read it now, at least save it for later. ]

First off, this post was preceeded by two posts to Bugzilla 115980.
Specifically, my comments #62 and #63, which resulted in some direct
correspondence.

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115980#c62  
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115980#c63  

TERMINOLOGY REFERENCE

- DOS Disk Label (pri/ext/log, "Basic" disk, "MBR" disk [label])
The legacy disk label (partition table) format of primary, extended and
logical.  Microsoft refers to this format in NT 5.x (2000, XP, 2003) as
a "Basic" disk or a "MBR" disk [label].  I will use "DOS" disk label.

-  LDM Disk Label ("Dynamic" disk, "LDM" disk [label])
The Microsoft Logical Disk Manager (LDM) in NT 5.x (2000, XP, 2003)
which looks like a single type 42h primary partition in a DOS disk
label.  Microsoft also refers to it as a "Dynamic" disk or a "LDM"
disk [label].  It stores geometry, NTFS-SID references and other
goodies, much like any OS logical volume management (LVM) does.

MY RECOMMENDATIONS

At this time, I recommend the following efforts be put forth.  I am
more than willing to bring myself up to speed and try to help out
(I am a meager C coder with a lot of experience in BIOS/disk geometry
issues).

1.  GRUB be modified to support booting volumes in LDM disk labels

2.  Util-linux's fdisk and Anaconda be modified to support creating
"simple" volumes in a LDM disk label, as well as the LDM disk label
itself

MY RATIONALE

A.  The LDM disk label solves boot-time geometry issues with NT
(as well as countless other issues).

B.  The LDM format is fairly well documented now
( http://linux-ntfs.sourceforge.net/ldm/index.html )

C.  Linux kernels support loading/accessing volumes in LDM disk labels
already, including LVM/LVM2 and MD.

ADDITIONAL RECOMMENDATIONS

3.  Installer prompts/info
a.  On a new (blank) disk, the installer should let the user choose
between using the legacy DOS or newer LDM disk label, and tell the user
why.
b.  On an existing, legacy DOS disk label, if the installer detects NT
5.x, it should recommend the user boot into NT 5.x+ and convert to a LDM
disk label (dynamic disk) before installing Linux.

ADDITIONAL RATIONALE

D.  Microsoft is pushing LDM adoption hard, largely because it solves
such geometry issues with itself (e.g., booting multiple NT 5.x+
versions).

E.  The LDM disk label is recommended when you read NTFS filesystems
from an OS installation that did not create the NTFS volume.  I.e., you
should _never_ write to a NTFS volume from even another NT installation
because of the SID mapping issues in a NTFS volume -- _unless_ a LDM
disk label is used (which can store these mappings outside the
registry).  Yes, NTFS write support is an issue with NT itself, if the
NT installation did not create the NTFS volume being written to (because
of the registry/SID issues).

MY COMMENTARY

God knows this was much easier back in the DOS/Win (95, 98, ME) days
where DOS/Win wouldn't even boot if the BIOS and disk label geometry
didn't match.  But now we're onto NT en-masse.

In a nutshell, yes, Microsoft should have created a mature NT kernel
that can read the DOS disk label geometry and compare/ignore the BIOS.  
I have advocated this for a long time (being an original NT 3.1 beta
tester myself).  But they have not.

Additionally, Microsoft never considered the issues with writing to NTFS
filesystems that were not created by the NT installation writing to it. 
You can (and I have) _toasted_ NTFS filesystems when writing to them
from a NT installation

_Both_ of these issues are _solved_ by using the LDM disk label.  Now
I'm not advocating we have Linux be able to do all sorts of LDM
manipulation.  But it would be nice if, again:

1. GRUB was modified to boot volumes inside of LDM disk
2. Linux fdisk/installers could at least create "Simple" volumes inside
of LDM disk labels (as well as a new LDM disk label itself)

Now #1 could be "put off" for a bit, since LILO (being dumb and a simple
"sector reference") _can_ boot volumes inside of LDM disk labels (at
least Linux, but NT 5.x too?).  But ultimately extensible GRUB should be
able to do this, correct?

POTENTIAL GOTCHAS

Microsoft does not support the LDM disk label on the following storage
devices:
- Notebooks (WTF? They are the biggest geometry nightmares!)
- Removable drives (CD-RW, DVD-RAM/RW/+RW, etc...)
- External drives (IEEE1394, USB)
- External solid state storage (flash cards, sticks, etc...)

The latter three items are not much of a big deal.  But notebooks, those
are a "sticking point."  Why did Microsoft not support LDM on them? 
Probably because of the "suspend partition" that some use?  I'm not
sure.


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From gareth at fedoraforum.org  Sun May 23 18:38:38 2004
From: gareth at fedoraforum.org (Gareth Russell)
Date: Sun, 23 May 2004 19:38:38 +0100
Subject: Request for Packages in Fedora Core 3
In-Reply-To: <20040523160010.CC8327379D@hormel.redhat.com>
References: <20040523160010.CC8327379D@hormel.redhat.com>
Message-ID: <1085337517.2551.3.camel@localhost.localdomain>

> Scribus - The first modern DTP package for Linux.  This is an 
> essential for myself and many others moving from commercial 
> operating systems.  More than any other package, I would love to see 
> this included.  It will help you win converts...

I agree that it should be included but probably not as a default
application due to its Qt status. It just doesn't integrate with the
Gnome environment which is default in Fedora i.e. no Drag and drop
functionality as in KDE. 

> KIllustrator or Sketch - Vector graphics would be very good.  I 
> understand one of these products has as much functionality as GIMP but I 
> am not sure which.  Open Office's drawings do not suffice.

I think you're referring to Sketch. Again Sketch would be a better
choice over the KDE app.

> Ardour or Audacity for audio manipulation.

Agreed - some good music/audio apps would add more depth to the packages
available and appeal to a certain niche.

Gareth
FedoraForum.org Administrator




From rdieter at math.unl.edu  Sun May 23 18:49:31 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 23 May 2004 13:49:31 -0500
Subject: Request for Packages in Fedora Core 3
In-Reply-To: <1085337517.2551.3.camel@localhost.localdomain>
References: <20040523160010.CC8327379D@hormel.redhat.com>
	<1085337517.2551.3.camel@localhost.localdomain>
Message-ID: <40B0F23B.8080006@math.unl.edu>

Gareth Russell wrote:

>>Scribus - The first modern DTP package for Linux.  This is an 
...
> I agree that it should be included but probably not as a default
> application due to its Qt status. It just doesn't integrate with the
> Gnome environment which is default in Fedora i.e. no Drag and drop
> functionality as in KDE. 
...
> I think you're referring to Sketch. Again Sketch would be a better
> choice over the KDE app.

IMO, simply whether an applications is based on Qt/KDE or not should 
absolutely *not* be a factor in determining default-app status.  This 
decision should be based upon factors such as the application's 
stability, robustness, features, functionality, maturity, etc...

-- Rex




From makgab at freemail.hu  Sun May 23 19:43:09 2004
From: makgab at freemail.hu (MG)
Date: Sun, 23 May 2004 21:43:09 +0200
Subject: Fedora minimal install...
Message-ID: <40B0FECD.1000506@freemail.hu>


Hi!

When will be avaiable in Fedora the absolute minimal install option?
It could be the 300-400MB with the absolute necessery packages?
For exmaple for a single firewall system.

Bye!
Gabor






From florin at andrei.myip.org  Sun May 23 19:56:34 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: 23 May 2004 12:56:34 -0700
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <1085154729.6414.44.camel@draco.sault.org>
References: <1085154729.6414.44.camel@draco.sault.org>
Message-ID: <1085342194.2580.2.camel@rivendell.home.local>

On Fri, 2004-05-21 at 08:52, Jason Tackaberry wrote:
>                     
> I think the other main contender for VPN software in Fedora Core would
> be Openswan.  OpenVPN is portable, comfortable (being in userspace),
> flexible, and easy, but Openswan implements IPsec which is (mostly)
> standardized across vendors, and that's certainly a strong selling
> point, in spite of its complexity.

Openswan is good to keep around, just in case you need to talk to IPSec
devices. But it's a pain in the butt; it's NAT-unfriendly, free and good
Windows clients are lacking, interoperability is problematic, etc.

I said, to hell with it, i installed OpenVPN and It Simply Works. It is
easy to setup (both server and clients), it does not care about NAT, the
Windows client is not a problem (it's the same software as the server),
interoperability is a breeze...

-- 
Florin Andrei

http://florin.myip.org/




From jspaleta at gmail.com  Sun May 23 20:02:57 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 23 May 2004 16:02:57 -0400
Subject: Fedora minimal install...
In-Reply-To: <40B0FECD.1000506@freemail.hu>
References: <40B0FECD.1000506@freemail.hu>
Message-ID: <604aa79104052313021598a531@mail.gmail.com>

On Sun, 23 May 2004 21:43:09 +0200, MG <makgab at freemail.hu> wrote:
> When will be avaiable in Fedora the absolute minimal install option?

When? As soon as people in the community who care make a real effort
to rework the comps.xml file.  This subject comes up again and again
on the mailinglists. I suggest you take a look back into the
mailinglist archives, all the way back to pre-fedora core 1
discussions.  Let me give you my personal summary where things stand:
1) everyone sort of agrees this is not a bad idea
2) red hat employees have said this is a low priority for them, but if
people in the community want to work together to clean up the comps
groupings and produce a smaller minimal install  feel free to start
working on it.
3)pre-fc1 there was some discussion on the mailinglist between
community members about what to do about it...and then they wandered
off never to be heard from again.


-jef"minimal install...an itch waiting for someone to feel compelled
to scratch it"spaleta




From dax at gurulabs.com  Sun May 23 21:39:49 2004
From: dax at gurulabs.com (Dax Kelson)
Date: Sun, 23 May 2004 15:39:49 -0600
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085108015.9697.46.camel@duergar>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar>
Message-ID: <1085348389.12538.4.camel@mentor.gurulabs.com>

On Thu, 2004-05-20 at 22:53 -0400, Stan Bubrouski wrote:
> On Thu, 2004-05-20 at 22:28, Warren Togami wrote:
> > Stan Bubrouski wrote:
> > > Quick query, as the title suggests I'm wondering if its safe to remove
> > > ip6 from kernel in FC2 + devel?
> > > 
> > 
> > This is not a topic suitable for fedora-devel-list, because you appear 
> > to be doing something unsupported for yourself and would not otherwise 
> 
> So I'd be alone in having no use for ipv6?  doubtful.
> 
> > contribute any improvement value to development of the Fedora Project. 
> 
> So you feel this question is of no value?  Lot's of people have no use
> for ipv6 at this point in time.  People rebuild kernels all the time and
> ask questions here.  How is this any different?

Ummm, because it's compiled as a module so you are free to not load it
without a kernel recompile.

To prevent the autoloading, run the command:

echo "NETWORKING_IPV6=no" >> /etc/sysconfig/network

Have a good day.

Dax Kelson




From devscott at charter.net  Mon May 24 00:19:41 2004
From: devscott at charter.net (Scott Sloan)
Date: Sun, 23 May 2004 19:19:41 -0500
Subject: The Fedora Hardware Project
In-Reply-To: <40AE37BA.3000509@pl.jaring.my>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
Message-ID: <1085357981.3935.11.camel@Curran415>

> >
> > Hey. I never had a chance to actually *work* on the Fedora Hardware
> > Project. If somebody wants to take it over, using that specification,
> > that's fine with me. :-)
> >

I am willing to give it a shot.  So we would need :

1.) a simple website, much like http://www.fedoratracker.org 

2.) A db 

3.) Some input and search code?

4.) Anything else?

Db would include
 
Hardware Category:
Manufacturer:
Chipset:
Distro Version:
Kernel Version:

I was thinking something like what the fine people over at mandrake have
in place (http://www.mandrakelinux.com/en/hardware.php3)


-- 
Scott Sloan <devscott at charter.net>




From scribusdocs at atlantictechsolutions.com  Mon May 24 01:20:15 2004
From: scribusdocs at atlantictechsolutions.com (Peter Linnell)
Date: Sun, 23 May 2004 21:20:15 -0400
Subject: Request for Packages in Fedora Core 3
In-Reply-To: <20040523160010.E91E473AA7@hormel.redhat.com>
References: <20040523160010.E91E473AA7@hormel.redhat.com>
Message-ID: <1085361614.31489.505.camel@localhost.localdomain>


> Message: 1
> Date: Sun, 23 May 2004 19:55:18 +1000
> From: David Le Sage <dlesage at iprimus.com.au>
> Subject: Request for Packages in Fedora Core 3
> To: fedora-devel-list at redhat.com
> Message-ID: <40B07506.8060407 at iprimus.com.au>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> 
> Hello All,
> 
> I am really enjoying my use fo Fedora Core 2.  To make the next release 
> even better, I humbly request the following packages be considered for 
> inclusion:
> 
> Scribus - The first modern DTP package for Linux.  This is an 
> essential 	for myself and many others moving from commercial 
> operating 		systems.  More than any other package, I would love to see 
> this included.  It will help you win converts...
> 
> KIllustrator or Sketch - Vector graphics would be very good.  I 
> understand one of these products has as much functionality as GIMP but I 
> am not sure which.  Open Office's drawings do not suffice.
> 
> Ardour or Audacity for audio manipulation.
> 
> Please keep up the excellent work.
> 
> 
> Regards,
> 
> David

Thanks for the kind words about Scribus. We are working diligently
towards a stable 1.2 release in the next few months. This is a question
I have long pondered having used RH since 7.0. "When would Scribus be
worthy of inclusion?"

Disclaimer: I have been part of Scribus since 0.37

Comments/Observations:

1) AFAIK - the best place to request this is:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107630 which is a
existing request to add Scribus in Fedora/RH.

2) Three of five Scribus devels run RH9 and/or Fedora. 

3) Scribus has been in Fedora.us and works very well with the stock
distro. We have had no issues with RH/Fedora users - provided they have
not messed with mixing third party stuff or home brewed installs. 

4) For Vector Graphics - I would vote for Inkscape or Skencil. Inkscape
is rapidly developing and has excellent SVG output. By the time FC-3 is
out it should be more feature complete and better import/export
capabilities. Inkscape has a very good team and is _very_ user friendly
for an advanced vector application. The only issue adding it to Core
would be the need for gtkmm. Skencil is mature and the next version is
based on GTK, not Tk. I do think a real drawing tool is needed for the
desktop. 

5) Suse has made a big fuss about Scribus:
http://www.suse.com/us/private/products/suse_linux/i386/graphics.html

6. Scribus needs no other packages from Fedora Core except littlecms.
That can be made optional, though not recommended.

7. It has consistently been voted one of the most popular programs on
kde-apps.org 

I think the best argument is Scribus fills a couple of huge niches on a
Linux Desktop: Desktop Publishing for both beginners _and_ experts. It
also can create PDF forms like Acrobat. 

By any objective standard, Scribus produces superb PDF, as tested by
several professional pre-press tools. It also can create PDF forms like
the full Acrobat and has other PDF features which no other application
is even remotely capable of on Linux. 

By the time, FC-3 is out, there should be a stable Scribus 1.2 released,
feature complete with new documentation, many sample files and
templates. 

As a long time Redhat user, yeah, I can honestly say, without
hesitation, its ready.

I would be most curious to have feedback from Redhat devels.

Cheers,
Peter




From dlesage at iprimus.com.au  Sun May 23 22:59:50 2004
From: dlesage at iprimus.com.au (dlesage at iprimus.com.au)
Date: Mon, 24 May 2004 08:59:50 +1000
Subject: Request for Packages in Fedora Core 3
In-Reply-To: <40B0F23B.8080006@math.unl.edu>
Message-ID: <40A1110B000076C9@cpms02.int.iprimus.net.au>

Gents,

Thanks for your feedback and thoughts.  I believe Scribus should definitely
be included, though maybe not by default
as it does not have the look and feel of a GTK-based environment.  

However, please bear in mind many designers and people using DTP are, in
general, not as technical.  They will be inclined to accept simple default
installations.  At least this will expose them to the breadth of open source
programs.  As far as I am aware, no GNOME DTP package is on the horizon yet.
 

By including it in the default, it will help overcome the perception that
Linux does not have many applications.

Cheers,

David
TASMANIA





>-- Original Message --
>Date: Sun, 23 May 2004 13:49:31 -0500
>From: Rex Dieter <rdieter at math.unl.edu>
>To: Development discussions related to Fedora Core <fedora-devel-list at redhat.com>
>Subject: Re: Request for Packages in Fedora Core 3
>Reply-To: Development discussions related to Fedora Core <fedora-devel-list at redhat.com>
>
>
>Gareth Russell wrote:
>
>>>Scribus - The first modern DTP package for Linux.  This is an 
>...
>> I agree that it should be included but probably not as a default
>> application due to its Qt status. It just doesn't integrate with the
>> Gnome environment which is default in Fedora i.e. no Drag and drop
>> functionality as in KDE. 
>...
>> I think you're referring to Sketch. Again Sketch would be a better
>> choice over the KDE app.
>
>IMO, simply whether an applications is based on Qt/KDE or not should 
>absolutely *not* be a factor in determining default-app status.  This 
>decision should be based upon factors such as the application's 
>stability, robustness, features, functionality, maturity, etc...
>
>-- Rex
>
>
>-- 
>fedora-devel-list mailing list
>fedora-devel-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-devel-list




From steve at silug.org  Mon May 24 03:09:17 2004
From: steve at silug.org (Steven Pritchard)
Date: Sun, 23 May 2004 22:09:17 -0500
Subject: Request for Packages in Fedora Core 3
In-Reply-To: <1085361614.31489.505.camel@localhost.localdomain>
References: <20040523160010.E91E473AA7@hormel.redhat.com>
	<1085361614.31489.505.camel@localhost.localdomain>
Message-ID: <20040524030917.GA22741@osiris.silug.org>

On Sun, May 23, 2004 at 09:20:15PM -0400, Peter Linnell wrote:
> "When would Scribus be worthy of inclusion?"

Personally, I think the major "problem" with Scribus is that it is a
Qt app, not a KDE app, so it doesn't exactly integrate with any of the
desktops available in FC.  As an occasional user, I think it would be
nice if Scribus at least had the option of pulling in the KDE libs to
get the consistent dialog boxes and such.

Although, again, I don't think it makes a bit of sense to have an app
like Scribus in Core.  It's definitely Extras material in my mind.

Of course, at this point I'm thinking OpenOffice, Gimp, and various
other things are looking like nice targets for Extras.  4 CDs for
Core?  :-)

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)398-7360               Mobile: (618)567-7320




From otaylor at redhat.com  Mon May 24 03:15:09 2004
From: otaylor at redhat.com (Owen Taylor)
Date: Sun, 23 May 2004 23:15:09 -0400
Subject: Request for Packages in Fedora Core 3
In-Reply-To: <40B0F23B.8080006@math.unl.edu>
References: <20040523160010.CC8327379D@hormel.redhat.com>
	<1085337517.2551.3.camel@localhost.localdomain>
	<40B0F23B.8080006@math.unl.edu>
Message-ID: <1085368508.4611.14.camel@localhost.localdomain>

On Sun, 2004-05-23 at 14:49, Rex Dieter wrote:
> Gareth Russell wrote:
> 
> >>Scribus - The first modern DTP package for Linux.  This is an 
> ...
> > I agree that it should be included but probably not as a default
> > application due to its Qt status. It just doesn't integrate with the
> > Gnome environment which is default in Fedora i.e. no Drag and drop
> > functionality as in KDE. 
> ...
> > I think you're referring to Sketch. Again Sketch would be a better
> > choice over the KDE app.
> 
> IMO, simply whether an applications is based on Qt/KDE or not should 
> absolutely *not* be a factor in determining default-app status.  This 
> decision should be based upon factors such as the application's 
> stability, robustness, features, functionality, maturity, etc...

One way of thinking about this is that it is a heck of a lot easier to
fix a few issues with DND between a Qt app and the GNOME desktop than to
write a new desktop publishing app from scratch...

Regards,
						Owen

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

From scribusdocs at atlantictechsolutions.com  Mon May 24 03:53:06 2004
From: scribusdocs at atlantictechsolutions.com (Peter Linnell)
Date: Sun, 23 May 2004 23:53:06 -0400
Subject: Request for Packages in Fedora Core 3
In-Reply-To: <20040524030917.GA22741@osiris.silug.org>
References: <20040523160010.E91E473AA7@hormel.redhat.com>
	<1085361614.31489.505.camel@localhost.localdomain>
	<20040524030917.GA22741@osiris.silug.org>
Message-ID: <1085370784.31489.615.camel@localhost.localdomain>

On Sun, 2004-05-23 at 23:09, Steven Pritchard wrote:
> On Sun, May 23, 2004 at 09:20:15PM -0400, Peter Linnell wrote:
> > "When would Scribus be worthy of inclusion?"
> 
> Personally, I think the major "problem" with Scribus is that it is a
> Qt app, not a KDE app, so it doesn't exactly integrate with any of the
> desktops available in FC.  As an occasional user, I think it would be
> nice if Scribus at least had the option of pulling in the KDE libs to
> get the consistent dialog boxes and such.
> 
<snip>

The reason why Scribus is not a purely KDE app is the desire to retain 
cross-platform compatibility. Scribus is available for fink, I am
testing it with Cygwin and a native Win32 port is underway. We could not
do this as a pure KDE application. 

We are planning on adding a compile time option to add KDE support, but
not likely until after 1.2 is released. We are not quite in a feature
freeze, but close.

Peter




From tdiehl at rogueind.com  Mon May 24 03:51:20 2004
From: tdiehl at rogueind.com (Tom Diehl)
Date: Sun, 23 May 2004 23:51:20 -0400 (EDT)
Subject: Request for Packages in Fedora Core 3
In-Reply-To: <1085361614.31489.505.camel@localhost.localdomain>
References: <20040523160010.E91E473AA7@hormel.redhat.com>
	<1085361614.31489.505.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.58.0405232341340.457@tigger.rogueind.com>

On Sun, 23 May 2004, Peter Linnell wrote:

> 
> > Message: 1
> > Date: Sun, 23 May 2004 19:55:18 +1000
> > From: David Le Sage <dlesage at iprimus.com.au>
> > Subject: Request for Packages in Fedora Core 3
> > To: fedora-devel-list at redhat.com
> > Message-ID: <40B07506.8060407 at iprimus.com.au>
> > Content-Type: text/plain; charset=us-ascii; format=flowed
> > 
> > Hello All,
> > 
> > I am really enjoying my use fo Fedora Core 2.  To make the next release 
> > even better, I humbly request the following packages be considered for 
> > inclusion:
> > 
> > Scribus - The first modern DTP package for Linux.  This is an 
> > essential 	for myself and many others moving from commercial 
> > operating 		systems.  More than any other package, I would love to see 
> > this included.  It will help you win converts...
> > 
> > KIllustrator or Sketch - Vector graphics would be very good.  I 
> > understand one of these products has as much functionality as GIMP but I 
> > am not sure which.  Open Office's drawings do not suffice.
> > 
> > Ardour or Audacity for audio manipulation.
> > 
> > Please keep up the excellent work.
> > 
> > 
> > Regards,
> > 
> > David
> 
> Thanks for the kind words about Scribus. We are working diligently
> towards a stable 1.2 release in the next few months. This is a question
> I have long pondered having used RH since 7.0. "When would Scribus be
> worthy of inclusion?"
> 
> Disclaimer: I have been part of Scribus since 0.37
> 
> Comments/Observations:
> 
> 1) AFAIK - the best place to request this is:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107630 which is a
> existing request to add Scribus in Fedora/RH.

Just a question from a disinterested 3rd party, If you think Scribus would be
useful for the majority of the users of the distroi, why don't you package it
up for inclusion into fedora.us. That is supposed to be the future
extras/alternatives anyway. If it proves useful then it might make it into the
main distro. OTOH if it is truely useful and maintained in fedora.us why bother.
That is what fedora.us and utilmately fedora extras/alternatives is supposed be.

So to me the real question is if you think it is ready for inclusion in the main
distro why not prove it?

<disclaimer> 
I do not even know nor do I care what Scribus is. My point is instead of trying
to continue to bloat the distro why not make use of the tools already available?
If it is already included in fedora.us then I truely do not understand the point
of this whole thread. If you think it is important then maintain it.
</disclaimer>

Tom




From b.j.smith at ieee.org  Mon May 24 05:44:19 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Mon, 24 May 2004 01:44:19 -0400
Subject: Request for Packages in Fedora Core 3 -- "Pure" Qt "Killer Apps"
Message-ID: <1085377459.18635.525.camel@bitman.oviedo.smithconcepts.com>

Lurker butting in here ...

Steven Pritchard wrote:  
> Personally, I think the major "problem" with Scribus is that it is a
> Qt app, not a KDE app, so it doesn't exactly integrate with any of the
> desktops available in FC.

Gareth Russell wrote:  
> I agree that it should be included but probably not as a default
> application due to its Qt status. It just doesn't integrate with the
> Gnome environment which is default in Fedora i.e. no Drag and drop
> functionality as in KDE. 

Peter Linnell wrote:  
> The reason why Scribus is not a purely KDE app is the desire to retain
> cross-platform compatibility. Scribus is available for fink, I am
> testing it with Cygwin and a native Win32 port is underway. We could
> not do this as a pure KDE application.

Peter, I 100% agree with the decision to go "Pure" Qt.

I consider two "Killer Apps" with _no_ Microsoft (although there are 3rd
party equivalents for Windows) equal to Linux to exist:  

1.  Typeset:  LyX ( http://www.lyx.org )

2.  DTP:  Scribus

LyX made the transition to a widget-independent codebase a couple of
years ago (it was XForms-based prior).  The result was not only a
preference for Qt, but an Aqua-native version for MacOS X (
http://www.18james.com/lyx_on_aqua.html )!  No X11 required (yes!).
Now there are still some licensing issues with the Windows version,
being that Qt/Win32 is not GPL.  But it's still an option that has
_no_ dependencies (other than TeTeX for the language back-end), because
it uses "Pure" Qt.

Using "Pure" Qt, Scribus also has the same option.  It can produce both
native Qt/UNIX and Qt/Mac versions that are fully GPL, as well as a
non-GPL Windows version using Qt/Win32 (non-GPL).

Now regarding DnD and GNOME integration, I can understand some
concerns.  But I have to believe there is nothing stopping Troll Tech
and other Qt developers from adding the small amount of code to support
DnD and other GNOME integration, at least for Qt/UNIX?  In fact, is
there such an effort underway or at least being suggested?

Just my thoughts.  I don't see any reason to "KDE'ize" Lyx-Qt or Scribus
at all.  There are many advantages to producing "Pure" Qt apps.

-- Bryan J. Smith, "Lurker" and anti-WP, pro-typeset/DTP advocate**

P.S.  Steve -- I'll respond to your further comment about "Extras" in
another post (i.e., I want to start another thread).

**BIAS EXPLAINED:  

I have _never_ been into "Word Processors" (WP) in general.  I consider
the WP to be a pre-GUI approach to documentation.

Pre-GUI, Pre-PC was the age of typeset.
Post-GUI is the age of Desktop Publishing (DTP).

In addition to the fact that DTP was invented on the Mac, even the
first, acclaimed documentation program on Windows was Ami Pro -- also a
DTP.  Although Ami Pro was somewhat simplistic, it was still more
powerful than MS Publisher today.

But, unfortunately, because of the proliferation of MS Word thanx to
Microsoft OEM bundling and rebates in the mid-'90s, most people have
never used either typeset or DTP.  If you're lucky, you might meet
someone who has used MS Publisher.  But because MS Publisher is an
elementary DTP, they dismiss it as "not powerful like MS Word."

MS Word attempts to be both a typeset and a DTP, and it is a bastard
that fails miserably at both.  That's because it lacks a good,
underlying documentation language.  Adobe FrameMaker, on the other hand,
does a fairly good job at both, because it does have an underlying
documentation language (even if not well documented).

There is no further proof in the capabilities of something like Adobe
FrameMaker v. MS Word than in Microsoft's own _preference_ for
FrameMaker for MS Office documentation.  Oh the irony!  [ I regualrly
use that argument, often in a losing fashion, when I am "forced" to
write 200+ page technical manuals at companies in MS Word -- Grrrrr! ]


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From b.j.smith at ieee.org  Mon May 24 05:45:13 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Mon, 24 May 2004 01:45:13 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
Message-ID: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>

[ This is a tangent based on this post:  
http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00800.html 
from the original thread that started with this post:  
http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00782.html
]

Steven Pritchard wrote:  
> Although, again, I don't think it makes a bit of sense to have an
> app like Scribus in Core.  It's definitely Extras material in my mind.
> Of course, at this point I'm thinking OpenOffice, Gimp, and various
> other things are looking like nice targets for Extras.  4 CDs for
> Core?  :-)

Steven brings up a larger issue.  With Fedora going to the "distributed"
model, at what point do we start to try (if at all?) to "reduce" the
size Fedore "Core" (FC)?

I mean, is there a reason we need to maintain a 3+ CD set for FC, just
as to match the "legacy" design of old Red Hat Linux (RHL)?

I personally would like to see "Core" reduced to a _single_ binary CD.

Maybe call it Fedora "miniCore" (FmC)?**
Or maybe Fedora Quark (FQ)?   I kinda like that better.

But that is a larger issue for the steering committee.

BTW, I hope I'm not the first one to suggest this?
>From Steve's post, I assume not.

-- Bryan J. Smith, "Lurker"

**NOTE:  This is just a suggestion.  I'm not one to name things.

In fact, I was first going to suggest Fedora "microCore" instead of
Fedora "miniCore" but the common use of "u" as the character for "Mu"
for "micro" produces a rather "intersting" acronym -- i.e., "FuC".
;-ppp

-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From dcmwai at pl.jaring.my  Mon May 24 08:23:17 2004
From: dcmwai at pl.jaring.my (Chan Min Wai)
Date: Mon, 24 May 2004 16:23:17 +0800
Subject: The Fedora Hardware Project
In-Reply-To: <1085357981.3935.11.camel@Curran415>
References: <40A67456.2010703@pl.jaring.my>	<1085044931.21879.19.camel@max.localdomain>	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
Message-ID: <40B1B0F5.4050504@pl.jaring.my>

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

Scott Sloan ??:
 > I am willing to give it a shot.  So we would need :
>
> 1.) a simple website, much like http://www.fedoratracker.org

Something like that... (As Simple as possible)

> 2.) A db
> 3.) Some input and search code?
> 4.) Anything else?
> Db would include
>
> Hardware Category:
> Manufacturer:
> Chipset:
> Distro Version:
> Kernel Version:
>
> I was thinking something like what the fine people over at mandrake have
> in place (http://www.mandrakelinux.com/en/hardware.php3)

I've a few more that have the similay idea, they are:

http://hardware.teamunix.de/ (Much simple, but seem to be hard to search)
http://www.linuxhardware.net/ (Can simply search but can't browse)

However Both of them didn't provided a Simple Easily Read Interface
after the search/browse like Redhat/Mandrake Hardware DB

Though?

Thank You
Chan Min Wai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAsbD0V0p9slMZLW4RAm0hAJsEZCxpWvgHciYmNeX4H8UB8CUPfwCfc7n0
zRnFKqKh7+jhduDRrCLR1ko=
=O9tI
-----END PGP SIGNATURE-----




From twaugh at redhat.com  Mon May 24 09:37:00 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Mon, 24 May 2004 10:37:00 +0100
Subject: python dependency for packages
In-Reply-To: <1085116726.3328.12.camel@bree.local.net>
References: <mailman.1085075523.14564.cvs-commits-list@redhat.com>
	<40AD6746.40409@redhat.com>
	<1085116726.3328.12.camel@bree.local.net>
Message-ID: <20040524093700.GY22616@redhat.com>

On Fri, May 21, 2004 at 01:18:47AM -0400, Jeremy Katz wrote:

> I guess you could do Requires: python-abi = $(python -c "import sys;
> print sys.ver[:3]), but that seems a little fragile as well.

This is exactly what alchemist and system-config-printer do.

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

From buildsys at redhat.com  Mon May 24 10:47:10 2004
From: buildsys at redhat.com (Build System)
Date: Mon, 24 May 2004 06:47:10 -0400
Subject: rawhide report: 20040524 changes
Message-ID: <200405241047.i4OAlAv30210@porkchop.devel.redhat.com>

 

 
Updated Packages:

Maelstrom-3.0.6-4
-----------------
* Sun May 23 2004 Florian La Roche <Florian.LaRoche at redhat.de>

- make some files again owned by root

SDL-1.2.7-4
-----------
* Mon May 24 2004 Thomas Woerner <twoerner at redhat.com> 1.2.7-4

- added requires for alsa-lib-devel (#123374)

* Wed Mar 31 2004 Harald Hoyer <harald at redhat.com> - 1.2.7-3

- fixed gcc34 compilation issues

* Wed Mar 10 2004 Thomas Woerner <twoerner at redhat.com> 1.2.7-2.1

- added buildrequires for alsa-lib-devel
- now using automake 1.5


dmalloc-5.3.0-1
---------------
* Sun May 23 2004 Florian La Roche <Florian.LaRoche at redhat.de>

- 5.3.0

kdeartwork-3.2.2-2
------------------
* Mon May 24 2004 Than Ngo <than at redhat.com> 3.2.2-2

- fix file conflict with other kde packages

kernel-utils-2.4-9.1.133
------------------------
* Tue May 11 2004 Arjan van de Ven <arjanv at redhat.com>

- remove dmidecode; the 2.6 kernel exports the info in sysfs
- include cpuspeed on all architectures

logwatch-5.1-4
--------------
* Mon May 24 2004 Joe Orton <jorton at redhat.com> 5.1-4

- stop logging access_log entries with 2xx response codes

rpmdb-fedora-2-0.20040524
-------------------------




From dhollis at davehollis.com  Mon May 24 11:28:41 2004
From: dhollis at davehollis.com (David T Hollis)
Date: Mon, 24 May 2004 07:28:41 -0400
Subject: Fedora minimal install...
In-Reply-To: <40B0FECD.1000506@freemail.hu>
References: <40B0FECD.1000506@freemail.hu>
Message-ID: <1085398121.3599.9.camel@dhollis-lnx.kpmg.com>

On Sun, 2004-05-23 at 21:43 +0200, MG wrote:
> Hi!
> 
> When will be avaiable in Fedora the absolute minimal install option?
> It could be the 300-400MB with the absolute necessery packages?
> For exmaple for a single firewall system.
> 
> Bye!
> Gabor
> 
I've managed some minimal installs of Fedora by using some of the tips
that have appeared on the list in the past.  What I do is to boot into
rescue mode from the CD.  I use fdisk to create my partitions, format,
etc then mount my filesystems under /mnt/sysimage directory.  I then do
an 'rpm --initdb --root /mnt/sysimage' which creates the rpmdb
under /mnt/sysimage/var/lib/rpm.  I then do an 'rpm -ivh
--root /mnt/sysimage kernel-xxxxx.rpm' or other known-needed package and
keep adding the requirements until all are satisfied.  Once glibc, rpm,
bash and their myriad of dependinces are installed, you can
'chroot /mnt/sysimage' so you are in your new install (kinda feeling
like Gentoo at this point ;) ) and continue adding your desired
packages.  

Things to remember:

If you want to keep with Fedora/RH tradition, label your filesystems and
copy an /etc/fstab from a different system for a base.  Tweak it as
necessary to match your partitioning.

Install grub or lilo if you want to boot!  Run through their respective
install routines so that you can boot.

There will be some package dependencies that don't make sense or you
don't feel are really needed.  If you want to maintain your sanity, just
go with the flow.  Fedora is not intended to be an embedded distro
fitting in as little space as possible.  If that is your real desire,
find a distro with that intent.  Don't try to use a belt sander when you
need to change a light bulb.

I would recommend trying to get yum or apt installed.  This will mean
additional reqs that you may not want such as python, but since you may
have next to nothing installed, it's so much nicer just saying 'yum
install blahblah' and letting it work things out instead of going
through all of the dependency fun all over again.  Of course, the yum
headers will add to your storage reqs.

With this method, I've managed working installs around 200mb with
additional utils installed that I needed/wanted.  Pretty spartan to be
sure (no man pages, etc) but it did work rather well.  Also helps you to
appreciate what Anaconda does for you!

-- 
David T Hollis <dhollis at davehollis.com>




From Nicolas.Mailhot at laPoste.net  Mon May 24 13:18:38 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Mon, 24 May 2004 15:18:38 +0200
Subject: Prepackaged configurations
In-Reply-To: <1085251432.16339.53.camel@localhost.localdomain>
References: <1085251432.16339.53.camel@localhost.localdomain>
Message-ID: <1085404718.4773.32.camel@ulysse.olympe.o2t>

Le sam, 22/05/2004 ? 14:43 -0400, Havoc Pennington a ?crit :

> Some of the things that _might_ change across canned configurations:
> 
>  - the package set (the only thing we can change now, via 
>    the Workstation or Server split in the comps file for example)

This really should be handled via package sets (standalone groups that
can be distributed in standalone xml files). We've already hashed this
to death last years.

Standalone package sets so one can add a "usage" to a system
post-install, separate sources can maintain groups and Fedora only has
to bundle the most popular ones (like themes right now).

Of course being able to use a package set floppy/cd at install time
would be a big plus, but the focus should be post-install roles IMHO -
the strength of linux systems is every reconf does not require a full
reinstall.

Another important points is to be able to install several package sets
concurrently - these days very few computers are dedicated to a single
task (OTOH a full multipurpose system is usually overkill).

>  - specific parts of a config file, e.g. enabling xdmcp in gdm
>  - default settings in gconf (e.g. each canned config might 
>    add a new config source in /etc/gconf/2/path)
>  - contents of /etc/skel
>  - optimum partitioning scheme
>  - first boot screens, e.g. asking for site-specific info to 
>    go into the configuration
>  - kernel boot options

This part OTOH more or less assumes a dedicated system. This is very
wrong IMHO. People will want a mail+music server, or an office+graphic
system, etc.

If you try to create setups for all the combos you'll drown.
OTOH you can have a group dedicated to the best "music" conf, another to
the best "office" one and users that mix all the package sets they're
interested in.

Of course, that also means you can not have a single package set
"owning" some config files, since a lot of them will need to be shared.
Automating requirement merging is probably very hairy (even more so if
you allow addition of new package set to a running system). Doing it
manually is probably possible provided the conf files are semi-sane (the
postfix doc with all its separate config scenarii is very good) but we
all know this is not always the case :(

A combinaison of howto + sample conf files set + automated test script
(? la samba testparm, nagios...) is probably the way to go.

Anyway that's just my 2 centimes, feel free to disregard it.

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

From davej at redhat.com  Mon May 24 13:38:14 2004
From: davej at redhat.com (Dave Jones)
Date: Mon, 24 May 2004 14:38:14 +0100
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <1085405894.12719.12.camel@delerium.codemonkey.org.uk>

On Mon, 2004-05-24 at 06:45, Bryan J. Smith wrote:

> Steven brings up a larger issue.  With Fedora going to the "distributed"
> model, at what point do we start to try (if at all?) to "reduce" the
> size Fedore "Core" (FC)?
> 
> I mean, is there a reason we need to maintain a 3+ CD set for FC, just
> as to match the "legacy" design of old Red Hat Linux (RHL)?
> 
> I personally would like to see "Core" reduced to a _single_ binary CD.

Cristian has expressed a desire to 'trim down' the core. How much
it gets trimmed down is as-yet undetermined afaik. The one thing
holding us back on doing this right now is the lack of infrastructure
to support 'extras'.  Ie, we drop something from core, where does it go?

With extras in place, we can migrate many of/all the non-essential apps
there.  Another area that may need improvements would be package
installation.  Whilst up2date / yum / system-config-packages are
improving over time, people (including myself) still have various gripes
over what these packages do (or don't do) in various situations.

I'd really like to see us get to the stage where an install just
installs a bare-bones system[1], and after booting, firstboot runs
system-config-packages to pull in anything else we desire.
Moving the bulk of the package selection out of the installer.
I think I recall Jeremy being quite enthusiastic about this too
at various points in time, so who knows.. it could happen 8)

	Dave

[1] Basically xorg, firstboot, system-config-packages and a probably a
handful of simple administration packages and their dependancies.




From cmadams at hiwaay.net  Mon May 24 13:46:25 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 24 May 2004 08:46:25 -0500
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085405894.12719.12.camel@delerium.codemonkey.org.uk>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
Message-ID: <20040524134625.GA703705@hiwaay.net>

Once upon a time, Dave Jones <davej at redhat.com> said:
> I'd really like to see us get to the stage where an install just
> installs a bare-bones system[1], and after booting, firstboot runs
> system-config-packages to pull in anything else we desire.
> Moving the bulk of the package selection out of the installer.
> I think I recall Jeremy being quite enthusiastic about this too
> at various points in time, so who knows.. it could happen 8)

If we get to that point, we will need CD/DVD images of Extras as well.
Not everyone has a high-speed link, at least when they are installing.
-- 
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 tagoh at redhat.com  Mon May 24 14:11:24 2004
From: tagoh at redhat.com (Akira TAGOH)
Date: Mon, 24 May 2004 23:11:24 +0900 (JST)
Subject: Call For Use of i18n keyword for bugs
Message-ID: <20040524.231124.467303578.tagoh@redhat.com>


Hi,

Our bugzilla has supported 'i18n' keyword on Keywords
field. and people can see from
http://bugzilla.redhat.com/bugzilla/describekeywords.cgi how
many I18N related bugs are opened. (of course it's not only
for I18N, though). but actually we have many bugs for I18N,
which isn't added 'i18n' keyword. so I would like to call for
use of 'i18n' keyword if you need to file an I18N related
bug. it will helps us to track the I18N bugs.

Please use proper keywords for people who wants to check out
the bugs extensively.

Thanks,
--
Akira TAGOH




From jspaleta at gmail.com  Mon May 24 13:12:50 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 24 May 2004 09:12:50 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <604aa79104052406125026c7f9@mail.gmail.com>

On Mon, 24 May 2004 01:45:13 -0400, Bryan J. Smith <b.j.smith at ieee.org> wrote:
> Steven brings up a larger issue.  With Fedora going to the "distributed"
> model, at what point do we start to try (if at all?) to "reduce" the
> size Fedore "Core" (FC)?


Feel free to start "educating" people like those who review
distributions in the media outlets, see if you can get them to agree
that having a 1 cd binary distribution is worth the effort if it that
lacks things like openoffice.

I'd rather not get into a discussion about whether Core should be 1 cd
or 2 or 8.
I'd much rather get into a discussion of what type of installs and
uses Core should be aimed at. I think the size of the core
distribution follows from the usage situation expected.  If Fedora
Core is meant to be general purpose..i dont think 1 CD is going to cut
it.   If people looking for 1 CD image are primarily interested in
specifically tasks servers or perhaps lowball hardware...i dont
necessarily thing the core install and core media sets should be aimed
at that usage. Following Havoc's suggestion regarding prepackaged
configs in another thread perhaps there is a new way to approach the
idea outside of anaconda that doesn't invovle gutting the official
fedora core media set.

-jef"and we sure as hell better not start dumping things from Core
into Extras until there is a clear understanding of how to use Extras
during installs and upgrades without requiring network
connectivity"spaleta




From skvidal at phy.duke.edu  Mon May 24 13:57:13 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 24 May 2004 09:57:13 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <20040524134625.GA703705@hiwaay.net>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
	<20040524134625.GA703705@hiwaay.net>
Message-ID: <1085407033.28367.0.camel@opus>


> If we get to that point, we will need CD/DVD images of Extras as well.
> Not everyone has a high-speed link, at least when they are installing.

cd/dvd images of extras are dramatically simpler, though b/c they don't
have to boot and be in order.

-sv





From jspaleta at gmail.com  Mon May 24 13:50:28 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 24 May 2004 09:50:28 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages
	in Fedora Core 3
In-Reply-To: <1085405894.12719.12.camel@delerium.codemonkey.org.uk>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
Message-ID: <604aa7910405240650194a8ec6@mail.gmail.com>

On Mon, 24 May 2004 14:38:14 +0100, Dave Jones <davej at redhat.com> wrote:
> With extras in place, we can migrate many of/all the non-essential apps
> there.  Another area that may need improvements would be package
> installation.  Whilst up2date / yum / system-config-packages are
> improving over time, people (including myself) still have various gripes
> over what these packages do (or don't do) in various situations.
<rant>
One situation that comes up repeatedly in #fedora
you do a desktop install which installs foo-1.1 package
you get the online update for foo-1.2
you using system-config-packages to install foo-server-1.1 from
cd...but it won't
install becuase there is a dependancy foo-1.1 and you have foo-1.2 installed.
since system-config-packages is not network aware yer screwed...you have to use
up2date or yum via the commandline to do the foo-server install from
the network.
</rant>


> 
> I'd really like to see us get to the stage where an install just
> installs a bare-bones system[1], and after booting, firstboot runs
> system-config-packages to pull in anything else we desire.
> Moving the bulk of the package selection out of the installer.
> I think I recall Jeremy being quite enthusiastic about this too
> at various points in time, so who knows.. it could happen 8)

This makes sense for fresh installs....but anaconda managed
upgrades...man oh man thats going to suck a lot. Multi-staged installs
make sense...but anaconda based upgrades...not so obvious that its
going to be able to do it in a way where you are risking some rather
nasty rpmdb inconsistancies. And having to require network
connectivity to do upgrades to get around this issue, well thats not
so cool in some situations.

-jef




From steve at silug.org  Mon May 24 14:21:30 2004
From: steve at silug.org (Steven Pritchard)
Date: Mon, 24 May 2004 09:21:30 -0500
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085407033.28367.0.camel@opus>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
	<20040524134625.GA703705@hiwaay.net>
	<1085407033.28367.0.camel@opus>
Message-ID: <20040524142130.GA25352@osiris.silug.org>

On Mon, May 24, 2004 at 09:57:13AM -0400, seth vidal wrote:
> cd/dvd images of extras are dramatically simpler, though b/c they don't
> have to boot and be in order.

And the packages could easily be installed with yum/apt.

firstboot already has the option of adding software...  Surely it
could handle such CDs easily.  If that's "too late" to make people
happy, how hard would it be to add a hook to anaconda to scan
additional CDs for installable software?

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)398-7360               Mobile: (618)567-7320




From mattdm at mattdm.org  Mon May 24 14:22:13 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 24 May 2004 10:22:13 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085405894.12719.12.camel@delerium.codemonkey.org.uk>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
Message-ID: <20040524142213.GB7735@jadzia.bu.edu>

On Mon, May 24, 2004 at 02:38:14PM +0100, Dave Jones wrote:
> I'd really like to see us get to the stage where an install just
> installs a bare-bones system[1], and after booting, firstboot runs
> system-config-packages to pull in anything else we desire.
> Moving the bulk of the package selection out of the installer.

I have mixed feelings about this. On the one hand, a simpler installer seems
like a good thing. But, there are many "early" decisions which need to be
made -- partitioning information, for example -- which can be related to
package selection later. (Think installclasses and Havoc's post earlier.)
It's annoying to be asked some basic questions, reboot, and then asked more
questions which could have been covered earlier.

Also, if too much functionality gets removed from the installer, kickstart
installs are either going to be a) broken or b) there will be a whole bunch
of code in the installer that only exists for kickstart and can't be
removed.

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




From jspaleta at gmail.com  Mon May 24 14:30:28 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 24 May 2004 10:30:28 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages
	in Fedora Core 3
In-Reply-To: <1085407033.28367.0.camel@opus>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
	<20040524134625.GA703705@hiwaay.net> <1085407033.28367.0.camel@opus>
Message-ID: <604aa791040524073015794298@mail.gmail.com>

On Mon, 24 May 2004 09:57:13 -0400, seth vidal <skvidal at phy.duke.edu> wrote:
> cd/dvd images of extras are dramatically simpler, though b/c they don't
> have to boot and be in order.

don't have to be in order?  Are we saying that we are going to be
happy with the idea that if extras spans 5 cd images while core spans
1... that its perfectly okay that users trying to use those 5 cd extra
images will have to swap in those 5 cd images somewhat randomly to
fill the dependancy chain?  I thought part of the point of ordering
images was to prevent the extra hassle of having to repeatedly go
between cd1 and cd3 over and over again during the install process.
Why would this be any different for Extras?

And I'm also somewhat concerned that whatever mechanism is created to
tie in Extras into the install/upgrade proces...that mechnism needs to
be general enough to encompass 3rd party repos too. No hardwiring of
extras into the default logic of firstboot or anaconda. No a priori
knowledge of the groupings to expect on the extra cds, things like
that. Whatever works with extras needs to work with things like
intranet or 3rd party addon media, in a general way...including
defined package groups outside of Core comps definition.


-jef




From john.hearns at clustervision.com  Mon May 24 14:37:02 2004
From: john.hearns at clustervision.com (John Hearns)
Date: Mon, 24 May 2004 15:37:02 +0100
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085405894.12719.12.camel@delerium.codemonkey.org.uk>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
Message-ID: <1085409421.6199.61.camel@vigor12>

On Mon, 2004-05-24 at 14:38, Dave Jones wrote:

> 
> I'd really like to see us get to the stage where an install just
> installs a bare-bones system[1], and after booting, firstboot runs
> system-config-packages to pull in anything else we desire.
> Moving the bulk of the package selection out of the installer.
> I think I recall Jeremy being quite enthusiastic about this too
> at various points in time, so who knows.. it could happen 8)

This fits quite nicely with the thread on "prepackaged configurations"

There would have to be some sort of configuration that firstboot reads,
saying "Use a canned configuration from CD  (such as we have with
Desktop/Workstation/Server at the moment)
OR use a network configuration server for my post-install step(s)"

It would make sense to use the same syntax for all configurations - just
that a small set would be held on CD and read from local disk for
a stand-alone install.




From bpm at ec-group.com  Mon May 24 14:56:50 2004
From: bpm at ec-group.com (Brian Millett)
Date: Mon, 24 May 2004 09:56:50 -0500 (CDT)
Subject: /sbin/devlabel errors at boot.
Message-ID: <41285.12.41.112.51.1085410610.squirrel@webmail.ec-group.com>

Hi,
 First of all, I am running FC2 + rawhide (got to bleed!).  I've been just
yum updating and did not have any problems that were not resolved.  I did
not upgrade to FC2 with the CS's so my problems could be a result of not
having anaconda work its final mojo, but I'm not sure.

Problem:  I get the following errors at boot, or rather when
/sbin/devlabel is restarted in /etc/rc.sysinit:

/sbin/devlabel: line 880: /etc/sysconfig/devlabel.d/ignore_list: No such
file or directory
/sbin/devlabel: line 881: /etc/sysconfig/devlabel.d/proc_partitions: No
such file or directory
grep: /etc/sysconfig/devlabel.d/ignore_list: No such file or directory
/sbin/devlabel: line 905: [: -eq: unary operator expected
grep: /etc/sysconfig/devlabel.d/ignore_list: No such file or directory
/sbin/devlabel: line 129: [: -gt: unary operator expected
grep: /etc/sysconfig/devlabel.d/ignore_list: No such file or directory
/sbin/devlabel: line 129: [: -gt: unary operator expected
grep: /etc/sysconfig/devlabel.d/ignore_list: No such file or directory
/sbin/devlabel: line 129: [: -gt: unary operator expected
grep: /etc/sysconfig/devlabel.d/ignore_list: No such file or directory
/sbin/devlabel: line 129: [: -gt: unary operator expected


I see that all of these messages are caused from a lack of having a
/etc/sysconfig/devlabel.d directory.

Do I need one?  What steps do I take to get right with the world?

Thanks.
-- 
Brian Millett
Enterprise Consulting Group  "Shifts in paradigms
(314) 205-9030           often cause nose bleeds."
bpmATec-groupDOTcom                     Greg Glenn






From mattdm at mattdm.org  Mon May 24 14:14:35 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 24 May 2004 10:14:35 -0400
Subject: Request for Packages in Fedora Core 3
In-Reply-To: <Pine.LNX.4.58.0405232341340.457@tigger.rogueind.com>
References: <20040523160010.E91E473AA7@hormel.redhat.com>
	<1085361614.31489.505.camel@localhost.localdomain>
	<Pine.LNX.4.58.0405232341340.457@tigger.rogueind.com>
Message-ID: <20040524141435.GA7735@jadzia.bu.edu>

On Sun, May 23, 2004 at 11:51:20PM -0400, Tom Diehl wrote:
> Just a question from a disinterested 3rd party, If you think Scribus would
> be useful for the majority of the users of the distroi, why don't you
> package it up for inclusion into fedora.us. That is supposed to be the

Someone already has.

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




From skvidal at phy.duke.edu  Mon May 24 14:25:38 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 24 May 2004 10:25:38 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <20040524142213.GB7735@jadzia.bu.edu>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
	<20040524142213.GB7735@jadzia.bu.edu>
Message-ID: <1085408738.28367.3.camel@opus>


> Also, if too much functionality gets removed from the installer, kickstart
> installs are either going to be a) broken or b) there will be a whole bunch
> of code in the installer that only exists for kickstart and can't be
> removed.
> 

What if anaconda took the package selection part out of kickstart and
passed it off to yum in  file in a specific place on the system?

So then on the next boot, your startup scripts looked for this file, if
it existed it would tell yum to use it as an input script to
install/remove/update things.

wouldn't that suffice - hell, that's what I do now to get packages that
aren't in Core installed.

B/c sometimes I can't install them in %post for various silly reasons.

-sv





From thomas at apestaart.org  Mon May 24 15:44:25 2004
From: thomas at apestaart.org (Thomas Vander Stichele)
Date: Mon, 24 May 2004 17:44:25 +0200
Subject: building packages for FC2 for external kernel modules
In-Reply-To: <1085242745.14486.6.camel@laptop.fenrus.com>
References: <1085241408.2861.44.camel@otto.amantes>
	<1085242745.14486.6.camel@laptop.fenrus.com>
Message-ID: <1085413465.2820.11.camel@otto.amantes>

Hi,

> > - Anyone know why FC2 module versioning is turned off ? AFAIK the build
> > setup we've come up with would take symbol versioning into account
> > correctly if it were turned on.
> 
> in 2.6 it makes it really hard to build external modules with

How so ? Seems to work fine.

> , in addition the thing we had symbol versioning for
> (preventing wrong modules to be inserted) now gets caught by the module version magic.
This is the line that reads
"vermagic:       2.6.5-1.358 686 REGPARM 4KSTACKS gcc-3.3"
for example, right ? Aren't there other settings in the kernel build
that affect module versioning that aren't represented in the vermagic ?
If not, why is module versioning still needed ?

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Will you take me for a ride
The one that never ends
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/





From dwmw2 at infradead.org  Mon May 24 15:54:05 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 24 May 2004 16:54:05 +0100
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <1085414045.27156.192.camel@imladris.demon.co.uk>

On Mon, 2004-05-24 at 01:45 -0400, Bryan J. Smith wrote:
> In fact, I was first going to suggest Fedora "microCore" instead of
> Fedora "miniCore" but the common use of "u" as the character for "Mu"
> for "micro" produces a rather "intersting" acronym -- i.e., "FuC".

Bah. What's the point in UTF-8 if people aren't going to use it?

Call it 'F?C' please. 

C'mon -- how hard is it to hit AltGr-m instead of just 'u' ? :)

(Yes, I also think that, for example, 'role' should be taken out of the
dictionaries and 'r?le' put in instead, etc. We finally outgrew
ascii-only typewriters. Let's make the most of it. :)

-- 
dwmw2





From notting at redhat.com  Mon May 24 16:12:19 2004
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 24 May 2004 12:12:19 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <20040524161218.GA15916@nostromo.devel.redhat.com>

Bryan J. Smith (b.j.smith at ieee.org) said: 
> I personally would like to see "Core" reduced to a _single_ binary CD.

If you don't want a GUI, sure!

Otherwise, two is a little more practical.

Bill




From rms at 1407.org  Mon May 24 16:43:21 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Mon, 24 May 2004 17:43:21 +0100
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085414045.27156.192.camel@imladris.demon.co.uk>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085414045.27156.192.camel@imladris.demon.co.uk>
Message-ID: <1085417001.12347.53.camel@roque>

On Mon, 2004-05-24 at 16:54 +0100, David Woodhouse wrote:
> Call it 'F?C' please. 
> C'mon -- how hard is it to hit AltGr-m instead of just 'u' ? :)

Very, when US International lacks lots of mappings!

Rui
-------------- 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/20040524/bb199d3a/attachment.sig>

From dennis at ausil.us  Mon May 24 14:36:21 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 25 May 2004 00:36:21 +1000
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <604aa791040524073015794298@mail.gmail.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
Message-ID: <200405250036.21757.dennis@ausil.us>

Once upon a time Tuesday 25 May 2004 12:30 am, Jeff Spaleta wrote:
> On Mon, 24 May 2004 09:57:13 -0400, seth vidal <skvidal at phy.duke.edu> wrote:
> > cd/dvd images of extras are dramatically simpler, though b/c they don't
> > have to boot and be in order.
>
> don't have to be in order?  Are we saying that we are going to be
> happy with the idea that if extras spans 5 cd images while core spans
> 1... that its perfectly okay that users trying to use those 5 cd extra
> images will have to swap in those 5 cd images somewhat randomly to
> fill the dependancy chain?  I thought part of the point of ordering
> images was to prevent the extra hassle of having to repeatedly go
> between cd1 and cd3 over and over again during the install process.
> Why would this be any different for Extras?
>
> And I'm also somewhat concerned that whatever mechanism is created to
> tie in Extras into the install/upgrade proces...that mechnism needs to
> be general enough to encompass 3rd party repos too. No hardwiring of
> extras into the default logic of firstboot or anaconda. No a priori
> knowledge of the groupings to expect on the extra cds, things like
> that. Whatever works with extras needs to work with things like
> intranet or 3rd party addon media, in a general way...including
> defined package groups outside of Core comps definition.


i think we should look at how debian  put togethether there cd images  all up 
they have 7 binary cds you can do a minimal install from 1 and 3 gets you the 
most common stuff  and the last 4 are more obscure packages.  they shouldnt 
be random but package foo on cd 2 should have all dependancies met in cd 1 
and 2  while package bar on cd 3  needs its dependancies met from cd1-3  what 
would be really neat  is to specify a location  say a nfs share that has the 
iso images and the package installer i.e yum, apt, or up2date could mount 
that isos  and get the packages off  without having to make a package tree

Dennis




From aoliva at redhat.com  Mon May 24 16:56:58 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 24 May 2004 13:56:58 -0300
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <or65alsqzp.fsf@free.redhat.lsd.ic.unicamp.br>

On May 24, 2004, "Bryan J. Smith" <b.j.smith at ieee.org> wrote:

> I mean, is there a reason we need to maintain a 3+ CD set for FC, just
> as to match the "legacy" design of old Red Hat Linux (RHL)?

Here are my favorite reasons:

Downloading an entire distro per machine installed isn't feasible for
a large number of people in the world.  Having a set of CDs that
people can download once, install on a lot of machines, then install
updates plus any additional packages over the Internet works; having
to download the entire distro for every install isn't.

Sure, local mirrors of Extras repositories may help alleviate the
bandwidth, but you have to have a significant number of machines for
this to actually make sense.


Another issue is that Extras packages don't generally work right after
a new Core release is out.  You have to resort to using Extras
repositories of earlier releases until they've installed the new
release themselves, and mass-rebuilt the packages for it.  This takes
time.  Since Fedora Core releases are already short-lived, and having
to wait some time in order to install them makes it even shorter.

And then, there's the issue of testing.  The smaller the core, the
fewer applications you'll get tested as part of the release process.
No matter how competent the extras packagers are, unless they maintain
a rawhide track of their repositories (and I don't think any of the
major repositories do), their packages for a new distro will only
begin getting tested when the new distro goes out.  That means further
instability and poorer user experience.


IMHO, the ideal solution for this problem is to not shrink the core or
split it from extras, but actually create a distro that contains core
and extras CDs, giving the installer the ability to install these
extras.

Sure, people who push for the Extras don't get to maintain fewer
packages, which was one of the main motivations of the Extras model,
but the packages, being in the Core or in Extras, have to be
maintained anyway.

Taking them out of the distro CD set makes them unavailable to a lot
of people, so let's instead start splitting package sets into Extras
CDs: instead of CDs numbered 1 to 4, I envision having CD1 and maybe 2
with a small core, and then separate CDs for Extras.  It is essential,
however, that these Extras CDs be just a packaging artifact, as
opposed to 2nd-class citizens in the distro.  One tricky bit is how to
name the CDs such that people can tell in advance what to download to
be able to install the software they want.  The other is how to rework
the distro compose scripts such that they follow these packaging
guidelines.  None of these should be too hard.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From alan at redhat.com  Mon May 24 17:04:08 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 24 May 2004 13:04:08 -0400
Subject: The Fedora Hardware Project
In-Reply-To: <1085357981.3935.11.camel@Curran415>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
Message-ID: <20040524170408.GB19161@devserv.devel.redhat.com>

On Sun, May 23, 2004 at 07:19:41PM -0500, Scott Sloan wrote:
> 3.) Some input and search code?
> 
> 4.) Anything else?

Some planning is needed on the backend to capture the data. It might be
nice for FC3 to allow anyone to submit their data automatically either
by running an add on app for FC2 or integrating into firstboot for later
releases

Is you can capture dmi data (bios, board, versions etc), ram size, I/O
devices, pci devices etc, and search on all of those (eg by PCI vendor id)
That would give a lot more correlation data for bugs for example.

[Given 50 samples you can meaningfully make assertions like "XYZ hw has
a direct relationship with hanging"]




From skvidal at phy.duke.edu  Mon May 24 17:05:09 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 24 May 2004 13:05:09 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages
	in Fedora Core 3
In-Reply-To: <604aa791040524073015794298@mail.gmail.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
	<20040524134625.GA703705@hiwaay.net> <1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
Message-ID: <1085418309.28367.6.camel@opus>

On Mon, 2004-05-24 at 10:30, Jeff Spaleta wrote:
> On Mon, 24 May 2004 09:57:13 -0400, seth vidal <skvidal at phy.duke.edu> wrote:
> > cd/dvd images of extras are dramatically simpler, though b/c they don't
> > have to boot and be in order.
> 
> don't have to be in order?  Are we saying that we are going to be
> happy with the idea that if extras spans 5 cd images while core spans
> 1... that its perfectly okay that users trying to use those 5 cd extra
> images will have to swap in those 5 cd images somewhat randomly to
> fill the dependancy chain?  I thought part of the point of ordering
> images was to prevent the extra hassle of having to repeatedly go
> between cd1 and cd3 over and over again during the install process.
> Why would this be any different for Extras?

You could group by the items themselves not by the likelihood of the
item being installed.

The cds, right now, must be ordered based on the likelihood of certain
things being installed in a normal install. But with separate extra cds
you could just group them based on similarity of the item.

-sv





From aoliva at redhat.com  Mon May 24 17:09:00 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 24 May 2004 14:09:00 -0300
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085405894.12719.12.camel@delerium.codemonkey.org.uk>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
Message-ID: <or1xl9sqfn.fsf@free.redhat.lsd.ic.unicamp.br>

On May 24, 2004, Dave Jones <davej at redhat.com> wrote:

> I'd really like to see us get to the stage where an install just
> installs a bare-bones system[1], and after booting, firstboot runs
> system-config-packages to pull in anything else we desire.

This is not such a good idea for a machine that needs all of the
extras installed before it boots up and start running say sendmail,
because people want to use these add-ons for their mail delivery.
sendmail is just an example; any other daemons that are started and
can be configured with kickstart rules to do the right thing suddenly
get trickier if the core is missing the packages and kickstart won't
let you do non-interactive up2date installs because it wants up2date
configuration to be confirmed.

After a kickstart install, I'd like to machine to be as ready for use
as possible.  Deferring installation of most of the distro to
post-installation time sounds like an oxymoron to me.

Now if only firstboot would run before the installer reboots, or
before any services are started, you might have a case, but having
firstboot run after a server comes up and starts pretending to serve
stuff correctly is a Very Bad Idea (TM).

I understand the wish to move stuff out of the installer.  Having the
installer run additional programs at the end, instead of after a
reboot, would help take code out of the installer, and might be seen
as a good thing for many.

However, one of the good things about anaconda is that it asks all
questions first, and then proceeds to install without any need for
additional interaction, except for the click for reboot at the end.
Adding a necessary firstboot step to select and install additional
packages would add a second major interaction before the install can
be said to be finished, followed by a potentially long delay as
additional packages are downloaded and installed.  And then, probably
yet another reboot just to make sure things are all set and in place.
This sounds *very* undesirable to me.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From jspaleta at gmail.com  Mon May 24 17:25:08 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 24 May 2004 13:25:08 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for
	Packages in Fedora Core 3
In-Reply-To: <1085418309.28367.6.camel@opus>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
	<20040524134625.GA703705@hiwaay.net> <1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
	<1085418309.28367.6.camel@opus>
Message-ID: <604aa791040524102526327a4e@mail.gmail.com>

On Mon, 24 May 2004 13:05:09 -0400, seth vidal <skvidal at phy.duke.edu> wrote:

 
> The cds, right now, must be ordered based on the likelihood of certain
> things being installed in a normal install. But with separate extra cds
> you could just group them based on similarity of the item.

I would agree with that as an ideal. I am concerned about dependancy
chains that span more than one extra cd that get whacked out and make
you bounce back and forth between extra cds and back to the Core cd to
pick up a lib or something to complete the install. Whatever gets
implemented...i would like a cd install process to be able to minimize
the number of times a specific cd has to be reloaded for use:
load cd A
load cd B
load cd C
if i have to reload cd A again becuase cd C wants a dependancy from cd
A, that could get painful in the general case.

I guess one thing you can do is make the "simularity grouped" extra
cds self-consitant by placing needed dependancy packages into each cd
image as needed. So maybe extras A and extras B cds include a few
duplicate packages to prevent cross cd image dependancies. And then if
yer cd image gets too big thanks to these duplicate packages..you just
break up the grouping into more cds.
This though, still doesn't take into account what happens if you need
a Core dependancy that you dont have installed yet. Potentially
firstboot is going to have to ask you to re-insert the Core media for
each extra cd you want to use. So if there are 4 extra cds, defined
along "simularity" lines...thats still 4 times you might have to
insert Core media to grab dependancies you dont have installed yet....
yucky.

Or perhaps an approach by which you tell firstboot which cds you want
to use by loading them in some random order as a first step so
firstboot can grab the metadata about dependancies and what
not...figure out the dependancy chain installation order...and then
firstboot will ask you for the install media in an order that minimize
the number of times you have to insert install media. So when you are
doing the actual package install...firstboot will ask you for each cd,
including Core media, only once minimizing the amount of human
interaction with the process.

-jef




From dhollis at davehollis.com  Mon May 24 17:32:34 2004
From: dhollis at davehollis.com (David T Hollis)
Date: Mon, 24 May 2004 13:32:34 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <or1xl9sqfn.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>
	<or1xl9sqfn.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <1085419954.3632.5.camel@dhollis-lnx.kpmg.com>

On Mon, 2004-05-24 at 14:09 -0300, Alexandre Oliva wrote:

> 
> However, one of the good things about anaconda is that it asks all
> questions first, and then proceeds to install without any need for
> additional interaction, except for the click for reboot at the end.
> Adding a necessary firstboot step to select and install additional
> packages would add a second major interaction before the install can
> be said to be finished, followed by a potentially long delay as
> additional packages are downloaded and installed.  And then, probably
> yet another reboot just to make sure things are all set and in place.
> This sounds *very* undesirable to me.

This sounds a lot like Windows to me!  The fact that I can install a
Fedora/RH based server/desktop with a grand total of 3 reboots is
something I would very much like to maintain.  And those reboots are:
1) initial boot off the cd to start install
2) reboot at the end of install
3) reboot after applying all updates, config tweaks, etc to make sure
the system comes up exactly as planned.

I think the concept of moving less 'core' packages to the Extras CDs is
a pretty sane approach.  These packages are still part of the overall
distro so they go through the same build process, are on the pack of
CDs/download set that I'm using to install all of my systems, etc.  If
you start moving something like Openoffice in Extras and Extras handled
off a different web site, that becomes a 100+mb download for a box.
Sure, I can mirror that repo, or pull all of that stuff down but that
becomes cumbersome and inefficient.  If Extras is just really
non-mainstream type of stuff (say snort, kino, Nagios, etc), that's fine
to pull down.  Stuff that is likely to be desired on every desktop
should be in the main download set.

-- 
David T Hollis <dhollis at davehollis.com>




From rms at 1407.org  Mon May 24 16:49:27 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Mon, 24 May 2004 17:49:27 +0100
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <200405250036.21757.dennis@ausil.us>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
	<200405250036.21757.dennis@ausil.us>
Message-ID: <1085417367.12347.57.camel@roque>

On Tue, 2004-05-25 at 00:36 +1000, Dennis Gilmore wrote:
> would be really neat  is to specify a location  say a nfs share that has the 
> iso images and the package installer i.e yum, apt, or up2date could mount 
> that isos  and get the packages off  without having to make a package tree

This reminds me of a doubt I have:
  Can one simply mount, say...

/mnt/rec/FC2-i386-isos/FC2-i386-disc1.iso
   /var/ftp/pub/fc2/disc1 auto    defaults,loop=/dev/loop0 0 0

/mnt/rec/FC2-i386-isos/FC2-i386-disc2.iso
   /var/ftp/pub/fc2/disc2 auto    defaults,loop=/dev/loop1 0 0

/mnt/rec/FC2-i386-isos/FC2-i386-disc3.iso
   /var/ftp/pub/fc2/disc3 auto    defaults,loop=/dev/loop2 0 0

/mnt/rec/FC2-i386-isos/FC2-i386-disc4.iso
   /var/ftp/pub/fc2/disc4 auto    defaults,loop=/dev/loop3 0 0

and then point askmethod to ftp://server/pub/fc2/ ?

Is this possible, or something like it?

Hugs, Rui
-------------- 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/20040524/20c962ed/attachment.sig>

From sopwith at redhat.com  Mon May 24 17:47:00 2004
From: sopwith at redhat.com (Elliot Lee)
Date: Mon, 24 May 2004 13:47:00 -0400
Subject: Fedora Project Mailing Lists reminder
Message-ID: <sopwith.2004-05-24.13.47.00.list-reminder@redhat.com>

This is a reminder of the mailing lists for the Fedora Project, and
the purpose of each list. You can view this information at
http://fedora.redhat.com/participate/communicate/

When you're using these mailing lists, please take the time to choose
the one that is most appropriate to your post. If you don't know the
right mailing list to use for a question or discussion, please contact
me. This will help you get the best possible answer for your question,
and keep other list subscribers happy!

Mailing Lists

Mailing lists are email addresses which send email to all users
subscribed to the mailing list. Sending an email to a mailing list
reaches all users interested in discussing a specific topic and users
available to help other users with the topic.

The following mailing lists are available. To subscribe, send email to <listname>-request at redhat.com
(replace <listname> with the desired mailing list name such as
fedora-list) with the word subscribe in the subject.

fedora-announce-list - Announcements of changes and events. To stay
aware of news, subscribe to this list.
fedora-list - For users of releases. If you want help with a problem
installing or using , this is the list for you.
fedora-test-list - For testers of test releases. If you would like to
discuss experiences using TEST releases, this is the list for you.
fedora-devel-list - For developers, developers, developers. If you are
interested in helping create releases, this is the list for you.
fedora-docs-list - For participants of the docs project
fedora-desktop-list - For discussions about desktop issues such as user
interfaces, artwork, and usability
fedora-config-list - For discussions about the development of
configuration tools
fedora-legacy-announce - For announcements about the Fedora Legacy
Project
fedora-legacy-list - For discussions about the Fedora Legacy Project
fedora-selinux-list - For discussions about the Fedora SELinux Project
fedora-de-list - For discussions about Fedora in the German language
fedora-ja-list - For discussions about Fedora in the Japanese language
fedora-i18n-list - For discussions about the internationalization of
Fedora Core
fedora-trans-list - For discussions about translating the software and
documentation associated with the Fedora Project
German: fedora-trans-de
French: fedora-trans-fr
Spanish: fedora-trans-es
Italian: fedora-trans-it
Brazilian Portuguese: fedora-trans-pt_br
Japanese: fedora-trans-ja
Korean: fedora-trans-ko
Simplified Chinese: fedora-trans-zh_cn
Traditional Chinese: fedora-trans-zh_tw




From ndbecker2 at verizon.net  Mon May 24 18:48:06 2004
From: ndbecker2 at verizon.net (Neal Becker)
Date: Mon, 24 May 2004 14:48:06 -0400
Subject: submount?
Message-ID: <200405241448.14725.ndbecker2@verizon.net>

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

I discovered submount when testing suse-9.1.  First, let me say, that 
something like this is really needed for a non-geek desktop linux system.  
Users expect that when they insert a CD it will be mounted, and that this 
would work "out of the box".

I don't know if submount is the "best" way to make this happen or not, 
although I think maybe it is.


I'd like to start a discussion on this topic.

http://submount.sourceforge.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAskNtMDqogpR5tkMRAhVaAJ4n4WhKc5hmxRFiQgd3I6h6Joat4gCdHGVC
A1hPMAS34m3WckdOmq5AdB0=
=a060
-----END PGP SIGNATURE-----




From dcbw at redhat.com  Mon May 24 18:53:56 2004
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 24 May 2004 14:53:56 -0400
Subject: submount?
In-Reply-To: <200405241448.14725.ndbecker2@verizon.net>
References: <200405241448.14725.ndbecker2@verizon.net>
Message-ID: <1085424836.3045.3.camel@dcbw.boston.redhat.com>

Hi,

This should more or less already happen, at least for FC2 in GNOME.  If
you insert a CD and it doesn't pop up on the desktop or in the
"Computer" window, its a bug that should go into bugzilla.  Also,
ongoing work with gnome-volume-manager will integrate automounting of
CDs, USB key drives, and other removable media into the GTK file
chooser.

Dan

On Mon, 2004-05-24 at 14:48 -0400, Neal Becker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I discovered submount when testing suse-9.1.  First, let me say, that 
> something like this is really needed for a non-geek desktop linux system.  
> Users expect that when they insert a CD it will be mounted, and that this 
> would work "out of the box".
> 
> I don't know if submount is the "best" way to make this happen or not, 
> although I think maybe it is.
> 
> 
> I'd like to start a discussion on this topic.
> 
> http://submount.sourceforge.net/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFAskNtMDqogpR5tkMRAhVaAJ4n4WhKc5hmxRFiQgd3I6h6Joat4gCdHGVC
> A1hPMAS34m3WckdOmq5AdB0=
> =a060
> -----END PGP SIGNATURE-----
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list




From ndbecker2 at verizon.net  Mon May 24 18:58:47 2004
From: ndbecker2 at verizon.net (Neal Becker)
Date: Mon, 24 May 2004 14:58:47 -0400
Subject: submount?
In-Reply-To: <1085424836.3045.3.camel@dcbw.boston.redhat.com>
References: <200405241448.14725.ndbecker2@verizon.net>
	<1085424836.3045.3.camel@dcbw.boston.redhat.com>
Message-ID: <200405241458.47145.ndbecker2@verizon.net>

On Monday 24 May 2004 2:53 pm, Dan Williams wrote:
> Hi,
>
> This should more or less already happen, at least for FC2 in GNOME.  If
> you insert a CD and it doesn't pop up on the desktop or in the
> "Computer" window, its a bug that should go into bugzilla.  Also,
> ongoing work with gnome-volume-manager will integrate automounting of
> CDs, USB key drives, and other removable media into the GTK file
> chooser.

Is this gnome specific?  If so, it's not a complete solution.  Many of us 
don't use gnome.




From sflory at rackable.com  Mon May 24 19:10:21 2004
From: sflory at rackable.com (Samuel Flory)
Date: Mon, 24 May 2004 12:10:21 -0700
Subject: submount?
In-Reply-To: <200405241458.47145.ndbecker2@verizon.net>
References: <200405241448.14725.ndbecker2@verizon.net>	<1085424836.3045.3.camel@dcbw.boston.redhat.com>
	<200405241458.47145.ndbecker2@verizon.net>
Message-ID: <40B2489D.7030007@rackable.com>

Neal Becker wrote:

>On Monday 24 May 2004 2:53 pm, Dan Williams wrote:
>  
>
>>Hi,
>>
>>This should more or less already happen, at least for FC2 in GNOME.  If
>>you insert a CD and it doesn't pop up on the desktop or in the
>>"Computer" window, its a bug that should go into bugzilla.  Also,
>>ongoing work with gnome-volume-manager will integrate automounting of
>>CDs, USB key drives, and other removable media into the GTK file
>>chooser.
>>    
>>
>
>Is this gnome specific?  If so, it's not a complete solution.  Many of us 
>don't use gnome.
>
>
>  
>
  It also occurs under KDE.

BTW-  How do I shut it off?!!?




From aoliva at redhat.com  Mon May 24 19:19:23 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 24 May 2004 16:19:23 -0300
Subject: building packages for FC2 for external kernel modules
In-Reply-To: <1085413465.2820.11.camel@otto.amantes>
References: <1085241408.2861.44.camel@otto.amantes>
	<1085242745.14486.6.camel@laptop.fenrus.com>
	<1085413465.2820.11.camel@otto.amantes>
Message-ID: <orbrkdr5tw.fsf@free.redhat.lsd.ic.unicamp.br>

On May 24, 2004, Thomas Vander Stichele <thomas at apestaart.org> wrote:

> Hi,
>> > - Anyone know why FC2 module versioning is turned off ? AFAIK the build
>> > setup we've come up with would take symbol versioning into account
>> > correctly if it were turned on.
>> 
>> in 2.6 it makes it really hard to build external modules with

> How so ? Seems to work fine.

If you want to build modules for both i586 and i686, it's a pain,
unless you're willing to have two different build roots, one with the
i586 kernel, and one with the i686 kernel.  smp kernels can be
installed alongside with UP kernels, since they report a different
string from the UP ones with `uname -r', but there's no way to
distinguish i586 from i686.

I suggested to Arjan to add .i586 and .i686 tags to the kernel version
string, similar to smp, but he said he was disgusted at the idea.
That's too bad, because it would greatly simplify building kernel
modules :-(

Maybe doing that only for non-i686 kernels would make it more
palatable?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From perbj at stanford.edu  Mon May 24 19:22:30 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Mon, 24 May 2004 12:22:30 -0700
Subject: submount?
In-Reply-To: <200405241458.47145.ndbecker2@verizon.net>
References: <200405241448.14725.ndbecker2@verizon.net>	<1085424836.3045.3.camel@dcbw.boston.redhat.com>
	<200405241458.47145.ndbecker2@verizon.net>
Message-ID: <40B24B76.9050600@stanford.edu>

Neal Becker wrote:

> On Monday 24 May 2004 2:53 pm, Dan Williams wrote:
> 
>>Hi,
>>
>>This should more or less already happen, at least for FC2 in GNOME.  If
>>you insert a CD and it doesn't pop up on the desktop or in the
>>"Computer" window, its a bug that should go into bugzilla.  Also,
>>ongoing work with gnome-volume-manager will integrate automounting of
>>CDs, USB key drives, and other removable media into the GTK file
>>chooser.

But everyone hates magicdev, right? ;) The locking interactions seem, 
um, confused at times. I'm happy that the real solution is on the 
horizon, I hope the Utopia stack will be in shape for FC3...

> Is this gnome specific?  If so, it's not a complete solution.  Many of us 
> don't use gnome.

The Project Utopia stack is based on DBUS and HAL
( http://hal.freedesktop.org ) which are desktop-neutral. The 
interaction with the desktop is desktop-specific as far as I can tell, I 
don't know if there is any work being done getting this done in KDE; 
that's what the gnome-volume-manager part takes care of in Gnome. Since 
most of the groundwork will be common, getting it integrated in KDE as 
well should be a relatively modest amount of work. Since Gnome is the 
default desktop in Red Hat systems it seems unlikely that anyone at Red 
Hat will do that work though, talk to the KDE developers...

/Per




From ckloiber at ckloiber.com  Mon May 24 19:22:55 2004
From: ckloiber at ckloiber.com (Chris Kloiber)
Date: Tue, 25 May 2004 03:22:55 +0800
Subject: submount?
In-Reply-To: <40B2489D.7030007@rackable.com>
References: <200405241448.14725.ndbecker2@verizon.net>
	<1085424836.3045.3.camel@dcbw.boston.redhat.com>
	<200405241458.47145.ndbecker2@verizon.net>
	<40B2489D.7030007@rackable.com>
Message-ID: <1085426575.4324.57.camel@roadrash.rdu.redhat.com>

On Tue, 2004-05-25 at 03:10, Samuel Flory wrote:
> Neal Becker wrote:
> 
> >On Monday 24 May 2004 2:53 pm, Dan Williams wrote:
> >  
> >
> >>Hi,
> >>
> >>This should more or less already happen, at least for FC2 in GNOME.  If
> >>you insert a CD and it doesn't pop up on the desktop or in the
> >>"Computer" window, its a bug that should go into bugzilla.  Also,
> >>ongoing work with gnome-volume-manager will integrate automounting of
> >>CDs, USB key drives, and other removable media into the GTK file
> >>chooser.
> >>    
> >>
> >
> >Is this gnome specific?  If so, it's not a complete solution.  Many of us 
> >don't use gnome.
> >
> >
> >  
> >
>   It also occurs under KDE.
> 
> BTW-  How do I shut it off?!!?

I know I answered this yesterday...

Gnome Fedora/Preferences/CD and DVD

Uncheck "Mount CD when inserted", "Run command when CD is inserted", and
"Run command when blank CD is inserted". This is the wording used in
RHEL3 (I'm at work) so the wording may differ slightly on Fedora.

-- 
Chris Kloiber





From aoliva at redhat.com  Mon May 24 19:28:21 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 24 May 2004 16:28:21 -0300
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085414045.27156.192.camel@imladris.demon.co.uk>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085414045.27156.192.camel@imladris.demon.co.uk>
Message-ID: <or7jv1r5ey.fsf@free.redhat.lsd.ic.unicamp.br>

On May 24, 2004, David Woodhouse <dwmw2 at infradead.org> wrote:

> C'mon -- how hard is it to hit AltGr-m instead of just 'u' ? :)

Dunno what your kbd config is, but mine doesn't generate anything when
I press AltGr-m.  Could this be because I have AltGr mapped to
Compose?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From bryan at arcamax.com  Mon May 24 19:02:23 2004
From: bryan at arcamax.com (Bryan White)
Date: Mon, 24 May 2004 15:02:23 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
 Fedora Core 3
In-Reply-To: <1085417367.12347.57.camel@roque>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>	<1085407033.28367.0.camel@opus>	<604aa791040524073015794298@mail.gmail.com>	<200405250036.21757.dennis@ausil.us>
	<1085417367.12347.57.camel@roque>
Message-ID: <40B246BF.9050604@arcamax.com>

Rui Miguel Seabra wrote:

> On Tue, 2004-05-25 at 00:36 +1000, Dennis Gilmore wrote:
> 
>>would be really neat  is to specify a location  say a nfs share that has the 
>>iso images and the package installer i.e yum, apt, or up2date could mount 
>>that isos  and get the packages off  without having to make a package tree
> 
> 
> This reminds me of a doubt I have:
>   Can one simply mount, say...
> 
> /mnt/rec/FC2-i386-isos/FC2-i386-disc1.iso
>    /var/ftp/pub/fc2/disc1 auto    defaults,loop=/dev/loop0 0 0
> 
> /mnt/rec/FC2-i386-isos/FC2-i386-disc2.iso
>    /var/ftp/pub/fc2/disc2 auto    defaults,loop=/dev/loop1 0 0
> 
> /mnt/rec/FC2-i386-isos/FC2-i386-disc3.iso
>    /var/ftp/pub/fc2/disc3 auto    defaults,loop=/dev/loop2 0 0
> 
> /mnt/rec/FC2-i386-isos/FC2-i386-disc4.iso
>    /var/ftp/pub/fc2/disc4 auto    defaults,loop=/dev/loop3 0 0
> 
> and then point askmethod to ftp://server/pub/fc2/ ?
> 
> Is this possible, or something like it?

I don't know if the installer can read the ISOs like that.  Here is what 
I did:
----
mkdir /home/mirrors/FC2
mkdir iso
mount FC2-i386-disc1.iso iso -t iso9660 -o loop=/dev/loop3
cp -a iso/* /home/mirrors/FC2
umount iso
mount FC2-i386-disc2.iso iso -t iso9660 -o loop=/dev/loop3
cp -a iso/* /home/mirrors/FC2
umount iso
mount FC2-i386-disc3.iso iso -t iso9660 -o loop=/dev/loop3
cp -a iso/* /home/mirrors/FC2
umount iso
mount FC2-i386-disc4.iso iso -t iso9660 -o loop=/dev/loop3
cp -a iso/* /home/mirrors/FC2
umount iso
rmdir iso
----
Note: It will complain about duplicate TRANS.TBL files.  It does not 
matter if you overwrite those on each 'cp' or not.

I have a symlink like this:
ln -s /home/mirrors /var/www/html/mirrors

At install time I use the http protocal, the host name of my server and 
/mirrors/FC2 as the path.  FTP should work similarly.

-- 
Bryan White, ArcaMax Inc.

There's no point in acting all surprised about it. All the planning
charts and demolition orders have been on display in your local
planning department on Alpha Centauri for fifty of your Earth years,
so you've had plenty of time to lodge any formal complaint and it's
far too late to start making a fuss about it now.
- Prostetnic Vogon Jeltz




From aoliva at redhat.com  Mon May 24 19:34:18 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 24 May 2004 16:34:18 -0300
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085417367.12347.57.camel@roque>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
	<200405250036.21757.dennis@ausil.us> <1085417367.12347.57.camel@roque>
Message-ID: <or3c5pr551.fsf@free.redhat.lsd.ic.unicamp.br>

On May 24, 2004, Rui Miguel Seabra <rms at 1407.org> wrote:

>   Can one simply mount, say...

> /mnt/rec/FC2-i386-isos/FC2-i386-disc1.iso
>    /var/ftp/pub/fc2/disc1 auto    defaults,loop=/dev/loop0 0 0

> /mnt/rec/FC2-i386-isos/FC2-i386-disc2.iso
>    /var/ftp/pub/fc2/disc2 auto    defaults,loop=/dev/loop1 0 0

> /mnt/rec/FC2-i386-isos/FC2-i386-disc3.iso
>    /var/ftp/pub/fc2/disc3 auto    defaults,loop=/dev/loop2 0 0

> /mnt/rec/FC2-i386-isos/FC2-i386-disc4.iso
>    /var/ftp/pub/fc2/disc4 auto    defaults,loop=/dev/loop3 0 0

> and then point askmethod to ftp://server/pub/fc2/ ?

I don't think so.  That would be nice very though.

But what would be *really* cool would be to have the next-generation
yum-arch search .iso files for rpms and generate meta information for
them as well, indicating the offsets into the .iso file that contain
the package.  Then mirrors wouldn't have to carry two copies of every
package, one in the .iso, one in an exploded tree.

Seth, are you keeping a wish list? :-)

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From ndbecker2 at verizon.net  Mon May 24 19:34:07 2004
From: ndbecker2 at verizon.net (Neal Becker)
Date: Mon, 24 May 2004 15:34:07 -0400
Subject: submount?
In-Reply-To: <40B24B76.9050600@stanford.edu>
References: <200405241448.14725.ndbecker2@verizon.net>
	<200405241458.47145.ndbecker2@verizon.net>
	<40B24B76.9050600@stanford.edu>
Message-ID: <200405241534.07418.ndbecker2@verizon.net>

On Monday 24 May 2004 3:22 pm, Per Bjornsson wrote:
> Neal Becker wrote:
> > On Monday 24 May 2004 2:53 pm, Dan Williams wrote:
> >>Hi,
> >>
> >>This should more or less already happen, at least for FC2 in GNOME.  If
> >>you insert a CD and it doesn't pop up on the desktop or in the
> >>"Computer" window, its a bug that should go into bugzilla.  Also,
> >>ongoing work with gnome-volume-manager will integrate automounting of
> >>CDs, USB key drives, and other removable media into the GTK file
> >>chooser.
>
> But everyone hates magicdev, right? ;) The locking interactions seem,
> um, confused at times. I'm happy that the real solution is on the
> horizon, I hope the Utopia stack will be in shape for FC3...
>

Is there no solution to the locking issue?  I would hope it was possible to 
unlock and eject a cd/dvd when the user presses the button on the drive.  I 
don't know anything about the actual mechanism for it, but I do know that 
other OS's seem to manage this feat.




From gauret at free.fr  Mon May 24 19:34:46 2004
From: gauret at free.fr (Aurelien Bompard)
Date: Mon, 24 May 2004 21:34:46 +0200
Subject: submount?
References: <200405241448.14725.ndbecker2@verizon.net>	<1085424836.3045.3.camel@dcbw.boston.redhat.com>
	<200405241458.47145.ndbecker2@verizon.net>
	<40B2489D.7030007@rackable.com>
Message-ID: <c8tiol$gn0$1@sea.gmane.org>

Samuel Flory wrote:
> It?also?occurs?under?KDE.
> BTW-??How?do?I?shut?it?off?!!?

You have to remove the automount launcher in ~/.kde/Autostart IIRC
 

Aur?lien
-- 
http://gauret.free.fr   ~~~~   Jabber : gauret at amessage.info
"Je suis fascin? par l'air. Si on enlevait l'air du ciel, tous les oiseaux
tomberaient par terre... Et les avions aussi..." -- Jean-Claude Vandamme





From dwmw2 at infradead.org  Mon May 24 19:36:11 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 24 May 2004 20:36:11 +0100
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <or7jv1r5ey.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085414045.27156.192.camel@imladris.demon.co.uk>
	<or7jv1r5ey.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <1085427371.27156.196.camel@imladris.demon.co.uk>

On Mon, 2004-05-24 at 16:28 -0300, Alexandre Oliva wrote:
> On May 24, 2004, David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> > C'mon -- how hard is it to hit AltGr-m instead of just 'u' ? :)
> 
> Dunno what your kbd config is, but mine doesn't generate anything when
> I press AltGr-m.  Could this be because I have AltGr mapped to
> Compose?

That's why you need the spell-checker to offer to fix it for you :)

-- 
dwmw2





From elliott at wilcoxon.org  Mon May 24 19:46:44 2004
From: elliott at wilcoxon.org (Elliott Wilcoxon)
Date: Mon, 24 May 2004 14:46:44 -0500
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages	in
 Fedora Core 3
In-Reply-To: <604aa791040524073015794298@mail.gmail.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>	<20040524134625.GA703705@hiwaay.net>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
Message-ID: <40B25124.7080406@wilcoxon.org>

Jeff Spaleta wrote:

  > And I'm also somewhat concerned that whatever mechanism is created to
> tie in Extras into the install/upgrade proces...that mechnism needs to
> be general enough to encompass 3rd party repos too. No hardwiring of
> extras into the default logic of firstboot or anaconda. No a priori
> knowledge of the groupings to expect on the extra cds, things like
> that. Whatever works with extras needs to work with things like
> intranet or 3rd party addon media, in a general way...including
> defined package groups outside of Core comps definition.
> 
> 
> -jef
> 

Would the following scenario be possible?  FC(n+1) is released, small 
Core, large Extras.  Apt/yum repos go up with the new stuff.  People who 
want to upgrade download a program (or have it installed already; the 
features could be added to up2date/system-config-packages/synaptic), and 
run it.  It opens a window with various options.  If they want to just 
upgrade to the next version, they press that button, and their rpm 
headers are extracted from their rpm database.  This information is 
compared to the Extras repo, and all packages needed for upgrading to 
FC(n+1) are downloaded, then packed into the correct number of .iso's. 
They burn these .iso's, along with the Core .iso, and go along to their 
upgrade.  The idea is that we can just use the yum/apt package managers 
to determine which rpm's to download, then how they should be placed on 
the CD's to satisfy dependencies in a simple CD1->CD2->CD3->done manner.

In addition to the 'just upgrade' option, a custom .iso feature should 
also be present, for clean installs on machines with different 
configurations than the one you're doing the downloading on.  Ideally, 
simple and advanced paths would be available.  Simple would look like 
anaconda's software selector, with broad groups of software.  Advanced 
would look more like synaptic, with individual packages, with automatic 
dependency handling as you mark packages for inclusion on the .iso's.

Elliott Wilcoxon




From kbn at daimi.au.dk  Mon May 24 19:53:36 2004
From: kbn at daimi.au.dk (kbn at daimi.au.dk)
Date: Mon, 24 May 2004 21:53:36 +0200
Subject: Interested to help....
Message-ID: <40B252C0.5020700@daimi.au.dk>

Hi...

To be short, I would like to participate in the development of new 
Fedora Releases...
I primary got experience in building new rpm packages and maintaining 
them, and I have some experience in overall system administration... But 
I'm also interested in learning new aspects of Linux, even though I'm 
not a newbie to Linux...

I didn't know how to announce my interest other places than here, so I 
hope it's apropriate... And i hope that there will be some tasks to do...

Regards
/kbn




From antonio at buiza.org  Mon May 24 19:07:33 2004
From: antonio at buiza.org (Antonio Buiza Calero)
Date: Mon, 24 May 2004 21:07:33 +0200
Subject: submount?
In-Reply-To: <200405241458.47145.ndbecker2@verizon.net>
References: <200405241448.14725.ndbecker2@verizon.net>
	<1085424836.3045.3.camel@dcbw.boston.redhat.com>
	<200405241458.47145.ndbecker2@verizon.net>
Message-ID: <200405242107.33852.antonio@buiza.org>

El Lunes, 24 de Mayo de 2004 20:58, Neal Becker escribi?:
> On Monday 24 May 2004 2:53 pm, Dan Williams wrote:
> > Hi,
> >
> > This should more or less already happen, at least for FC2 in GNOME.  If
> > you insert a CD and it doesn't pop up on the desktop or in the
> > "Computer" window, its a bug that should go into bugzilla.  Also,
> > ongoing work with gnome-volume-manager will integrate automounting of
> > CDs, USB key drives, and other removable media into the GTK file
> > chooser.
>
> Is this gnome specific?  If so, it's not a complete solution.  Many of us
> don't use gnome.

At least KDE works in the same way. I've heard Mandrake comes with something 
called supermount, but don't know anything about how it works. Do this kind 
of software automatically unmount CDs when eject button is pushed? would it 
be possible?

-- 
Antonio Buiza Calero
	antonio at buiza.org
	abuiza at esi.us.es




From janina at rednote.net  Mon May 24 19:59:12 2004
From: janina at rednote.net (Janina Sajka)
Date: Mon, 24 May 2004 15:59:12 -0400
Subject: The Fedora Hardware Project
In-Reply-To: <20040524170408.GB19161@devserv.devel.redhat.com>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
Message-ID: <20040524195912.GG18881@rednote.net>

It's rather upsetting to read about extensions to firstboot. It's 100% inaccessible, you know. Bad, very bad.

Current advice to users with accessibility concerns installing FC2 are to access Console 2 and chkconfig it off before booting the installation.

This has been previously reported of course, but I haven't heard of any plan to fix this. Is there one?

Alan Cox writes:
> On Sun, May 23, 2004 at 07:19:41PM -0500, Scott Sloan wrote:
> > 3.) Some input and search code?
> > 
> > 4.) Anything else?
> 
> Some planning is needed on the backend to capture the data. It might be
> nice for FC3 to allow anyone to submit their data automatically either
> by running an add on app for FC2 or integrating into firstboot for later
> releases
> 
> Is you can capture dmi data (bios, board, versions etc), ram size, I/O
> devices, pci devices etc, and search on all of those (eg by PCI vendor id)
> That would give a lot more correlation data for bugs for example.
> 
> [Given 50 samples you can meaningfully make assertions like "XYZ hw has
> a direct relationship with hanging"]
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

		Chair, Accessibility Workgroup
	Free Standards Group (FSG)

Email: janina at afb.net		Phone: (202) 408-8175




From b.j.smith at ieee.org  Mon May 24 20:04:12 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Mon, 24 May 2004 16:04:12 -0400
Subject: Reduce "Core" to 1 Binary CD? -- Don't change Core, but make
	CD #1 "standalone"
Message-ID: <1085429050.25327.2.camel@bitman.oviedo.smithconcepts.com>

[ BTW, should this be on "users" instead?  My apologies if so. ]

I've seen a lot of good arguments here, from many angles.  The fact that
people don't have high-speed connections, the issues with moving stuff
to Extras, etc...

Basically, what I'm saying is that we probably should touch "Core." 
What is in "Core" is done.  There is no sense trying to remove bloat. 
We're just going to run into dependency hell.

But at what point shouldn't be consider maybe making a "Core subset"?
One that fits on a single CD.  It would not only be a standalone CD, but
it would also be Fedora Core CD #1 itself.

Surely we could fit a lot of functionality on a single CD.  Just the
basic utilities, X, GNOME and a few other things.  Just enough to get up
and running.  For those of us that might have a fast Internet
connection.  Or maybe we just want a "bare bones" install.

Heck, it might simply distribution altogether.  You'd just have:
1 CD Version:  Fedora Quark (or whatever you'all call it)
1 DVD Version:  Fedora Core (Quark CD #1 + all other CDs)

And for those that want the full CD set, the DVD version would include a
script to remaster all into CDs.  That way Red Hat could expedite
pushing to mirrors with a _single_ DVD .iso, that is then remastered
into both the CD .isos and ./os directories locally with that script.

Imagine all the reduced traffic.  And now some mirrors might just have
"Quark" instead of the full "Core," for users that do want to pull their
own, select packages.

Just an idea.  It could solve a lot of issues.


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org




From jspaleta at gmail.com  Mon May 24 20:05:08 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 24 May 2004 16:05:08 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages
	in Fedora Core 3
In-Reply-To: <40B25124.7080406@wilcoxon.org>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>	<1085405894.12719.12.camel@delerium.codemonkey.org.uk>	<20040524134625.GA703705@hiwaay.net>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
	<40B25124.7080406@wilcoxon.org>
Message-ID: <604aa79104052413056a928d33@mail.gmail.com>

On Mon, 24 May 2004 14:46:44 -0500, Elliott Wilcoxon
<elliott at wilcoxon.org> wrote:
> 
> Would the following scenario be possible?  FC(n+1) is released, small
> Core, large Extras.  Apt/yum repos go up with the new stuff.

A lot of discussion and ideas seems to center around being able to do
further upgrades cleanly, assuming a network connection.  I have no
problem
with saying that yes...from now on fedora is going to demand that you
have broad band connectivity to do clean upgrades or installs. But if
thats going to be the case...lets just stop pretending that media sets
are important moving forward and wasting all this trouble screwing
around with installable media sets altogether.  If thats not going to
be the case... we need to think hard about how to do clean upgrades
using media sets where network connectivity is assumed.

I point to the vendors pages at fedora,redhat.com where vendors are
selling pressed install media as evidence of the importance of making
sure upgrades paths exist that do not invovle downloading potential 4
gigs of information to each client machine and then burning isos to
disk locally on client machines.  Doing the sort of customized iso
burning you are talking about seems great for people who have the
bandwidth to do it...but those people have the bandwidth to do a
network based install already they dont need custom isos.  And i think
the bittorrent lesson for fc2 release has some lesson about how
effective this sort of client side iso creation is going to be..on
release week. Pushing a bundle of pre-cooked isos around via torrent
is going to scale MUCH better than everyone trying to pull custom
package collection from the mirrors...ugh the first release to see
that option...im hiding that whole release week while people complaing
about not being able to get all their custom packages from the mirrors
due to mirror load.


If everything moving forward demands highband network connectivity to
be at all useful, then lets just state that and throw away isosets
altogether....in a world like that all we need is rescuecd.iso and the
restt can sit in a repo somewhere.


-jef




From jspaleta at gmail.com  Mon May 24 20:12:46 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 24 May 2004 16:12:46 -0400
Subject: The Fedora Hardware Project
In-Reply-To: <20040524195912.GG18881@rednote.net>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
Message-ID: <604aa79104052413124388efd9@mail.gmail.com>

On Mon, 24 May 2004 15:59:12 -0400, Janina Sajka <janina at rednote.net> wrote:
> This has been previously reported of course, but I haven't heard of any plan to fix 
> this. Is there one?

I strongly suggest that you put together a group of community people
interested in
addressing accessibility issues who can prioritize the accessibility
issue and create a roadmap towards full distribution accessibility
over a several release timescale and who can provide assistance to
fedora packagers and upstream project maintainers.  An accessibility
working group as a subcommunity group could be a very helpful thing,
especially if they organized a roadmap and systematically help
developers address accessibility issues in an organized way.

-jef




From csm at redhat.com  Mon May 24 20:29:35 2004
From: csm at redhat.com (Chuck Mead)
Date: Mon, 24 May 2004 16:29:35 -0400
Subject: Interested to help....
In-Reply-To: <40B252C0.5020700@daimi.au.dk>
References: <40B252C0.5020700@daimi.au.dk>
Message-ID: <40B25B2F.3010504@redhat.com>

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

kbn at daimi.au.dk wrote:
| Hi...
|
| To be short, I would like to participate in the development of new
| Fedora Releases...
| I primary got experience in building new rpm packages and maintaining
| them, and I have some experience in overall system administration... But
| I'm also interested in learning new aspects of Linux, even though I'm
| not a newbie to Linux...
|
| I didn't know how to announce my interest other places than here, so I
| hope it's apropriate... And i hope that there will be some tasks to do...
|
| Regards
| /kbn

Read the information here:

http://fedora.redhat.com/participate/

- --
Chuck Mead <csm at redhat.com>
Instructor II (and resident Postfix bigot), GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAslsvZfy0juH51WsRAnUZAJ9zQ4nJxVxlyMKO+XpPfC0oX5Fo6gCgi4QF
SzhzkMyAt/8pDDaei4UZDfo=
=h5Ha
-----END PGP SIGNATURE-----




From pmatilai at welho.com  Mon May 24 20:32:06 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Mon, 24 May 2004 23:32:06 +0300
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <or3c5pr551.fsf@free.redhat.lsd.ic.unicamp.br>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
	<200405250036.21757.dennis@ausil.us> <1085417367.12347.57.camel@roque>
	<or3c5pr551.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <1085430726.29155.1.camel@weasel.net.laiskiainen.org>

On Mon, 2004-05-24 at 22:34, Alexandre Oliva wrote:
> On May 24, 2004, Rui Miguel Seabra <rms at 1407.org> wrote:
> 
> >   Can one simply mount, say...
> 
> > /mnt/rec/FC2-i386-isos/FC2-i386-disc1.iso
> >    /var/ftp/pub/fc2/disc1 auto    defaults,loop=/dev/loop0 0 0
> 
> > /mnt/rec/FC2-i386-isos/FC2-i386-disc2.iso
> >    /var/ftp/pub/fc2/disc2 auto    defaults,loop=/dev/loop1 0 0
> 
> > /mnt/rec/FC2-i386-isos/FC2-i386-disc3.iso
> >    /var/ftp/pub/fc2/disc3 auto    defaults,loop=/dev/loop2 0 0
> 
> > /mnt/rec/FC2-i386-isos/FC2-i386-disc4.iso
> >    /var/ftp/pub/fc2/disc4 auto    defaults,loop=/dev/loop3 0 0
> 
> > and then point askmethod to ftp://server/pub/fc2/ ?
> 
> I don't think so.  That would be nice very though.

I think that's been supported for quite a while now. From anaconda's
install-methods.txt:

- FTP/HTTP (from a directory of loopback-mounted ISOs)
------------------------------------------------------
 
  Summary:
      Pulls files from tree via FTP.  Looks in 'disc1/' directory to
contain files from CD #1, 'disc2/' for CD #2, etc.  These can be created
on the server by loopback mounting the ISO images into these directories
under the directory made available to ftp.

	- Panu -




From rms at 1407.org  Mon May 24 20:47:46 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Mon, 24 May 2004 21:47:46 +0100
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085430726.29155.1.camel@weasel.net.laiskiainen.org>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
	<200405250036.21757.dennis@ausil.us> <1085417367.12347.57.camel@roque>
	<or3c5pr551.fsf@free.redhat.lsd.ic.unicamp.br>
	<1085430726.29155.1.camel@weasel.net.laiskiainen.org>
Message-ID: <1085431666.2690.6.camel@roque>

On Mon, 2004-05-24 at 23:32 +0300, Panu Matilainen wrote:
> I think that's been supported for quite a while now. From anaconda's
> install-methods.txt:
> 
> - FTP/HTTP (from a directory of loopback-mounted ISOs)
> ------------------------------------------------------
>  
>   Summary:
>       Pulls files from tree via FTP.  Looks in 'disc1/' directory to
> contain files from CD #1, 'disc2/' for CD #2, etc.  These can be created
> on the server by loopback mounting the ISO images into these directories
> under the directory made available to ftp.

But does it work?

I mean, I had heard the rumour (and didn't read the file), hence the
discN names I used :).

However, when I tried to use it, it started something, and then ... just
stopped.

Rui
-------------- 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/20040524/66884bca/attachment.sig>

From alan at redhat.com  Mon May 24 21:16:01 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 24 May 2004 17:16:01 -0400
Subject: The Fedora Hardware Project
In-Reply-To: <20040524195912.GG18881@rednote.net>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
Message-ID: <20040524211601.GA17868@devserv.devel.redhat.com>

On Mon, May 24, 2004 at 03:59:12PM -0400, Janina Sajka wrote:
> Current advice to users with accessibility concerns installing FC2 are to access Console 2 and chkconfig it off before booting the installation.
> 
> This has been previously reported of course, but I haven't heard of any plan to fix this. Is there one?

I don't know but I would hope there is. Its clearly important.




From alan at redhat.com  Mon May 24 21:18:08 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 24 May 2004 17:18:08 -0400
Subject: The Fedora Hardware Project
In-Reply-To: <604aa79104052413124388efd9@mail.gmail.com>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
Message-ID: <20040524211808.GB17868@devserv.devel.redhat.com>

On Mon, May 24, 2004 at 04:12:46PM -0400, Jeff Spaleta wrote:
> working group as a subcommunity group could be a very helpful thing,
> especially if they organized a roadmap and systematically help
> developers address accessibility issues in an organized way.

That has been going on for some time. Sun in particular did a lot of heavy
lifting to get core accessibility functionality into the desktop and the
toolkits.




From davej at redhat.com  Mon May 24 21:37:08 2004
From: davej at redhat.com (Dave Jones)
Date: Mon, 24 May 2004 22:37:08 +0100
Subject: submount?
In-Reply-To: <200405241448.14725.ndbecker2@verizon.net>
References: <200405241448.14725.ndbecker2@verizon.net>
Message-ID: <1085434628.8116.3.camel@delerium.codemonkey.org.uk>

On Mon, 2004-05-24 at 19:48, Neal Becker wrote:

> I discovered submount when testing suse-9.1.  First, let me say, that 
> something like this is really needed for a non-geek desktop linux system.  
> Users expect that when they insert a CD it will be mounted, and that this 
> would work "out of the box".
> 
> I don't know if submount is the "best" way to make this happen or not, 
> although I think maybe it is.

"Warning:Submount is still under development.   It has had moderate
testing so far.   If it crashes your system, destroys your data, or
causes your computer to go mad and try to murder you, the author is not
responsible"

"SuSE was the first major distribution to include submount, and now is
the first to use it in the standard installation. (Now I get to find out
if millions of users expose bugs that haven't come to light yet. Yes, I
am paranoid.)"

This *really* fills me with confidence.  That and the fact it's had
no upstream (linux-kernel) review whatsoever.

	Dave




From rms at 1407.org  Mon May 24 20:45:37 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Mon, 24 May 2004 21:45:37 +0100
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <40B246BF.9050604@arcamax.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085407033.28367.0.camel@opus>	<604aa791040524073015794298@mail.gmail.com>
	<200405250036.21757.dennis@ausil.us> <1085417367.12347.57.camel@roque>
	<40B246BF.9050604@arcamax.com>
Message-ID: <1085431537.2690.3.camel@roque>

On Mon, 2004-05-24 at 15:02 -0400, Bryan White wrote:
> Rui Miguel Seabra wrote:
> > On Tue, 2004-05-25 at 00:36 +1000, Dennis Gilmore wrote:
> >>would be really neat  is to specify a location  say a nfs share that has the 
> >>iso images and the package installer i.e yum, apt, or up2date could mount 
> >>that isos  and get the packages off  without having to make a package tree
> > 
> > This reminds me of a doubt I have:
> >   Can one simply mount, say...
> > 
> > /mnt/rec/FC2-i386-isos/FC2-i386-disc1.iso
> >    /var/ftp/pub/fc2/disc1 auto    defaults,loop=/dev/loop0 0 0
> > (...)
> > 
> > and then point askmethod to ftp://server/pub/fc2/ ?
> > 
> > Is this possible, or something like it?
> 
> I don't know if the installer can read the ISOs like that.  Here is what 
> I did:
> ----
> mkdir /home/mirrors/FC2
> mkdir iso
> mount FC2-i386-disc1.iso iso -t iso9660 -o loop=/dev/loop3
> cp -a iso/* /home/mirrors/FC2

erms... the purpose being using the original iso's and not wasting the
double of the space? :)

Rui
-------------- 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/20040524/3c7151a7/attachment.sig>

From janina at rednote.net  Mon May 24 21:53:10 2004
From: janina at rednote.net (Janina Sajka)
Date: Mon, 24 May 2004 17:53:10 -0400
Subject: The Fedora Hardware Project
In-Reply-To: <604aa79104052413124388efd9@mail.gmail.com>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
Message-ID: <20040524215310.GJ18881@rednote.net>

Thanks, Jef. I do agree with this. We've begun moving in this direction.

1.)	There are several activities listed for Free Standards Group Accessibility that are related.

2.)	Over the weekend I've initiated conversation between those of us (like me) who use the Speakup screen reader, and the maintainer of brltty regarding merging our activity. In the short term the goal would be to support both braille and speech users through one set of HOWTO documents and one tweaked distribution. The longer term goal would be to add other specific needs and road map them as you suggest. This activity would be FC specific, but should provide generalizable guidance to the FSG work as well.

Hopefully, I've made some sense in this. I will post here from time to time on this if folks are interested.

Jeff Spaleta writes:
> On Mon, 24 May 2004 15:59:12 -0400, Janina Sajka <janina at rednote.net> wrote:
> > This has been previously reported of course, but I haven't heard of any plan to fix 
> > this. Is there one?
> 
> I strongly suggest that you put together a group of community people
> interested in
> addressing accessibility issues who can prioritize the accessibility
> issue and create a roadmap towards full distribution accessibility
> over a several release timescale and who can provide assistance to
> fedora packagers and upstream project maintainers.  An accessibility
> working group as a subcommunity group could be a very helpful thing,
> especially if they organized a roadmap and systematically help
> developers address accessibility issues in an organized way.
> 
> -jef
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

		Chair, Accessibility Workgroup
	Free Standards Group (FSG)

Email: janina at afb.net		Phone: (202) 408-8175




From strange at nsk.no-ip.org  Mon May 24 22:28:56 2004
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Mon, 24 May 2004 23:28:56 +0100
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <40B246BF.9050604@arcamax.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
	<200405250036.21757.dennis@ausil.us>
	<1085417367.12347.57.camel@roque> <40B246BF.9050604@arcamax.com>
Message-ID: <20040524222856.GA2099@nsk.no-ip.org>

On Mon, May 24, 2004 at 03:02:23PM -0400, Bryan White wrote:
> cp -a iso/* /home/mirrors/FC2

I use cp -as ... It creates symbolic links instead of file copies. :)

Regards,
Luciano Rocha




From aoliva at redhat.com  Mon May 24 22:52:33 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 24 May 2004 19:52:33 -0300
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <40B246BF.9050604@arcamax.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
	<200405250036.21757.dennis@ausil.us> <1085417367.12347.57.camel@roque>
	<40B246BF.9050604@arcamax.com>
Message-ID: <orhdu5phe6.fsf@free.redhat.lsd.ic.unicamp.br>

On May 24, 2004, Bryan White <bryan at arcamax.com> wrote:

> I don't know if the installer can read the ISOs like that.

It can read them if they're all in the same readable directory.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From aoliva at redhat.com  Mon May 24 23:00:37 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 24 May 2004 20:00:37 -0300
Subject: Reduce "Core" to 1 Binary CD? -- Don't change Core,
	but make CD #1 "standalone"
In-Reply-To: <1085429050.25327.2.camel@bitman.oviedo.smithconcepts.com>
References: <1085429050.25327.2.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <or7jv1ph0q.fsf@free.redhat.lsd.ic.unicamp.br>

On May 24, 2004, "Bryan J. Smith" <b.j.smith at ieee.org> wrote:

> Surely we could fit a lot of functionality on a single CD.  Just the
> basic utilities, X, GNOME and a few other things.  Just enough to get up
> and running.

As in, make the installer one of the applications of a Fedora Core
Live CD?  First thing it does is to copy the contents of its root
filesystem to the chosen root filesystem (should be faster than
`rpm'ing around lots and lots of packages, and saves CD space!), then
enables the user to select additional packages to install/remove.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From chabotc at 4-ice.com  Tue May 25 00:07:14 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Tue, 25 May 2004 02:07:14 +0200
Subject: Reduce "Core" to 1 Binary CD? -- Don't change Core,
	but make CD #1 "standalone"
References: <1085429050.25327.2.camel@bitman.oviedo.smithconcepts.com>
	<or7jv1ph0q.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <002901c441ec$3bdf6540$0200a8c0@gandalf>

> As in, make the installer one of the applications of a Fedora Core
> Live CD?  First thing it does is to copy the contents of its root
> filesystem to the chosen root filesystem (should be faster than
> `rpm'ing around lots and lots of packages, and saves CD space!), then
> enables the user to select additional packages to install/remove.

Actually rpm packages compress the binary payload (gzip default,
configurable for bzip2), so uncompressed on cd storage would require more
space. Secondly cd read speed is slower (presumably) then your HD write
speed, so extracting & writing files should be faster then copying them
straight from cd.

However most importantly: While 'blow over all the files without doing that
fancy rpm stuff' sounds good in theory, did you ever think about how this
would work if you wanted to upgrade your fedora instalation? Using the 'just
copy' method this wouldnt be posible anymore, or wreck absolute havoc on
your dependencies. (And making seperate 'upgrade' and 'install' cd's would
be a nightmare, so would be upgrading between releases using yum since that
doesnt do all that anaconda does, and/or ppl might not have a fast internet
connection, etc etc)

    -- Chris




From b.j.smith at ieee.org  Tue May 25 00:41:32 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Mon, 24 May 2004 20:41:32 -0400
Subject: Making Fedora Core CD #1 Standalone -- WAS: Reduce "Core" to 1
	Binary CD?
Message-ID: <1085445692.25327.152.camel@bitman.oviedo.smithconcepts.com>

[ Yes, I'm renaming the subject yet again ;-]

Alexandre Oliva wrote:  
> As in, make the installer one of the applications of a Fedora Core
> Live CD?  First thing it does is to copy the contents of its root
> filesystem to the chosen root filesystem (should be faster than
> `rpm'ing around lots and lots of packages, and saves CD space!), then
> enables the user to select additional packages to install/remove.

Oh, no.  I don't think I was saying that at all.  Doing a "Live!" CD
would only bloat the sucker, while adding additional engineering
effort.

What I'm proposing is just:  
  1.  A careful re-evaluation of the "essential" components
  2.  These components go on Fedora Core CD #1,
       which can _now_ be standalone (you only need CD #1)

That's _all_ I'm suggesting.  All it takes is some careful decision
making regarding packages, but *0* re-engineering effort.  At most,
there would just need to be some checking that _nothing_ on CD #1
has any dependencies on any other "Core" CDs.

Maybe I only confused people by calling it "Quark" or "miniCore."
In a nutshell, I'm just talking about making Fedora Core CD #1
standalone -- that's all!

But if careful planning is required, then we _might_ need to add
a 6th repository guideline (I call it "Quark" by call it whatever):

                   Dependency Limitations
  Quark:    Quark
    Core:  Quark, Core
 Extras:   Quark, Core, Extras
    ... etc ...

We'll still have "Core" for Legacy Red Hat Linux (RHL) and all its
dependencies.  But sooner or later (hopefully sooner), it would be
nice to define a "smaller Core" -- one that amounts to less than
500MB compressed would be ideal (fits on a single CD).  Let us
aim for just basic client functionality using X+GNOME (and minimal
at that!).

I call this Fedora "Quark" for repository/dependency arguments
sake (call it what you will in the finale).

Fedora "Core" should continue to be developed, as-is, as the RHL
replacement.  Quark will be a part of Core.  But Quark will offer a
"reduced package list" that has self-only dependency, just like
Core is to Core, Extra to Extras, etc...

[ BTW, someone could certainly make a "Live" version of Fedora Core
CD #1, but I'm not suggesting the Fedora team head that up.  There
are plenty of people who could do this after-the-fact.  In fact,
something like "Quark" should be defined in the first place _before_
someone comes up with a "Live" CD.  But a Live CD is something else
entirely. ]

Chris Chabot wrote:  
> Actually rpm packages compress the binary payload (gzip default,
> configurable for bzip2), so uncompressed on cd storage would require
> more space. Secondly cd read speed is slower (presumably) then your
> HD write speed, so extracting & writing files should be faster then
> copying them straight from cd.

Just to re-iterate, I was not talking about a Live CD.  That's not
related to my recomendation for a "subset" of Core that weighs
in at less than 500MB, has 0 dependencies on anything else, and would
ideally be CD #1 in Fedora Core itself.



-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From chabotc at 4-ice.com  Tue May 25 01:23:11 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Tue, 25 May 2004 03:23:11 +0200
Subject: Making Fedora Core CD #1 Standalone -- WAS: Reduce "Core" to
	1Binary CD?
References: <1085445692.25327.152.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <001501c441f6$d817dfa0$0200a8c0@gandalf>

Bryan J. Smith wrote:
> Just to re-iterate, I was not talking about a Live CD.  That's not
> related to my recomendation for a "subset" of Core that weighs
> in at less than 500MB, has 0 dependencies on anything else, and would
> ideally be CD #1 in Fedora Core itself.

Actually that makes me wonder though what this 'core' is of fedora.

I've seen this core concept mentioned many times in this thread, and most
ppl do seem enthusiastic about the concept (though there are obvious bariers
to overcome, problems to solve etc). However i haven't seen anyone explain
what -they- see as a core.

A xorg, gnome basics, system-config-packages etc is all nice and dandy, but
ppl who want to setup a server without X would not be pleased by this system
at all.

Or if was a workstation, and the core CD only had those core apps, wouldnt
you always need the extra's cd's? (for say openoffice, mozilla, or whatever
is needed)

Another question, is there a seperate development cd? (auto*, gcc*
kernel-source, etc), or is that considered core functionality?




From b.j.smith at ieee.org  Tue May 25 02:35:03 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Mon, 24 May 2004 22:35:03 -0400
Subject: Making Fedora Core CD #1 Standalone -- Core should continue,
	but let's define a subset
Message-ID: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>

Chris Chabot wrote:  
> Actually that makes me wonder though what this 'core' is of fedora.
> I've seen this core concept mentioned many times in this thread, and
> most ppl do seem enthusiastic about the concept (though there are
> obvious bariers to overcome, problems to solve etc). However i
> haven't seen anyone explain what -they- see as a core.

Well, I'm sure I have confused many.
To start, let me tell you what I think, and where I am coming from.

1.  I consider Fedora Core to be Red Hat Linux
2.  Fedora Core will bloat to 5, 6 and more CDs

As such, all the legacy needs to be in it, along with anything new.
There is no way to avoid this, without breaking compatibility and
assumptions.  Is it a bad thing?  That's debateable.  There is much
good to adding more and more as part of the "full" install,
Scribus, OpenGroupware.org (OGo), Firefox/Thunderbird, etc...

Now many have suggested, heck I even started out by taking Pritchard's
post, about "rolling back" the size of Fedora Core.  Talk of moving
things to Extras, or elsewhere.  But by the very nature of Core v.
Extras, there may be legacy/compatibility issues to consider.  And
as many have stated, there is the fact that some people want a
full install from media, since Internet bandwidth is still a
premium in many parts of the US (let alone many places  outside the US).

So what I'm considering is not touching Core itself.  Instead, let's
define the "absolute minimum" of Core.  If we can do this by making
sure it is the CD #1 in Core, then it will have minimal impact.  If
we need to do it by defining a set of "rules" -- maybe a "sub-
repository" that is still part of Core, but has the contraints that
no package requires any additional Core packages not in it, then
let's do it.  I proposed the name "miniCore" or "Quark," but that's
just a temporary reference I make.

So, onto defining what is in "Quark" ...

> A xorg, gnome basics, system-config-packages etc is all nice and
> dandy, but ppl who want to setup a server without X would not be
> pleased by this system at all.
> Or if was a workstation, and the core CD only had those core apps,
> wouldnt you always need the extra's cd's? (for say openoffice,
> mozilla, or whatever is needed)

It's hard to "please everyone."  Let's not try to break up Fedora
Core into different CDs for different users.  That's a headache
that will only add to the burden.  I'm all about minimizing the
packaging burden.  Besides, with Fedora's new, distributed nature,
it is not necessary.

No, what I'm talking about is _ultra_basic_ stuff.  A basic server.
A basic workstation.  _No_ applications.  _No_ feature rich services.

You get X and GNOME, *0* apps.  Not even the standard GNOME app spread.
You get basic services, enough for a basic file, print or web server,
but with _no_ riches.

And we _really_ need to start defining the _basic_ scripting support
required in Perl, Python and/or PHP, etc...  Otherwise, the bloat is
only going to get worst in packages.  Yes, it's hard to do it now, but
let's at least _define_ the "recommendations," like Debian did long
ago.

For example, packages that require Emacs _only_ because it runs some
Lisp or other interface for just the package script -- stuff like that
has just got to end.  Now we can't do it overnight with Core.  Trying to
do so would only break compatibiltiy and cause additional re-engineering
headaches.

But by defining a new set of rules for including in "Quark," we
can lay a new foundation.  If you're going to be part of the "Quark"
cornerstone of Fedora, you have to adhere to X, Y and Z.  It won't
happen overnight, but luckily we can start by making Quark minimal
in design.

I'm sure in 3-5 years, Quark will bloat, and then we'll need a
"sub-Quark" to refresh it.  As you may note, the idea here is not to
"reduce" Core, but to slowly replace it with a smaller standard.
Because things bloat.  God, if there is one "bad habit" the social
design has, it is the tendency to add yet more and more and more
until many people forget about various things available (there is
no more proof than that the ultimate social design, governments ;-).

So the "workaround" is to let what exists be, but slowly move
people towards a new, smaller version.

> Another question, is there a seperate development cd? (auto*, gcc*
> kernel-source, etc), or is that considered core functionality?

Again, let's not over-complicate this.  Remember, I'm all about
_minimal_impact_ and _minimal_re-engineering_ effort.

In a nutshell, let's just let "Core" be as it is.  A slowly bloating
reference.  With Apt/Yam, we can yank what we need over the Internet.
For those with limited bandwidth, well, they'll just want the full Core.

But for those that want to "start simple," that's what Quark will be.
At least until 3-5 years later when Quark has now bloated.  ;-ppp

Ahhh, someone could write a thesis on the natural occurrance of
bloat in software distribution!  The key is to not fight the bloat,
as that only breaks compatibility and assumptions.  The key is to
introduce a new, smaller distribution until it bloats, and then
another, etc...

So I'm suggesting we do that with "Quark."  A sub-set of Core that
is just enough to get a basic file/print/web server running, or a
X workstation with just the bare GNOME interface.  Nothing more.


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From gauret at free.fr  Tue May 25 06:40:50 2004
From: gauret at free.fr (Aurelien Bompard)
Date: Tue, 25 May 2004 08:40:50 +0200
Subject: submount?
References: <200405241448.14725.ndbecker2@verizon.net>
Message-ID: <c8uppe$k1o$1@sea.gmane.org>

> I don't know if submount is the "best" way to make this happen or not,
> although I think maybe it is.
> 
> I'd like to start a discussion on this topic.

Mandrake has abandoned supermount in their latest distro (10.0) IIRC. The
project continues here: http://supermount-ng.sourceforge.net
This version is probably much more tested than submount.

Aur?lien
-- 
http://gauret.free.fr   ~~~~   Jabber : gauret at amessage.info
For external use only





From arjanv at redhat.com  Tue May 25 06:56:38 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Tue, 25 May 2004 08:56:38 +0200
Subject: submount?
In-Reply-To: <c8uppe$k1o$1@sea.gmane.org>
References: <200405241448.14725.ndbecker2@verizon.net>
	<c8uppe$k1o$1@sea.gmane.org>
Message-ID: <1085468198.2783.4.camel@laptop.fenrus.com>

On Tue, 2004-05-25 at 08:40, Aurelien Bompard wrote:
> > I don't know if submount is the "best" way to make this happen or not,
> > although I think maybe it is.
> > 
> > I'd like to start a discussion on this topic.
> 
> Mandrake has abandoned supermount in their latest distro (10.0) IIRC.

for a reason; supermount seems to be unfixable on a fundamental level ;(

The problem it tries to solve is hard. It will require fundamental
kernel changes to get right I fear, and just trying to paper over the
underlying kernel with a small module ain't gonna fix it, it will remain
just papering over ;(

-------------- 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/20040525/227d2b7c/attachment.sig>

From alan at redhat.com  Tue May 25 07:23:08 2004
From: alan at redhat.com (Alan Cox)
Date: Tue, 25 May 2004 03:23:08 -0400
Subject: submount?
In-Reply-To: <1085468198.2783.4.camel@laptop.fenrus.com>
References: <200405241448.14725.ndbecker2@verizon.net>
	<c8uppe$k1o$1@sea.gmane.org>
	<1085468198.2783.4.camel@laptop.fenrus.com>
Message-ID: <20040525072308.GC5395@devserv.devel.redhat.com>

On Tue, May 25, 2004 at 08:56:38AM +0200, Arjan van de Ven wrote:
> The problem it tries to solve is hard. It will require fundamental
> kernel changes to get right I fear, and just trying to paper over the
> underlying kernel with a small module ain't gonna fix it, it will remain
> just papering over ;(

Or user space 8). volumagic proves you can do it that way for only a small
hit




From kaboom at gatech.edu  Tue May 25 02:15:57 2004
From: kaboom at gatech.edu (Chris Ricker)
Date: Mon, 24 May 2004 22:15:57 -0400 (EDT)
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <1085348389.12538.4.camel@mentor.gurulabs.com>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar>
	<1085348389.12538.4.camel@mentor.gurulabs.com>
Message-ID: <Pine.GSO.4.58.0405242207380.26413@redfish.gatech.edu>

On Sun, 23 May 2004, Dax Kelson wrote:

> Ummm, because it's compiled as a module so you are free to not load it
> without a kernel recompile.
> 
> To prevent the autoloading, run the command:
> 
> echo "NETWORKING_IPV6=no" >> /etc/sysconfig/network

The scripts look like they try to do that, but it doesn't actually work.  
With "NETWORKING_IPV6=no" in /etc/sysconfig/network, the IPv6 module still
autoloads and link-local addresses are still automagically assigned.

I've not yet had time to investigate and see why it's not working.

later,
chris




From buildsys at redhat.com  Tue May 25 12:22:16 2004
From: buildsys at redhat.com (Build System)
Date: Tue, 25 May 2004 08:22:16 -0400
Subject: rawhide report: 20040525 changes
Message-ID: <200405251222.i4PCMGJ16732@porkchop.devel.redhat.com>

New package mod_authz_ldap
	LDAP authorization module for the Apache HTTP Server


Removed package bluez-sdp

Removed package bluez-pan

Updated Packages:

cdrdao-1.1.8-4
--------------
* Wed Apr 14 2004 Harald Hoyer <harald at redhat.com> - 1.1.8-4

- fixed BuildRequires

distcache-1.4.5-4
-----------------
* Mon May 17 2004 Joe Orton <jorton at redhat.com> 1.4.5-4

- run ldconfig in %post and %postun

* Sun May 02 2004 Joe Orton <jorton at redhat.com> 1.4.5-3

- add BuildRequires: openssl-devel (#122265)

gmp-4.1.3-1
-----------
* Mon May 24 2004 Thomas Woerner <twoerner at redhat.com> 4.1.3-1

- new version 4.1.3

iiimf-le-xcin-0.1.5-2
---------------------
* Fri May 21 2004 Leon Ho <llch at redhat.com> 0.1-5-2

- backport from cvs
    - fixed the problem on ctrl, alt keys when turned on (#121050)
    - added new candidate selection screen (shift+< and shift+>)

kernel-2.6.6-1.381
------------------
* Mon May 24 2004 Dave Jones <davej at redhat.com>

- Add yet another multi-card reader to the whitelist (#85851)

* Sun May 23 2004 Dave Jones <davej at redhat.com>

- Add another multi-card reader to the whitelist (#124048)

* Wed May 19 2004 Arjan van de Ven <arjanv at redhat.com>

- put firewire race fix in (datacorruptor)


pilot-link-0.11.8-4
-------------------
* Mon May 24 2004 Than Ngo <than at redhat.com> 1:0.11.8-4

- fix build problem with new libpng

qmkbootdisk-1.0.2-1
-------------------
* Mon May 24 2004 Than Ngo <than at redhat.com> 1.0.2-1

- release 1.0.2, fix build problem with qt,
  add missing KDE icon

rpmdb-fedora-2-0.20040525
-------------------------

tvtime-0.9.12-8
---------------
* Mon May 24 2004 Than Ngo <than at redhat.com> 0.9.12-8

- add another patch to enable PIE build of tvtime binary

* Mon May 17 2004 Than Ngo <than at redhat.com> 0.9.12-7

- add patch to enable PIE build

wl-2.10.1-3
-----------
* Fri May 21 2004 Jens Petersen <petersen at redhat.com> - 2.10.1-3

- update semi to 1.14.6
- semi-1.14.3-CAN-2003-0440.patch no longer needed
- rename some of the version variables in this file
- mention semi in the package description

zisofs-tools-1.0.4-5
--------------------
* Mon May 24 2004 Harald Hoyer <harald at redhat.com> - 1.0.4-5

- fixed BuildRequires (123771)




From zleite at mminternet.com  Tue May 25 02:57:10 2004
From: zleite at mminternet.com (Z)
Date: Mon, 24 May 2004 19:57:10 -0700
Subject: The return of the acute-cedilla BUG FROM HELL
In-Reply-To: <20040524215310.GJ18881@rednote.net>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
	<20040524215310.GJ18881@rednote.net>
Message-ID: <1085453830.4695.7.camel@z>

FC2 has again the bug on the us-acentos keymap. Pressing "'" + c gives
an non-existing symbol (at least non-existing in the languages I know)
instad of the cedilla.
I saw some bugs related to this in bugzilla. Shoud I file it anyway?
It seems to be a reversion from the xorg migration.




From jspaleta at gmail.com  Mon May 24 21:37:31 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 24 May 2004 17:37:31 -0400
Subject: The Fedora Hardware Project
In-Reply-To: <20040524211808.GB17868@devserv.devel.redhat.com>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
	<20040524211808.GB17868@devserv.devel.redhat.com>
Message-ID: <604aa79104052414374b7d9ac3@mail.gmail.com>

On Mon, 24 May 2004 17:18:08 -0400, Alan Cox <alan at redhat.com> wrote:
> 
> On Mon, May 24, 2004 at 04:12:46PM -0400, Jeff Spaleta wrote:
> > working group as a subcommunity group could be a very helpful thing,
> > especially if they organized a roadmap and systematically help
> > developers address accessibility issues in an organized way.
> 
> That has been going on for some time. Sun in particular did a lot of heavy
> lifting to get core accessibility functionality into the desktop and the
> toolkits.

But is there a community group that aims to press the accessibility issue beyond
the desktop? A group that has a battle plan and human expertise to
help to make the whole process from the moment you drop a cd into the
machine to start the install accessible?  I'm not aware of a community
group like that in general...and certaintly not a group of community
contributors focused on doing this for fedora specifically.  Right now
and it the past, it seems Janina expects for Red Hat to make
accessibility very important, as important as she makes it, and I
don't think that expectation is going to be realized unless someone
organizes community contributors into a dedicated group whose goal is
to tackle the accessibility question in a focused and organized way,
by providing assistance, feedback and code on accessibility issues
through the fedora distribution.

Accessibility is important, important enough to pull everyone who is
interested in making it work well together, giving them a roadmap and
putting them to work towards making fc6 completely accessible.

-jef




From jspaleta at gmail.com  Tue May 25 13:41:17 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 25 May 2004 09:41:17 -0400
Subject: Making Fedora Core CD #1 Standalone -- Core should continue,
	but let's define a subset
In-Reply-To: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>
References: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <604aa7910405250641781ef39c@mail.gmail.com>

On Mon, 24 May 2004 22:35:03 -0400, Bryan J. Smith <b.j.smith at ieee.org> wrote:
> So what I'm considering is not touching Core itself.  Instead, let's
> define the "absolute minimum" of Core.  If we can do this by making
> sure it is the CD #1 in Core, then it will have minimal impact.  If
> we need to do it by defining a set of "rules" -- maybe a "sub-
> repository" that is still part of Core, but has the contraints that
> no package requires any additional Core packages not in it, then
> let's do it.  I proposed the name "miniCore" or "Quark," but that's
> just a temporary reference I make.
> 
> So, onto defining what is in "Quark" ...


I really really really don't think you have to do something as
elaborate as this.
Just have people in the community who care about this issue work on
the comps.xml file definitions that define what a minimal install
includes and have those packages be part of cd1.  No reason to
formalize with lots and lots of policy.
This has come up repeatedly...and people in the community SEEM
interested but those people wander off the mailinglists and never
actually produce anything of usefulness. Look back in the pre-fc1
release discussions there are several threads about how to better
define a minimal install and the go no where...no where fast.
If you are serious about this...you will work on the comps.xml file
with other people who have an interest in a better defined minimal
install option.

-jef


> 
> > A xorg, gnome basics, system-config-packages etc is all nice and
> > dandy, but ppl who want to setup a server without X would not be
> > pleased by this system at all.
> > Or if was a workstation, and the core CD only had those core apps,
> > wouldnt you always need the extra's cd's? (for say openoffice,
> > mozilla, or whatever is needed)
> 
> It's hard to "please everyone."  Let's not try to break up Fedora
> Core into different CDs for different users.  That's a headache
> that will only add to the burden.  I'm all about minimizing the
> packaging burden.  Besides, with Fedora's new, distributed nature,
> it is not necessary.
> 
> No, what I'm talking about is _ultra_basic_ stuff.  A basic server.
> A basic workstation.  _No_ applications.  _No_ feature rich services.
> 
> You get X and GNOME, *0* apps.  Not even the standard GNOME app spread.
> You get basic services, enough for a basic file, print or web server,
> but with _no_ riches.
> 
> And we _really_ need to start defining the _basic_ scripting support
> required in Perl, Python and/or PHP, etc...  Otherwise, the bloat is
> only going to get worst in packages.  Yes, it's hard to do it now, but
> let's at least _define_ the "recommendations," like Debian did long
> ago.
> 
> For example, packages that require Emacs _only_ because it runs some
> Lisp or other interface for just the package script -- stuff like that
> has just got to end.  Now we can't do it overnight with Core.  Trying to
> do so would only break compatibiltiy and cause additional re-engineering
> headaches.
> 
> But by defining a new set of rules for including in "Quark," we
> can lay a new foundation.  If you're going to be part of the "Quark"
> cornerstone of Fedora, you have to adhere to X, Y and Z.  It won't
> happen overnight, but luckily we can start by making Quark minimal
> in design.
> 
> I'm sure in 3-5 years, Quark will bloat, and then we'll need a
> "sub-Quark" to refresh it.  As you may note, the idea here is not to
> "reduce" Core, but to slowly replace it with a smaller standard.
> Because things bloat.  God, if there is one "bad habit" the social
> design has, it is the tendency to add yet more and more and more
> until many people forget about various things available (there is
> no more proof than that the ultimate social design, governments ;-).
> 
> So the "workaround" is to let what exists be, but slowly move
> people towards a new, smaller version.
> 
> > Another question, is there a seperate development cd? (auto*, gcc*
> > kernel-source, etc), or is that considered core functionality?
> 
> Again, let's not over-complicate this.  Remember, I'm all about
> _minimal_impact_ and _minimal_re-engineering_ effort.
> 
> In a nutshell, let's just let "Core" be as it is.  A slowly bloating
> reference.  With Apt/Yam, we can yank what we need over the Internet.
> For those with limited bandwidth, well, they'll just want the full Core.
> 
> But for those that want to "start simple," that's what Quark will be.
> At least until 3-5 years later when Quark has now bloated.  ;-ppp
> 
> Ahhh, someone could write a thesis on the natural occurrance of
> bloat in software distribution!  The key is to not fight the bloat,
> as that only breaks compatibility and assumptions.  The key is to
> introduce a new, smaller distribution until it bloats, and then
> another, etc...
> 
> So I'm suggesting we do that with "Quark."  A sub-set of Core that
> is just enough to get a basic file/print/web server running, or a
> X workstation with just the bare GNOME interface.  Nothing more.
> 
> --
> Bryan J. Smith, E.I. -- b.j.smith at ieee.org
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>




From chabotc at 4-ice.com  Tue May 25 14:06:40 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Tue, 25 May 2004 16:06:40 +0200
Subject: A usefull tool (Was: Making Fedora Core CD #1 Standalone)
In-Reply-To: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>
References: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <40B352F0.6010009@4-ice.com>

Dep Tree 0.1 by Chris Chabot.
This program may be freely redistributed under the terms of the GNU GPL.

With all these discussions about making Fedora Core a core cd, ideas 
about what should or should not be included, i thought it might be easy 
to be able to quantify and experiment with package dependencies and 
package sizes so you can find out what can and can not fit on one CD.

This script takes a package or list of packages as command line 
argument, and recursivly walks the full dependency tree for that/those 
package(s) and calculates the packages size (size of the RPM's) and 
installed size (size on disk) for the packages.

It queries the rpm database using the rpm command line tool, so please 
only use the base package name (mozilla) and not the file name 
(mozilla-1.6-6.i386.rpm). Also note that since this tool only queries 
the rpm database, and doesn't write or change anything, so safe to play 
around with.

For example
  # ./dep-tree.php mozilla
    <.. shows the complete tree of all  the dep. packages & package sizes..>
  Number of packages: 66
  Total size installed: 165 Mb
  Total packaged size:  59 Mb

With this tool it's a lot easier to experiment with 'what if', and try 
out what the real impact is of including package XYZ in the core CD.

It can also take multiple packages on the command line, and will do a 
full dependency tree run for all those packages, so you could see how 
many packages, and what packaged size something like the packages 
"firstboot system-config-packages mozilla" would take up..

This script requires PHP and RPM to be installed to run. Save the 
attached dep-tree.php to disk and run by
  # chmod +x dep-tree.php
  # ./dep-tree.php
or
  # php -Cq ./dep-tree.php


Usage explained in detail: dep-tree.php [-d] [-r=path] package [package 
package]

package [package..]     List of packages to include in the dependency 
tree run, for example: "mozilla openoffice.org sendmail"

-d             Include the *-devel packages for all packages in the list 
(and it's dependencies). This is includes because i am a big fan of 
having a system that could build it's self, it's updates and any other 
source rpm's/tarbals you would download.

-r=/path   (For users who know what they are doing only!) Use 
--root=/path in all rpm commands. The rpm --root command allows you to 
query against a rpm database other then the standard location. This is 
usefull for if you want to play with all installed packages or packages 
you don't have installed in your normal setup without having to modify 
your existing setup by doing something like this (Note: Please please by 
all that is holy, don't forget to include --root=/fc2-tests in your rpm 
--initdb command, else you will NUKE, DELETE and DESTROY your rpm database!)
  # mkdir /fc2-test
  # rpm --initdb --root=/fc2-test
  # rpm -Uvh --root=/fc2-test --nomd5 --nodigest --nosignature --justdb 
/location/to/all/fc2/rpms/*.rpm


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dep-tree.php
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040525/65794dbe/attachment.ksh>

From b.j.smith at ieee.org  Tue May 25 14:06:56 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Tue, 25 May 2004 10:06:56 -0400
Subject: Making Fedora Core CD #1 Standalone -- Core should continue,
	but let's define a subset
Message-ID: <1085494015.19191.28.camel@bitman.oviedo.smithconcepts.com>

Jeff Spaleta wrote:  
> I really really really don't think you have to do something as
> elaborate as this.

Well, that depends.  (read on)

Eventually it _might_ be a good idea to define a "formal" subset.
But I see where you are leading this.

> Just have people in the community who care about this issue work
> on the comps.xml file definitions that define what a minimal
> install includes and have those packages be part of cd1.
> No reason to formalize with lots and lots of policy.

It seems that simple at first.  Unfortunately, there seems to be
a lot of "legacy" dependencies that bite you in the touche.

> This has come up repeatedly...and people in the community SEEM
> interested but those people wander off the mailinglists and never
> actually produce anything of usefulness.

And I can read between the frustration there.  Point taken.

There's nothing more distracting than a bunch of "dreamers" but
no "doers" -- I for one have been guilty of being in the former
9 times of out 10.

However, I have been doing little things like this since Red Hat
Linux (RHL) 7, and multiple CDs.  Packaging has been much of my
Linux epxerience.  And those "legacy" dependencies, one that don't
make sense -- lots of touche missing.  ;-ppp

I would like to start documenting some of them, as they exist
in Fedora Core 2.

> Look back in the pre-fc1 release discussions there are several
> threads about how to better define a minimal install and the go
> no where...no where fast. If you are serious about this...you
> will work on the comps.xml file with other people who have an
> interest in a better defined minimal install option.

And that's what I was interesting in.  Finding out who was
interesting in helping me.

I'm just curious on what happens if and when I start finding
"interesting" dependencies.  Who can I "report" them to
("devel" list or Bugzilla)?  At what point will there be
"changes" made -- if at all?

I guess I'll just wait to see those answer _after_ I start
producing more than just hot air, eh?  Thanx for your input,
and I _do_ understand where you are coming from.


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From chabotc at 4-ice.com  Tue May 25 14:13:56 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Tue, 25 May 2004 16:13:56 +0200
Subject: Making Fedora Core CD #1 Standalone -- Core should continue but
 let's define a subset
In-Reply-To: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>
References: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <40B354A4.1010202@4-ice.com>

Bryan J. Smith wrote:

>To start, let me tell you what I think, and where I am coming from.
>
>1.  I consider Fedora Core to be Red Hat Linux
>2.  Fedora Core will bloat to 5, 6 and more CDs
>
>As such, all the legacy needs to be in it, along with anything new.
>There is no way to avoid this, without breaking compatibility and
>assumptions.  Is it a bad thing?  That's debateable.  There is much
>good to adding more and more as part of the "full" install,
>Scribus, OpenGroupware.org (OGo), Firefox/Thunderbird, etc...
>  
>
This actually opens a whole new can of worms for the fedora project.. 
Most of these plans should really be split into 3 different repositories:
- Supported Core
- Support additional packages
- Unsupported additional packages

That way the core is a solid base on which to base everything else. The 
supported packages would be bugzilla'ble and would either be maintained 
by Redhat or by a trusted maintainer (who has earned this title and 
trust over time in the unsupported playground) and the unsupported would 
be a great place for well working packages that are not maintained by a 
trusted maintainer or redhat.

This way anyone can try to contribute packages (as u said, for things 
like OpenGroupWare.org, etc) and the maintainer can prove and show he 
can maintain, fix and support this contribution over time before it gets 
moved to 'officialy included'. in essence this follows the debian 
structure, packages are only included if there is a valid and trusted 
maintainer for them.

Reasoning for this is that it would be a _lot_ worse if there was a 
serious data-destroying bug or security compromising bug in a package 
that no one would fix (in a timely and correct fashion) then it would be 
to not include a package.





From jspaleta at gmail.com  Tue May 25 14:17:14 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 25 May 2004 10:17:14 -0400
Subject: A usefull tool (Was: Making Fedora Core CD #1 Standalone)
In-Reply-To: <40B352F0.6010009@4-ice.com>
References: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>
	<40B352F0.6010009@4-ice.com>
Message-ID: <604aa79104052507176a91419f@mail.gmail.com>

On Tue, 25 May 2004 16:06:40 +0200, Chris Chabot <chabotc at 4-ice.com> wrote:
> 
> Dep Tree 0.1 by Chris Chabot.
> This program may be freely redistributed under the terms of the GNU GPL.

Not trying to comment on your script or its usefulness...
Have you seen this?

rpm-analyzer? 
http://www.maisondubonheur.com/rpm-analyzer/

it does forward and reverse dep trees and supposedly handles comps.xml
groupings.

-jef




From chabotc at 4-ice.com  Tue May 25 14:37:48 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Tue, 25 May 2004 16:37:48 +0200
Subject: Making Fedora Core CD #1 Standalone -- Core should continue,
 but let's define a subset
In-Reply-To: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>
References: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <40B35A3C.9060902@4-ice.com>

Bryan J. Smith wrote:

>Now many have suggested, heck I even started out by taking Pritchard's
>post, about "rolling back" the size of Fedora Core.  Talk of moving
>things to Extras, or elsewhere.  But by the very nature of Core v.
>Extras, there may be legacy/compatibility issues to consider.
>  
>
This is indeed a big can of worms. To further complicate the matter, you 
always need to keep the upgrade path in mind to. If someone is running 
redhat 8,9, fedora core 1 or 2, they should be able to download the 
install cd's and upgrade their existing system.. This means a whole lot 
of packages _have_ to be included to provide compat-XYZ or newer 
versions of the already installed packages. This kind of means that 90% 
of the existing packages are automaticly tied in on the install cd's.

So with that in mind, what profit can still be gained by re-ordering 
packages around on cd's, and making minimal install cd's?

IMHO you could make the first cd a "Basic but relatively complete" 
install cd, which includes all basic apps, web browsers, basic services 
and server apps, yum, system-config-packages, etc; Which you could use 
to install a new functional and working Workstation, or Server installation.

The other (3) cd's would include all the other packages that are 
currently in fedora core 2, and should be listed and described in the 
comps / rpmdb-fedora packages.

Then if you do a clean install it would only use the first CD to do the 
basic install, run thru first-boot, and allow people to add additional 
packages from either the 3 extra's cd's (it would know where they are 
and ask for the correct cd by looking that up in the comps / 
rpmdb-fedora lists), or offer the option to download them from a 
selected mirror.

However if you do an upgrade using the first cd, it can use the 
knowledge of what packages are on what cd's to include those in the 
upgrade, and do a clean and sound upgrade (asking for those cd's as it 
does now).


As far as i can think off thats the only way to satisfy the upgrade 
cycle dependency, while allowing for a 1 core cd install.

Ofcource then the question becomes "What packages do we include on the 
core cd". To be able to play around with that question i've written a 
little tool in PHP which i've posted in a seperate email (Subject: A 
usefull tool (Was: Making Fedora Core CD #1 Standalone)).

You would be supprised at how much you can still include on the first 
CD.. With that tool you can show that all this paranoia about "Don't 
include any, *0* apps on the core CD" is being overly zealous..

Your able to fit quite a large collection of workstation and server 
packages on one CD.. The mix that i came up with playing with the 
dep-tree tool is:

./dep-tree.php -d firstboot system-config-packages mozilla yum rpm mdadm 
cups vixie-cron httpd samba jfsutils php perl usbutils isdn4k-utils 
irda-utils metacity gnome-desktop gnome-session gnome-panel compat-db 
compat-libstdc++ compat-glibc openssh openssh-server openssh-clients 
openldap samba screen magicdev openmotif xmms gedit lm_sensors ntp 
gnome-utils autofs setserial nmap mgetty stunnel curl eject 
nautilus-cd-burner nautilus-media lsof wget telnet ftp gnome-applets 
gftp openoffice.org gimp gaim links mkinitrd mktemp ttmkfdir mkbootdisk 
xpdf eog gcc autoconf automake15 autoconf213 automake automake14 make
Number of packages: 457
Total size installed: 1557 Mb
Total packaged size:  498 Mb

So this includes (i think) all the basic packages for a working linux 
instalation, qt/gnome/kde/motif compatiblity, mozilla, gimp, gaim, 
openoffice and lots of other workstation apps, and all required basic 
server apps (webserver, openssh, telnet, ftp, yum, nmap, screen, wget, 
links etc)

The nice thing of this is that the first CD can then offer 4 install modes:
- Basic Workstation
- Basic Server
- Both server and workstation software
- Minimal instalation (90 or so megs, already included in FC1/2)
[x] checkbox Include development packages and tools

While still offering a fully functional end result, and including all 
*-devel packages and compilers so the system is self-building and allows 
you to compile kernels, source rpm's or tarbals (imho it would go 
against the spirit of *nix / open source to have a system that could not 
compile software or it's self)

Then if they want all KDE apps, more server software, a slow of perl-* 
packages, databases, then the extra 3 cd's come into play (and/or 
external repositories)




From chabotc at 4-ice.com  Tue May 25 14:45:58 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Tue, 25 May 2004 16:45:58 +0200
Subject: A usefull tool (Was: Making Fedora Core CD #1 Standalone)
In-Reply-To: <604aa79104052507176a91419f@mail.gmail.com>
References: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>	<40B352F0.6010009@4-ice.com>
	<604aa79104052507176a91419f@mail.gmail.com>
Message-ID: <40B35C26.1080402@4-ice.com>

Yes i know the tool, but i wanted a simple approach and had most of this 
laying around anyhow.

It's also build with expantion in mind to actually write comps lists and 
posibly build the cd's

However thanks for pointing it out to the list, that is a nice tool indeed

    -- Chris

Jeff Spaleta wrote:

>On Tue, 25 May 2004 16:06:40 +0200, Chris Chabot <chabotc at 4-ice.com> wrote:
>  
>
>>Dep Tree 0.1 by Chris Chabot.
>>This program may be freely redistributed under the terms of the GNU GPL.
>>    
>>
>
>Not trying to comment on your script or its usefulness...
>Have you seen this?
>
>rpm-analyzer? 
>http://www.maisondubonheur.com/rpm-analyzer/
>
>it does forward and reverse dep trees and supposedly handles comps.xml
>groupings.
>
>-jef
>
>
>  
>

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

From katzj at redhat.com  Tue May 25 14:53:23 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 25 May 2004 10:53:23 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085417367.12347.57.camel@roque>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
	<200405250036.21757.dennis@ausil.us> <1085417367.12347.57.camel@roque>
Message-ID: <1085496803.8977.11.camel@bree.local.net>

On Mon, 2004-05-24 at 17:49 +0100, Rui Miguel Seabra wrote:
> This reminds me of a doubt I have:
>   Can one simply mount, say...
[snip]
> and then point askmethod to ftp://server/pub/fc2/ ?
> 
> Is this possible, or something like it?

Yes, just like that.  This functionality has been present since Red Hat
Linux 7.2, iirc.

Jeremy




From b.j.smith at ieee.org  Tue May 25 14:55:33 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Tue, 25 May 2004 10:55:33 -0400
Subject: Making Fedora Core CD #1 Standalone -- Core should continue
	but let's define a subset
Message-ID: <1085496933.19191.40.camel@bitman.oviedo.smithconcepts.com>

Chris Chabot wrote:  
> This actually opens a whole new can of worms for the fedora project..
> Most of these plans should really be split into 3 different
> repositories:
> - Supported Core
> - Support additional packages
> - Unsupported additional packages

Is that not Fedora "Core" "Extras" (and "Alternatives") and "3rd party"
now?  Why reproduce what _does_ work _now_?

I'm not questioning Red Hat's selection/repository as it is build atop
of Core.  And I'm not really even questioning Core itself.

I'm must saying that (as someone else pointed out), the "comps.xml"
could use some play.  That is where I have focused my efforts in the
past (from RHL 7 upward).

> That way the core is a solid base on which to base everything else.
> The supported packages would be bugzilla'ble and would either be
> maintained by Redhat or by a trusted maintainer (who has earned this
> title and trust over time in the unsupported playground) and the
> unsupported would be a great place for well working packages that are
> not maintained by a trusted maintainer or redhat.

But at some point Core is going to be overbloated (some said RHL 7 was
;-).  You get no argument from me behind the reasoning -- legacy/upward
compatibility.  But there should probably be an attempt to create a new,
"subset" that people can choose that just gives them a running system.

> This way anyone can try to contribute packages (as u said, for things
> like OpenGroupWare.org, etc) and the maintainer can prove and show he
> can maintain, fix and support this contribution over time before it
> gets moved to 'officialy included'. in essence this follows the debian
> structure, packages are only included if there is a valid and trusted
> maintainer for them.

No, I'm not saying that (did I even say that?).  I don't question the
Fedora steering committee on the selection for Core, Extras, etc...  I
trust their good judgement to continue Core, Extras, etc... on the path
it is going.  To do otherwise is only a distraction and a lot of useless
effort.  After all, Fedora is distributed now -- or someone gets Core
plus Extras on a single DVD because they have low bandwidth.

I'm just suggesting it might be time to define a "basic" subset for
Core.  With the distributed repositories and dependency checking, any
thing that needs to be install can be installed.

> Reasoning for this is that it would be a _lot_ worse if there was a
> serious data-destroying bug or security compromising bug in a package
> that no one would fix (in a timely and correct fashion) then it would
> be to not include a package.

I don't think I've ever suggested this.  I think you're making a
statement based on what you think I suggested, but did not.

Trying to replicate the package and support decisions of the RH/Fedora
team would be ludicrious.  And it's unnecessary with the distributed
repositories nowdays.

As someone else pointed out, all I'm saying is that it might be time
for  a "tighter" comps.xml as just an _option_ for a CD.


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From aoliva at redhat.com  Tue May 25 14:57:51 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 25 May 2004 11:57:51 -0300
Subject: Reduce "Core" to 1 Binary CD? -- Don't change Core,
	but make CD #1 "standalone"
In-Reply-To: <002901c441ec$3bdf6540$0200a8c0@gandalf>
References: <1085429050.25327.2.camel@bitman.oviedo.smithconcepts.com>
	<or7jv1ph0q.fsf@free.redhat.lsd.ic.unicamp.br>
	<002901c441ec$3bdf6540$0200a8c0@gandalf>
Message-ID: <orekp8imfk.fsf@free.redhat.lsd.ic.unicamp.br>

On May 24, 2004, "Chris Chabot" <chabotc at 4-ice.com> wrote:

> so uncompressed on cd storage

who said uncompressed?

> so extracting & writing files should be faster then copying them
> straight from cd.

but the rpm transaction overhead is not negligible.

> However most importantly: While 'blow over all the files without doing that
> fancy rpm stuff' sounds good in theory, did you ever think about how this
> would work if you wanted to upgrade your fedora instalation?

Oh, I was thinking of clean installs.  It obviously doesn't work for
upgrades.  The only way to avoid having an additional CD with rpms for
the packages included in the Live CD would be to have some mechanism
to recreate the RPM from the installed files.  Shouldn't be too hard,
but I agree it would be a pain.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From b.j.smith at ieee.org  Tue May 25 14:59:28 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Tue, 25 May 2004 10:59:28 -0400
Subject: A usefull tool -- Dep Tree and RPM-Analyzer
Message-ID: <1085497168.19191.43.camel@bitman.oviedo.smithconcepts.com>

Chris Chabot wrote:
> Dep Tree 0.1 by Chris Chabot.

Jeff Spaleta wrote:  
> rpm-analyzer? 
> http://www.maisondubonheur.com/rpm-analyzer/

Very good gentlemen!
Things have certainly changed in the last few years!
Most excellent.

-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From chabotc at 4-ice.com  Tue May 25 15:11:52 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Tue, 25 May 2004 17:11:52 +0200
Subject: Making Fedora Core CD #1 Standalone -- Core should continue	but
 let's define a subset
In-Reply-To: <1085496933.19191.40.camel@bitman.oviedo.smithconcepts.com>
References: <1085496933.19191.40.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <40B36238.3010807@4-ice.com>

Bryan J. Smith wrote:

>As someone else pointed out, all I'm saying is that it might be time
>for  a "tighter" comps.xml as just an _option_ for a CD.
>  
>
Actually i did try to sugest a tighter subset (for a 'functional 1 cd' 
option):

./dep-tree.php -d firstboot system-config-packages mozilla yum rpm mdadm 
cups vixie-cron httpd samba jfsutils php perl usbutils isdn4k-utils 
irda-utils metacity gnome-desktop gnome-session gnome-panel compat-db 
compat-libstdc++ compat-glibc openssh openssh-server openssh-clients 
openldap samba screen magicdev openmotif xmms gedit lm_sensors ntp 
gnome-utils autofs setserial nmap mgetty stunnel curl eject 
nautilus-cd-burner nautilus-media lsof wget telnet ftp gnome-applets 
gftp openoffice.org gimp gaim links mkinitrd mktemp ttmkfdir mkbootdisk 
xpdf eog gcc autoconf automake15 autoconf213 automake automake14 make
<...>
Number of packages: 457
Total size installed: 1557 Mb
Total packaged size:  498 Mb

That leaves plenty of room for packages i left out (kernel-*) and 
instalation software on the cd its self (and posibly add some extra 
desktop and server packages).  The goal is to define a "functionaly 
working" subset without any superflous extra's which can be added after 
the install using system-config-packages.

It would be quite easy to actually build this into a distribution.. You 
keep the existing hdlist/comps listings, however redefine the 
instalation options (to the in other email defined 
workstation/server/both/minimal) install 'groups', and anaconda won't 
ask for the other cd's during a clean install. On upgrade it will know 
those packages exist, and will include them in the install process (and 
hence prompt for those cd's)

Sounds to me like it optimaly uses the current infrastructure (anaconda, 
comps/hdlist, install & upgrade methods) while creating 1 cd "without 
bloat" instalation option (and allowing ppl to add more software 
afterwards using yum or system-conf-packages).

The above list creates this package list (including all -devel and 
dependency packages)

firstboot (293 Kb)
  bash (1493 Kb)
    glibc (5024 Kb)
      glibc-common (14278 Kb)
        tzdata (441 Kb)
      basesystem (3 Kb)
        setup (29 Kb)
        filesystem (18 Kb)
      libgcc (33 Kb)
    glibc-devel (1893 Kb)
      info (141 Kb)
        ncurses (1540 Kb)
        ncurses-devel (1466 Kb)
        zlib (43 Kb)
        zlib-devel (89 Kb)
      glibc-headers (525 Kb)
        glibc-kernheaders (697 Kb)
          coreutils (2872 Kb)
            findutils (102 Kb)
            grep (168 Kb)
              pcre (59 Kb)
              pcre-devel (97 Kb)
            libacl (15 Kb)
              libattr (9 Kb)
              libattr-devel (29 Kb)
            libacl-devel (78 Kb)
            pam (1927 Kb)
              cracklib (26 Kb)
              cracklib-dicts (409 Kb)
                words (137 Kb)
              db4 (1570 Kb)
                libstdc++ (240 Kb)
                libstdc++-devel (1316 Kb)
              db4-devel (1946 Kb)
              glib (135 Kb)
              glib-devel (115 Kb)
              glib2 (471 Kb)
              glib2-devel (892 Kb)
                pkgconfig (48 Kb)
              sed (116 Kb)
            pam-devel (78 Kb)
            libselinux (45 Kb)
            libselinux-devel (54 Kb)
          initscripts (878 Kb)
            gawk (1527 Kb)
              mktemp (12 Kb)
            fedora-release (92 Kb)
            iputils (92 Kb)
            chkconfig (99 Kb)
            psmisc (41 Kb)
            iproute (591 Kb)
            procps (175 Kb)
            shadow-utils (485 Kb)
            SysVinit (96 Kb)
            dev (3687 Kb)
            e2fsprogs (728 Kb)
            e2fsprogs-devel (1269 Kb)
            ethtool (48 Kb)
            mingetty (18 Kb)
            modutils (395 Kb)
            util-linux (1508 Kb)
              popt (61 Kb)
            net-tools (311 Kb)
            sysklogd (65 Kb)
            which (21 Kb)
    libtermcap (12 Kb)
      termcap (237 Kb)
    libtermcap-devel (97 Kb)
  python (5049 Kb)
    bzip2-libs (32 Kb)
    openssl (1113 Kb)
      krb5-libs (481 Kb)
    openssl-devel (1649 Kb)
      krb5-devel (831 Kb)
    gdbm (26 Kb)
    gdbm-devel (36 Kb)
    gmp (779 Kb)
    gmp-devel (413 Kb)
    readline (175 Kb)
    readline-devel (125 Kb)
  python-devel (1424 Kb)
  authconfig-gtk (34 Kb)
    authconfig (190 Kb)
      newt (81 Kb)
        slang (463 Kb)
        slang-devel (528 Kb)
      newt-devel (64 Kb)
    pygtk2-libglade (12 Kb)
      atk (145 Kb)
      atk-devel (88 Kb)
      gtk2 (4068 Kb)
        xorg-x11-libs (2394 Kb)
          freetype (710 Kb)
          freetype-devel (509 Kb)
          xorg-x11-Mesa-libGL (330 Kb)
          expat (68 Kb)
          expat-devel (106 Kb)
          xorg-x11-libs-data (352 Kb)
        fontconfig (115 Kb)
        fontconfig-devel (236 Kb)
        libjpeg (127 Kb)
        libjpeg-devel (170 Kb)
        libpng (146 Kb)
        libpng-devel (163 Kb)
        libtiff (191 Kb)
        libtiff-devel (934 Kb)
        pango (267 Kb)
        pango-devel (159 Kb)
          xorg-x11-devel (5247 Kb)
      gtk2-devel (1964 Kb)
      libglade2 (91 Kb)
        libxml2 (657 Kb)
        libxml2-devel (2174 Kb)
      libglade2-devel (86 Kb)
  libuser (254 Kb)
    openldap (551 Kb)
      cyrus-sasl (1224 Kb)
      cyrus-sasl-devel (1325 Kb)
      cyrus-sasl-md5 (55 Kb)
    openldap-devel (535 Kb)
  libuser-devel (75 Kb)
  metacity (1767 Kb)
    ORBit2 (233 Kb)
      libIDL (81 Kb)
      libIDL-devel (88 Kb)
    ORBit2-devel (359 Kb)
      indent (91 Kb)
    GConf2 (1035 Kb)
    GConf2-devel (190 Kb)
    startup-notification (28 Kb)
    startup-notification-devel (20 Kb)
  pygtk2 (447 Kb)
  pygtk2-devel (186 Kb)
  redhat-artwork (4545 Kb)
  fedora-logos (395 Kb)
  rhpl (262 Kb)
    pyxf86config (57 Kb)
  system-config-date (462 Kb)
    htmlview (7 Kb)
      redhat-menus (127 Kb)
    ntp (1226 Kb)
      libcap (16 Kb)
      libcap-devel (16 Kb)
  system-config-display (203 Kb)
    xorg-x11 (12314 Kb)
      xorg-x11-font-utils (230 Kb)
      xorg-x11-xauth (232 Kb)
      cpp (1456 Kb)
      chkfontpath (13 Kb)
        xorg-x11-xfs (268 Kb)
          ttmkfdir (43 Kb)
      Glide3 (290 Kb)
      Glide3-devel (22 Kb)
      kernel (13538 Kb)
        mkinitrd (86 Kb)
          gzip (88 Kb)
            less (85 Kb)
          lvm2 (709 Kb)
            device-mapper (313 Kb)
          tar (351 Kb)
      utempter (42 Kb)
      xinitrc (23 Kb)
        switchdesk (13 Kb)
      xorg-x11-base-fonts (7964 Kb)
    xorg-x11-devel (5247 Kb)
    hwdata (261 Kb)
    kudzu (374 Kb)
    kudzu-devel (131 Kb)
      pciutils-devel (41 Kb)
  system-config-keyboard (45 Kb)
  system-config-language (44 Kb)
  system-config-network (393 Kb)
    gnome-python2 (95 Kb)
      gnome-python2-bonobo (48 Kb)
        libbonobo (424 Kb)
        libbonobo-devel (265 Kb)
        libbonoboui (321 Kb)
          libart_lgpl (70 Kb)
          libart_lgpl-devel (68 Kb)
          libgnome (580 Kb)
            gnome-vfs2 (854 Kb)
              gnome-mime-data (551 Kb)
              fam (81 Kb)
                portmapportmap
                xinetd (129 Kb)
                  tcp_wrappers (99 Kb)
              fam-devel (27 Kb)
              shared-mime-info (55 Kb)
            gnome-vfs2-devel (324 Kb)
            audiofile (96 Kb)
            audiofile-devel (78 Kb)
            esound (120 Kb)
              alsa-lib (300 Kb)
              alsa-lib-devel (782 Kb)
            esound-devel (29 Kb)
            libxslt (413 Kb)
            libxslt-devel (257 Kb)
          libgnome-devel (101 Kb)
          libgnomecanvas (205 Kb)
          libgnomecanvas-devel (153 Kb)
        libbonoboui-devel (361 Kb)
        pyorbit (45 Kb)
          linc (29 Kb)
          linc-devel (31 Kb)
        pyorbit-devel (5 Kb)
      libgnomeui (728 Kb)
        gnome-keyring (105 Kb)
        gnome-keyring-devel (6 Kb)
      libgnomeui-devel (505 Kb)
    gnome-python2-canvas (17 Kb)
    system-config-network-tui (1078 Kb)
      pciutils (60 Kb)
        kernelkernel
      pciutils-devel (41 Kb)
      rpm-python (82 Kb)
        elfutils (132 Kb)
          elfutils-libelf (36 Kb)
          elfutils-libelf-devel (49 Kb)
        elfutils-devel (29 Kb)
        rpm (2238 Kb)
          beecrypt (64 Kb)
          beecrypt-devel (338 Kb)
        rpm-devel (3263 Kb)
  system-config-packages (251 Kb)
    comps-extras (108 Kb)
    libxml2-python (481 Kb)
  system-config-rootpassword (38 Kb)
  system-config-securitylevel (126 Kb)
    system-config-securitylevel-tui (120 Kb)
      iptables (168 Kb)
      iptables-devel (40 Kb)
  system-config-soundcard (1009 Kb)
    alsa-utils (115 Kb)
    sox (253 Kb)
      libogg (16 Kb)
      libogg-devel (71 Kb)
      libvorbis (184 Kb)
      libvorbis-devel (760 Kb)
    sox-devel (133 Kb)
  up2date (1277 Kb)
    gnupg (1613 Kb)
    python-optik (57 Kb)
    rhnlib (94 Kb)
      pyOpenSSL (135 Kb)
  usermode (88 Kb)
  xsri (17 Kb)
mozilla (9228 Kb)
  mozilla-nspr (103 Kb)
  mozilla-nspr-devel (178 Kb)
  mozilla-nss (625 Kb)
  mozilla-nss-devel (415 Kb)
mozilla-devel (3384 Kb)
yum (133 Kb)
mdadm (83 Kb)
cups (2544 Kb)
  cups-libs (99 Kb)
  dbus (287 Kb)
    dbus-glib (21 Kb)
  dbus-devel (135 Kb)
cups-devel (135 Kb)
vixie-cron (64 Kb)
httpd (893 Kb)
  mailcap (14 Kb)
  file (242 Kb)
  apr (90 Kb)
  apr-devel (511 Kb)
  apr-util (52 Kb)
  apr-util-devel (240 Kb)
httpd-devel (139 Kb)
samba (14604 Kb)
  logrotate (32 Kb)
  samba-common (4214 Kb)
jfsutils (276 Kb)
php (3281 Kb)
  aspell (728 Kb)
    aspell-en (1902 Kb)
  aspell-devel (15 Kb)
  curl (269 Kb)
  curl-devel (177 Kb)
  php-pear (230 Kb)
php-devel (227 Kb)
perl (11353 Kb)
usbutils (41 Kb)
isdn4k-utils (3713 Kb)
isdn4k-utils-devel (35 Kb)
irda-utils (58 Kb)
gnome-desktop (663 Kb)
gnome-desktop-devel (48 Kb)
gnome-session (310 Kb)
  control-center (2245 Kb)
    gnome-icon-theme (2845 Kb)
      hicolor-icon-theme (11 Kb)
    eel2 (339 Kb)
      librsvg2 (91 Kb)
        libcroco (115 Kb)
        libcroco-devel (26 Kb)
        libgsf (74 Kb)
        libgsf-devel (87 Kb)
      librsvg2-devel (49 Kb)
    eel2-devel (49 Kb)
      gail-devel (16 Kb)
        gail (281 Kb)
        gail-devel (16 Kb)
    libgail-gnome (24 Kb)
      at-spi (218 Kb)
      at-spi-devel (121 Kb)
    gstreamer-plugins (933 Kb)
      gstreamer (640 Kb)
      gstreamer-devel (454 Kb)
      arts (1131 Kb)
        qt (3014 Kb)
          libmng (104 Kb)
          libmng-devel (31 Kb)
        qt-devel (20031 Kb)
      arts-devel (192 Kb)
      cdparanoia-libs (48 Kb)
      flac (263 Kb)
      flac-devel (563 Kb)
      SDL (199 Kb)
      SDL-devel (612 Kb)
      libdv (72 Kb)
      libdv-devel (69 Kb)
      gtk+ (868 Kb)
        gdk-pixbuf (222 Kb)
        gdk-pixbuf-devel (193 Kb)
          gdk-pixbuf-gnome (12 Kb)
            gnome-libs (1026 Kb)
              ORBit (332 Kb)
              ORBit-devel (389 Kb)
              imlib (151 Kb)
                libungif (29 Kb)
                libungif-devel (108 Kb)
              imlib-devel (234 Kb)
                gtk+-devel (1133 Kb)
              libpng10 (138 Kb)
              libpng10-devel (111 Kb)
            gnome-libs-devel (1167 Kb)
      gtk+-devel (1133 Kb)
      mikmod (547 Kb)
      libraw1394 (36 Kb)
      libraw1394-devel (33 Kb)
      speex (205 Kb)
      speex-devel (58 Kb)
    gstreamer-plugins-devel (30 Kb)
    nautilus (3814 Kb)
      desktop-backgrounds-basic (1611 Kb)
      eog (678 Kb)
        libgnomeprint22 (311 Kb)
          ghostscript (7789 Kb)
            VFlib2 (485 Kb)
            VFlib2-devel (140 Kb)
          ghostscript-devel (33 Kb)
          ghostscript-fonts (809 Kb)
          urw-fonts (3629 Kb)
        libgnomeprint22-devel (268 Kb)
        libgnomeprintui22 (236 Kb)
        libgnomeprintui22-devel (105 Kb)
      gnome-vfs2-smb (24 Kb)
      libexif (58 Kb)
      libexif-devel (38 Kb)
      nautilus-cd-burner (175 Kb)
        cdrecord (414 Kb)
        cdrecord-devel (166 Kb)
        mkisofs (285 Kb)
      scrollkeeper (292 Kb)
        docbook-dtds (400 Kb)
          openjade (2038 Kb)
          openjade-devel (2023 Kb)
          sgml-common (41 Kb)
          xml-common (6 Kb)
        intltool (102 Kb)
          patch (61 Kb)
    libxklavier (66 Kb)
    libxklavier-devel (59 Kb)
    xscreensaver (5680 Kb)
      xorg-x11-Mesa-libGLU (399 Kb)
      xloadimage (125 Kb)
gnome-panel (2475 Kb)
  libwnck (131 Kb)
  libwnck-devel (84 Kb)
gnome-panel-devel (39 Kb)
compat-db (4702 Kb)
  compat-libstdc++compat-gcc-c++
  tcl (862 Kb)
  tcl-devel (1016 Kb)
compat-libstdc++ (1032 Kb)
compat-libstdc++-devel (357 Kb)
compat-glibc
openssh (181 Kb)
openssh-server (183 Kb)
openssh-clients (306 Kb)
screen (544 Kb)
magicdev (45 Kb)
openmotif (1382 Kb)
openmotif-devel (2703 Kb)
xmms (1986 Kb)
  unzip (139 Kb)
xmms-devel (42 Kb)
gedit (1943 Kb)
  gtksourceview (211 Kb)
  gtksourceview-devel (47 Kb)
gedit-devel (27 Kb)
lm_sensors (405 Kb)
  kernel-utils (383 Kb)
lm_sensors-devel (55 Kb)
gnome-utils (4109 Kb)
autofs (176 Kb)
  hesiod (21 Kb)
  hesiod-devel (61 Kb)
setserial (21 Kb)
nmap (386 Kb)
mgetty (424 Kb)
stunnel (117 Kb)
  make (337 Kb)
eject (37 Kb)
nautilus-media (146 Kb)
lsof (278 Kb)
wget (477 Kb)
telnet (52 Kb)
ftp (49 Kb)
gnome-applets (4975 Kb)
  libgtop2 (347 Kb)
  libgtop2-devel (53 Kb)
gftp (892 Kb)
openoffice.org (35242 Kb)
  bitstream-vera-fonts (345 Kb)
  openoffice.org-libs (39027 Kb)
    libgnomecups (28 Kb)
    libgnomecups-devel (23 Kb)
  openoffice.org-i18n (61985 Kb)
gimp (9637 Kb)
  gimp-print (2349 Kb)
  gimp-print-devel (547 Kb)
  gtkhtml2 (166 Kb)
  gtkhtml2-devel (43 Kb)
gimp-devel (872 Kb)
gaim (2653 Kb)
  libao (32 Kb)
  libao-devel (30 Kb)
  gtkspell (18 Kb)
  gtkspell-devel (15 Kb)
links
mkbootdisk (9 Kb)
  dosfstools (44 Kb)
  syslinux (102 Kb)
    mtools (197 Kb)
xpdf (4357 Kb)
gcc (3864 Kb)
  binutils (2900 Kb)
autoconf (630 Kb)
  m4 (86 Kb)
automake15 (332 Kb)
autoconf213 (248 Kb)
automake (480 Kb)
automake14 (306 Kb)

Number of packages: 457
Total size installed: 1557 Mb
Total packaged size:  498 Mb





From rms at 1407.org  Tue May 25 15:14:16 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Tue, 25 May 2004 16:14:16 +0100
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085496803.8977.11.camel@bree.local.net>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	<1085407033.28367.0.camel@opus>
	<604aa791040524073015794298@mail.gmail.com>
	<200405250036.21757.dennis@ausil.us> <1085417367.12347.57.camel@roque>
	<1085496803.8977.11.camel@bree.local.net>
Message-ID: <1085498056.2886.55.camel@roque>

On Tue, 2004-05-25 at 10:53 -0400, Jeremy Katz wrote:
> On Mon, 2004-05-24 at 17:49 +0100, Rui Miguel Seabra wrote:
> > This reminds me of a doubt I have:
> >   Can one simply mount, say...
> [snip]
> > and then point askmethod to ftp://server/pub/fc2/ ?
> > 
> > Is this possible, or something like it?
> 
> Yes, just like that.  This functionality has been present since Red Hat
> Linux 7.2, iirc.

Ok, then there is a probability this got broken somehow...

I haven't tested with other machines than the one I did, so I wonder if
someone has been able to do it this way with fc2...

Rui
-------------- 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/20040525/96906e55/attachment.sig>

From katzj at redhat.com  Tue May 25 15:16:37 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 25 May 2004 11:16:37 -0400
Subject: A usefull tool (Was: Making Fedora Core CD #1 Standalone)
In-Reply-To: <40B352F0.6010009@4-ice.com>
References: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>
	<40B352F0.6010009@4-ice.com>
Message-ID: <1085498197.8977.13.camel@bree.local.net>

On Tue, 2004-05-25 at 16:06 +0200, Chris Chabot wrote:
> -d             Include the *-devel packages for all packages in the list 
> (and it's dependencies). This is includes because i am a big fan of 
> having a system that could build it's self, it's updates and any other 
> source rpm's/tarbals you would download.

Unfortunately, this doesn't tell you what you need to build.  For that,
you need src.rpms and to analyze the BuildRequires (since BuildRequires
only show up as a Requires on a src.rpm)

Cheers,

Jeremy




From aoliva at redhat.com  Tue May 25 15:17:17 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 25 May 2004 12:17:17 -0300
Subject: The return of the acute-cedilla BUG FROM HELL
In-Reply-To: <1085453830.4695.7.camel@z>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my> <1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
	<20040524215310.GJ18881@rednote.net> <1085453830.4695.7.camel@z>
Message-ID: <oraczwilj6.fsf@free.redhat.lsd.ic.unicamp.br>

On May 24, 2004, Z <zleite at mminternet.com> wrote:

> FC2 has again the bug on the us-acentos keymap. Pressing "'" + c gives
> an non-existing symbol (at least non-existing in the languages I know)
> instad of the cedilla.

Well, ? surely exists in some languages, and you have to agree that it
would be damn surprising if ? were to prefer ? over ?.  Why the heck
is the acute accent *under* the letter, one would think...

If your locale is pt (or pt_BR?), gtk apps will map 'c to ?, but X
will still compose 'c into ?.  That's bad, and inconsistent.  The
solution (untested) is to create a file in
/usr/lib/X11/locale/pt_BR.UTF-8/Compose, adapted from
/usr/lib/X11/locale/en_US.UTF-8/Compose, in which the combinations of
<dead_acute> and <c> or <C> are mapped to the ? and ? characters,
instead of ? and ? as they are.  Then adjust compose.dir in the parent
directory such that pt_BR.UTF-8 is mapped to this new Compose rules.

Maybe there's a way to create a specialization of the Compose rules; I
don't know.

Then, work to get this change into upstream Xorg, and it will be fixed
in whatever Fedora Core release happens to integrate the Xorg release
that has your change.


Personally, I just got used to entering <Multi_key> <,> <c> to
generate ?.  Being a native pt_BR speaker, and writing a
non-negligible amount of e-mail in Portuguese, I don't find it to be
too much of a pain, as long as you know about it, and use a reasonable
key for <Multi_key> (AKA Compose).  I use the AltGR key for this
purpose; others choose the Win-key, or the Menu key.  You can easily
select one of them in the Layout Options in Keyboard Preferences.

> I saw some bugs related to this in bugzilla. Shoud I file it anyway?

You're probably better off filing an enhancement request with upstream
Xorg.  We don't have a bug here, just an inconvenience that takes some
getting-used-to.

> It seems to be a reversion from the xorg migration.

As far as I can tell you're mistaken.  From personal experience, FC1
(and probably RHL9) worked just the same in this regard, at least as
far as X11 is concerned.  I haven't checked for changes in gtk within
pt_BR locales, though; this might have changed.  Maybe you had
different i18n settings.  For example, switching from ISO-8859-1 to
UTF-8, or from pt_BR to en_US would have changed the 'c compose rules
on at least some applications.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From b.j.smith at ieee.org  Tue May 25 15:22:39 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Tue, 25 May 2004 11:22:39 -0400
Subject: Making Fedora Core CD #1 Standalone -- Now you're seeing it my
	way!
Message-ID: <1085498559.19191.66.camel@bitman.oviedo.smithconcepts.com>

[ I think at this point I've spewed enough vapor, so it's time for me to
go off and do something.  I really appreciate *EVERYONE'S*! input on
this.  I'm going to try to have a "nailed down" comps.xml by the
weekend, and identify some of the "BS dependencies" that should be
removed (if any) on various, basic packages. ]

Chris Chabot wrote:  
> This is indeed a big can of worms. To further complicate the matter,
> you always need to keep the upgrade path in mind to. If someone is
> running redhat 8,9, fedora core 1 or 2, they should be able to
> download the install cd's and upgrade their existing system.

I think some people are missing the fact that I _do_ recognize that. 
And that's why I'm advocating that the full "Core" _not_ be touched.

This new sub-Core would be explicit.  Ideally it would be Core CD #1.

> This means a whole lot of packages _have_ to be included to provide
> compat-XYZ or newer versions of the already installed packages. This
> kind of means that 90% of the existing packages are automaticly tied
> in on the install cd's.

Right.  I don't disagree with that.

> So with that in mind, what profit can still be gained by re-ordering
> packages around on cd's, and making minimal install cd's?
> IMHO you could make the first cd a "Basic but relatively complete"
> install cd, which includes all basic apps, web browsers, basic
> services and server apps, yum, system-config-packages, etc; Which you
> could use to install a new functional and working Workstation, or
> Server installation.

I think that was what I was saying.
But maybe I wasn't saying it as clearly?
My apologies ;-).

> The other (3) cd's would include all the other packages that are
> currently in fedora core 2, and should be listed and described in the
> comps / rpmdb-fedora packages.
> Then if you do a clean install it would only use the first CD to do
> the basic install, run thru first-boot, and allow people to add
> additional packages from either the 3 extra's cd's (it would know
> where they are and ask for the correct cd by looking that up in the
> comps / rpmdb-fedora lists), or offer the option to download them from
> a selected mirror.
> However if you do an upgrade using the first cd, it can use the
> knowledge of what packages are on what cd's to include those in the
> upgrade, and do a clean and sound upgrade (asking for those cd's as it
> does now).
> As far as i can think off thats the only way to satisfy the upgrade
> cycle dependency, while allowing for a 1 core cd install.

Now you're seeing it my way!
Thank you for re-iterating it in another way.
Maybe now others will see it as you do.

> Ofcource then the question becomes "What packages do we include on the
> core cd". To be able to play around with that question i've written a
> little tool in PHP which i've posted in a seperate email (Subject: A
> usefull tool (Was: Making Fedora Core CD #1 Standalone)).

Right, and I'm going to start play with it.

> You would be supprised at how much you can still include on the first
> CD.. With that tool you can show that all this paranoia about "Don't
> include any, *0* apps on the core CD" is being overly zealous..

Well, I'm anal.  I'm thinking of the company that has its own, internal
Apt repository.  So it's easy to fetch what you need for different
systems.  Eventually the company should write its own comps.xml, but
this "Quark" gives them a "nice base."

Eventually I'd like to see the "Quark" weed out a lot of stupid,
unnecesary dependencies in "Core."  But that's a future ideal.

> Your able to fit quite a large collection of workstation and server
> packages on one CD.. The mix that i came up with playing with the
> dep-tree tool is:
> ./dep-tree.php -d firstboot system-config-packages mozilla yum rpm
> mdadm cups vixie-cron httpd samba jfsutils php perl usbutils
> isdn4k-utils irda-utils metacity gnome-desktop gnome-session
> gnome-panel compat-db compat-libstdc++ compat-glibc openssh
> openssh-server openssh-clients openldap samba screen magicdev
> openmotif xmms gedit lm_sensors ntp gnome-utils autofs setserial nmap
> mgetty stunnel curl eject nautilus-cd-burner nautilus-media lsof wget
> telnet ftp gnome-applets gftp openoffice.org gimp gaim links mkinitrd
> mktemp ttmkfdir mkbootdisk xpdf eog gcc autoconf automake15
> autoconf213 automake automake14 make
> Number of packages: 457
> Total size installed: 1557 Mb
> Total packaged size: 498 Mb
> So this includes (i think) all the basic packages for a working linux
> instalation, qt/gnome/kde/motif compatiblity, mozilla, gimp, gaim,
> openoffice and lots of other workstation apps, and all required basic
> server apps (webserver, openssh, telnet, ftp, yum, nmap, screen, wget,
> links etc)

I'd go the other way.  No apps.  Why?  Because in short order, it will
bloat to more than 1 CD.  The idea here is to make it as small as
possible.  Even if its only 300MB or smaller.

Someone can _always_ "fill" the official "Core" CD #1 with more -- but
it all starts with the "Quark" comps.xml _first_, as the "base."  We
need more than the 90MB one (although that's not a bad start).

BTW, does that list include Kerberos?  I probably need to find out by
using RPM-Analyzer.

> The nice thing of this is that the first CD can then offer 4 install modes:
> - Basic Workstation
> - Basic Server
> - Both server and workstation software
> - Minimal instalation (90 or so megs, already included in FC1/2)
> [x] checkbox Include development packages and tools

I  see little reason to include development.  They can be fetched via Apt/Yam.
For those that can't, Quark is not for them.  They should install the full
"Core" instead (possibly from 3rd party DVD with Extras added).

> While still offering a fully functional end result, and including all
> *-devel packages and compilers so the system is self-building and
> allows you to compile kernels, source rpm's or tarbals (imho it would
> go against the spirit of *nix / open source to have a system that
> could not compile software or it's self)

But at what point do you start not including stuff?  I say devel is out
for "Quark."  You have Apt/Yam to fetch them anytime you need.

> Then if they want all KDE apps, more server software, a slow of perl-*
> packages, databases, then the extra 3 cd's come into play (and/or
> external repositories)

Here's what I think should be in "Quark" (or whatever it is called):

- Everything in "Minimal Install" (90MB)
This is a suppport consideration

- All client network services for basic X/GNOME functionality
- All client probing/hardware support
Everything from DHCP to Mozilla, and the GTK+/GNOME to run it
This includes Fonts (which can quickly be a size issue)

- All directory service, authentication, crypto clients/services
- All network client/services having to do with file
Because if you can't connect to any network setup, you can't fetch

And that's all.  No extra GNOME applets or goodies.  No bitmaps other
than maybe the Fedora one.  No frills.  Those can be apt-get'ted.

In an enterprise environment, I'd rather have a "base" install like
Quark on a CD, and then run a script that does an "apt-get" of
everything else needed.  But that's just me.


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From chabotc at 4-ice.com  Tue May 25 15:33:01 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Tue, 25 May 2004 17:33:01 +0200
Subject: A usefull tool (Was: Making Fedora Core CD #1 Standalone)
In-Reply-To: <1085498197.8977.13.camel@bree.local.net>
References: <1085452503.25327.195.camel@bitman.oviedo.smithconcepts.com>	<40B352F0.6010009@4-ice.com>
	<1085498197.8977.13.camel@bree.local.net>
Message-ID: <40B3672D.90701@4-ice.com>

Ahh good point.. Fortunatly by including 'all the -devels' 98% is 
covered.. What's probably missing from the list are things like doxygen 
(i dont think anything requires it, but i know apr/httpd forinstance do 
buildrequire it). But as i said, i think most of it is in there.

I think you might've just inspired me to expand my script to pull in 
.spec's too..

.. Just brainstorming here, easiest way to get the .spec file for 
installed packages would probably be to:

source_pkg = `rpm -q <package> -qf "%{SOURCERPM}"`
spec_file      = `rpm -qpl /path/to/$source_pkg | grep ".spec"`
rpm2cpio $source_pkg | cpio -iv $spec_file

    -- Chris

Jeremy Katz wrote:

>On Tue, 2004-05-25 at 16:06 +0200, Chris Chabot wrote:
>  
>
>>-d             Include the *-devel packages for all packages in the list 
>>(and it's dependencies). This is includes because i am a big fan of 
>>having a system that could build it's self, it's updates and any other 
>>source rpm's/tarbals you would download.
>>    
>>
>
>Unfortunately, this doesn't tell you what you need to build.  For that,
>you need src.rpms and to analyze the BuildRequires (since BuildRequires
>only show up as a Requires on a src.rpm)
>
>Cheers,
>
>Jeremy
>
>
>  
>

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

From jspaleta at gmail.com  Tue May 25 15:43:43 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 25 May 2004 11:43:43 -0400
Subject: Making Fedora Core CD #1 Standalone -- Now you're seeing it
	my way!
In-Reply-To: <1085498559.19191.66.camel@bitman.oviedo.smithconcepts.com>
References: <1085498559.19191.66.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <604aa79104052508436d42da09@mail.gmail.com>

On Tue, 25 May 2004 11:22:39 -0400, Bryan J. Smith <b.j.smith at ieee.org> wrote:
> 
> [ I think at this point I've spewed enough vapor, so it's time for me to
> go off and do something.  I really appreciate *EVERYONE'S*! input on
> this.  I'm going to try to have a "nailed down" comps.xml by the
> weekend, and identify some of the "BS dependencies" that should be
> removed (if any) on various, basic packages. ]

Do some research... a lot of this ground was covered in pre-fc1 discussions on
the mailinglists... look for threads about minimal install...

Aug/Sep 2003 archive in fedora-test-list would probably be of interest
to you if you plan to incorporate other community opinion in your
master plan about better minimal base.

-jef




From janina at rednote.net  Tue May 25 15:45:34 2004
From: janina at rednote.net (Janina Sajka)
Date: Tue, 25 May 2004 11:45:34 -0400
Subject: The Fedora Hardware Project
In-Reply-To: <604aa79104052414374b7d9ac3@mail.gmail.com>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
	<20040524211808.GB17868@devserv.devel.redhat.com>
	<604aa79104052414374b7d9ac3@mail.gmail.com>
Message-ID: <20040525154534.GH6371@rednote.net>

I think it important to recognize that all of Sun's excellent contribution is desktop focused--exclusively. There's more to accessibility than that. It has to cover the console, bios, boot loader, installation, documentation, etc.

BTW: Helpful as Sun's contribution has been and will continue to be, they've also left us a nasty problem--their dependency on their Java license. So, their desktop contribution comes with yet more cleanup work for gcj.

I am happy to help move this forward, and I am happy to do so for Fedora. However, we need more than just some accessibility folks. For example, I would hope we can reinvigorate Red Hat's participation in FSG A11y work as well. There is an emerging road map. There are also known issues that should just be addressed, and can be addressed without waiting for the road map. Let's take firstboot as an example. I shudder at the thought of making it accessible given the architecture that underlies it. Can we put on the table the notion of moving it to W3C/WAI compliant html/xml markup? That would make accessibility easier to deliver. Is that worthy of consideration?

Jeff Spaleta writes:
> On Mon, 24 May 2004 17:18:08 -0400, Alan Cox <alan at redhat.com> wrote:
> > 
> > On Mon, May 24, 2004 at 04:12:46PM -0400, Jeff Spaleta wrote:
> > > working group as a subcommunity group could be a very helpful thing,
> > > especially if they organized a roadmap and systematically help
> > > developers address accessibility issues in an organized way.
> > 
> > That has been going on for some time. Sun in particular did a lot of heavy
> > lifting to get core accessibility functionality into the desktop and the
> > toolkits.
> 
> But is there a community group that aims to press the accessibility issue beyond
> the desktop? A group that has a battle plan and human expertise to
> help to make the whole process from the moment you drop a cd into the
> machine to start the install accessible?  I'm not aware of a community
> group like that in general...and certaintly not a group of community
> contributors focused on doing this for fedora specifically.  Right now
> and it the past, it seems Janina expects for Red Hat to make
> accessibility very important, as important as she makes it, and I
> don't think that expectation is going to be realized unless someone
> organizes community contributors into a dedicated group whose goal is
> to tackle the accessibility question in a focused and organized way,
> by providing assistance, feedback and code on accessibility issues
> through the fedora distribution.
> 
> Accessibility is important, important enough to pull everyone who is
> interested in making it work well together, giving them a roadmap and
> putting them to work towards making fc6 completely accessible.
> 
> -jef
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

		Chair, Accessibility Workgroup
	Free Standards Group (FSG)

Email: janina at afb.net		Phone: (202) 408-8175




From b.j.smith at ieee.org  Tue May 25 15:56:41 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Tue, 25 May 2004 11:56:41 -0400
Subject: Making Fedora Core CD #1 Standalone -- Goals of "Quark"
Message-ID: <1085500601.20189.14.camel@bitman.oviedo.smithconcepts.com>

Jeff Spaleta wrote:  
> Do some research... a lot of this ground was covered in pre-fc1
> discussions on the mailinglists... look for threads about minimal
> install...

Right.  I've been looking through some of this already.

> Aug/Sep 2003 archive in fedora-test-list would probably be of interest
> to you if you plan to incorporate other community opinion in your
> master plan about better minimal base.

Yes.  I'm already formulating the official "goals."  I have to have those
in-place before I can build a rationale for the comps.xml and package list.

So far I have:

1.  Establish "minimum" inter-dependency in a "minimum" install,
including identifying poor interdependencies in basic "Core" packages

2.  Establish a "bare" network client/server install, but with
full, modern access, directory and authentication support.

3.  A bare, no frills network/GUI install (no applications)

4.  A "common denominator" for not only all subsequent package sets,
but an "aim point" for developers creating new GUI applications

#4 is what I keep coming back to.  If I'm developing a new GUI
application, what components _should_ I "aim for" -- that I
_know_ will be on _all_ systems?

Right now we have little more than the full, 4 CD "Core."
There's nothing wrong with that looking from legacy RHL upward.

But there is a good reason to start "afresh."


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From chabotc at 4-ice.com  Tue May 25 16:12:29 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Tue, 25 May 2004 18:12:29 +0200
Subject: Making Fedora Core CD #1 Standalone -- Now you're seeing it my
 way!
In-Reply-To: <1085498559.19191.66.camel@bitman.oviedo.smithconcepts.com>
References: <1085498559.19191.66.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <40B3706D.5080106@4-ice.com>

Bryan J. Smith wrote:

>[ lots of snippage]
>
>I think that was what I was saying.
>But maybe I wasn't saying it as clearly?
>My apologies ;-).
>  
>
Oh no i wasn't agreeing or disagreeing.. I was just brainstorming and 
discussing the ideas in a general fashion and trying to give it some 
shape (for my own mind to)


>Eventually I'd like to see the "Quark" weed out a lot of stupid,
>unnecesary dependencies in "Core."  But that's a future ideal.
>  
>
Actually by splitting up the packages between CD1 = basic working 
server/workstation, and the rest on cd's 2..4, you've already filtered 
out most of those dependencies.

Secondly, i've tried this 'filter out silly dependencies' quite a few 
times my self.. It always ended up biting me in the behind though. 
(tried it on rh es, rh9 for some time actually). Often taking out the 
dependency will cause bugs to re-appear that were fixed by those 
dependencies, or it will break external 3rd party (or legacy) rpm's. 
It's easier to pick the low hanging fruit and just put all the 'silly 
deps' on the other cd's

>I'd go the other way.  No apps.  Why?  Because in short order, it will
>bloat to more than 1 CD.  The idea here is to make it as small as
>possible.  Even if its only 300MB or smaller.
>  
>
Ah finaly something we disagree on :-) Small is suprisingly easy to 
accomplish.. However to make this install usefull to to the average 
user, thats something different i.m.o.

We might not share the same vision here.. I envision a 1 CD instalation 
that allows ppl to get up and running, and do all the basic server 
and/or workstation stuff that you would expect.. So basic IM, browsing, 
office document editing, graphic packages, full gnome/nautilus with 
basic utilities.. etc. Not the expanded list that makes it 4 cd's, but 
enough to have the same experiance as you would have using Windows 9x / 
XP.. even just a little more. For a lot of people this 1 CD instalation 
should already be enough to start 'using linux'. If after that they want 
to install another desktop envirioment, databases, etc.. then they will 
need the extra cd's or download things from internet repositories.

Thus my 'quark' (to use your definition) vision is different from 
yours.. While i like the concept of "just basics please", i can see this 
confusing people why they have to download the 4 cd's anyway (thus not 
solving that problem). While for advanced users this pure-basics 1 cd 
usefull, i think it misses the point for the "average user"

I gues a terminology i'd use to describe my 1st cd vision is 'assumed 
functionality'. An Average User(Tm) is the non-vocal majority who doesnt 
care to much about licencing politics, desktop wars or package 
inclusions.. All he wants is to download a CD, pop it in, reboot, and 
have a brand-sparkling-new linux system up and running within half and 
hour; Where he can do his buisness (mail, browse, open office documents, 
view his pictures, chat with friends, edit text files and play some 
media). If, after that experiance settles in, he wants video 
conferencing, databases or any of that 'extra' stuff, 
system-config-packages should point him the way to how to get that and 
ask for the instalation cd's or download it.. For ppl like that 'yum' is 
already quite a far fetched and scary concept

I gues the question i'm asking that appart from "having to be carefull 
not to bloat out of the 1 cd confinements for a basic install", what 
advantages would this "only very basics please" approach have over a 
"functional but kept to one cd" basic install concept?

Last argument i have on this is wasting CD space.. if CD1 only has 200Mb 
of stuff on it, there's a big risk this will add another cd to the 
instalation, and thus be more expensive to publish/burn, make for more 
cd swapping, and make ppl scream bloat even more then they do now..

>BTW, does that list include Kerberos?  I probably need to find out by
>using RPM-Analyzer.
>  
>
Oh no it didnt, add another 1 Mb to the number then (very minimal 
impact).. ps rpm-analyzer requires some hacking to get it running.. 
Using my tool works nicely to (ofcource i would think so), and shows 
very nicely what extra packages are pulled in to satisfy dependencies.. 
great for if your doing a measuring game

>I  see little reason to include development.  They can be fetched via Apt/Yam.
>For those that can't, Quark is not for them.  They should install the full
>"Core" instead (possibly from 3rd party DVD with Extras added).
>  
>
Self building and able-to-compile systems are very open-source and *nix 
like though.. yum/apt is great, but really relying on them to much is 
not a good thing either.. Using yum to install mysql .. sure... Using 
yum to make assumed basics functionality .. goes to far for me.

Reality is that a lot of users, experianced or not, like compiling 
things from source, or are being told to do so in emails, faq's and 
todo's.. It's also one of those 'mystical' new linux user experiance 
when they see they can.

Not to mention using yum to forfill building dependencies is a nightmare 
for anyone who's not a heavely experianced redhat user.. What -devel 
package gives me /usr/include/obscure/file.h or /usr/lib/weird/name.so ? 
Yum doesnt process build requirements.. So you'd have to teach them 
about --whatprovides and --redhat-provides type command lines or teach 
them what packages provide what libs.. Neither of those options is very 
attractive if you ask me.

The only reason i see to not include devel packages in an instalation is 
for either a secure server (if you can't compile your prefered root kit, 
90% of your h4x0rs are already stomped) or for corperate desktop style 
instalations.

>In an enterprise environment, I'd rather have a "base" install like
>Quark on a CD, and then run a script that does an "apt-get" of
>everything else needed.  But that's just me.
>
Actually in an enterprise environment i'd use the anaconda-ks.cfg 
kickstart file, adjust that to my needs as i see fit and make a new 
install CD from it (the hard way), or just network instalation using a 
bootdisk or preferably thru PXE (the easy way) and install it that way.





From dhollis at davehollis.com  Tue May 25 18:21:45 2004
From: dhollis at davehollis.com (David T Hollis)
Date: Tue, 25 May 2004 14:21:45 -0400
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <Pine.GSO.4.58.0405242207380.26413@redfish.gatech.edu>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar>
	<1085348389.12538.4.camel@mentor.gurulabs.com>
	<Pine.GSO.4.58.0405242207380.26413@redfish.gatech.edu>
Message-ID: <1085509305.3270.6.camel@dhollis-lnx.kpmg.com>

On Mon, 2004-05-24 at 22:15 -0400, Chris Ricker wrote:
> The scripts look like they try to do that, but it doesn't actually work.  
> With "NETWORKING_IPV6=no" in /etc/sysconfig/network, the IPv6 module still
> autoloads and link-local addresses are still automagically assigned.


I've seen that as well.  To prevent the loading of the ipv6 module, add
'alias net-pf-10 off' to your /etc/modprobe.conf.

-- 
David T Hollis <dhollis at davehollis.com>




From jspaleta at gmail.com  Tue May 25 18:58:35 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 25 May 2004 14:58:35 -0400
Subject: Call for Discussion: Summary document concerning Prevention and
	Recovery of XP Dual Boot Problems
Message-ID: <604aa79104052511586a67d722@mail.gmail.com>

Okay, a generous community member has been so kind as to write a
summary document
outlining  prevention and recovery on systems where the infamous
harddrive geometry installer bug causes problems with XP dual booting.

Please, read over the attached document and test the preventative and
recovery methods outlined.  Suggestions on useful textual edits and
corrections to make before this is widely broadcast are welcome. This
is important enough of an issue to make sure the information in here
is non-toxic before we broadcast a version of this widely, the goal
being to prevent all unncessary dataloss.

Of particular interest:

1)test the preventative measure if you still have access to a machine
where this is a problem. Prevention is always better, if it can be
done reliably.

2)finding a better workaround stdisk warning messages that are being
produced that intefere with simple sfdisk command pipe recovery.
 

-jef"Die CHS Die!"spaleta

------------------->Begin Summary Document Text<----------------------------

Dual Booting Issues With Fedora Core 2 and Windows: Prevention & Recovery
 
NOTICE: Please read this document in its entirety.
 
This guide was inspired by the solution developed by Radu Cornea and
Alexandre Oliva in this thread:
http://www.redhat.com/archives/fedora-test-list/2004-May/msg02114.html .
This guide aims to integrate the original solution with the refinements
evolved in that thread.  This guide offers an explanation of why the
refinements are beneficial and some workarounds to problems that may prevent
the uninitiated from using the solution. It also provides a means of
preventing the problem entirely.
 
Primer:
 
        There is a bug in Fedora Core 2 that causes the hard disk geometry as
reported in the partition table to be altered during installation.  This
change may cause Windows boot failure.  Although this bug is severe, it is
recoverable and no data should be lost.  It is important not to panic if and
when this happens so you do not cause further problems or cause actual loss
of data in the process of recovering from the error.

Prevention:
                                                                                
        This bug can be avoided entirely by using some preventative steps while
installing Fedora Core 2.  Thanks go out to Cero (cero at coolnetworx.net) for
discovery and testing of this solution.
                                                                                
        To avoid the hard disk geometry to be altered you may enter it manually
during installation by using the hdN=<drive geometry> parameter (where N is
the letter representing the drive with the MBR you will use).  To discover
the current geometry before installing Fedora Core 2 you should use a
utility that can read the drive geometry as reported in the partition table

From chabotc at 4-ice.com  Tue May 25 19:34:40 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Tue, 25 May 2004 21:34:40 +0200
Subject: Call for Discussion: Summary document concerning Prevention
	andRecovery of XP Dual Boot Problems
References: <604aa79104052511586a67d722@mail.gmail.com>
Message-ID: <001b01c4428f$52bed090$0200a8c0@gandalf>

Hi Jeff, all..

Three notes i have, one of them somewhat 'bitter' i'm afraid.

First of all i found out about this bug by being hit by it .. Unfortunatly i
only have one machine here and needed to get work on it done, so without
knowledge of how to fix this, all that was left to me was to whipe my
partitions completely, losing a bit of data and work in the process, and
re-installing. Now this leads to my actual question.. Is it really smart to
leave FC2 out there when this scenario will probably hit a lot of people?
Not everyone has many computers setup you know, and completely hoosing you
system is probably enough to make people somewhat non sympathetic to what
seems to have caused it (fedora in this case). I know i had to swallow hard
and take a very deep breath when it hit me

Secondly these notes do mostly seemed geared towards quite advanced users?
Specificly "..you should use a utility that can read the drive geometry" ..
I think you've lost quite a bit of your target audiance there already.. What
utility, what do those values mean, how to use those values in the
workaround.. ?

Last i'm missing the part about recovery.. I've read in the bug and in the
email threads that you could use sfdisk (which can be usable by booting the
install/rescue cd, going into rescue mode, installing sfdisk, and running
that command..). Shouldnt we include a guide on how to do that to?



While i do think its great btw to send out a major call to read this info,
with a guide to how to prevent and/or recover from it. I am to put it
mildly, quite supprised the 'Fedora Project' allows this bug to exist in
cd's that anyone can just download.. However well we describe the
fix/workarounds and spread the news, it will not reach a lot of people..
Nevermind about people who just want to try linux out. I remeber the times
when serious dataloss was considered a show-stopper bug.. Having had the
experiance of having lost data and work due to this bug, it's easy to call
this data loss.. So in my eyes a _serious_ show stopper for this release..
Recall is what my voice will shout if anyone will listen; Or atleast patch
the installers on the cd to detect the miss-alignment and refuse to take any
further actions or install..

Really how's it gonna look to the world: "Hey we have this great new
release, but installing it might mean having to do high-tech complicated
workarounds or reinstalling your complete system"






----- Original Message ----- 
From: "Jeff Spaleta" <jspaleta at gmail.com>
To: <fedora-devel-list at redhat.com>
Sent: Tuesday, May 25, 2004 20:58
Subject: Call for Discussion: Summary document concerning Prevention
andRecovery of XP Dual Boot Problems


Okay, a generous community member has been so kind as to write a
summary document
outlining  prevention and recovery on systems where the infamous
harddrive geometry installer bug causes problems with XP dual booting.

Please, read over the attached document and test the preventative and
recovery methods outlined.  Suggestions on useful textual edits and
corrections to make before this is widely broadcast are welcome. This
is important enough of an issue to make sure the information in here
is non-toxic before we broadcast a version of this widely, the goal
being to prevent all unncessary dataloss.

Of particular interest:

1)test the preventative measure if you still have access to a machine
where this is a problem. Prevention is always better, if it can be
done reliably.

2)finding a better workaround stdisk warning messages that are being
produced that intefere with simple sfdisk command pipe recovery.


-jef"Die CHS Die!"spaleta

------------------->Begin Summary Document Text<----------------------------

Dual Booting Issues With Fedora Core 2 and Windows: Prevention & Recovery

NOTICE: Please read this document in its entirety.

This guide was inspired by the solution developed by Radu Cornea and
Alexandre Oliva in this thread:
http://www.redhat.com/archives/fedora-test-list/2004-May/msg02114.html .
This guide aims to integrate the original solution with the refinements
evolved in that thread.  This guide offers an explanation of why the
refinements are beneficial and some workarounds to problems that may prevent
the uninitiated from using the solution. It also provides a means of
preventing the problem entirely.

Primer:

        There is a bug in Fedora Core 2 that causes the hard disk geometry
as
reported in the partition table to be altered during installation.  This
change may cause Windows boot failure.  Although this bug is severe, it is
recoverable and no data should be lost.  It is important not to panic if and
when this happens so you do not cause further problems or cause actual loss
of data in the process of recovering from the error.

Prevention:

        This bug can be avoided entirely by using some preventative steps
while
installing Fedora Core 2.  Thanks go out to Cero (cero at coolnetworx.net) for
discovery and testing of this solution.

        To avoid the hard disk geometry to be altered you may enter it
manually
during installation by using the hdN=<drive geometry> parameter (where N is
the letter representing the drive with the MBR you will use).  To discover
the current geometry before installing Fedora Core 2 you should use a
utility that can read the drive geometry as reported in the partition table=


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


> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>




From pekkas at netcore.fi  Tue May 25 20:15:38 2004
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 25 May 2004 23:15:38 +0300 (EEST)
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <Pine.GSO.4.58.0405242207380.26413@redfish.gatech.edu>
Message-ID: <Pine.LNX.4.44.0405252308230.25663-100000@netcore.fi>

On Mon, 24 May 2004, Chris Ricker wrote:
> On Sun, 23 May 2004, Dax Kelson wrote:
> 
> > Ummm, because it's compiled as a module so you are free to not load it
> > without a kernel recompile.
> > 
> > To prevent the autoloading, run the command:
> > 
> > echo "NETWORKING_IPV6=no" >> /etc/sysconfig/network
> 
> The scripts look like they try to do that, but it doesn't actually work.  
> With "NETWORKING_IPV6=no" in /etc/sysconfig/network, the IPv6 module still
> autoloads and link-local addresses are still automagically assigned.
> 
> I've not yet had time to investigate and see why it's not working.

Well, setting NETWORKING_IPV6=no.

If it's "yes", the scripts add the net-pf-10 -> ipv6 alias to 
modules.conf and start up IPv6.

If it's "no", the scripts do nothing.  If an application tries to set 
up an IPv6 socket:

 1) previously IPv6 ended up being loaded in any case unless you 
commented off net-pf-10 entries from modules.conf

 2) currently, AFAIR when modutils already includes the implicit 
net-pf-10 -> ipv6 mapping internally, even commenting it out doesn't 
help to prevent IPv6 from being loaded.

So, I guess the fix here is that if NETWORKING_IPV6 has been set to
"no", the scripts should remove all the net-pf-10 entries and insert
'alias net-pf-10 off' entry.  

We might also want to do this when NETWORKING_IPV6 is unset, for
consistency, but that's a slighly different scenario.  This is
probably similar if we'd change the implicit default value of
NETWORKING_IPV6 from "no" to "yes".

-- 
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 dhollis at davehollis.com  Tue May 25 20:26:14 2004
From: dhollis at davehollis.com (David T Hollis)
Date: Tue, 25 May 2004 16:26:14 -0400
Subject: Call for Discussion: Summary document concerning Prevention
	andRecovery of XP Dual Boot Problems
In-Reply-To: <001b01c4428f$52bed090$0200a8c0@gandalf>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
Message-ID: <1085516774.3270.12.camel@dhollis-lnx.kpmg.com>

On Tue, 2004-05-25 at 21:34 +0200, Chris Chabot wrote:

> Secondly these notes do mostly seemed geared towards quite advanced users?
> Specificly "..you should use a utility that can read the drive geometry" ..
> I think you've lost quite a bit of your target audiance there already.. What
> utility, what do those values mean, how to use those values in the
> workaround.. ?
> 
I agree on this point totally.  What format is the geometry in?  I've
seen various ways of reporting HD geometry from straight cylinder counts
(4134788423 cyl), to the CHS 16/8/64 whatever style, etc.  A sample of
what the user would be looking for would probably be very helpful. 

-- 
David T Hollis <dhollis at davehollis.com>




From jspaleta at gmail.com  Tue May 25 20:31:31 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 25 May 2004 16:31:31 -0400
Subject: Call for Discussion: Summary document concerning Prevention
	andRecovery of XP Dual Boot Problems
In-Reply-To: <1085516774.3270.12.camel@dhollis-lnx.kpmg.com>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
	<1085516774.3270.12.camel@dhollis-lnx.kpmg.com>
Message-ID: <604aa7910405251331438a9252@mail.gmail.com>

On Tue, 25 May 2004 16:26:14 -0400, David T Hollis
<dhollis at davehollis.com> wrote:
> I agree on this point totally.  What format is the geometry in?  I've
> seen various ways of reporting HD geometry from straight cylinder counts
> (4134788423 cyl), to the CHS 16/8/64 whatever style, etc.  A sample of
> what the user would be looking for would probably be very helpful.

something is going wrong with getting the full document into the mailinglist...
its getting chopped....there's no point really discussing this until
the full doc can be seen correctly. Hell...even Jack's repost of the
document got eaten by the list demon even though my forward directly
to him was fine. I've used up my alotment of community goodwill today,
other people can attempt to get the full document to the list again.

-jef




From katzj at redhat.com  Tue May 25 20:32:56 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 25 May 2004 16:32:56 -0400
Subject: anaconda CVS repository moved to rhlinux.redhat.com
Message-ID: <1085517176.8977.66.camel@bree.local.net>

This is a heads-up that the CVS repository for anaconda has moved from
its previous home of an internal server to the externally accessible
rhlinux.redhat.com.  You can check it out by doing
  cvs -d:pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS login
  cvs -d:pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS co anaconda

This will give you the current trunk of anaconda development (ie, what's
destined for FC3 and beyond).  I'm going to send a mail shortly with a
list of some of the things that myself and some of the other people at
Red Hat who work on anaconda are looking at or working on with the goal
of getting as much of it done as possible for Fedora Core 3 for
discussion or for others to pick up some of the ideas and run with them.

Cheers,

Jeremy




From mattdm at mattdm.org  Tue May 25 20:57:23 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 25 May 2004 16:57:23 -0400
Subject: rpm groups and fedora: a modest proposal
Message-ID: <20040525205723.GA25684@jadzia.bu.edu>

One of the vestigial tags in the rpm format is "Group". Long ago, this was
used by the installer to sort out packages by function, to make it easier to
choose what you wanted installed. But recent installers don't really use
this -- it was found to be more maintainable to keep this metainformation in
the 'comps' file, external to the packages themselves. 

And, although this isn't intrinsic to the rpm-group vs. comps-group switch,
the rpm-groups tend to be organized so that you look at the group and pick
which members you want (chosing, for example, GNOME from "User
Interface/Desktops") while the comps-groups are the other way around: pick
"GNOME Desktop", and it installs all the GNOME bits you might want. This is
generally better and more useful.

The canonical list of valid RPM groups is /usr/share/doc/rpm-*/GROUPS.
Theoretically, all packages should have a group listed here. But often,
there's not a very good fit -- does all science and math go under
"Applications/Engineering"? And even Fedora itself doesn't hold to this:
there's a bunch of random "Applications/CPAN", "Networking/Other",
"Desktop/Accessibility", and probably more.

Now, one approach would be to reevaluate the canonical list -- reorganize it
a bit, make some broader groups, and so on, and then make sure all packages
properly fit that list.

But that's not my suggestion. I think Group has become too ugly to be
properly saved. Applications like synaptic should instead use the comps file
groups for organizational purposes. In fact, there's already a lua script
for at-get to make it do exactly that. (I dunno what up2date does -- I
haven't used it.)

Meanwhile, the Group tag itself should be reduced in function. I suggest
very very vastly reduced: it should simply be "Core" for Fedora Core,
"Extras" for Fedora Extras, "Legacy" for Fedora Legacy, and "Alternatives"
for Fedora Alternatives.

Or, if that's too much like the big disttags argument, it should simply be
"Fedora", and then phased out completely. (Packages with no group would
default to "Fedora", and then it could eventually stop being listed in the
spec file completely.)



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




From jaboutboul at speakeasy.net  Tue May 25 21:25:06 2004
From: jaboutboul at speakeasy.net (Jack Aboutboul)
Date: Tue, 25 May 2004 17:25:06 -0400
Subject: Prevention and Recovery of XP Dual Boot Problems
Message-ID: <1085520305.1990.48.camel@deepfort>

This is the whole document for those who didnt get it.

<---BEGIN--->

Dual Booting Issues With Fedora Core 2 and Windows: Prevention & Recovery

NOTICE: Please read this document in its entirety.

This guide was inspired by the solution developed by Radu Cornea and 
Alexandre Oliva in this thread: 
http://www.redhat.com/archives/fedora-test-list/2004-May/msg02114.html . 
This guide aims to integrate the original solution with the refinements 
evolved in that thread.  This guide offers an explanation of why the 
refinements are beneficial and some workarounds to problems that may prevent 
the uninitiated from using the solution. It also provides a means of 
preventing the problem entirely.

Primer:

        There is a bug in Fedora Core 2 that causes the hard disk geometry as 
reported in the partition table to be altered during installation.  This 
change may cause Windows boot failure.  Although this bug is severe, it is 
recoverable and no data should be lost.  It is important not to panic if and 
when this happens so you do not cause further problems or cause actual loss 
of data in the process of recovering from the error.

Prevention:

        This bug can be avoided entirely by using some preventative steps while 
installing Fedora Core 2.  Thanks go out to Cero (cero at coolnetworx.net) for 
discovery and testing of this solution.

        To avoid the hard disk geometry to be altered you may enter it manually 
during installation by using the hdN=<drive geometry> parameter (where N is 
the letter representing the drive with the MBR you will use).  To discover 
the current geometry before installing Fedora Core 2 you should use a 
utility that can read the drive geometry as reported in the partition table. 
It is important to understand that some tools may not be reporting the 
actual data from this location, but, rather, some derived value, so your 
surest way is to use the fdisk utility.  You can get this information by 
following these steps.

Note: This example will assume you are looking at /dev/hda, which is the 
master on the primary IDE interface. If your MBR is located on another 
device you should use its name (eg: /dev/hde )

Download and burn the Fedora Core 2 Rescue CD.

Boot from the Rescue CD (there is no need to start networking or mount 
drives)

Issue the command: fdisk -l /dev/hda   to print the current partition table 
to screen in non-interactive mode.

Write down the drive geometry as reported at the beginning of the output 
from fdisk. This is reported as number of Cylinders, Heads, and Sectors 
(hence the name CHS).

You can now reboot the computer by simultaneously holding down the keys 
Ctrl-Alt-Delete.

You can now boot the Fedora Core 2 installation CD. At the first menu prompt 
you should now choose to run the installer with the known geometry.

Example: linux hda=14593,255,63

        The installer should now run normally and not alter your partition table 
geometry entry.  If, for any reason, this geometry should be changed 
regardless of this preventative step, please use the recovery steps to 
correct the geometry of the drive as reported by the partition table.


Recovery:

        You have installed Fedora Core 2 and find that you cannot boot Windows.  
Typically the boot process will terminate with the words

        Rootnoverify(hd0,0)
        Chainloader +1

        These are the boot parameters from your Grub configuration.  The parameters 
are likely to be correct, but Windows fails to boot because Fedora Core 2 
altered the hard disk geometry as reported by the drives partition table.

IMPORTANT: Do not panic and do not begin using multiple tools in an attempt 
to correct this error. Automated tools can be very dangerous. The actual 
changes that need to be made are minor and benign.  By running 3rd party 
applications to recover a bootable Windows installation may cause you to 
lose your data.  You have been warned.

        For those who are technically inclined I include here a brief explanation 
of what is going on.  The drive has not been damaged and your partition 
table is fine.  The problem is that Windows demands a "sane" CHS table.  
This table has been altered by Fedora Cores installer and Windows hangs.  
Luckily, the actual table, in LBA format, is not  corrupted.  For those 
seeing a strange partition table, take note that you are probably looking at 
the table in CHS values and these values are derived from the geometry.  The 
GNU/Linux operating system does not use these values and operates purely 
with LBA values.  Windows should not be using CHS either, but for some 
reason it at least checks this geometry and can be prevented from booting by 
them being bad.  Changing the drive geometry changes the CHS partition table 
because this is a virtualization of the true state of affairs on the drive 
which are best described as being mystical.  Think of CHS geometry as a 
compass.  If you change the geometry you have recalibrated where the 
needles reference point is and you are no longer looking at true north.

        The solution to this problem is very simple, but it may confuse people 
because most people will question why they are seeing strange values 
reported from their partition table in CHS format.  If you do not trust this 
solution or your ability to follow these steps then you should stop and seek 
hard disk recovery consulting services.  The Fedora Project is in no way 
liable for any data loss and this guide is offered without guarantees.  You 
are taking responsibility for what happens.  Now, let us go through the 
solution.

        Because only the drive geometry is altered there is no need for manual 
intervention in the form of discovering and entry of partition information.  
The information in your partition table is correct.  However, you need to 
alter the geometry entry and normally this would require you to re-enter the 
partition table by hand using a tool like fdisk.  This is where the 
application sfdisk comes to the rescue. Sfdisk can be very powerful in 
non-interactive mode, it can output information that can be used as input 
elsewhere, and it can accept data as input at run-time.  This makes sfdisk 
ideal for this solution because you can ask it to read the partition table 
and deliver the result in a way that itself can write back when you tell it 
to change your drive geometry.  This makes the process fast and less prone 
to human error as very few values need to be supplied.  The solution can be 
summed up in a single line with two commands:

        sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda

        So that the reader may better understand what is going on here, lets go 
through what each section does and what the parameters mean.

sfdisk -d /dev/hda

This part runs sfdisk non-interactively and dumps the partition table in a 
format that sfdisk can also use for input (as we are doing).  Try this 
command by itself to see your partition table as it is very safe.  You will 
want to check to check for warnings in the output.  Warnings pose a problem 
because they interfere with the use of this data as input. Output containing 
a warning may look like the example below:

$ sfdisk -d /dev/hda
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
# partition table of /dev/hda
unit: sectors

/dev/hda1 : start=       63, size= 16771797, Id= 7, bootable
/dev/hda2 : start= 16771860, size=217632555, Id= f
/dev/hda3 : start=        0, size=        0, Id= 0
/dev/hda4 : start=        0, size=        0, Id= 0
/dev/hda5 : start= 16771923, size=104856192, Id= 7
/dev/hda6 : start=121628178, size=112776237, Id= 7


For reasons unknown, using the option -- quiet does not suppress all 
warnings so it becomes the task of the user to discover a way to still use 
the output as input.  The simplest way is to write the output to a plain 
text file, editing out the warning in that text file, and using the edited 
text file as the input, thus:

sfdisk -d /dev/hda > MyPartitionTable.txt
        editing MyPartitionTable.txt to remove the warnings, saving the edited 
text, and
cat MyPartitionTable.txt | sfdisk --no-reread -H255 /dev/hda

The output from "sfdisk -d /dev/hda" should begin like this (this is the 
edited version of the example given before):

# partition table of /dev/hda
unit: sectors

/dev/hda1 : start=       63, size= 16771797, Id= 7, bootable
/dev/hda2 : start= 16771860, size=217632555, Id= f
/dev/hda3 : start=        0, size=        0, Id= 0
/dev/hda4 : start=        0, size=        0, Id= 0
/dev/hda5 : start= 16771923, size=104856192, Id= 7
/dev/hda6 : start=121628178, size=112776237, Id= 7

        Note that "cat MyPartitionTable.txt" takes the place of "sfdisk -d 
/dev/hda" as these are now equivalent. In this case the warning portion has 
been stripped, preserving the needed data used by sfdisk in step two of the 
command.

sfdisk --no-reread -H255 /dev/hda

        This portion of the two-part command performs the actual change to your 
hard disk.  This main operation is in -H255. This tells sfdisk to write a 
head count of 255 into the drive geometry.  This command executed by itself 
would ask for user input of the partition table (just like fdisk).  However, 
by piping the table we just read in the first command, this is avoided and 
work is saved and we know the data is correct (or, at least, unchanged).  
This is why sfdisk is used.

        The --no-reread option allows the command to run even when the disk has a 
mounted partition.  Some users may find they need to further force the 
operation to complete. This is done by using --force (sfdisk --no-reread 
--force -H255 /dev/hda).

        In this example we are only changing the number of heads in the geometry.  
If you know the correct number of cylinders before the Fedora Core 
installation changed these values you may also write back this number.   An 
example with 14,593 cylinders is provided below.

sfdisk -d /dev/hda | sfdisk --no-reread -H255 -C14593 /dev/hda

        The number of reported sectors (S) should not have changed and remained as 
63.

        This is the part most likely to be met with the question "if I change the 
number of heads, must I not also change the the number of cylinders?"  The 
answer to this question is "no."  When the geometry was changed the number 
of heads changed from 255 to 16 and the number of cylinders was increased to 
compensate.  As long as the values are large everything should be ok.  Only 
the pedantic need worry about changing the number of cylinders manually.  If 
you do not know the value from before you are best off not supplying this 
number.

        By using this method there is no need, and indeed you should not, run a 
program that wipes the MBR (like fdisk /mbr).  Doing so will cause you to 
lose the Grub pointer installed in the MBR and you will have to use the 
Recovery CD to regain access to your Fedora Core installation.

        Updating Grub after installation seems to have no effect on the drive 
geometry as the problem seems strictly limited to the Fedora Core installer.

Good luck and join us on the IRC at #fedora on irc.freenode.net for any 
questions you have or contributions to the community you wish to make.




From webmaster at margo.bijoux.nom.br  Tue May 25 21:56:12 2004
From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo)
Date: Tue, 25 May 2004 18:56:12 -0300
Subject: Call for Discussion: Summary document concerning
	Prevention andRecovery of XP Dual Boot Problems
In-Reply-To: <604aa7910405251331438a9252@mail.gmail.com>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
	<1085516774.3270.12.camel@dhollis-lnx.kpmg.com>
	<604aa7910405251331438a9252@mail.gmail.com>
Message-ID: <1085522171.14102.2.camel@tirael>

On Tue, 2004-05-25 at 17:31, Jeff Spaleta wrote:
> something is going wrong with getting the full document into the mailinglist...
> its getting chopped....there's no point really discussing this until
> the full doc can be seen correctly. Hell...even Jack's repost of the
> document got eaten by the list demon even though my forward directly
> to him was fine. I've used up my alotment of community goodwill today,
> other people can attempt to get the full document to the list again.
> 
> -jef

Jeff,
by default , mailman limits the size of the messages (configurable for
each mailing list).. The best way is to attach it or post it on a
website and send the link..

--
Pedro Macedo




From jspaleta at gmail.com  Tue May 25 22:01:00 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 25 May 2004 18:01:00 -0400
Subject: Call for Discussion: Summary document concerning
	Prevention andRecovery of XP Dual Boot Problems
In-Reply-To: <1085522171.14102.2.camel@tirael>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
	<1085516774.3270.12.camel@dhollis-lnx.kpmg.com>
	<604aa7910405251331438a9252@mail.gmail.com>
	<1085522171.14102.2.camel@tirael>
Message-ID: <604aa79104052515016c51f66f@mail.gmail.com>

On Tue, 25 May 2004 18:56:12 -0300, Pedro Fernandes Macedo
<webmaster at margo.bijoux.nom.br> wrote:
> Jeff,
> by default , mailman limits the size of the messages (configurable for
> each mailing list).. The best way is to attach it or post it on a
> website and send the link..

Jack got it through....
http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00908.html
that message has the whole document.

Please make 'specific' edit suggestions and test the
stated prevention and recovery methods.

-jef




From fedora-devel at tlarson.com  Tue May 25 22:20:02 2004
From: fedora-devel at tlarson.com (fedora-devel at tlarson.com)
Date: Tue, 25 May 2004 17:20:02 -0500
Subject: Installing without a CDROM or USB drive
Message-ID: <1085523602.40b3c69259cb3@webmail.tlarson.com>

Unfortunately, the size of Fedora's boot image is too large
to fit on a floppy. If you're like me and don't have a CD burner
handy, but also can't boot off a USB drive, you can still boot the 
install image from your hard drive. 

As trivial as the process is, it took me a while to figure out that
it was an option. I'll explain it here to save others headache of 
coming up with a way to install without having to burn any CDs.

Luckily you're already running FC1, right? And you already have
grub installed, right? Perfect. Just tell grub to boot the kernel
provided for USB drives (using the appropriate ramdisk image) and
you're done.                                                                   
                 

Here's a simple command sequence.  Note that this isn't for the
novice. If anything below doesn't look familiar, don't do it.
                                                                               
     
 cd iso_dir
 mkdir mnt1 mnt2
 mount -o loop FC2-i386-disc1.iso mnt1
 mnt -o loop mnt1/images/diskboot.img mnt2
 mkdir /boot/fc2inst
 cp mnt2/vmlinuz mnt2/initrd.img /boot/fc2inst
 umount mnt2
 umount mnt1
 rmdir mnt1 mnt2
                                                                               
     
 reboot
                                                                               
     
When GRUB comes up, hit 'c' to bring up a command prompt...
                                                                               
     
GRUB> kernel /fc2inst/vmlinuz ramdisk_size=8192
GRUB> initrd /fc2inst/initrd.img
GRUB> boot
                                                                               
     
If you did it right, it should boot and run anaconda.
You can specify additional kernel parameters if you want to,
like the location of your kickstart file.

Obviously your file paths may vary (for example, depending on
whether you use a boot partition or not), but this should give 
you an idea of the basic process. Adapt it to your own situation.




From katzj at redhat.com  Tue May 25 22:30:27 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 25 May 2004 18:30:27 -0400
Subject: Installing without a CDROM or USB drive
In-Reply-To: <1085523602.40b3c69259cb3@webmail.tlarson.com>
References: <1085523602.40b3c69259cb3@webmail.tlarson.com>
Message-ID: <1085524227.12971.20.camel@bree.local.net>

On Tue, 2004-05-25 at 17:20 -0500, fedora-devel at tlarson.com wrote:
> Luckily you're already running FC1, right? And you already have
> grub installed, right? Perfect. Just tell grub to boot the kernel
> provided for USB drives (using the appropriate ramdisk image) and
> you're done.                                                                   

There's an even simpler thing you can do...
  
>  cd iso_dir
>  mkdir mnt1 mnt2
>  mount -o loop FC2-i386-disc1.iso mnt1
>  mnt -o loop mnt1/images/diskboot.img mnt2
Not needed
>  mkdir /boot/fc2inst
>  cp mnt2/vmlinuz mnt2/initrd.img /boot/fc2inst
Instead, do cp mnt1/isolinux/{vmlinuz,initrd.img} /boot/fc2inst
>  umount mnt2
Then this isn't needed either
>  umount mnt1
>  rmdir mnt1 mnt2

Cheers,

Jeremy




From alan at redhat.com  Tue May 25 22:45:23 2004
From: alan at redhat.com (Alan Cox)
Date: Tue, 25 May 2004 18:45:23 -0400
Subject: Call for Discussion: Summary document concerning Prevention and
	Recovery of XP Dual Boot Problems
In-Reply-To: <604aa79104052511586a67d722@mail.gmail.com>
References: <604aa79104052511586a67d722@mail.gmail.com>
Message-ID: <20040525224523.GB6612@devserv.devel.redhat.com>

On Tue, May 25, 2004 at 02:58:35PM -0400, Jeff Spaleta wrote:
> during installation by using the hdN=<drive geometry> parameter (where N is
> the letter representing the drive with the MBR you will use).  To discover
> the current geometry before installing Fedora Core 2 you should use a
> utility that can read the drive geometry as reported in the partition table

Looking in the BIOS is another way for many boxes. Also if you set the 
bios to LBA that is reported by many to keep stuff happy




From jspaleta at gmail.com  Tue May 25 23:04:02 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 25 May 2004 19:04:02 -0400
Subject: Call for Discussion: Summary document concerning Prevention
	and Recovery of XP Dual Boot Problems
In-Reply-To: <20040525224523.GB6612@devserv.devel.redhat.com>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<20040525224523.GB6612@devserv.devel.redhat.com>
Message-ID: <604aa7910405251604671af9cd@mail.gmail.com>

On Tue, 25 May 2004 18:45:23 -0400, Alan Cox <alan at redhat.com> wrote:
> Looking in the BIOS is another way for many boxes. Also if you set the
> bios to LBA that is reported by many to keep stuff happy

yes looking around... it seems using the bios to put the drive into
LBA mode even
comes up as a workaround for madrake's release.

-jef




From webmaster at margo.bijoux.nom.br  Tue May 25 23:10:51 2004
From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo)
Date: Tue, 25 May 2004 20:10:51 -0300
Subject: Call for Discussion: Summary document concerning
	Prevention and Recovery of XP Dual Boot Problems
In-Reply-To: <604aa7910405251604671af9cd@mail.gmail.com>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<20040525224523.GB6612@devserv.devel.redhat.com>
	<604aa7910405251604671af9cd@mail.gmail.com>
Message-ID: <1085526651.14102.7.camel@tirael>

On Tue, 2004-05-25 at 20:04, Jeff Spaleta wrote:
> On Tue, 25 May 2004 18:45:23 -0400, Alan Cox <alan at redhat.com> wrote:
> > Looking in the BIOS is another way for many boxes. Also if you set the
> > bios to LBA that is reported by many to keep stuff happy
> 
> yes looking around... it seems using the bios to put the drive into
> LBA mode even
> comes up as a workaround for madrake's release.
> 
> -jef
> 
I have to add that this corrects the problem in , let's say , 99% of the
cases. However , sometimes it does nothing (here I had my drive set to
LBA after FC1.92 was installed and it didnt work. Then when core 2 was
released , the same bug appeared...)

--
Pedro Macedo




From dnjinc at wowway.com  Wed May 26 01:00:39 2004
From: dnjinc at wowway.com (Demond James)
Date: Tue, 25 May 2004 21:00:39 -0400
Subject: Unresolved dependencies in Rawhide 05/25/04
Message-ID: <1085533239.17588.5.camel@lanos>

Unresolvable chain of dependencies:
abiword  2.0.6-1                         requires libcrlayeng.so.1
abiword  2.0.6-1                         requires libcroco.so.1
abiword  2.0.6-1                         requires libcrseleng.so.2
gnome-bluetooth  0.4.1-7                 requires libcrlayeng.so.1
gnome-bluetooth  0.4.1-7                 requires libcroco.so.1
gnome-bluetooth  0.4.1-7                 requires libcrseleng.so.2
initscripts-7.54-1                       requires pppd < 2.3.9
rusers-server  0.17-37                   requires libproc.so.3.2.0
rusers-server  0.17-37                   requires
libproc.so.3.2.0(_3_1_14)




From fedora at wir-sind-cool.org  Wed May 26 01:36:33 2004
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 26 May 2004 03:36:33 +0200
Subject: Call for Discussion: Summary document concerning Prevention
 andRecovery of XP Dual Boot Problems
In-Reply-To: <604aa7910405251331438a9252@mail.gmail.com>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
	<1085516774.3270.12.camel@dhollis-lnx.kpmg.com>
	<604aa7910405251331438a9252@mail.gmail.com>
Message-ID: <20040526033633.51d63aa8.fedora@wir-sind-cool.org>

On Tue, 25 May 2004 16:31:31 -0400, Jeff Spaleta wrote:

> On Tue, 25 May 2004 16:26:14 -0400, David T Hollis
> <dhollis at davehollis.xxx> wrote:
> > I agree on this point totally.  What format is the geometry in?  I've
> > seen various ways of reporting HD geometry from straight cylinder counts
> > (4134788423 cyl), to the CHS 16/8/64 whatever style, etc.  A sample of
> > what the user would be looking for would probably be very helpful.
> 
> something is going wrong with getting the full document into the mailinglist...
> its getting chopped....there's no point really discussing this until
> the full doc can be seen correctly. Hell...even Jack's repost of the
> document got eaten by the list demon even though my forward directly
> to him was fine. I've used up my alotment of community goodwill today,
> other people can attempt to get the full document to the list again.

The most common cause is a bug in mailman. It cuts off the message when it
encounters a period '.' on a line by itself as if it were an SMTP message
body delimiter. In your message, the last line was

  utility that can read the drive geometry as reported in the partition table

and the period behind "table" is missing [compared with Jack's posting],
because probably it was auto-wrapped into the next line where mailman then
cut off the message. You should be able to reproduce this in every message
by adding some text after a line which contains nothing else than a period.




From sopwith at redhat.com  Wed May 26 01:45:09 2004
From: sopwith at redhat.com (Elliot Lee)
Date: Tue, 25 May 2004 21:45:09 -0400 (EDT)
Subject: Unresolved dependencies in Rawhide 05/25/04
In-Reply-To: <1085533239.17588.5.camel@lanos>
References: <1085533239.17588.5.camel@lanos>
Message-ID: <Pine.LNX.4.58.0405252142220.699@devserv.devel.redhat.com>

On Tue, 25 May 2004, Demond James wrote:

> Unresolvable chain of dependencies:

At this stage in the development cycle, these are pretty much the norm -
things are "under development". As we get closer to a release, these
should disappear.

-- Elliot
The daring is in the doing

http://people.redhat.com/sopwith/




From sopwith at redhat.com  Wed May 26 01:55:24 2004
From: sopwith at redhat.com (Elliot Lee)
Date: Tue, 25 May 2004 21:55:24 -0400 (EDT)
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <20040525205723.GA25684@jadzia.bu.edu>
References: <20040525205723.GA25684@jadzia.bu.edu>
Message-ID: <Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>

Well, for the packages in fedora core, the 'Group:' field will need to
remain, since we use it for things like sorting debuginfo packages into
separate dirs and such. It is also useful for quick 'what does this
package do' ponderings when looking at rpm -qip output.

I'm sure package maintainers would welcome patches to update errant Group:  
fields that don't match the proper format.

Cheers,
-- Elliot
The daring is in the doing

http://people.redhat.com/sopwith/




From mattdm at mattdm.org  Wed May 26 02:14:43 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 25 May 2004 22:14:43 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
Message-ID: <20040526021443.GA4031@jadzia.bu.edu>

On Tue, May 25, 2004 at 09:55:24PM -0400, Elliot Lee wrote:
> Well, for the packages in fedora core, the 'Group:' field will need to
> remain, since we use it for things like sorting debuginfo packages into
> separate dirs and such. It is also useful for quick 'what does this
> package do' ponderings when looking at rpm -qip output.

But what's the good of sorting them into separate dirs by vague and
ill-fitting categories? If it's a matter of keeping directory size down,
grouping by first letter would be better. Or, do it via comps.xml groups
(with a big "other" category for everything else). Or use some other more
meaningful test.

The same complaint goes for the -qip argument -- a category like "System
Environment/Base" doesn't tell you much about what ScrollKeeper does, or
"Applications/Internet" much about openssh-askpass. And "System
Environment/Daemons" for procmail??? You'll get much more useful (and
quicker) information by looking at the Summary.


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




From rhally at mindspring.com  Wed May 26 02:48:25 2004
From: rhally at mindspring.com (Richard Hally)
Date: Tue, 25 May 2004 22:48:25 -0400
Subject: Unresolved dependencies in Rawhide 05/25/04
In-Reply-To: <Pine.LNX.4.58.0405252142220.699@devserv.devel.redhat.com>
References: <1085533239.17588.5.camel@lanos>
	<Pine.LNX.4.58.0405252142220.699@devserv.devel.redhat.com>
Message-ID: <40B40579.8050801@mindspring.com>

Elliot Lee wrote:

> On Tue, 25 May 2004, Demond James wrote:
> 
> 
>>Unresolvable chain of dependencies:
> 
> 
> At this stage in the development cycle, these are pretty much the norm -
> things are "under development". As we get closer to a release, these
> should disappear.
> 
> -- Elliot
> The daring is in the doing
> 
> http://people.redhat.com/sopwith/
> 
> 
Aren't these types of dependency screw ups usually fixed by the 
responsible packager within a day or two of them being reported?
It's a pain in the butt to continually have to add more and more 
--exclude switches to 'yum update' to get past these problems to get the 
day's updates
Thanks for your help
Richard Hally




From brads at redhat.com  Wed May 26 01:20:51 2004
From: brads at redhat.com (Brad Smith)
Date: Tue, 25 May 2004 21:20:51 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <20040526021443.GA4031@jadzia.bu.edu>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
	<20040526021443.GA4031@jadzia.bu.edu>
Message-ID: <1085534451.7850.44.camel@localhost.localdomain>

Perhaps I've totally misunderstood you, but are you suggesting that we
do away with having any grouping information in the rpm headers at all
and instead having it all in comps.xml? 

If so, what about packages that don't appear in comps.xml? Let's face
it, a lot of people are going to install packages from the third-party
repos and it would be awkward at best to just have them all lumped into
an "Other" category.

Plus I have a personal interest in doing the opposite of what you're
suggesting. Currently the headers stored on apt and yum servers don't
include the Group field though it would be great for people to be able
to search by in Fedora Tracker. Thus I'm very pleased that the new XML
metadata format does include this information. 

Assuming I didn't misinterpret your post, is there any way we can
reconcile the two approaches? 

--Brad 




From skvidal at phy.duke.edu  Wed May 26 04:29:11 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 26 May 2004 00:29:11 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085534451.7850.44.camel@localhost.localdomain>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
	<20040526021443.GA4031@jadzia.bu.edu>
	<1085534451.7850.44.camel@localhost.localdomain>
Message-ID: <1085545751.15229.3.camel@binkley>


> Plus I have a personal interest in doing the opposite of what you're
> suggesting. Currently the headers stored on apt and yum servers don't
> include the Group field though it would be great for people to be able
> to search by in Fedora Tracker. Thus I'm very pleased that the new XML
> metadata format does include this information. 

The yum headers and the apt headers do include this information.


The group field is too freeform. If it is to be used it needs to be
restricted.

-sv





From jspaleta at gmail.com  Wed May 26 04:36:27 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 26 May 2004 00:36:27 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085534451.7850.44.camel@localhost.localdomain>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
	<20040526021443.GA4031@jadzia.bu.edu>
	<1085534451.7850.44.camel@localhost.localdomain>
Message-ID: <604aa791040525213637efee3c@mail.gmail.com>

On Tue, 25 May 2004 21:20:51 -0400, Brad Smith <brads at redhat.com> wrote:
> If so, what about packages that don't appear in comps.xml? Let's face
> it, a lot of people are going to install packages from the third-party
> repos and it would be awkward at best to just have them all lumped into
> an "Other" category.

Once repos start producing their own comps.xml files, and the
management tools understand you to handle repo specific comps.xml
files...there is no all encompassing "Other" category.
 
> Plus I have a personal interest in doing the opposite of what you're
> suggesting. Currently the headers stored on apt and yum servers don't
> include the Group field though it would be great for people to be able
> to search by in Fedora Tracker. Thus I'm very pleased that the new XML
> metadata format does include this information.

Only if the group field is useful...which it isnt, if yer suppose to
stick with the canonical groupnames as mentioned in the parent post.
Some yum mirrors understand yum's group commands that work of of
comps.xml file definitions. Hell even if you are using a Fedora Core
mirror with yum that doesnt support yum's group features you can steal
the comps.xml file and stick it in yer yum cache and get the group
functionality back.  Hell...you can even imagine having people create
personalized comps.xml files for use with yum that regroup the same
repository to better suit their needs. There is no reason that each
repo can not define their own comps.xml groupings to be useful both as
a way to group categories in a way that makes intuitive sense for that
repository and to use as a metapackage installation method.  Usage of
comps.xml files at all repositories makes sense, if there is any
desire to make it possible for people to use 3rd party media sets at
install time (at some point in the future) or when
system-config-packages gets rebaked to include support for repos.
Relying on the somewhat static and inflexible Group tag that rpm knows
about is revisionist history at this point. The base distro tools have
moved very far away from that and rely heavily on comps information
now. Instead of moving back in time, we need to move forward and make
usage of the comps file MORE pervasive and build tools to help repos
build and maintainer their own comps files that provide the grouping
information to the distro tools that understand grouping.



-jef




From brads at redhat.com  Wed May 26 01:40:03 2004
From: brads at redhat.com (Brad Smith)
Date: Tue, 25 May 2004 21:40:03 -0400
Subject: Call for Discussion: Summary document concerning Prevention
	andRecovery of XP Dual Boot Problems
In-Reply-To: <001b01c4428f$52bed090$0200a8c0@gandalf>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
Message-ID: <1085535602.7850.51.camel@localhost.localdomain>

> Now this leads to my actual question.. Is it really smart to
> leave FC2 out there when this scenario will probably hit a lot of people?

This has been on my mind as well. The Mandrake bugzilla entry mentions a
fix (or anaconda? grub?) being in Cooker (their unstable distro) and so
assumedly in the just-released MDK10-Official. That leaves FC2 in the
unenviable position of being the only(?) distro out there afflicted with
this problem. 

So in other words:

a) Is a fix being developed (by whom? if not, who wants it?)

b) Once it's developed, can we replace the FC2 ISOs on the website and
mirrors with ones that incorporate the fix?

--Brad




From skvidal at phy.duke.edu  Wed May 26 04:41:33 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 26 May 2004 00:41:33 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <604aa791040525213637efee3c@mail.gmail.com>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
	<20040526021443.GA4031@jadzia.bu.edu>
	<1085534451.7850.44.camel@localhost.localdomain>
	<604aa791040525213637efee3c@mail.gmail.com>
Message-ID: <1085546493.15229.6.camel@binkley>

> Only if the group field is useful...which it isnt, if yer suppose to
> stick with the canonical groupnames as mentioned in the parent post.
> Some yum mirrors understand yum's group commands that work of of
> comps.xml file definitions. Hell even if you are using a Fedora Core
> mirror with yum that doesnt support yum's group features you can steal
> the comps.xml file and stick it in yer yum cache and get the group
> functionality back.  Hell...you can even imagine having people create
> personalized comps.xml files for use with yum that regroup the same
> repository to better suit their needs. There is no reason that each
> repo can not define their own comps.xml groupings to be useful both as
> a way to group categories in a way that makes intuitive sense for that
> repository and to use as a metapackage installation method.  Usage of
> comps.xml files at all repositories makes sense, if there is any
> desire to make it possible for people to use 3rd party media sets at
> install time (at some point in the future) or when
> system-config-packages gets rebaked to include support for repos.


To that point.
http://linux.duke.edu/projects/yum/download/misc/yumgengroups.py

That script lets you relatively easily generate your own yumgroups.xml
file.

yum will merge groups files b/t repositories - but packages from any
repository can be listed in any yumgroups.xml file.

-sv





From brads at redhat.com  Wed May 26 01:49:54 2004
From: brads at redhat.com (Brad Smith)
Date: Tue, 25 May 2004 21:49:54 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <604aa791040525213637efee3c@mail.gmail.com>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
	<20040526021443.GA4031@jadzia.bu.edu>
	<1085534451.7850.44.camel@localhost.localdomain>
	<604aa791040525213637efee3c@mail.gmail.com>
Message-ID: <1085536194.7850.60.camel@localhost.localdomain>

It seems that what we're talking about here is a matter of
standardization, not of storing Group info in comps.xml being better
than storing it in the package header. I mean, someone could create a
comps.xml with wacky groupings just as easily as they could add wacky
groupings to their package's headers, right? Or am I misunderstanding
some aspect of this?

I concede the point about utils like anaconda being geared more toward
using comps.xml than the Group field and agree that we should settle on
one rather than both. But I'm not convinced that it's better to keep all
this information in one file (even one file per repo) instead of in the
packages themselves. What, other than current development trends,
warrants the use of a file that would need to be updated every time a
package got added to a repository if reaching an accepted standard for
Group field values would suffice?

--Brad







From brads at redhat.com  Wed May 26 01:51:11 2004
From: brads at redhat.com (Brad Smith)
Date: Tue, 25 May 2004 21:51:11 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085545751.15229.3.camel@binkley>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
	<20040526021443.GA4031@jadzia.bu.edu>
	<1085534451.7850.44.camel@localhost.localdomain>
	<1085545751.15229.3.camel@binkley>
Message-ID: <1085536271.7850.63.camel@localhost.localdomain>

On Wed, 2004-05-26 at 00:29, seth vidal wrote:
> > Plus I have a personal interest in doing the opposite of what you're
> > suggesting. Currently the headers stored on apt and yum servers don't
> > include the Group field though it would be great for people to be able
> > to search by in Fedora Tracker. Thus I'm very pleased that the new XML
> > metadata format does include this information. 
> 
> The yum headers and the apt headers do include this information.
> 

My bad. I took apart a header once and couldn't find it. I'll go look
again.

> 
> The group field is too freeform. If it is to be used it needs to be
> restricted.

Point taken. See my response to Jeff Spaleta. 

--Brad




From Nicolas.Mailhot at laPoste.net  Wed May 26 06:17:20 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 26 May 2004 08:17:20 +0200
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <20040525205723.GA25684@jadzia.bu.edu>
References: <20040525205723.GA25684@jadzia.bu.edu>
Message-ID: <1085552240.10293.50.camel@m64.net81-64-154.noos.fr>

Le mar, 25/05/2004 ? 16:57 -0400, Matthew Miller a ?crit :

> But that's not my suggestion. I think Group has become too ugly to be
> properly saved. Applications like synaptic should instead use the comps file
> groups for organizational purposes. 

Comps is totally unsuitable since it limits you to whatever packages
where known to the distribution at the time of its release. (ie bye bye
third-party packages).

Like for spec file i18n we need a solution that permits standalone
self-contained packages. Anything else will sort-of work with RedHat and
be rejected by anyone else.

Now if you want mon opinion on rpm organisation, a mix of a Keywords
in-spec field (Matches: java, games, x11) and external group
declarations (external group descriptors, including user-provided group
overlays and perhaps grouping policy files) is the way to go. Really
this is much the same problem as menu building for example.

Cheers,

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

From skvidal at phy.duke.edu  Wed May 26 06:33:12 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 26 May 2004 02:33:12 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
Message-ID: <1085553192.15997.5.camel@binkley>


> Comps is totally unsuitable since it limits you to whatever packages
> where known to the distribution at the time of its release. (ie bye bye
> third-party packages).

Anyone can generate a comps file, trivially. The groups support in yum,
for example, can merge multiple comps-format files into one set of
groups.

> Like for spec file i18n we need a solution that permits standalone
> self-contained packages. Anything else will sort-of work with RedHat and
> be rejected by anyone else.

standalone packages are slowly becoming obsolete.

There is no point in discussing groups for standalone packages b/c a
standalone is not a member of any group by its very nature - it is
standalone.

-sv





From dwmw2 at infradead.org  Wed May 26 06:36:58 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 26 May 2004 07:36:58 +0100
Subject: safe to remove IPV6 from kernel?
In-Reply-To: <20040522142521.GA24751@devserv.devel.redhat.com>
References: <1085095592.9697.37.camel@duergar> <40AD695F.4070409@redhat.com>
	<1085108015.9697.46.camel@duergar> <40AD75D7.1070103@redhat.com>
	<1085194238.9697.1004.camel@duergar>
	<20040522142521.GA24751@devserv.devel.redhat.com>
Message-ID: <1085553418.27156.1516.camel@imladris.demon.co.uk>

On Sat, 2004-05-22 at 10:25 -0400, Alan Cox wrote:
> On Fri, May 21, 2004 at 10:50:38PM -0400, Stan Bubrouski wrote:
> > First of all I'm sick of this attitude Warren.  I wasn't asking YOU to
> > remove IPv6 from the kernel.  My question was if I remove it, am I going
> > to face problems...
> 
> gftp might break. There was a bug with gftp and ipv6 aware sites that
> Im not sure was fixed by gftp updates, by the fact with have ipv6 or
> in both.

This may have been 'fixed' by the fact that glibc-2.3.3 has a proper
implementation of RFC3484 and will actually return the addresses in
order of the probability of being able to connect to them -- in
particular, if there's an IPv6 global address and an IPv4 address in the
RRset and you don't have a global IPv6 address of your own, it should
return the IPv6 address of the host you're looking up last in the list.

However, if gftp isn't bothering to try _all_ the addresses it's given,
but instead is claiming failure when the first one isn't contactable, it
still wants fixing. Evolution has the same problem.

-- 
dwmw2





From Nicolas.Mailhot at laPoste.net  Wed May 26 06:53:55 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 26 May 2004 08:53:55 +0200
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085553192.15997.5.camel@binkley>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
	<1085553192.15997.5.camel@binkley>
Message-ID: <1085554435.10293.78.camel@m64.net81-64-154.noos.fr>

Le mer, 26/05/2004 ? 02:33 -0400, seth vidal a ?crit :
> > Comps is totally unsuitable since it limits you to whatever packages
> > where known to the distribution at the time of its release. (ie bye bye
> > third-party packages).
> 
> Anyone can generate a comps file, trivially. The groups support in yum,
> for example, can merge multiple comps-format files into one set of
> groups.
> 
> > Like for spec file i18n we need a solution that permits standalone
> > self-contained packages. Anything else will sort-of work with RedHat and
> > be rejected by anyone else.
> 
> standalone packages are slowly becoming obsolete.
> 
> There is no point in discussing groups for standalone packages b/c a
> standalone is not a member of any group by its very nature - it is
> standalone.

Of course not - take very small repositories (like the evo 1.5 one,
arjanv kernel, rpms released by the developpers of a given app, etc)

They do exist. They are very useful. But they shouldn't be required ot
maintain all the infrastructure of a full-blown repo with hundreds of
packages.

Big repos need to standardise common categories. But they should not
decide what rpm comes into which category. A rpm must be able to declare
itself where it hooks.

Again, this is much the same problem as menus, and the freedesktop
people were right to choose a solution where each app can just put a
descriptor somewhere instead of relying on a big centralised standalone
db.

What all those separate rpms need are standard keyword/categories,
nothing more.

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

From kewley at cns.caltech.edu  Wed May 26 06:22:11 2004
From: kewley at cns.caltech.edu (David Kewley)
Date: Tue, 25 May 2004 23:22:11 -0700
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085536194.7850.60.camel@localhost.localdomain>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
Message-ID: <200405252322.11584.kewley@cns.caltech.edu>

Brad Smith wrote on Tuesday 25 May 2004 18:49:
> I concede the point about utils like anaconda being geared more toward
> using comps.xml than the Group field and agree that we should settle on
> one rather than both. But I'm not convinced that it's better to keep all
> this information in one file (even one file per repo) instead of in the
> packages themselves. What, other than current development trends,
> warrants the use of a file that would need to be updated every time a
> package got added to a repository if reaching an accepted standard for
> Group field values would suffice?

I collect packages from various places, make a yumgroups.xml (yum's analog 
to comps.xml), and publish my own package groups in my local custom yum 
repository.  I'd have to rebuild all the collected packages with my own 
Group: header if install-group membership was keyed off of that header 
instead of yumgroups.xml.

Possibly after a careful rethinking of the problem, it would become clear 
that a Group: header suffices, but right now it's awfully handy to have an 
easily-edited yumgroups.xml.

David




From dwmw2 at infradead.org  Wed May 26 07:01:22 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 26 May 2004 08:01:22 +0100
Subject: FC 2 - RPM virtual provides on PIE broken (odd
	conflicts/triggers)
In-Reply-To: <20040521115111.GA32686@devserv.devel.redhat.com>
References: <20040521115111.GA32686@devserv.devel.redhat.com>
Message-ID: <1085554882.27156.1547.camel@imladris.demon.co.uk>

On Fri, 2004-05-21 at 07:51 -0400, Paul Nasrat wrote:
> Some people will be experiencing  odd behaviour due to the way rpm adds library provides - this can causes any PIE executables to be added as 
> 
> Provides: $(basename /path/to/foo)
> 
> A name level provides matches all EVR so known issues - spurious conflicts,
> misfired triggers, etc occur. As more things in rawhide get built
> -fPIE it's something to be aware of untill an errata can be issued.

'an erratum' HTH.

Is there a way to disable the automatic Provides, other than just
disabling PIE? If I build ppp, it suddenly starts providing pppd, which
it never did before -- and initscripts has a Conflicts: for pppd <
2.3.9. (which should presumably be ppp < 2.3.9; BZ #124386)

-- 
dwmw2





From pnasrat at redhat.com  Wed May 26 07:49:39 2004
From: pnasrat at redhat.com (Paul Nasrat)
Date: Wed, 26 May 2004 03:49:39 -0400
Subject: FC 2 - RPM virtual provides on PIE broken (odd
	conflicts/triggers)
In-Reply-To: <1085554882.27156.1547.camel@imladris.demon.co.uk>
References: <20040521115111.GA32686@devserv.devel.redhat.com>
	<1085554882.27156.1547.camel@imladris.demon.co.uk>
Message-ID: <20040526074939.GB15609@devserv.devel.redhat.com>

On Wed, May 26, 2004 at 08:01:22AM +0100, David Woodhouse wrote:
> On Fri, 2004-05-21 at 07:51 -0400, Paul Nasrat wrote:

> > Some people will be experiencing  odd behaviour due to the way rpm adds
> > library provides - this can causes any PIE executables to be added as 
> > 
> > Provides: $(basename /path/to/foo)
> > 
> > A name level provides matches all EVR so known issues - spurious conflicts,
> > misfired triggers, etc occur. As more things in rawhide get built -fPIE

> Is there a way to disable the automatic Provides, other than just
> disabling PIE? 

I think if you disable the internal depgen stuff that find-provides won't do this which is a temporary work around - try adding the following to the spec:

%define _use_internal_dependency_generator 0

Paul




From buildsys at redhat.com  Wed May 26 09:02:01 2004
From: buildsys at redhat.com (Build System)
Date: Wed, 26 May 2004 05:02:01 -0400
Subject: rawhide report: 20040526 changes
Message-ID: <200405260902.i4Q921M15649@porkchop.devel.redhat.com>




From Nicolas.Mailhot at laPoste.net  Wed May 26 09:02:36 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 26 May 2004 11:02:36 +0200
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <200405252322.11584.kewley@cns.caltech.edu>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
Message-ID: <1085562157.13536.11.camel@ulysse.olympe.o2t>

Le mar, 25/05/2004 ? 23:22 -0700, David Kewley a ?crit :
> Brad Smith wrote on Tuesday 25 May 2004 18:49:
> > I concede the point about utils like anaconda being geared more toward
> > using comps.xml than the Group field and agree that we should settle on
> > one rather than both. But I'm not convinced that it's better to keep all
> > this information in one file (even one file per repo) instead of in the
> > packages themselves. What, other than current development trends,
> > warrants the use of a file that would need to be updated every time a
> > package got added to a repository if reaching an accepted standard for
> > Group field values would suffice?
> 
> I collect packages from various places, make a yumgroups.xml (yum's analog 
> to comps.xml), and publish my own package groups in my local custom yum 
> repository.  I'd have to rebuild all the collected packages with my own 
> Group: header if install-group membership was keyed off of that header 
> instead of yumgroups.xml.
> 
> Possibly after a careful rethinking of the problem, it would become clear 
> that a Group: header suffices, but right now it's awfully handy to have an 
> easily-edited yumgroups.xml.

The fact is, you need both.

The application developer that publishes on rpm of its app on sf need to
be able to select where it will appear in the rpm classification (via
keywords/categories hints)

The distribution people need to be able to choose the policy that
classifies stuff based on the keywords/names provided by each individual
rpm (and yes this can be a policy as dumb as : the members of the foo
group are bar1, bar2, bar3). This policy includes defining standard
keywords/categories/hints

The sysadmin needs to be able to add its own custom overlay to this
standard policy (Jane's stuff group is ...), either to accommodate his
local users needs or a third-party repo that is not covered by the
standard policy.

Any setup that does not allow in-package hints, distro policy and local
sysadmin overlay will f*-up one of these people.

Cheers,

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

From stuart at terminus.co.uk  Wed May 26 09:47:41 2004
From: stuart at terminus.co.uk (Stuart Children)
Date: Wed, 26 May 2004 10:47:41 +0100
Subject: rpm package renames
Message-ID: <20040526094741.GA2710@urchin.earth.li>

Hi

Suppose I have a package foo, which I need to rename to bar (to better fit 
package naming guidelines, or for trademark reasons say). What exact magic 
do I need in my bar spec file to ensure upgrades go smoothly? "Obsoletes: 
foo" obviously. I'm guessing probably also restricting it to <= the last 
version released as foo to be paranoid - is that definitely 
necessary/suggested?

I've seen some notes saying that Obsoletes should be paired with Provides. 
In what situations should one do that? If I'm certain foo is not 
explicitely Required by any other packages, can I safely skip it?

Whilst playing around I noticed that if the versions of foo and bar are 
the same (which in this case they won't be, but consider bar being a whole 
new project that is designed to replace foo) then foo is not removed 
when upgrading to bar. Which confused the hell out of me for a while 
last night (that and the difference installing vs upgrading, but I can 
understand that). :)

I can't find any definite guidelines or indeed explainations of exactly 
how rpm treats Obsoletes. This is very frustrating, and lack of 
documentation is surely a reason why packaging is sometimes considered a 
black art when it should be quite accessible to developers.

Anyway, if people can come up with some guidelines here then perhaps they 
could be added to the following pages:

http://fedora.redhat.com/participate/developers-guide/ch-rpm-building.html
http://www.fedora.us/wiki/PackagingHints

PS: Before I forget, is there an easy way to find out who is supposed to 
be maintaining a particular package in the fedora.us repository?

TIA

-- 
Stuart




From chabotc at 4-ice.com  Wed May 26 11:00:06 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Wed, 26 May 2004 13:00:06 +0200
Subject: rpm package renames
References: <20040526094741.GA2710@urchin.earth.li>
Message-ID: <008901c44310$9aeeb750$0200a8c0@gandalf>

Hi Stuart,

Just Obsoletes: should do just fine.

Personaly i do always use a Provides: Even if it's just as documentation of
the past ('this packages used to be called..') and who knows what weird
dependencies 3rd party rpm's have; So it's just good form. However if your
certain nothing ever depends on the package, ofcource it could be left out
(but unless the package was never released 'in the wild', how can you be
certain?)

To prevent the side by side install when they are the same version, a
Conflicts: tag should do the trick.. (Conflicts: foo)

ps, if your into the black arts of rpm packaging (or just have questions
like these), rpm-list at redhat.com is a more suitable list, and has a few
resident packaging experts on it..

----- Original Message ----- 
From: "Stuart Children" <stuart at terminus.co.uk>
To: <fedora-devel-list at redhat.com>
Sent: Wednesday, May 26, 2004 11:47
Subject: rpm package renames


> Hi
>
> Suppose I have a package foo, which I need to rename to bar (to better fit
> package naming guidelines, or for trademark reasons say). What exact magic
> do I need in my bar spec file to ensure upgrades go smoothly? "Obsoletes:
> foo" obviously. I'm guessing probably also restricting it to <= the last
> version released as foo to be paranoid - is that definitely
> necessary/suggested?
>
> I've seen some notes saying that Obsoletes should be paired with Provides.
> In what situations should one do that? If I'm certain foo is not
> explicitely Required by any other packages, can I safely skip it?
>
> Whilst playing around I noticed that if the versions of foo and bar are
> the same (which in this case they won't be, but consider bar being a whole
> new project that is designed to replace foo) then foo is not removed
> when upgrading to bar. Which confused the hell out of me for a while
> last night (that and the difference installing vs upgrading, but I can
> understand that). :)
>
> I can't find any definite guidelines or indeed explainations of exactly
> how rpm treats Obsoletes. This is very frustrating, and lack of
> documentation is surely a reason why packaging is sometimes considered a
> black art when it should be quite accessible to developers.
>
> Anyway, if people can come up with some guidelines here then perhaps they
> could be added to the following pages:
>
> http://fedora.redhat.com/participate/developers-guide/ch-rpm-building.html
> http://www.fedora.us/wiki/PackagingHints
>
> PS: Before I forget, is there an easy way to find out who is supposed to
> be maintaining a particular package in the fedora.us repository?
>
> TIA
>
> -- 
> Stuart
>
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>




From chabotc at 4-ice.com  Wed May 26 12:10:42 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Wed, 26 May 2004 14:10:42 +0200
Subject: Prevention and Recovery of XP Dual Boot Problems
References: <1085520305.1990.48.camel@deepfort>
Message-ID: <003601c4431a$778b11f0$0200a8c0@gandalf>

Credit where credit is due.. This is a great and well written document,
thanks to the writers and the people who are publishing it

The only sections i'd like to see added is "Set your BIOS disk mode to LBA"
to prevention (which works for some ppl, very new bios'es only have auto/chs
though), and i would also love to see a small chapter on "How did this bug
ever happen" (From what i've been able to gather, it is caused by changes in
the 2.6.x kernel where it was decided HD layout translation should be
handled in user space (which obviously we didn't do..) which causes this
problem)


----- Original Message ----- 
From: "Jack Aboutboul" <jaboutboul at speakeasy.net>
To: <fedora-devel-list at redhat.com>
Sent: Tuesday, May 25, 2004 23:25
Subject: Prevention and Recovery of XP Dual Boot Problems


> This is the whole document for those who didnt get it.
>
> <---BEGIN--->
>
> Dual Booting Issues With Fedora Core 2 and Windows: Prevention & Recovery
>
> NOTICE: Please read this document in its entirety.
>
> This guide was inspired by the solution developed by Radu Cornea and
> Alexandre Oliva in this thread:
> http://www.redhat.com/archives/fedora-test-list/2004-May/msg02114.html .
> This guide aims to integrate the original solution with the refinements
> evolved in that thread.  This guide offers an explanation of why the
> refinements are beneficial and some workarounds to problems that may
prevent
> the uninitiated from using the solution. It also provides a means of
> preventing the problem entirely.
>
> Primer:
>
>         There is a bug in Fedora Core 2 that causes the hard disk geometry
as
> reported in the partition table to be altered during installation.  This
> change may cause Windows boot failure.  Although this bug is severe, it is
> recoverable and no data should be lost.  It is important not to panic if
and
> when this happens so you do not cause further problems or cause actual
loss
> of data in the process of recovering from the error.
>
> Prevention:
>
>         This bug can be avoided entirely by using some preventative steps
while
> installing Fedora Core 2.  Thanks go out to Cero (cero at coolnetworx.net)
for
> discovery and testing of this solution.
>
>         To avoid the hard disk geometry to be altered you may enter it
manually
> during installation by using the hdN=<drive geometry> parameter (where N
is
> the letter representing the drive with the MBR you will use).  To discover
> the current geometry before installing Fedora Core 2 you should use a
> utility that can read the drive geometry as reported in the partition
table.
> It is important to understand that some tools may not be reporting the
> actual data from this location, but, rather, some derived value, so your
> surest way is to use the fdisk utility.  You can get this information by
> following these steps.
>
> Note: This example will assume you are looking at /dev/hda, which is the
> master on the primary IDE interface. If your MBR is located on another
> device you should use its name (eg: /dev/hde )
>
> Download and burn the Fedora Core 2 Rescue CD.
>
> Boot from the Rescue CD (there is no need to start networking or mount
> drives)
>
> Issue the command: fdisk -l /dev/hda   to print the current partition
table
> to screen in non-interactive mode.
>
> Write down the drive geometry as reported at the beginning of the output
> from fdisk. This is reported as number of Cylinders, Heads, and Sectors
> (hence the name CHS).
>
> You can now reboot the computer by simultaneously holding down the keys
> Ctrl-Alt-Delete.
>
> You can now boot the Fedora Core 2 installation CD. At the first menu
prompt
> you should now choose to run the installer with the known geometry.
>
> Example: linux hda=14593,255,63
>
>         The installer should now run normally and not alter your partition
table
> geometry entry.  If, for any reason, this geometry should be changed
> regardless of this preventative step, please use the recovery steps to
> correct the geometry of the drive as reported by the partition table.
>
>
> Recovery:
>
>         You have installed Fedora Core 2 and find that you cannot boot
Windows.
> Typically the boot process will terminate with the words
>
>         Rootnoverify(hd0,0)
>         Chainloader +1
>
>         These are the boot parameters from your Grub configuration.  The
parameters
> are likely to be correct, but Windows fails to boot because Fedora Core 2
> altered the hard disk geometry as reported by the drives partition table.
>
> IMPORTANT: Do not panic and do not begin using multiple tools in an
attempt
> to correct this error. Automated tools can be very dangerous. The actual
> changes that need to be made are minor and benign.  By running 3rd party
> applications to recover a bootable Windows installation may cause you to
> lose your data.  You have been warned.
>
>         For those who are technically inclined I include here a brief
explanation
> of what is going on.  The drive has not been damaged and your partition
> table is fine.  The problem is that Windows demands a "sane" CHS table.
> This table has been altered by Fedora Cores installer and Windows hangs.
> Luckily, the actual table, in LBA format, is not  corrupted.  For those
> seeing a strange partition table, take note that you are probably looking
at
> the table in CHS values and these values are derived from the geometry.
The
> GNU/Linux operating system does not use these values and operates purely
> with LBA values.  Windows should not be using CHS either, but for some
> reason it at least checks this geometry and can be prevented from booting
by
> them being bad.  Changing the drive geometry changes the CHS partition
table
> because this is a virtualization of the true state of affairs on the drive
> which are best described as being mystical.  Think of CHS geometry as a
> compass.  If you change the geometry you have recalibrated where the
> needles reference point is and you are no longer looking at true north.
>
>         The solution to this problem is very simple, but it may confuse
people
> because most people will question why they are seeing strange values
> reported from their partition table in CHS format.  If you do not trust
this
> solution or your ability to follow these steps then you should stop and
seek
> hard disk recovery consulting services.  The Fedora Project is in no way
> liable for any data loss and this guide is offered without guarantees.
You
> are taking responsibility for what happens.  Now, let us go through the
> solution.
>
>         Because only the drive geometry is altered there is no need for
manual
> intervention in the form of discovering and entry of partition
information.
> The information in your partition table is correct.  However, you need to
> alter the geometry entry and normally this would require you to re-enter
the
> partition table by hand using a tool like fdisk.  This is where the
> application sfdisk comes to the rescue. Sfdisk can be very powerful in
> non-interactive mode, it can output information that can be used as input
> elsewhere, and it can accept data as input at run-time.  This makes sfdisk
> ideal for this solution because you can ask it to read the partition table
> and deliver the result in a way that itself can write back when you tell
it
> to change your drive geometry.  This makes the process fast and less prone
> to human error as very few values need to be supplied.  The solution can
be
> summed up in a single line with two commands:
>
>         sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda
>
>         So that the reader may better understand what is going on here,
lets go
> through what each section does and what the parameters mean.
>
> sfdisk -d /dev/hda
>
> This part runs sfdisk non-interactively and dumps the partition table in a
> format that sfdisk can also use for input (as we are doing).  Try this
> command by itself to see your partition table as it is very safe.  You
will
> want to check to check for warnings in the output.  Warnings pose a
problem
> because they interfere with the use of this data as input. Output
containing
> a warning may look like the example below:
>
> $ sfdisk -d /dev/hda
> Warning: extended partition does not start at a cylinder boundary.
> DOS and Linux will interpret the contents differently.
> # partition table of /dev/hda
> unit: sectors
>
> /dev/hda1 : start=       63, size= 16771797, Id= 7, bootable
> /dev/hda2 : start= 16771860, size=217632555, Id= f
> /dev/hda3 : start=        0, size=        0, Id= 0
> /dev/hda4 : start=        0, size=        0, Id= 0
> /dev/hda5 : start= 16771923, size=104856192, Id= 7
> /dev/hda6 : start=121628178, size=112776237, Id= 7
>
>
> For reasons unknown, using the option -- quiet does not suppress all
> warnings so it becomes the task of the user to discover a way to still use
> the output as input.  The simplest way is to write the output to a plain
> text file, editing out the warning in that text file, and using the edited
> text file as the input, thus:
>
> sfdisk -d /dev/hda > MyPartitionTable.txt
>         editing MyPartitionTable.txt to remove the warnings, saving the
edited
> text, and
> cat MyPartitionTable.txt | sfdisk --no-reread -H255 /dev/hda
>
> The output from "sfdisk -d /dev/hda" should begin like this (this is the
> edited version of the example given before):
>
> # partition table of /dev/hda
> unit: sectors
>
> /dev/hda1 : start=       63, size= 16771797, Id= 7, bootable
> /dev/hda2 : start= 16771860, size=217632555, Id= f
> /dev/hda3 : start=        0, size=        0, Id= 0
> /dev/hda4 : start=        0, size=        0, Id= 0
> /dev/hda5 : start= 16771923, size=104856192, Id= 7
> /dev/hda6 : start=121628178, size=112776237, Id= 7
>
>         Note that "cat MyPartitionTable.txt" takes the place of "sfdisk -d
> /dev/hda" as these are now equivalent. In this case the warning portion
has
> been stripped, preserving the needed data used by sfdisk in step two of
the
> command.
>
> sfdisk --no-reread -H255 /dev/hda
>
>         This portion of the two-part command performs the actual change to
your
> hard disk.  This main operation is in -H255. This tells sfdisk to write a
> head count of 255 into the drive geometry.  This command executed by
itself
> would ask for user input of the partition table (just like fdisk).
However,
> by piping the table we just read in the first command, this is avoided and
> work is saved and we know the data is correct (or, at least, unchanged).
> This is why sfdisk is used.
>
>         The --no-reread option allows the command to run even when the
disk has a
> mounted partition.  Some users may find they need to further force the
> operation to complete. This is done by using --force (sfdisk --no-reread
> --force -H255 /dev/hda).
>
>         In this example we are only changing the number of heads in the
geometry.
> If you know the correct number of cylinders before the Fedora Core
> installation changed these values you may also write back this number.
An
> example with 14,593 cylinders is provided below.
>
> sfdisk -d /dev/hda | sfdisk --no-reread -H255 -C14593 /dev/hda
>
>         The number of reported sectors (S) should not have changed and
remained as
> 63.
>
>         This is the part most likely to be met with the question "if I
change the
> number of heads, must I not also change the the number of cylinders?"  The
> answer to this question is "no."  When the geometry was changed the number
> of heads changed from 255 to 16 and the number of cylinders was increased
to
> compensate.  As long as the values are large everything should be ok.
Only
> the pedantic need worry about changing the number of cylinders manually.
If
> you do not know the value from before you are best off not supplying this
> number.
>
>         By using this method there is no need, and indeed you should not,
run a
> program that wipes the MBR (like fdisk /mbr).  Doing so will cause you to
> lose the Grub pointer installed in the MBR and you will have to use the
> Recovery CD to regain access to your Fedora Core installation.
>
>         Updating Grub after installation seems to have no effect on the
drive
> geometry as the problem seems strictly limited to the Fedora Core
installer.
>
> Good luck and join us on the IRC at #fedora on irc.freenode.net for any
> questions you have or contributions to the community you wish to make.
>
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>




From tdiehl at rogueind.com  Wed May 26 12:24:14 2004
From: tdiehl at rogueind.com (Tom Diehl)
Date: Wed, 26 May 2004 08:24:14 -0400 (EDT)
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <200405252322.11584.kewley@cns.caltech.edu>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
Message-ID: <Pine.LNX.4.58.0405260823270.24934@tigger.rogueind.com>

On Tue, 25 May 2004, David Kewley wrote:

> Brad Smith wrote on Tuesday 25 May 2004 18:49:
> > I concede the point about utils like anaconda being geared more toward
> > using comps.xml than the Group field and agree that we should settle on
> > one rather than both. But I'm not convinced that it's better to keep all
> > this information in one file (even one file per repo) instead of in the
> > packages themselves. What, other than current development trends,
> > warrants the use of a file that would need to be updated every time a
> > package got added to a repository if reaching an accepted standard for
> > Group field values would suffice?
> 
> I collect packages from various places, make a yumgroups.xml (yum's analog 
> to comps.xml), and publish my own package groups in my local custom yum 
> repository.  I'd have to rebuild all the collected packages with my own 
> Group: header if install-group membership was keyed off of that header 
> instead of yumgroups.xml.
> 
> Possibly after a careful rethinking of the problem, it would become clear 
> that a Group: header suffices, but right now it's awfully handy to have an 
> easily-edited yumgroups.xml.

+1

I do the same thing as I am sure do others.

Tom




From katzj at redhat.com  Wed May 26 14:19:02 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 26 May 2004 10:19:02 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085536194.7850.60.camel@localhost.localdomain>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
	<20040526021443.GA4031@jadzia.bu.edu>
	<1085534451.7850.44.camel@localhost.localdomain>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
Message-ID: <1085581142.12971.63.camel@bree.local.net>

On Tue, 2004-05-25 at 21:49 -0400, Brad Smith wrote:
> I concede the point about utils like anaconda being geared more toward
> using comps.xml than the Group field and agree that we should settle on
> one rather than both. But I'm not convinced that it's better to keep all
> this information in one file (even one file per repo) instead of in the
> packages themselves. What, other than current development trends,
> warrants the use of a file that would need to be updated every time a
> package got added to a repository if reaching an accepted standard for
> Group field values would suffice?

The problem with using the Group field is that it means that
reorganizing the way packages get displayed requires a rebuild of the
packages.  This is very heavy-weight, especially when you consider that
different sites may want slightly different categorizations of packages.
Having them to have to rebuild the packages to get this is non-ideal as
that's far more fragile and something that's likely to not succeed or
introduce other problems.  Editing an XML file is fairly low risk

Jeremy




From leonard at den.ottolander.nl  Wed May 26 14:00:09 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Wed, 26 May 2004 16:00:09 +0200
Subject: rpmbuild-nonroot %{version} interpreted incorrectly
Message-ID: <1085580008.4457.10.camel@athlon.localdomain>

Hi,

When using Mike Harris' rpmbuild-nonroot setup (except for the no archs
hack) I have a problem building rpm. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124364 .

rpmbuild -bp rpm.spec fails:
error: File /data/rpmbuild-fc1/rpm-1.8.1/rpm-4.2.1.tar.gz: No such
file or directory

It looks like the last "Version:" (popt's) is being used in the path
expansion for %setup.

$ rpm --showrc | grep sourcedir
  RPM_SOURCE_DIR="%{u2p:%{_sourcedir}}"
RPM_SOURCE_DIR="%{_sourcedir}"
-14: _sourcedir %{_topdir}/%{name}-%{version}
-14: _specdir   %{_sourcedir}

The latest "Version:" tag in the spec file is the one for popt. It
looks as if this value is substituted for %{version}. How can this be
fixed?

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From Nicolas.Mailhot at laPoste.net  Wed May 26 14:34:29 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 26 May 2004 16:34:29 +0200
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085581142.12971.63.camel@bree.local.net>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
	<20040526021443.GA4031@jadzia.bu.edu>
	<1085534451.7850.44.camel@localhost.localdomain>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<1085581142.12971.63.camel@bree.local.net>
Message-ID: <1085582070.16304.10.camel@ulysse.olympe.o2t>

Le mer, 26/05/2004 ? 10:19 -0400, Jeremy Katz a ?crit :

> The problem with using the Group field is that it means that
> reorganizing the way packages get displayed requires a rebuild of the
> packages. 

Hence you need a hint+policy system, so packagers can provide hints and
you decide what to do with them.

Cheers,

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

From nphilipp at redhat.com  Wed May 26 14:58:12 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Wed, 26 May 2004 16:58:12 +0200
Subject: rpmbuild-nonroot %{version} interpreted incorrectly
In-Reply-To: <1085580008.4457.10.camel@athlon.localdomain>
References: <1085580008.4457.10.camel@athlon.localdomain>
Message-ID: <1085583491.18988.61.camel@gibraltar.stuttgart.redhat.com>

On Wed, 2004-05-26 at 16:00, Leonard den Ottolander wrote:
> Hi,
> 
> When using Mike Harris' rpmbuild-nonroot setup (except for the no archs
> hack) I have a problem building rpm. See
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124364 .
> 
> rpmbuild -bp rpm.spec fails:
> error: File /data/rpmbuild-fc1/rpm-1.8.1/rpm-4.2.1.tar.gz: No such
> file or directory
> 
> It looks like the last "Version:" (popt's) is being used in the path
> expansion for %setup.
> 
> $ rpm --showrc | grep sourcedir
>   RPM_SOURCE_DIR="%{u2p:%{_sourcedir}}"
> RPM_SOURCE_DIR="%{_sourcedir}"
> -14: _sourcedir %{_topdir}/%{name}-%{version}
> -14: _specdir   %{_sourcedir}
> 
> The latest "Version:" tag in the spec file is the one for popt. It
> looks as if this value is substituted for %{version}. How can this be
> fixed?

I guess this has to be fixed in RPM itself -- I think you should file it
in Bugzilla (actually I stumbled over this a while ago but was too lazy
to file it ;-).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040526/ac5324e4/attachment.sig>

From jspaleta at gmail.com  Wed May 26 14:00:27 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 26 May 2004 10:00:27 -0400
Subject: Call for Discussion: Summary document concerning Prevention
	andRecovery of XP Dual Boot Problems
In-Reply-To: <1085535602.7850.51.camel@localhost.localdomain>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
	<1085535602.7850.51.camel@localhost.localdomain>
Message-ID: <604aa791040526070041b14707@mail.gmail.com>

On Tue, 25 May 2004 21:40:03 -0400, Brad Smith <brads at redhat.com> wrote:
> This has been on my mind as well. The Mandrake bugzilla entry mentions a
> fix (or anaconda? grub?) being in Cooker (their unstable distro) and so
> assumedly in the just-released MDK10-Official. That leaves FC2 in the
> unenviable position of being the only(?) distro out there afflicted with
> this problem.

So much assumption making...so little useful information in that
paragraph. Perhaps...next time...you cite the bugreport specifically
instead of particpating in rumormongering. If you can't cite the
report...don't bother mentioning it. Better yet do more than just cite
it...actively keep an eye on it to watch the new reports roll in. 
Unless you can bring specific and accurate information to the
discussion, you aren't moving it forward.

-jef" http://qa.mandrakesoft.com/show_bug.cgi?id=7959#c27 "spaleta




From jspaleta at gmail.com  Wed May 26 14:54:17 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 26 May 2004 10:54:17 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085582070.16304.10.camel@ulysse.olympe.o2t>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
	<20040526021443.GA4031@jadzia.bu.edu>
	<1085534451.7850.44.camel@localhost.localdomain>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<1085581142.12971.63.camel@bree.local.net>
	<1085582070.16304.10.camel@ulysse.olympe.o2t>
Message-ID: <604aa79104052607544b8bfdc6@mail.gmail.com>

On Wed, 26 May 2004 16:34:29 +0200, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> Hence you need a hint+policy system, so packagers can provide hints and
> you decide what to do with them.

I still dont see the NEED for internal package level hinting.
All the internal package level hinting can do is give you a very gross grouping
package foo belows to group bar.  It can't define flexible nested
groupings like comps.xml can...so if group bar can ask for group
bar-base to be installed when group bar is asked for. At best you can
pretend the groups tag give you some sort of linear grouping
tree...but if you have a need to list a package in multiple groups,
yer screwed. I certaintly would like to be able to see grouping
definitions get to the point where users can browse for packages like
I can browse for projects through freshmeat. With a mature comps.xml
system I could do something like that easily..I could browse by
function or i could browse by desktop environment
or intended audience becuase the comps.xml is flexible enough to allow
packages to exist in multiple parallel groupings.

Personally I think all package level hinting does is get in the way
because it doesn't provide enough contextual information to be useful
for anything.
I can't think of a single thing I can do with correct per package
group tag, that I can't do with a correct set of comps.xml files and
tools that support browsing by comps.xml defined groupings.


-jef




From jspaleta at gmail.com  Wed May 26 12:16:28 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 26 May 2004 08:16:28 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085562157.13536.11.camel@ulysse.olympe.o2t>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085562157.13536.11.camel@ulysse.olympe.o2t>
Message-ID: <604aa791040526051641b8d669@mail.gmail.com>

On Wed, 26 May 2004 11:02:36 +0200, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> Any setup that does not allow in-package hints, distro policy and local
> sysadmin overlay will f*-up one of these people.

Have you not been listening to seth?
yum can merge group definitions from multiple sources. I'm really not
convinced you NEED in package group tags, just like i don't think you
NEED in package recommend tags. You publish packages in a repo...you
publish a comps.xml as well that can be merged in by package
management tools to handle both grouping and metapackage behavior.


-jef




From tibbs at math.uh.edu  Wed May 26 15:06:12 2004
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 26 May 2004 10:06:12 -0500
Subject: FC 2 - RPM virtual provides on PIE broken (odd
	conflicts/triggers)
In-Reply-To: <20040526074939.GB15609@devserv.devel.redhat.com>
References: <20040521115111.GA32686@devserv.devel.redhat.com>
	<1085554882.27156.1547.camel@imladris.demon.co.uk>
	<20040526074939.GB15609@devserv.devel.redhat.com>
Message-ID: <ufawu2zmdnf.fsf@epithumia.math.uh.edu>

>>>>> "PN" == Paul Nasrat <pnasrat at redhat.com> writes:

PN> I think if you disable the internal depgen stuff that
PN> find-provides won't do this which is a temporary work around - try
PN> adding the following to the spec:

PN> %define _use_internal_dependency_generator 0

You can also include a custom dependency generator that calls the
normal one and greps out the broken ones.  Grab the nss_db SRPM and
look at how it does things.  (I use this to remove GLIBC_PRIVATE
dependencies with packaging the PGI compiler suite for my machines.)
It's basically:

(somewhere early)

%define _use_internal_dependency_generator 0
%define __find_requires %{_builddir}/%{name}-%{version}/find-requires

(in %prep)

find_requires=`rpm --eval %%{__find_requires}`
echo "$find_requires | grep -v GLIBC_PRIVATE" > find-requires
chmod +x find-requires

 - J<




From mike at netlyncs.com  Wed May 26 15:27:04 2004
From: mike at netlyncs.com (Mike Chambers)
Date: Wed, 26 May 2004 10:27:04 -0500
Subject: Call for Discussion: Summary document concerning
	Prevention andRecovery of XP Dual Boot Problems
In-Reply-To: <604aa791040526070041b14707@mail.gmail.com>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
	<1085535602.7850.51.camel@localhost.localdomain>
	<604aa791040526070041b14707@mail.gmail.com>
Message-ID: <1085585224.2155.2.camel@scrappy.netlyncs.com>

On Wed, 2004-05-26 at 10:00 -0400, Jeff Spaleta wrote:
> On Tue, 25 May 2004 21:40:03 -0400, Brad Smith <brads at redhat.com> wrote:
> > This has been on my mind as well. The Mandrake bugzilla entry mentions a
> > fix (or anaconda? grub?) being in Cooker (their unstable distro) and so
> > assumedly in the just-released MDK10-Official. That leaves FC2 in the
> > unenviable position of being the only(?) distro out there afflicted with
> > this problem.
> 
> So much assumption making...so little useful information in that
> paragraph. Perhaps...next time...you cite the bugreport specifically
> instead of particpating in rumormongering. If you can't cite the
> report...don't bother mentioning it. Better yet do more than just cite
> it...actively keep an eye on it to watch the new reports roll in. 
> Unless you can bring specific and accurate information to the
> discussion, you aren't moving it forward.

And unless your someone from @redhat.com, not sure there is anything you
need to be telling him what he can/can't do on their own mailing lists
(unless we are talking spamming it, abusing or that type thing), whether
it's useful (to you?) or not.

Besides, maybe the bug # was posted to @redhat.com folks or someone
already know of it from Red Hat and he was just posting what is already
known.

-- 
Mike Chambers
Madisonville, KY

"It's always better to hurt a little now, than to hurt a lot later!"




From Nicolas.Mailhot at laPoste.net  Wed May 26 15:32:18 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 26 May 2004 17:32:18 +0200
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <604aa791040526051641b8d669@mail.gmail.com>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085562157.13536.11.camel@ulysse.olympe.o2t>
	<604aa791040526051641b8d669@mail.gmail.com>
Message-ID: <1085585538.16473.19.camel@ulysse.olympe.o2t>

Le mer, 26/05/2004 ? 08:16 -0400, Jeff Spaleta a ?crit :
> On Wed, 26 May 2004 11:02:36 +0200, Nicolas Mailhot
> <nicolas.mailhot at laposte.net> wrote:
> > Any setup that does not allow in-package hints, distro policy and local
> > sysadmin overlay will f*-up one of these people.
> 
> Have you not been listening to seth?
> yum can merge group definitions from multiple sources. I'm really not
> convinced you NEED in package group tags, just like i don't think you
> NEED in package recommend tags. You publish packages in a repo

And this is where you didn't listen to me.
All the world is not a yum repo.
Right now yum is an *optional* rpm overlay.
If you make yum mandatory for something as trivial as rpm classification
you kill a lot of rpm's interest.

How do you handle single-rpm publication on sf on your setup ? How do
you handle rpm -Uvh http://foo.org/bar.rpm ? How do you handle using a
CD of unindexed rpms as a yum source ?

Are you seriously suggesting someone needs all the repository plumbing
just to declare a package is a game, a gnome applet or whatever ? Why
not get all the metadata out of spec files while you're at this ?

The group tag is broken mostly because it is 
1. mono-valuated
2. not standardised
3. interpreted as-is instead of getting through even the dumbest
filter/formatter

Frankly nothing I've read so far justifies moving this info out of the
spec files and making yum an hard requirement. Changing the
format/allowed values yes. Changing the way it is parsed/interpreted
yes.  Moving it out ? No.

You have to give a lot more compelling arguments than "it works better
than foo known-broken-for-ages setup" to sell something that goes
against package=standalone software unit rule.

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

From Nicolas.Mailhot at laPoste.net  Wed May 26 15:39:36 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 26 May 2004 17:39:36 +0200
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <604aa79104052607544b8bfdc6@mail.gmail.com>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<Pine.LNX.4.58.0405252145230.699@devserv.devel.redhat.com>
	<20040526021443.GA4031@jadzia.bu.edu>
	<1085534451.7850.44.camel@localhost.localdomain>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<1085581142.12971.63.camel@bree.local.net>
	<1085582070.16304.10.camel@ulysse.olympe.o2t>
	<604aa79104052607544b8bfdc6@mail.gmail.com>
Message-ID: <1085585976.16473.27.camel@ulysse.olympe.o2t>

Le mer, 26/05/2004 ? 10:54 -0400, Jeff Spaleta a ?crit :

> Personally I think all package level hinting does is get in the way
> because it doesn't provide enough contextual information to be useful
> for anything.

Then define what hinting you need. Because hinting is the only way of
accommodating gracefully unknown standalone packages.

(and btw if the argument is "we don't need no stoopid policy filter with
comps" guess how long it will take for all the various third-party
comps.xmls to diverge from the Fedora one ? Especially for groups that
target multiple distributions ?)

It's a hell more difficult to classify menu entries since you get into
screen-estate problems, are not allowed to have an entry appear in
several places, etc but somehow people manage using only the
freedesktop-defined hinting.

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

From jspaleta at gmail.com  Wed May 26 16:04:47 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 26 May 2004 12:04:47 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085585538.16473.19.camel@ulysse.olympe.o2t>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085562157.13536.11.camel@ulysse.olympe.o2t>
	<604aa791040526051641b8d669@mail.gmail.com>
	<1085585538.16473.19.camel@ulysse.olympe.o2t>
Message-ID: <604aa7910405260904713badec@mail.gmail.com>

On Wed, 26 May 2004 17:32:18 +0200, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> And this is where you didn't listen to me.
> All the world is not a yum repo.

yum is an example of mature comps.xml usage
anaconda and system-config-packages are other examples..i won't
comment on the maturity of them :->.  I'm saying teach ALL the tools
to use comps.xml more effectively becuase right now the in distros use
the groups tag for pretty much...nothing.

> Right now yum is an *optional* rpm overlay.
> If you make yum mandatory for something as trivial as rpm classification
> you kill a lot of rpm's interest.

I would say ALL grouping information should be optional....

> 
> How do you handle single-rpm publication on sf on your setup ? How do
> you handle rpm -Uvh http://foo.org/bar.rpm ? How do you handle using a
> CD of unindexed rpms as a yum source ?

I know before hand what those packages actually do...or i read the
summary information and the the Description that gives me CONTEXT. I
have certaintly NEVER gone...hmm i wonder if crackattack.i386.rpm is a
a game or a gnome game or a kde game by looking at the group tag. I
read the package summary and description or for fun...i dive into
freshmeat's searchable trove for it.

> Are you seriously suggesting someone needs all the repository plumbing
> just to declare a package is a game, a gnome applet or whatever ?

No im saying declaring its a game via a tag is POINTLESS. Becuase that
tag is limited and doesn't really give much in the way of group
handling abilities at the tool level. If the summary and the
description don't make it clear its a game...something is already very
wrong...why do i NEED the group tag.


> 
> The group tag is broken mostly because it is
> 1. mono-valuated

hold your breath on getting that to change inside rpm....

> 2. not standardised
there is a actually a list of conanoncal
groups..../usr/share/doc/rpm-4.2.1/GROUPS
And I argue that ANY attempt to standardize this group definitions is
ultimately short-sighted. I think that groupings NEED to be flexible
to account for as much new functionality to be future-proof. comps.xml
is future proof because the NAMES of the groups themselves are not
important in comps.xml..its the relationship between groups that is
important in comps.xml. You standardize on a set of names and yer
pretty much garunteed that at somepoint that set of standard names
isnt going to be intuitive anymore and your constantly trying to fight
the need to keep old names compatible with the new more intuitive
names if the group tag is inside the packages themselves. Stop the
madness, pull the group crap out of the packages and let people who
build collections of packages work out how the packages should be
grouped seperate from the build process.


> 3. interpreted as-is instead of getting through even the dumbest
> filter/formatter
xml is more flexible....packages can be listed in multiple groups..yer
not going to easily get that in the group tag in a
package...especially if the multiple groupings you want to place a
package in are an evolving set.
 
> Frankly nothing I've read so far justifies moving this info out of the
> spec files and making yum an hard requirement. Changing the
> format/allowed values yes. Changing the way it is parsed/interpreted
> yes.  Moving it out ? No.
Its already moved out...the in distro tools that are parsing for
useful group definitions are using comps.xml. Nothing in distro uses
the group tag for anything useful in a tool specific. We can keep
pretending like this has been an historically useful tag...but it
hasn't.

> 
> You have to give a lot more compelling arguments than "it works better
> than foo known-broken-for-ages setup" to sell something that goes
> against package=standalone software unit rule.

see thats sort of the point... grouping information is NOT useful in a
standalone situation. Group information is ONLY useful when we are
talking about multiple packages. Sort of the definition of a group of
packages. If people are building standlone packages..i see no reason
for them to impress on the people 'grouping' packages their
pre-concieved ideas. The package description and summary should be
more than enough to 'hint' to people who are 'grouping' stand alone
packages into groups that makes intuitive sense to them.

-jef




From bpm at ec-group.com  Wed May 26 16:08:49 2004
From: bpm at ec-group.com (Brian Millett)
Date: Wed, 26 May 2004 11:08:49 -0500 (CDT)
Subject: rawhide packages behide updates/testing??
Message-ID: <34782.12.41.112.51.1085587729.squirrel@webmail.ec-group.com>

There are several packages in rawhide that are behide the packages in
updates/testing.

 updates                   rawhide

kudzu-1.1.68-1          kudzu-1.1.67-1
subversion-1.0.4-1      subversion-1.0.3-1

I'm confussed.  Should I, once I go down the rawhide path, ignore updates?
 Shouldn't rawhide be the "bleeding-edge"?

Thanks.
-- 
Brian Millett
Enterprise Consulting Group  "Shifts in paradigms
(314) 205-9030           often cause nose bleeds."
bpmATec-groupDOTcom                     Greg Glenn






From buildsys at redhat.com  Wed May 26 16:20:12 2004
From: buildsys at redhat.com (Build System)
Date: Wed, 26 May 2004 12:20:12 -0400
Subject: rawhide report: 20040526 changes
Message-ID: <200405261620.i4QGKCk25357@porkchop.devel.redhat.com>




From twaugh at redhat.com  Wed May 26 16:36:22 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Wed, 26 May 2004 17:36:22 +0100
Subject: rawhide packages behide updates/testing??
In-Reply-To: <34782.12.41.112.51.1085587729.squirrel@webmail.ec-group.com>
References: <34782.12.41.112.51.1085587729.squirrel@webmail.ec-group.com>
Message-ID: <20040526163622.GU707@redhat.com>

On Wed, May 26, 2004 at 11:08:49AM -0500, Brian Millett wrote:

> There are several packages in rawhide that are behide the packages in
> updates/testing.
> 
>  updates                   rawhide
> 
> kudzu-1.1.68-1          kudzu-1.1.67-1
> subversion-1.0.4-1      subversion-1.0.3-1
> 
> I'm confussed.  Should I, once I go down the rawhide path, ignore updates?
>  Shouldn't rawhide be the "bleeding-edge"?

Fedora Core updates are built from HEAD, i.e. they get the next
version number (unless there's a reason to branch off from rawhide).
So rawhide will overtake the updates version numbers next time that
package is built.

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

From cra at WPI.EDU  Wed May 26 16:40:27 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Wed, 26 May 2004 12:40:27 -0400
Subject: debugging xorg-x11
Message-ID: <20040526164027.GI13803@angus.ind.WPI.EDU>

I have a FC2 system whose X11 has locked up after sitting on a
screensaver overnight.  I can still get into the system via ssh, but I
cannot vt switch away from the locked up X11.  The X process is taking 
up all the CPU:

USER       PID %CPU %MEM   VSZ  RSS TT       STAT  STARTED     TIME COMMAND
root     23040 97.7  5.2 67488 20248 ?       R     May 22 1-16:02:50 /usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7

strace shows it in a tight loop:

select(1024, [8], NULL, NULL, {0, 0})   = ? ERESTARTNOHAND (To be restarted)
select(1024, [8], NULL, NULL, {0, 0})   = ? ERESTARTNOHAND (To be restarted)
select(1024, [8], NULL, NULL, {0, 0})   = ? ERESTARTNOHAND (To be restarted)

Xorg.0.log shows this repeating error:

(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
...

How can I go about debugging this so I can make a meaningful bug
report?  What debuginfo packages and gdb version do I need?

xorg-x11-6.7.0-2 is using radeon driver for this card:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc Radeon 7000/Radeon VE
        Flags: bus master, stepping, 66Mhz, medium devsel, latency 32, IRQ 161
        Memory at d0000000 (32-bit, prefetchable)
        I/O ports at d000 [size=256]
        Memory at dd000000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [58] AGP version 2.0
        Capabilities: [50] Power Management version 2

kernel is 2.6.5-1.358smp.  Chipset:

00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
        Flags: bus master, medium devsel, latency 0
        Memory at d8000000 (32-bit, prefetchable)
        Capabilities: [a0] AGP version 2.0
        Capabilities: [c0] Power Management version 2

00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, medium devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: dc000000-ddffffff
        Prefetchable memory behind bridge: d0000000-d7ffffff
        Expansion ROM at 0000d000 [disabled] [size=4K]
        Capabilities: [80] Power Management version 2

CPUs:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 3
cpu MHz         : 799.919
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1572.86

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 3
cpu MHz         : 799.919
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1597.44

Thanks.




From skvidal at phy.duke.edu  Wed May 26 16:56:28 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 26 May 2004 12:56:28 -0400
Subject: Call for Discussion: Summary document concerning
	Prevention andRecovery of XP Dual Boot Problems
In-Reply-To: <1085585224.2155.2.camel@scrappy.netlyncs.com>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
	<1085535602.7850.51.camel@localhost.localdomain>
	<604aa791040526070041b14707@mail.gmail.com>
	<1085585224.2155.2.camel@scrappy.netlyncs.com>
Message-ID: <1085590588.10344.44.camel@opus>


> And unless your someone from @redhat.com, not sure there is anything you
> need to be telling him what he can/can't do on their own mailing lists
> (unless we are talking spamming it, abusing or that type thing), whether
> it's useful (to you?) or not.
> 
> Besides, maybe the bug # was posted to @redhat.com folks or someone
> already know of it from Red Hat and he was just posting what is already
> known.

If fedora is supposed to be a community-included project then whether
someone is @redhat.com should not affect whether they can attempt to
contribute and influence the discussion in positive ways.

As Jef is involved in the fedora bug triaging efforts I think his input
is uniquely qualified on this thread.

I hope @redhat.com are not the only people whose opinions matter.

-sv




From ville.skytta at iki.fi  Wed May 26 16:52:03 2004
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Wed, 26 May 2004 19:52:03 +0300
Subject: rpm package renames
In-Reply-To: <20040526094741.GA2710@urchin.earth.li>
References: <20040526094741.GA2710@urchin.earth.li>
Message-ID: <1085590323.3123.47.camel@bobcat.mine.nu>

On Wed, 2004-05-26 at 12:47, Stuart Children wrote:

> PS: Before I forget, is there an easy way to find out who is supposed to 
> be maintaining a particular package in the fedora.us repository?

Follow the "Component" link from the "Enter bug" page(s for each
product) at bugzilla.fedora.us.

I believe most maintainers prefer new Bugzilla entries over personal
mail wrt packages though, in case mailing a maintainer is what you have
in mind.




From brads at redhat.com  Wed May 26 14:30:12 2004
From: brads at redhat.com (Brad Smith)
Date: Wed, 26 May 2004 10:30:12 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <200405252322.11584.kewley@cns.caltech.edu>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
Message-ID: <1085581811.7850.79.camel@localhost.localdomain>

> I collect packages from various places, make a yumgroups.xml (yum's analog 
> to comps.xml), and publish my own package groups in my local custom yum 
> repository.  I'd have to rebuild all the collected packages with my own 
> Group: header if install-group membership was keyed off of that header 
> instead of yumgroups.xml.


That works great for you, but what about the noob who doesn't know how
to do that and doesn't need (yet) another component to deal with in the
Fedora's already complex package management system. 

I hope everyone can agree that the fewer external components we involve
here, the simpler the process becomes and the fewer things can go wrong.
With standardized Group info in the headers you don't have to deal with
issues like users not having up-to-date *.comps.xml files, incomplete
comps, etc. 

That said, you make a very good point about the advantage of an external
file: It makes it simple for the user to group packages however he or
she wants. So I think a compromise can be met by rescinding one of the
points I made earlier: That it would be a bad idea to support both. 


I suggest that we:

1) Agree on a standard set of group names (and make sure at least most
of the third-party maintainers are willing to conform to them)

2) Begin packaging so that, starting with FC3, all packages have one of
these groups in the Group header

3) Design all packaging tools (yum, system-config-package, anaconda,
(apt?)) so that if a *.comps.xml, yumgroups.xml, etc file exists it
takes precedence over the Group field, but if the package does not
appear in an xml file, the Group field is used.


For all I know, step 3 may already be the way it works. Either way, it
seems to me that while there are advantages to the external xml files,
deprecating Group so that grouping data is kept there exclusively is
going to open users up to yet another thing that can go wrong when
managing packages, which is a Bad Thing.

Comments? Appologies if I  sound like I'm speaking out of line here. I
know a lot of the people on this list know a heck of a lot more about
yum/rpm and so forth than I. I'm just calling it I see it here.

--Brad




From brads at redhat.com  Wed May 26 14:49:39 2004
From: brads at redhat.com (Brad Smith)
Date: Wed, 26 May 2004 10:49:39 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <604aa7910405260904713badec@mail.gmail.com>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085562157.13536.11.camel@ulysse.olympe.o2t>
	<604aa791040526051641b8d669@mail.gmail.com>
	<1085585538.16473.19.camel@ulysse.olympe.o2t>
	<604aa7910405260904713badec@mail.gmail.com>
Message-ID: <1085582979.7850.105.camel@localhost.localdomain>

You make some very compelling points, but I still disagree with this:

> see thats sort of the point... grouping information is NOT useful in a
> standalone situation. Group information is ONLY useful when we are
> talking about multiple packages. Sort of the definition of a group of
> packages. If people are building standlone packages..i see no reason
> for them to impress on the people 'grouping' packages their
> pre-concieved ideas. The package description and summary should be
> more than enough to 'hint' to people who are 'grouping' stand alone
> packages into groups that makes intuitive sense to them.


Ok, so I've installed foo.rpm (which we'll assume is a game) and I
figured out what it was not by looking at Groups, but by looking at the
description in the headers, on the website etc. Sure enough that's how I
do it and I think you're correct in asserting that that's how most
others do it as well.

But now it's installed. So suppose I'm cleaning up my system and I run
system-config-packages and go looking through the games to see what I'm
not using anymore. Or suppose I'm just a user on the system and I'm
using some other tool just to see what all is installed. I would expect
foo to show up under games, but if it was just downloaded from the web
and the various *.xml files are the only sources for grouping
information it's not. Best-case scenario it goes into an ugly "Other"
category. Worst-case it's ignored. 

So there is a need for grouping info even for "standalone" packages
because once they are installed they become part of a group of packages,
effective management of which is very important. So I still say the best
solution is to use *.xml but allow the tools to fall back on the rpm's
headers if that fails.

--Brad




From brads at redhat.com  Wed May 26 14:57:46 2004
From: brads at redhat.com (Brad Smith)
Date: Wed, 26 May 2004 10:57:46 -0400
Subject: Call for Discussion: Summary document concerning
	Prevention andRecovery of XP Dual Boot Problems
In-Reply-To: <1085585224.2155.2.camel@scrappy.netlyncs.com>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
	<1085535602.7850.51.camel@localhost.localdomain>
	<604aa791040526070041b14707@mail.gmail.com>
	<1085585224.2155.2.camel@scrappy.netlyncs.com>
Message-ID: <1085583465.7850.120.camel@localhost.localdomain>


> And unless your someone from @redhat.com, not sure there is anything you
> need to be telling him what he can/can't do on their own mailing lists
> (unless we are talking spamming it, abusing or that type thing), whether
> it's useful (to you?) or not.
> 
> Besides, maybe the bug # was posted to @redhat.com folks or someone
> already know of it from Red Hat and he was just posting what is already
> known.

I've got to agree with Seth there. My job at Red Hat has nothing to do
with development and I have no special access to anything to do with
Fedora. Jeff, though I wish he'd been more polite about it, was correct
in that I should have checked to see if there had been any more news
(sure enough, the bug still exists in mdk10).

That said, this thread is getting focused on a relatively unimportant
part of my post (IMO) and ignoring where I *was* trying to "move the
discussion forward"

To wit:

> a) Is a fix being developed (by whom? if not, who wants it?)
> 
> b) Once it's developed, can we replace the FC2 ISOs on the website and
> mirrors with ones that incorporate the fix?

My incorrect assertion that we were the only ones with this problem aside, I fail to 
see how asking these (still unanswered) questions fail to move the discussion forward.

--Brad




From shiva at sewingwitch.com  Wed May 26 18:01:52 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Wed, 26 May 2004 11:01:52 -0700
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085582979.7850.105.camel@localhost.localdomain>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085562157.13536.11.camel@ulysse.olympe.o2t>
	<604aa791040526051641b8d669@mail.gmail.com>
	<1085585538.16473.19.camel@ulysse.olympe.o2t>
	<604aa7910405260904713badec@mail.gmail.com>
	<1085582979.7850.105.camel@localhost.localdomain>
Message-ID: <571629A5AA440324221B889C@[10.170.7.6]>

--On Wednesday, May 26, 2004 10:49 AM -0400 Brad Smith <brads at redhat.com> 
wrote:

> So there is a need for grouping info even for "standalone" packages
> because once they are installed they become part of a group of packages,
> effective management of which is very important.

Instead of grouping, might it not make sense to use a keywords field? When 
packaging I find either that something fits in no existing group or several 
existing groups, so I often want multiple entries and often need a new one.





From jspaleta at gmail.com  Wed May 26 18:00:03 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 26 May 2004 14:00:03 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085581811.7850.79.camel@localhost.localdomain>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085581811.7850.79.camel@localhost.localdomain>
Message-ID: <604aa7910405261100560f00f4@mail.gmail.com>

On Wed, 26 May 2004 10:30:12 -0400, Brad Smith <brads at redhat.com> wrote:

> 
> That works great for you, but what about the noob who doesn't know how
> to do that and doesn't need (yet) another component to deal with in the
> Fedora's already complex package management system.

Then we spend the time to fix the noob facing components to use comps.xml files
provided by noob friendly repositories. Re-inventing the group tag and
arguing over what exactly the right group tag names should be is a
huge waste of effort.
comps.xml provides flexibility... 3rd party public repos and intranet repos
can define the groupings that make sense to them without having to
pretend like we are ALL going agree on how best to codify a group
naming scheme. Who cares if my personal repositories invents a new
package group just for plasma physics software....if the in distro
packaging tools aimed at a noob, see my comps.xml file and merge my
comps.xml file into a groups listing...problem solved. There is no
reason to think that Core has to pre-define every concievable grouping
for packages and force every concievable collection of packages that
are in use to abide by that set of names.

A sensible group naming scheme is going to be a continual work in
progress and shackling an evolving grouping standard into the package
building itself serves only to stagnate the discussion around group
naming into the future becuase you have to constantly worry about the
group names defined in packages you can not rebuild but must continue
to worry about.  Seperate it out...let the group naming scheme evolve
on its own seperate from actual package building. Let university
intranets define their OWN groupings in repositories that make sense
to them. Let 3rd party repositories choice to follow Core grouping or
to expand on grouping as they see fit. Don't pretend like everyone is
going to come to a consensous about how to group packages
together..its not going to happen. Don't try to pretend like the list
of package groups that make sense right now...will make sense 6 months
from now or a year from now..thats just asking us to have the same
fight about group names again in the future...over and over and over
again.

> I hope everyone can agree that the fewer external components we involve
> here, the simpler the process becomes and the fewer things can go wrong.
> With standardized Group info in the headers you don't have to deal with
> issues like users not having up-to-date *.comps.xml files, incomplete
> comps, etc.

I have very little faith that all packagers can agree on intuitive
naming scheme and stick to it more than 6 months....very little faith.
 At best you are going to force a naming structure on people that is
ill-fitting 6 months from now. We HAVE a set of standard names...they
aren't good enough hence...comps.xml. comps.xml is not going away, and
the group tag is not flexible enough to replace what comps.xml does in
terms of grouping groups into metagroups and to flag packages as
optional in one group but a default member in another group.  Given
that developer resources are the scarce commodity comps.xml has
already shown itself to be MORE useful in terms of installation and
metapackaging functionality than the group tag could ever hope to
be...without mentioning the locale support inherent in the comps.xml
file format which is non-trvially important. Burning brain-power and
developer cycles to think hard about how to bootstrap all of comps.xml
advantages back into a group tag in rpm, is wastefully indulgent.

> That said, you make a very good point about the advantage of an external
> file: It makes it simple for the user to group packages however he or
> she wants. So I think a compromise can be met by rescinding one of the
> points I made earlier: That it would be a bad idea to support both.
> 
> I suggest that we:
> 
> 1) Agree on a standard set of group names (and make sure at least most
> of the third-party maintainers are willing to conform to them)

Not going to happen. Everyone with a stake in defining a bettter set
of names are NOT going to agree..its going to be a long dragged out
fight...no point in starting it.
And there is no way to be comprehensive and account for ALL possible
future groupname needs.


> 3) Design all packaging tools (yum, system-config-package, anaconda,
> (apt?)) so that if a *.comps.xml, yumgroups.xml, etc file exists it
> takes precedence over the Group field, but if the package does not
> appear in an xml file, the Group field is used.
Screw that, make repos responsible for defining their own comps.xml
files and demand repos provide comps.xml files.  If repos want to use
the Group tag as an automated way to build their own groups...fine by
me..they can do so in a way that makes sense for them. Expecting tools
to fall back to a per package...maybe standard...maybe not...group
tag...no thanks....extra functionality in the tools means potentially
more bugs...and less testing.

> For all I know, step 3 may already be the way it works. Either way, it
> seems to me that while there are advantages to the external xml files,
> deprecating Group so that grouping data is kept there exclusively is
> going to open users up to yet another thing that can go wrong when
> managing packages, which is a Bad Thing.

The group tag can go wrong...dont even doubt it. Instead I say drop
the group tag...
drop the tag that each packager has to worry about conforming to a
"standard" they might not even know about. And deal with all the
grouping information at the repo level, so one person can be
responsible for keeping the grouping definitions for a repo in tact.



-jef




From kewley at cns.caltech.edu  Wed May 26 18:15:37 2004
From: kewley at cns.caltech.edu (David Kewley)
Date: Wed, 26 May 2004 11:15:37 -0700
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <571629A5AA440324221B889C@[10.170.7.6]>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<1085582979.7850.105.camel@localhost.localdomain>
	<571629A5AA440324221B889C@[10.170.7.6]>
Message-ID: <200405261115.37745.kewley@cns.caltech.edu>

Kenneth Porter wrote on Wednesday 26 May 2004 11:01:
> --On Wednesday, May 26, 2004 10:49 AM -0400 Brad Smith <brads at redhat.com> 
> wrote:
> 
> > So there is a need for grouping info even for "standalone" packages
> > because once they are installed they become part of a group of packages,
> > effective management of which is very important.
> 
> Instead of grouping, might it not make sense to use a keywords field? When 
> packaging I find either that something fits in no existing group or
> several existing groups, so I often want multiple entries and often need a
> new one.

I think the idea in this subthread is that Group: is good for indexing.  
Either at install time, or at cleanup time, or at "what sorts of packages 
do I have on my system" time.

So maybe the question isn't "What should we do with Group:?", but rather 
"How can we best provide indexes of available or installed packages?"  I 
think keywords and indexing tools are a very good idea here.

David




From brads at redhat.com  Wed May 26 15:15:34 2004
From: brads at redhat.com (Brad Smith)
Date: Wed, 26 May 2004 11:15:34 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <571629A5AA440324221B889C@[10.170.7.6]>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085562157.13536.11.camel@ulysse.olympe.o2t>
	<604aa791040526051641b8d669@mail.gmail.com>
	<1085585538.16473.19.camel@ulysse.olympe.o2t>
	<604aa7910405260904713badec@mail.gmail.com>
	<1085582979.7850.105.camel@localhost.localdomain>
	<571629A5AA440324221B889C@[10.170.7.6]>
Message-ID: <1085584533.7850.137.camel@localhost.localdomain>


> Instead of grouping, might it not make sense to use a keywords field? When 
> packaging I find either that something fits in no existing group or several 
> existing groups, so I often want multiple entries and often need a new one.

Nicolas Mailhot seems to be advocating something like that and the main
thing holding me back from it is that, as has been pointed out, it would
seem to involve a nontrivial change to the inner-workings of rpm and
introduce a lot backwards-compatability issues.

But the guts of rpm's machinery is not something I'm familiar with
enough to comment much more than that.

--Brad




From jspaleta at gmail.com  Wed May 26 18:22:53 2004
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 26 May 2004 14:22:53 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085582979.7850.105.camel@localhost.localdomain>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085562157.13536.11.camel@ulysse.olympe.o2t>
	<604aa791040526051641b8d669@mail.gmail.com>
	<1085585538.16473.19.camel@ulysse.olympe.o2t>
	<604aa7910405260904713badec@mail.gmail.com>
	<1085582979.7850.105.camel@localhost.localdomain>
Message-ID: <604aa7910405261122789c4d0a@mail.gmail.com>

On Wed, 26 May 2004 10:49:39 -0400, Brad Smith <brads at redhat.com> wrote:
> But now it's installed. So suppose I'm cleaning up my system and I run
> system-config-packages and go looking through the games to see what I'm
> not using anymore. Or suppose I'm just a user on the system and I'm
> using some other tool just to see what all is installed. I would expect
> foo to show up under games, but if it was just downloaded from the web
> and the various *.xml files are the only sources for grouping
> information it's not. Best-case scenario it goes into an ugly "Other"
> category. Worst-case it's ignored.

Now here we get into the concept of what it means to actually manage
packages...and package collections.  I was hoping the discussion would
have gotten to this point sooner.....i've been waiting to beat up this
point of view.

I don't think its wise to have a tool treat one-off package installs
that have to be installed by hand and can not have updates retrieved
in the same way it treats packages that are managed in collections
that don't have to be installed by hand and can be updated via methods
known by the management tool entity.

I think its absolutely important that people KNOW which packages
listed there are managed and which packages are local one-off
installs.  I expect symmetry in tool operation. for packages managed
in repos...or from install media that can be registered with the
management tool I can use the management tool to
install/upgrade/remove in a sensible collective way.

For packages that i download by hand...and install by hand...i expect
the tool to go out of its way to notify me that these packages are
considered EXTRA_ORDINARY. I think its very unwise for one off
packages to be grouped in the same way that managed packages(install
media or online repos) because there isn't an equitable and symmetric
way to get things like updates for those packages. It needs to be
obvious to the user that the package management tool can not update
those one-off packages in a sensible way and further manual
intervention is needed to keep things shipshape.


> So there is a need for grouping info even for "standalone" packages
> because once they are installed they become part of a group of packages,
> effective management of which is very important.

Effective management is important... one-offs can not be effectively
managed..the management tool does not know how to update them or
install them via group operations...as such one-offs need to be held
outside standad listings to make that difference obvious.


-jef"personal posting limit vastly exceeded on this thread...going
into lurk mode on the list to compensate"spaleta




From brads at redhat.com  Wed May 26 15:44:44 2004
From: brads at redhat.com (Brad Smith)
Date: Wed, 26 May 2004 11:44:44 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <604aa7910405261122789c4d0a@mail.gmail.com>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085562157.13536.11.camel@ulysse.olympe.o2t>
	<604aa791040526051641b8d669@mail.gmail.com>
	<1085585538.16473.19.camel@ulysse.olympe.o2t>
	<604aa7910405260904713badec@mail.gmail.com>
	<1085582979.7850.105.camel@localhost.localdomain>
	<604aa7910405261122789c4d0a@mail.gmail.com>
Message-ID: <1085586284.7850.193.camel@localhost.localdomain>

> For packages that i download by hand...and install by hand...i expect
> the tool to go out of its way to notify me that these packages are
> considered EXTRA_ORDINARY. I think its very unwise for one off
> packages to be grouped in the same way that managed packages(install
> media or online repos) because there isn't an equitable and symmetric
> way to get things like updates for those packages. It needs to be
> obvious to the user that the package management tool can not update
> those one-off packages in a sensible way and further manual
> intervention is needed to keep things shipshape.

That sounds like an excellent idea to me. How should the tools do it?
Would it be safe to assume that any package appearing in *.xml is a
managed package? Perhaps not if users can customize them to group
whatever packages they have installed, wherever they came from. Maybe an
update_source attribute? Or is there some already-there mechanism I
don't know about that would be better suited?

> 
> > So there is a need for grouping info even for "standalone" packages
> > because once they are installed they become part of a group of packages,
> > effective management of which is very important.
> 
> Effective management is important... one-offs can not be effectively
> managed..the management tool does not know how to update them or
> install them via group operations...as such one-offs need to be held
> outside standad listings to make that difference obvious.

I think your definition of management is too narrow here. One-offs can't
be effectively updated (or, as you say, at least ought to be flagged to
the admin knows to keep them manually updated). But there is still a
need to be able to see them in a browse-list for removal, seeing what
all is installed, etc. Thus I still say there's a need for some
mechanism that allows them to fit into the hierarchy.

> -jef"personal posting limit vastly exceeded on this thread...going
> into lurk mode on the list to compensate"spaleta

Please don't. You seem to have a well thought-out agenda here and if you don't contribute then it's not going to go anywhere. =:)

--Brad




From ckloiber at ckloiber.com  Wed May 26 18:55:18 2004
From: ckloiber at ckloiber.com (Chris Kloiber)
Date: Thu, 27 May 2004 02:55:18 +0800
Subject: debugging xorg-x11
In-Reply-To: <20040526164027.GI13803@angus.ind.WPI.EDU>
References: <20040526164027.GI13803@angus.ind.WPI.EDU>
Message-ID: <1085597718.4331.22.camel@roadrash.rdu.redhat.com>

On Thu, 2004-05-27 at 00:40, Charles R. Anderson wrote:
> I have a FC2 system whose X11 has locked up after sitting on a
> screensaver overnight.  I can still get into the system via ssh, but I
> cannot vt switch away from the locked up X11.  The X process is taking 
> up all the CPU:
> 
> USER       PID %CPU %MEM   VSZ  RSS TT       STAT  STARTED     TIME COMMAND
> root     23040 97.7  5.2 67488 20248 ?       R     May 22 1-16:02:50 /usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7
> 
> strace shows it in a tight loop:
> 
> select(1024, [8], NULL, NULL, {0, 0})   = ? ERESTARTNOHAND (To be restarted)
> select(1024, [8], NULL, NULL, {0, 0})   = ? ERESTARTNOHAND (To be restarted)
> select(1024, [8], NULL, NULL, {0, 0})   = ? ERESTARTNOHAND (To be restarted)
> 
> Xorg.0.log shows this repeating error:
> 
> (EE) RADEON(0): GetBuffer timed out, resetting engine...
> (EE) RADEON(0): Idle timed out, resetting engine...
> (EE) RADEON(0): GetBuffer timed out, resetting engine...
> (EE) RADEON(0): Idle timed out, resetting engine...
> (EE) RADEON(0): Idle timed out, resetting engine...
> (EE) RADEON(0): Idle timed out, resetting engine...
> (EE) RADEON(0): Idle timed out, resetting engine...
> ...
> 
> How can I go about debugging this so I can make a meaningful bug
> report?  What debuginfo packages and gdb version do I need?
> 
> xorg-x11-6.7.0-2 is using radeon driver for this card:
> 
> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
>         Subsystem: ATI Technologies Inc Radeon 7000/Radeon VE
>         Flags: bus master, stepping, 66Mhz, medium devsel, latency 32, IRQ 161
>         Memory at d0000000 (32-bit, prefetchable)
>         I/O ports at d000 [size=256]
>         Memory at dd000000 (32-bit, non-prefetchable) [size=64K]
>         Capabilities: [58] AGP version 2.0
>         Capabilities: [50] Power Management version 2
> 
> kernel is 2.6.5-1.358smp.  Chipset:
> 
> 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
>         Flags: bus master, medium devsel, latency 0
>         Memory at d8000000 (32-bit, prefetchable)
>         Capabilities: [a0] AGP version 2.0
>         Capabilities: [c0] Power Management version 2
> 
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode])
>         Flags: bus master, 66Mhz, medium devsel, latency 0
>         Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>         I/O behind bridge: 0000d000-0000dfff
>         Memory behind bridge: dc000000-ddffffff
>         Prefetchable memory behind bridge: d0000000-d7ffffff
>         Expansion ROM at 0000d000 [disabled] [size=4K]
>         Capabilities: [80] Power Management version 2
> 
> CPUs:
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 8
> model name      : Pentium III (Coppermine)
> stepping        : 3
> cpu MHz         : 799.919
> cache size      : 256 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse
> bogomips        : 1572.86
> 
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 8
> model name      : Pentium III (Coppermine)
> stepping        : 3
> cpu MHz         : 799.919
> cache size      : 256 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse
> bogomips        : 1597.44
> 
> Thanks.

I'm guessing a gl-based screensaver is what has you stuck. Once you
reboot, use glxinfo to see if dri is enabled, then try running glxgears
(or tuxracer). I think you will see similar behavior (screen will lock
up, but you can ssh in and reboot that way). At least it seems I can
reproduce it that way here. (I have screensavers disabled).

-- 
Chris Kloiber





From tony at tgds.net  Wed May 26 19:18:05 2004
From: tony at tgds.net (Tony Grant)
Date: Wed, 26 May 2004 21:18:05 +0200
Subject: debugging xorg-x11
In-Reply-To: <20040526164027.GI13803@angus.ind.WPI.EDU>
References: <20040526164027.GI13803@angus.ind.WPI.EDU>
Message-ID: <1085599084.7642.90.camel@localhost.localdomain>

Le mer 26/05/2004 ? 18:40, Charles R. Anderson a ?crit :
> I have a FC2 system whose X11 has locked up after sitting on a
> screensaver overnight.  I can still get into the system via ssh, but I
> cannot vt switch away from the locked up X11.  The X process is taking 

Been there!

So you ssh into the machine and you do "killall xscreensaver"

Then you chose a sane screen saver instead of looping through them all.
Just to remind me that this happens I use BSOD...

Cheers

Tony Grant

-- 
www.tgds.net Library management software toolkit





From shiva at sewingwitch.com  Wed May 26 20:05:36 2004
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Wed, 26 May 2004 13:05:36 -0700
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085584533.7850.137.camel@localhost.localdomain>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085562157.13536.11.camel@ulysse.olympe.o2t>
	<604aa791040526051641b8d669@mail.gmail.com>
	<1085585538.16473.19.camel@ulysse.olympe.o2t>
	<604aa7910405260904713badec@mail.gmail.com>
	<1085582979.7850.105.camel@localhost.localdomain>
	<571629A5AA440324221B889C@[10.170.7.6]>
	<1085584533.7850.137.camel@localhost.localdomain>
Message-ID: <CAEE8244972C56F9D406ABA9@[10.170.7.6]>

--On Wednesday, May 26, 2004 11:15 AM -0400 Brad Smith <brads at redhat.com> 
wrote:

> But the guts of rpm's machinery is not something I'm familiar with
> enough to comment much more than that.

One approach would be to recycle the Groups field and treat the slashes as 
keyword separators. Legacy packages would in effect have two keywords 
already defined. (I'd need to double-check that the Groups field in the 
header works this way, but I suspect it's just free-form text.)





From rhally at mindspring.com  Wed May 26 20:08:59 2004
From: rhally at mindspring.com (Richard Hally)
Date: Wed, 26 May 2004 16:08:59 -0400
Subject: debugging xorg-x11
In-Reply-To: <1085599084.7642.90.camel@localhost.localdomain>
References: <20040526164027.GI13803@angus.ind.WPI.EDU>
	<1085599084.7642.90.camel@localhost.localdomain>
Message-ID: <40B4F95B.9080707@mindspring.com>

Tony Grant wrote:

> Le mer 26/05/2004 ? 18:40, Charles R. Anderson a ?crit :
> 
>>I have a FC2 system whose X11 has locked up after sitting on a
>>screensaver overnight.  I can still get into the system via ssh, but I
>>cannot vt switch away from the locked up X11.  The X process is taking 
> 
> 
> Been there!
> 
> So you ssh into the machine and you do "killall xscreensaver"
> 
> Then you chose a sane screen saver instead of looping through them all.
> Just to remind me that this happens I use BSOD...
> 
> Cheers
> 
> Tony Grant
> 
I've had this "screensaver lockup" also.  It seems to happen on two 
screen savers in particular "atunnel" and "polytopes" so I just 
unselected those from the rotation. IIRC this has been bugzilled.
Richard Hally




From mike at netlyncs.com  Wed May 26 20:50:02 2004
From: mike at netlyncs.com (Mike Chambers)
Date: Wed, 26 May 2004 15:50:02 -0500
Subject: Call for Discussion: Summary document concerning
	Prevention andRecovery of XP Dual Boot Problems
In-Reply-To: <1085583465.7850.120.camel@localhost.localdomain>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<001b01c4428f$52bed090$0200a8c0@gandalf>
	<1085535602.7850.51.camel@localhost.localdomain>
	<604aa791040526070041b14707@mail.gmail.com>
	<1085585224.2155.2.camel@scrappy.netlyncs.com>
	<1085583465.7850.120.camel@localhost.localdomain>
Message-ID: <1085604602.2314.3.camel@scrappy.netlyncs.com>

On Wed, 2004-05-26 at 10:57 -0400, Brad Smith wrote:

> I've got to agree with Seth there. My job at Red Hat has nothing to do
> with development and I have no special access to anything to do with
> Fedora. 

Agreed, sort of wasn't meant in the way it sounded, read below.


> Jeff, though I wish he'd been more polite about it, was correct
> in that I should have checked to see if there had been any more news
> (sure enough, the bug still exists in mdk10).

I think I was just a little ticked at the way he did/said it and not
being more polite as you pointed out.

> That said, this thread is getting focused on a relatively unimportant
> part of my post (IMO) and ignoring where I *was* trying to "move the
> discussion forward"

Also agree and sorry to everyone for even bringing it up :(

-- 
Mike Chambers
Madisonville, KY

"It's always better to hurt a little now, than to hurt a lot later!"




From Nicolas.Mailhot at laPoste.net  Wed May 26 20:53:09 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Wed, 26 May 2004 22:53:09 +0200
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <604aa7910405261122789c4d0a@mail.gmail.com>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<604aa791040525213637efee3c@mail.gmail.com>
	<1085536194.7850.60.camel@localhost.localdomain>
	<200405252322.11584.kewley@cns.caltech.edu>
	<1085562157.13536.11.camel@ulysse.olympe.o2t>
	<604aa791040526051641b8d669@mail.gmail.com>
	<1085585538.16473.19.camel@ulysse.olympe.o2t>
	<604aa7910405260904713badec@mail.gmail.com>
	<1085582979.7850.105.camel@localhost.localdomain>
	<604aa7910405261122789c4d0a@mail.gmail.com>
Message-ID: <1085604790.2302.29.camel@m64.net81-64-154.noos.fr>

Le mer, 26/05/2004 ? 14:22 -0400, Jeff Spaleta a ?crit :
> On Wed, 26 May 2004 10:49:39 -0400, Brad Smith <brads at redhat.com> wrote:
> > But now it's installed. So suppose I'm cleaning up my system and I run
> > system-config-packages and go looking through the games to see what I'm
> > not using anymore. Or suppose I'm just a user on the system and I'm
> > using some other tool just to see what all is installed. I would expect
> > foo to show up under games, but if it was just downloaded from the web
> > and the various *.xml files are the only sources for grouping
> > information it's not. Best-case scenario it goes into an ugly "Other"
> > category. Worst-case it's ignored.
> 
> Now here we get into the concept of what it means to actually manage
> packages...and package collections.  I was hoping the discussion would
> have gotten to this point sooner.....i've been waiting to beat up this
> point of view.
> 
> I don't think its wise to have a tool treat one-off package installs
> that have to be installed by hand and can not have updates retrieved
> in the same way it treats packages that are managed in collections
> that don't have to be installed by hand and can be updated via methods
> known by the management tool entity.

I'm afraid the one-off packages you dismiss so easily cover a rather
large spectrum of current rpm use, from single-rpm upstream project
releases to nosrc.rpms, packages downloaded directly using the links in
the rhn interface, trivial packages we all make up every once in a while
that are way too ugly to submit to fedora, etc

Moreover sometimes project names collide (most (in)famous example not so
long ago firebird the browser and firebird the database), so using a the
name as a single key is very unwise (esp. when they collisions are bound
to occur the most frequently in obscure repositories/sources). For
example, what is crimson ?

And managing packages also means the poor sod who gets to administer a
system installed years ago by someone who choose to pursue personal
enlightment in a nepalese lamasery since. And I can tell you when you
get there you're pretty happy to have groups or any other sort of hint
that gives you a starting point instead of a big whack on the head like
"others, you stoopid admin, why didn't you think of it before going
outside my repository" (did I tell you you had 30 min to uninstall
something without breaking the system since the disks are now
overflowing ?)

The conclusion of all this is I do support, use and contribute to strict
homogenous projects like fedora.us, but expecting real-world systems to
restrict their software usage to such sources is akin to expect any
given car to be as scratchless and clean after a year of use as the day
it rolled out of the factory.

Hell, you'll be lucky if all your systems are even 100% rpmified.

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

From strange at nsk.no-ip.org  Wed May 26 21:08:08 2004
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Wed, 26 May 2004 22:08:08 +0100
Subject: Confusion with new platforms and packages
In-Reply-To: <407DB3E3.8030906@nathanr.net>
References: <407DB3E3.8030906@nathanr.net>
Message-ID: <20040526210808.GA16513@nsk.no-ip.org>

On Thu, Apr 15, 2004 at 07:57:55AM +1000, Nathan Robertson wrote:
> Hi,
> 
> I've been doing a fair amount of work (ie. a fair slice of my free time 
> over the last couple of months) on getting Fedora Core booting on Apple 
> PowerPC. Because the ppc tree already existed (from my understanding, 
> just not tested on Apple hardware), I was given a huge head start. I now 
> have a install of FC/devel on my PowerBook and an old PowerMac G3, and 
> have been reporting bugs against packages (usually with patches) to 
> correct issues I've found.
<snip>

Hello,

Could you inform me of the status of Fedora Core on an iBook?

If it works properly, how easy it easy to setup up, and if binary packages
are available.

Thanks,
Luciano Rocha

-- 
Consciousness: that annoying time between naps.




From strange at nsk.no-ip.org  Wed May 26 21:09:28 2004
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Wed, 26 May 2004 22:09:28 +0100
Subject: Confusion with new platforms and packages
In-Reply-To: <20040526210808.GA16513@nsk.no-ip.org>
References: <407DB3E3.8030906@nathanr.net>
	<20040526210808.GA16513@nsk.no-ip.org>
Message-ID: <20040526210928.GA17715@nsk.no-ip.org>

On Wed, May 26, 2004 at 10:08:08PM +0100, Luciano Miguel Ferreira Rocha wrote:
> On Thu, Apr 15, 2004 at 07:57:55AM +1000, Nathan Robertson wrote:
> > Hi,
> > 
> > I've been doing a fair amount of work (ie. a fair slice of my free time 
> > over the last couple of months) on getting Fedora Core booting on Apple 
> > PowerPC. Because the ppc tree already existed (from my understanding, 
> > just not tested on Apple hardware), I was given a huge head start. I now 
> > have a install of FC/devel on my PowerBook and an old PowerMac G3, and 
> > have been reporting bugs against packages (usually with patches) to 
> > correct issues I've found.
> <snip>
> 
> Hello,
> 
> Could you inform me of the status of Fedora Core on an iBook?
> 
> If it works properly, how easy it easy to setup up, and if binary packages
> are available.
> 

Damn... Forgot to change the To:. Is reply-to really necessary?...

Regards,
Luciano Rocha

-- 
Consciousness: that annoying time between naps.




From cra at WPI.EDU  Wed May 26 21:18:31 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Wed, 26 May 2004 17:18:31 -0400
Subject: debugging xorg-x11
In-Reply-To: <40B4F95B.9080707@mindspring.com>
References: <20040526164027.GI13803@angus.ind.WPI.EDU>
	<1085599084.7642.90.camel@localhost.localdomain>
	<40B4F95B.9080707@mindspring.com>
Message-ID: <20040526211831.GK13803@angus.ind.WPI.EDU>

On Wed, May 26, 2004 at 04:08:59PM -0400, Richard Hally wrote:
> I've had this "screensaver lockup" also.  It seems to happen on two 
> screen savers in particular "atunnel" and "polytopes" so I just 
> unselected those from the rotation. IIRC this has been bugzilled.
> Richard Hally

It happens to have stuck on the screensaver that shows the old "Apple
][" screenshot.

I've killed all processes under my userid (except my ssh session) and
the X server is still stuck at 100% CPU.




From tony at tgds.net  Wed May 26 21:31:06 2004
From: tony at tgds.net (Tony Grant)
Date: Wed, 26 May 2004 23:31:06 +0200
Subject: debugging xorg-x11
In-Reply-To: <20040526211831.GK13803@angus.ind.WPI.EDU>
References: <20040526164027.GI13803@angus.ind.WPI.EDU>
	<1085599084.7642.90.camel@localhost.localdomain>
	<40B4F95B.9080707@mindspring.com>
	<20040526211831.GK13803@angus.ind.WPI.EDU>
Message-ID: <1085607066.7642.94.camel@localhost.localdomain>

Le mer 26/05/2004 ? 23:18, Charles R. Anderson a ?crit :
> On Wed, May 26, 2004 at 04:08:59PM -0400, Richard Hally wrote:
> > I've had this "screensaver lockup" also.  It seems to happen on two 
> > screen savers in particular "atunnel" and "polytopes" so I just 
> > unselected those from the rotation. IIRC this has been bugzilled.
> > Richard Hally
> 
> It happens to have stuck on the screensaver that shows the old "Apple
> ][" screenshot.
> 
> I've killed all processes under my userid (except my ssh session) and
> the X server is still stuck at 100% CPU.

OK had that too. 

Kill -9 X process ID is the only way out. Mop up. Turn off all screen
saver modules except one when you get it back up and running.

Cheers

Tony Grant
-- 
www.tgds.net Library management software toolkit





From leonard at den.ottolander.nl  Wed May 26 22:08:09 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Thu, 27 May 2004 00:08:09 +0200
Subject: rpmbuild-nonroot %{version} interpreted incorrectly
In-Reply-To: <1085583491.18988.61.camel@gibraltar.stuttgart.redhat.com>
References: <1085580008.4457.10.camel@athlon.localdomain>
	<1085583491.18988.61.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <1085609288.4457.26.camel@athlon.localdomain>

Hi Nils,

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

> > -14: _sourcedir %{_topdir}/%{name}-%{version}

> > The latest "Version:" tag in the spec file is the one for popt. It
> > looks as if this value is substituted for %{version}. How can this be
> > fixed?
> 
> I guess this has to be fixed in RPM itself -- I think you should file it
> in Bugzilla (actually I stumbled over this a while ago but was too lazy
> to file it ;-).

What do you think the above bugzilla reference is for? Sadly Jeff has
already tagged this a WONTFIX. Too bad, as this setup with spec, source
and patch files separated by package is very convenient.

Guess we will have to work around packages that define "Version:" tags
for sub packages. Too bad :( .

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research





From felipe_alfaro at linuxmail.org  Wed May 26 22:21:33 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Thu, 27 May 2004 00:21:33 +0200
Subject: debugging xorg-x11
In-Reply-To: <1085599084.7642.90.camel@localhost.localdomain>
References: <20040526164027.GI13803@angus.ind.WPI.EDU>
	<1085599084.7642.90.camel@localhost.localdomain>
Message-ID: <1085610093.2417.0.camel@teapot.felipe-alfaro.com>

On Wed, 2004-05-26 at 21:18, Tony Grant wrote:
> Le mer 26/05/2004 ? 18:40, Charles R. Anderson a ?crit :
> > I have a FC2 system whose X11 has locked up after sitting on a
> > screensaver overnight.  I can still get into the system via ssh, but I
> > cannot vt switch away from the locked up X11.  The X process is taking 
> 
> Been there!
> 
> So you ssh into the machine and you do "killall xscreensaver"
> 
> Then you chose a sane screen saver instead of looping through them all.
> Just to remind me that this happens I use BSOD...

I think he wanted to debug what was going on, not just fixing the
problem without knowing what caused it.




From cra at WPI.EDU  Wed May 26 22:30:24 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Wed, 26 May 2004 18:30:24 -0400
Subject: debugging xorg-x11
In-Reply-To: <1085610093.2417.0.camel@teapot.felipe-alfaro.com>
References: <20040526164027.GI13803@angus.ind.WPI.EDU>
	<1085599084.7642.90.camel@localhost.localdomain>
	<1085610093.2417.0.camel@teapot.felipe-alfaro.com>
Message-ID: <20040526223024.GL13803@angus.ind.WPI.EDU>

On Thu, May 27, 2004 at 12:21:33AM +0200, Felipe Alfaro Solana wrote:
> I think he wanted to debug what was going on, not just fixing the
> problem without knowing what caused it.

That's true, yes.  I want to help fix the underlying cause of this
problem, which is why I asked on the -devel list.  I'm not in any 
hurry reboot or anything.

So, what gdb and debuginfo packages do I need?  I remember in the
not-so-distant past one needed a special version of gdb to debug
XFree86.




From somlo at acns.colostate.edu  Wed May 26 22:50:26 2004
From: somlo at acns.colostate.edu (Gabriel L. Somlo)
Date: Wed, 26 May 2004 16:50:26 -0600
Subject: xdaliclock rpm for fedora core 2 ?
Message-ID: <20040526225001.GB17143@hedwig.acns.colostate.edu>


Wanted to build xdaliclock from src.rpm myself, so I ripped PLD's
xdaliclock-2.20-1.src.rpm

(http://rpmfind.net/linux/RPM/PLD/dists/ra/updates/general/i386/xdaliclock-2.20-1.i386.html)

and made it build on my brand-spanking-new Fedora Core 2 install !

The modified spec file is attached (along with pld's two patches) for
your rpm-building convenience.

Please let me know in case this is redundant and/or if there's a
better place to send this kind of thing. (is there a FC2 'extras'
repository ?)

Thanks,
Gabriel


-------------- next part --------------
# FC2 spec file for xdaliclock

Summary:	Funky clock with morphing digits
Name:		xdaliclock
Version:	2.20
Release:	1gls
License:	MIT
Group:		User Interface/X
Source0:	http://www.jwz.org/xdaliclock/%{name}-%{version}.tar.gz
Patch0:		%{name}-shape-cycle.patch
Patch1:		%{name}-DESTDIR.patch
URL:		http://www.jwz.org/xdaliclock/
BuildRoot:	%{_tmppath}/%{name}-%{version}-root
BuildRequires:	xorg-x11-devel, autoconf

%define		_prefix		/usr/X11R6
%define 	_mandir 	%{_prefix}/man

%description
The xdaliclock program displays a digital clock; when a digit changes,
it "morphs" into its new shape.

It can display in 12 or 24 hour modes, and displays the date when a
mouse button is held down. It has two large fonts built into it, but
it can animate other fonts.

%prep
%setup -q
%patch0 -p1
%patch1 -p1

%build
cd X11
CFLAGS="-D_GNU_SOURCE"
%{__autoconf}
%configure
%{__make}

%install
rm -rf %{buildroot}
cd X11
%{__make} install install-man DESTDIR=%{buildroot}
install -D XDaliClock.ad %{buildroot}%{_libdir}/X11/app-defaults/XDaliClock

%clean
rm -rf %{buildroot}

%files
%defattr(644,root,root,755)
%attr(755,root,root) %{_bindir}/%{name}
%{_libdir}/X11/app-defaults/XDaliClock
%{_mandir}/man1/*

%define date	%(echo `LC_ALL="C" date +"%a %b %d %Y"`)
%changelog
* %{date} Gabriel L. Somlo <somlo at acns.colostate.edu>
Changed XFree86-devel reference to xorg-x11-devel
Trimmed down spec file :)
Made sure package builds correctly on Fedora Core 2
Fixed "error: Package already exists: %_package debuginfo" error
Removed %_{rpmcflags} from CFLAGS line -- was borking build on FC2
AppDefaults install required -D flag to create directory.

* Wed Oct 15 2003 PLD Team <feedback at pld.org.pl>
All persons listed below can be reached at <cvs_login>@pld.org.pl

$Log: xdaliclock.spec,v $
Revision 1.27.2.1  2003/10/15 15:42:24  kloczek
- reelase 1 for Ra.

Revision 1.27  2003/10/15 15:41:56  kloczek
- updated to 2.20: bug fixes,
- remove oudated time patch,
- merge translations from KSI.

Revision 1.26  2002/12/08 20:38:56  ankry
- remove bogus fr Summary

Revision 1.25  2002/12/08 11:53:21  blues
- spelling fixes by Tomasz "Witek" Wittner <wittt_ at poczta.onet.pl>

Revision 1.24  2002/05/21 23:15:04  kloczek
perl -pi -e "s/^automake -a -c -f --foreing/\%\{__automake\}/; \
             s/^automake -a -c -f/\%\{__automake\}/; \
	     s/^autoconf/\%\{__autoconf\}/"

Revision 1.23  2002/02/23 05:11:00  kloczek
- adapterized.

Revision 1.22  2002/02/22 23:30:03  kloczek
- removed all Group fields translations (oure rpm now can handle translating
  Group field using gettext).

Revision 1.21  2002/01/18 02:15:28  kloczek
perl -pi -e "s/pld-list\@pld.org.pl/feedback\@pld.org.pl/"

Revision 1.20  2001/07/23 02:29:03  kloczek
- release 8,
- merge time patch from rawhide,
- regenerate ac files (spec is ac 2.5x ready).

Revision 1.19  2001/01/30 04:59:54  kloczek
- typos in %_install.

Revision 1.18  2001/01/30 04:56:53  kloczek
- release 6,
- added icons (based on MDK resources) and desktop file (based on Conectiva
  wmconfig) for xdaliclock,
- spec adapterized.

Revision 1.17  2000/11/12 20:11:56  kloczek
- modyfications for using neew rpm automation.

Revision 1.16  2000/06/09 07:55:16  kloczek
- more %%{__make} macros.

Revision 1.15  2000/06/09 07:24:14  kloczek
- added using %%{__make} macro.

Revision 1.14  2000/05/21 20:05:15  kloczek
- spec adapterized.

Revision 1.13  2000/04/01 11:16:00  zagrodzki
- changed all BuildRoot definitons
- removed all applnkdir defs
- changed some prereqs/requires
- removed duplicate empty lines

Revision 1.12  2000/03/28 16:55:15  baggins
- translated kloczkish into english

Revision 1.11  2000/03/06 03:05:59  kloczek
- updated to 2.18,
- updated Source url and added URL.

Revision 1.10  1999/09/04 09:44:01  pius
- cosmetics

Revision 1.9  1999/07/20 12:48:11  wiget
- switch to rpm 3.0.2

Revision 1.8  1999/07/12 23:06:21  kloczek
- added using CVS keywords in %changelog (for automating them).

* Thu May 20 1999 Piotr Czerwi?ski <pius at pld.org.pl>
  [2.14-1]
- package is FHS 2.0 compliant,
- spec file based on RH version; modified for PLD use by me
  and Tomasz K?oczko <kloczek at rudy.mif.pg.gda.pl>.
-------------- next part --------------
--- xdaliclock-2.18/X11/digital.c.foo	Tue Nov 30 16:32:40 1999
+++ xdaliclock-2.18/X11/digital.c	Tue Nov 30 16:32:47 1999
@@ -1249,7 +1249,6 @@
             XShapeCombineMask (dpy, window, ShapeBounding,
                                window_offset_x, window_offset_y,
                                pixmap, ShapeSet);
-          else
 #endif /* HAVE_SHAPE */
             /* sends 28 bytes */
             XCopyPlane (dpy, pixmap, window, window_draw_gc, 0, 0,
-------------- next part --------------
--- xdaliclock-2.20/X11/Makefile.in~	Mon Sep  8 01:48:59 2003
+++ xdaliclock-2.20/X11/Makefile.in	Wed Oct 15 16:57:14 2003
@@ -78,16 +78,18 @@
 		install
 
 install-program: xdaliclock
-	$(INSTALL_PROGRAM) xdaliclock $(install_prefix)$(bindir)/xdaliclock
+	$(INSTALL) -d $(DESTDIR)$(bindir)
+	$(INSTALL_PROGRAM) xdaliclock $(DESTDIR)$(bindir)/xdaliclock
 
 install-man: xdaliclock.man
-	$(INSTALL_DATA) $(srcdir)/xdaliclock.man $(install_prefix)$(man1dir)/xdaliclock.1
+	$(INSTALL) -d $(DESTDIR)$(man1dir)
+	$(INSTALL_DATA) $(srcdir)/xdaliclock.man $(DESTDIR)$(man1dir)/xdaliclock.1
 
 uninstall-program:
-	rm -f $(install_prefix)$(bindir)/xdaliclock
+	rm -f $(DESTDIR)$(bindir)/xdaliclock
 
 uninstall-man:
-	rm -f $(install_prefix)$(man1dir)/xdaliclock.1
+	rm -f $(DESTDIR)$(man1dir)/xdaliclock.1
 
 clean:
 	-rm -f *.o a.out core xdaliclock XDaliClock_ad.h xdaliclock.hlp

From carwyn at carwyn.com  Wed May 26 23:57:16 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Thu, 27 May 2004 00:57:16 +0100
Subject: xdaliclock rpm for fedora core 2 ?
In-Reply-To: <20040526225001.GB17143@hedwig.acns.colostate.edu>
References: <20040526225001.GB17143@hedwig.acns.colostate.edu>
Message-ID: <40B52EDC.1090306@carwyn.com>

Gabriel L. Somlo wrote:

> if there's a better place to send this kind of thing.
> (is there a FC2 'extras' repository ?)

Your best bet I'd guess is http://www.fedora.us/

Specifically:

http://www.fedora.us/wiki/FedoraDocuments

.. as there you can find out how to submit your RPM.

Carwyn




From wrrhdev at riede.org  Thu May 27 02:52:45 2004
From: wrrhdev at riede.org (Willem Riede)
Date: Wed, 26 May 2004 22:52:45 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
	(from b.j.smith@ieee.org on Mon, May 24, 2004 at 01:45:13 -0400)
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <20040527025245.GG13627@serve.riede.org>

On 2004.05.24 01:45, Bryan J. Smith wrote:
> Steven Pritchard wrote:  
> > Although, again, I don't think it makes a bit of sense to have an
> > app like Scribus in Core.  It's definitely Extras material in my mind.
> > Of course, at this point I'm thinking OpenOffice, Gimp, and various
> > other things are looking like nice targets for Extras.  4 CDs for
> > Core?  :-)
> 
> Steven brings up a larger issue.  With Fedora going to the "distributed"
> model, at what point do we start to try (if at all?) to "reduce" the
> size Fedore "Core" (FC)?
> 
> I mean, is there a reason we need to maintain a 3+ CD set for FC, just
> as to match the "legacy" design of old Red Hat Linux (RHL)?
> 
> I personally would like to see "Core" reduced to a _single_ binary CD.

Why? I've read the barrage of mails this triggered, and I see absolutely
no benefit. I can understand the desire to have a more minimal "minimal"
install package set, and the packages that would be in that set will
probably all sit on the first CD. But that doesn't translate into the
need to limit the size of the distribution. Convenience for those of us
(like me) that use a more extensive package set should not be compromised.

Regards, Willem Riede.




From aoliva at redhat.com  Thu May 27 04:17:38 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 27 May 2004 01:17:38 -0300
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
References: <1085377512.18635.528.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <or4qq2mrkt.fsf@livre.redhat.lsd.ic.unicamp.br>

On May 24, 2004, "Bryan J. Smith" <b.j.smith at ieee.org> wrote:

> I personally would like to see "Core" reduced to a _single_ binary CD.

<humor bad=maybe>
I'd be fine with a single DVD.  Oh, wait :-)
</humor>

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From dwmw2 at infradead.org  Thu May 27 07:32:39 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 27 May 2004 08:32:39 +0100
Subject: Confusion with new platforms and packages
In-Reply-To: <20040526210808.GA16513@nsk.no-ip.org>
References: <407DB3E3.8030906@nathanr.net>
	<20040526210808.GA16513@nsk.no-ip.org>
Message-ID: <1085643159.27156.3058.camel@imladris.demon.co.uk>

On Wed, 2004-05-26 at 22:08 +0100, Luciano Miguel Ferreira Rocha wrote:
> Could you inform me of the status of Fedora Core on an iBook?

It's working very nicely on my G4 PowerBook.

> If it works properly, 

Yes, mostly. The tracking bug for all things mac/ppc related is 
https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=121179

> how easy it easy to setup up, 

The installer doesn't know how to make a hard disk bootable by the Mac
yet. We're working on it. Don't let it autopartition -- make sure you
make a bootstrap partition of 800K (or 1M if the installer doesn't let
you specify 800K). Then when it's finished installing but before you let
it reboot, follow the instructions at
http://www.bytebot.net/geekdocs/ibook/fedorappc.html to install yaboot.

Join #fedora-ppc on freenode and someone will talk you through it.

> and if binary packages are available.

Yes. http://fedora.linux.duke.edu/fedorappc/ has a known good working
tree from which you can run up2date. I think
http://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/
doesn't have a mac boot.iso right now for some reason.

Once the installer is finished it'd be nice to make a real FC2 release
for Mac.

-- 
dwmw2





From pnasrat at redhat.com  Thu May 27 08:05:30 2004
From: pnasrat at redhat.com (Paul Nasrat)
Date: Thu, 27 May 2004 04:05:30 -0400
Subject: Confusion with new platforms and packages
In-Reply-To: <1085643159.27156.3058.camel@imladris.demon.co.uk>
References: <407DB3E3.8030906@nathanr.net>
	<20040526210808.GA16513@nsk.no-ip.org>
	<1085643159.27156.3058.camel@imladris.demon.co.uk>
Message-ID: <20040527080530.GC6672@devserv.devel.redhat.com>

On Thu, May 27, 2004 at 08:32:39AM +0100, David Woodhouse wrote:
> On Wed, 2004-05-26 at 22:08 +0100, Luciano Miguel Ferreira Rocha wrote:
> > Could you inform me of the status of Fedora Core on an iBook?
> 
> It's working very nicely on my G4 PowerBook.

Likewise on ibooks and imac DV SE (with some fb issues atm)
> 
> > If it works properly, 
> 
> Yes, mostly. The tracking bug for all things mac/ppc related is 
> https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=121179

> > and if binary packages are available.
> 
> Yes. http://fedora.linux.duke.edu/fedorappc/ has a known good working
> tree from which you can run up2date. I think

This should now have the tree as of 14 May so pretty close to FC 2.  I need to
check the tree again there is a newer yaboot and fedora-release was missing but
the hdlist should be updated.  I probably should update kudzu and other things as there have been a few mac specific fixes since then.

I need to upload the SRPMS too - but my upstream push is painfully slow at
times.

> Once the installer is finished it'd be nice to make a real FC2 release
> for Mac.

Yup.

Paul




From buildsys at redhat.com  Thu May 27 10:35:44 2004
From: buildsys at redhat.com (Build System)
Date: Thu, 27 May 2004 06:35:44 -0400
Subject: rawhide report: 20040527 changes
Message-ID: <200405271035.i4RAZis10947@porkchop.devel.redhat.com>

 

 
Updated Packages:

cups-1.1.20-10
--------------
* Wed May 26 2004 Tim Waugh <twaugh at redhat.com> 1:1.1.20-10

- Finish fix for cupsenable/cupsdisable (bug #102490).
- Fix MaxLogSize setting (bug #123003).

device-mapper-1.00.17-2.0
-------------------------
* Wed May 26 2004 Alasdair Kergon <agk at redhat.com> - 1.00.17-2

- Fix is_selinux_enabled() test

* Mon Apr 19 2004 Alasdair Kergon <agk at redhat.com> - 1.00.17-1

- Fix non-root build with current version of 'install'.
- Incorporate last two selinux patches into tarball.

hfsutils-3.2.6-3
----------------
* Mon Apr 19 2004 David Woodhouse  <dwmw2 at redhat.com> 3.2.6-3

- BuildRequires tk-devel

iproute-2.4.7-16
----------------
* Wed May 26 2004 Phil Knirsch <pknirsch at redhat.com> 2.4.7-16

- Took tons of manpages from debian, much more complete (#123952).

lvm2-2.00.15-4
--------------
* Wed May 26 2004 Alasdair Kergon <agk at redhat.com> - 2.00.15-4

- clone %description from LVM rpm

* Wed May 26 2004 Alasdair Kergon <agk at redhat.com> - 2.00.15-3

- vgscan shouldn't return error status when no VGs present

rpmdb-fedora-2-0.20040527
-------------------------

subversion-1.0.2-2.1
--------------------
* Sat May 15 2004 Joe Orton <jorton at redhat.com> 1.0.2-2.1

- add security fix for CVE CAN-2004-0397 (Ben Reser)

* Tue May 04 2004 Joe Orton <jorton at redhat.com> 1.0.2-2

- add perl MODULE_COMPAT requirement for -perl subpackage
- move perl man pages into -perl subpackage
- clean up -perl installation and dependencies (Ville Skytt??, #123045)

* Mon Apr 19 2004 Joe Orton <jorton at redhat.com> 1.0.2-1

- update to 1.0.2


vnc-4.0-1.beta5.2
-----------------
* Wed May 26 2004 Tim Waugh <twaugh at redhat.com> 4.0-1.beta5.2

- Switch to xorg-x11 (bug #119530).




From christian.paratschek at reflex.at  Thu May 27 11:32:16 2004
From: christian.paratschek at reflex.at (Christian Paratschek)
Date: Thu, 27 May 2004 13:32:16 +0200
Subject: small improvements for fedora 3: sound mixing
Message-ID: <1085657429.28535.9.camel@localhost.localdomain>

hi people on this list, i am a new member!

first of all: fedora core 2 is a very fine system. i have been an avid
user of red hat 7.3, 8.0,9 and fc1 and i am quite a loyal user...

i have some small gripes with fc2 and i wanna tell you, so that fc3 is
an even better product:

a default fc2 install doesn't mix sound events, i.e. i run xmms,
rhythmbox, etc and my gaim sounds don't play (here the bug is most
obvious). there is a simple fix for this, described on fedoranews.org:

http://fedoranews.org/contributors/andre_costa/alsa/

i didn't even have to do all the stuff mentioned there, i just had to
create the .asoundrc file and put that into it:

pcm.!default {
type plug
slave.pcm "swmixer"
}

pcm.swmixer {
type dmix
ipc_key 1234
slave {
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
}
} 

and then it worked without further configuration with all of xmms,
rhythmbox, gaim, totem in all combinations.

sound mixing is, imho a very essential feature, because not having it
makes fc2 look unpolished. if the fix is easy, i would suggest turning
the mixing on for fc3. we have kernel 2.6, we have alsa, this should
"just work".

regards,
christian




From peter.backlund at home.se  Thu May 27 13:53:27 2004
From: peter.backlund at home.se (Peter Backlund)
Date: Thu, 27 May 2004 15:53:27 +0200
Subject: small improvements for fedora 3: sound mixing
In-Reply-To: <1085657429.28535.9.camel@localhost.localdomain>
References: <1085657429.28535.9.camel@localhost.localdomain>
Message-ID: <1085666007.3015.45.camel@localhost.localdomain>

[snip]

> a default fc2 install doesn't mix sound events, i.e. i run xmms,
> rhythmbox, etc and my gaim sounds don't play (here the bug is most
> obvious). there is a simple fix for this, described on fedoranews.org:
> 
> http://fedoranews.org/contributors/andre_costa/alsa/
> 
> i didn't even have to do all the stuff mentioned there, i just had to
> create the .asoundrc file and put that into it:
> 
> pcm.!default {
> type plug
> slave.pcm "swmixer"
> }
> 
> pcm.swmixer {
> type dmix
> ipc_key 1234
> slave {
> pcm "hw:0,0"
> period_time 0
> period_size 1024
> buffer_size 4096
> rate 44100
> }
> } 

I have further suggestions: make the defult output device dmix, and
default input device dsnoop. Then create a default device with full
duplex, like this:

#
# DMIX input device
#
pcm.!output {
    type dmix
    ipc_key 1234
    slave {
        pcm "hw:0,0"
        period_time 0
        period_size 1024
        rate 44100
    }
}
                                                                                                                        
#
# DSNOOP output device
#
pcm.!input {
    type dsnoop
    ipc_key 1234
    slave {
        pcm "hw:0,0"
        period_time 0
        period_size 1024
        rate 44100
    }
}
                                                                                                                        
#
# ASYM duplex device
#
pcm.!duplex {
    type asym
    playback.pcm "output"
    capture.pcm "input"
}
                                                                                                                        
#
# Make the duplex device default
#
pcm.!default {
    type plug
    slave.pcm "duplex"
}
                                                                                                                        
#
# OSS Compability
#
pcm.!dsp0 {
    type plug
    slave.pcm "duplex"
}
                                                                                                                        
ctl.!mixer0 {
    type hw
    card 0
}

This should enable sound mixing - both input and ouput - to /just work/
for all supported cards.    

/Peter Backlund


> and then it worked without further configuration with all of xmms,
> rhythmbox, gaim, totem in all combinations.
> 
> sound mixing is, imho a very essential feature, because not having it
> makes fc2 look unpolished. if the fix is easy, i would suggest turning
> the mixing on for fc3. we have kernel 2.6, we have alsa, this should
> "just work".
> 
> regards,
> christian
> 
> 
-- 
Peter Backlund <peter.backlund at home.se>




From czar at czarc.net  Thu May 27 14:35:50 2004
From: czar at czarc.net (Gene C.)
Date: Thu, 27 May 2004 10:35:50 -0400
Subject: Call for Discussion: Summary document concerning Prevention and
	Recovery of XP Dual Boot Problems
In-Reply-To: <604aa7910405251604671af9cd@mail.gmail.com>
References: <604aa79104052511586a67d722@mail.gmail.com>
	<20040525224523.GB6612@devserv.devel.redhat.com>
	<604aa7910405251604671af9cd@mail.gmail.com>
Message-ID: <200405271035.50353.czar@czarc.net>

On Tuesday 25 May 2004 19:04, Jeff Spaleta wrote:
> On Tue, 25 May 2004 18:45:23 -0400, Alan Cox <alan at redhat.com> wrote:
> > Looking in the BIOS is another way for many boxes. Also if you set the
> > bios to LBA that is reported by many to keep stuff happy
>
> yes looking around... it seems using the bios to put the drive into
> LBA mode even
> comes up as a workaround for madrake's release.

Yes, LBA is a key factor to this problem .... I have looked at the whole 
document and do not see much about the problem being related to LBA (versus 
the physical c/h/s) and I believe this is key to the problem as well as the 
preventative solution.  This should be covered in more detail in the 
document.

>From other discussions, as I understand it the problem is in the upstream 2.6 
kernel and, since Fedora is trying to stay very close to what is in the 
upstream kernel, it needs to get fixed there.

A bad part to all of this is that it is likely to hit the new users who are 
trying to install FC2 on their Windows system.  When finalized, this should 
be published on the fedora-announce-list ... it really should be in the 
release note but it is too late for that now.

One regret I have is that the warning popup saying that there was something 
"wrong" with the partition table was removed ... at least this would give 
users a pause where they might research the problem.
-- 
Gene




From dwmw2 at infradead.org  Thu May 27 15:16:03 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 27 May 2004 16:16:03 +0100
Subject: Confusion with new platforms and packages
In-Reply-To: <20040526210808.GA16513@nsk.no-ip.org>
References: <407DB3E3.8030906@nathanr.net>
	<20040526210808.GA16513@nsk.no-ip.org>
Message-ID: <1085670963.26119.16.camel@hades.cambridge.redhat.com>

On Wed, 2004-05-26 at 22:08 +0100, Luciano Miguel Ferreira Rocha wrote:
> Could you inform me of the status of Fedora Core on an iBook?

Oh, and there's a Yum repository at
ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac with some stuff like
qemu (which runs acroread/i386 very nicely), xine, pmud, etc.

-- 
dwmw2




From christian.paratschek at reflex.at  Thu May 27 16:40:52 2004
From: christian.paratschek at reflex.at (Christian Paratschek)
Date: Thu, 27 May 2004 18:40:52 +0200
Subject: small improvements for fedora 3: sound mixing
In-Reply-To: <fc.3b9aca000364c2793b9aca009d663a79.34fc949@reflex.at>
References: <1085657429.28535.9.camel@localhost.localdomain>
	<fc.3b9aca000364c2793b9aca009d663a79.34fc949@reflex.at>
Message-ID: <1085676052.2797.2.camel@localhost.localdomain>

hi!

this does not work for me. xmms and rhythmbox play fine, but gaim sound
does not and gaim crashes when i try to close it.

i am not a programmer  but i test whatever you tell me :-)
would be great if i could be helpful here...

regards,
christian

> [snip]
> 
> I have further suggestions: make the defult output device dmix, and
> default input device dsnoop. Then create a default device with full
> duplex, like this:
> 
> #
> # DMIX input device
> #
> pcm.!output {
>     type dmix
>     ipc_key 1234
>     slave {
>         pcm "hw:0,0"
>         period_time 0
>         period_size 1024
>         rate 44100
>     }
> }
>                                                                           
>                                              
> #
> # DSNOOP output device
> #
> pcm.!input {
>     type dsnoop
>     ipc_key 1234
>     slave {
>         pcm "hw:0,0"
>         period_time 0
>         period_size 1024
>         rate 44100
>     }
> }
>                                                                           
>                                              
> #
> # ASYM duplex device
> #
> pcm.!duplex {
>     type asym
>     playback.pcm "output"
>     capture.pcm "input"
> }
>                                                                           
>                                              
> #
> # Make the duplex device default
> #
> pcm.!default {
>     type plug
>     slave.pcm "duplex"
> }
>                                                                           
>                                              
> #
> # OSS Compability
> #
> pcm.!dsp0 {
>     type plug
>     slave.pcm "duplex"
> }
>                                                                           
>                                              
> ctl.!mixer0 {
>     type hw
>     card 0
> }
> 
> This should enable sound mixing - both input and ouput - to /just work/
> for all supported cards.    
> 
> /Peter Backlund





From thiers at fosfertil.com.br  Thu May 27 18:29:53 2004
From: thiers at fosfertil.com.br (Thiers Botelho)
Date: Thu, 27 May 2004 15:29:53 -0300
Subject: XP Dual Boot Problems - contribution from a newbie
Message-ID: <OF230831B2.5835ACBA-ON03256EA1.0060A48D@fosfertil-ultrafertil.com.br>

Hi all devels,

I don't consider myself as a developer but, as I have written and 
successfully tested at least _one_ shell script, I think I might loosely 
fit on this category.   :))

Now seriously: regarding JS's call on this thread,

 http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00901.html

and also JA's posting of a preliminary doc on this one,

 http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00908.html

I wish to offer a contribution to the theme, following a different path 
from what's being explored till now. Note that some users might consider 
it more troublesome and  more involved, whereas some other users might 
prefer it due to the additional security it offers.

I have been playing for a time with 'System Rescue CD' which is a live CD 
with recovery tools, published at

        http://sysresccd.org/ .

Using it a few times, and adding a shallow knowledge of shell scripts, 
I've managed to build a set of scripts which work together and allow me to 
make partition backups (ext3, vfat and ntfs have been tested) to another 
HD or smb share (using partimage), plus backups of the MBR and partition 
table using dd and sfdisk .

I've also successfully restored NTFS and VFAT partitions which these 
scripts. In one case I purposely deleted the Windoze boot partition with 
fdisk and then restored it with a partimage backup after manually 
restoring the MBR and partition table.

Summing up all of this: if a doc is being cooked up to advise users on the 
perils of dual booting, I suppose many users would be pleased to find on 
this doc an additional and optional procedure like the following:

        - back up MBR with dd (per script)
        - back up partition table with sfdisk (per script)
        - back up windows partition(s) using partimage (per script)
        - install FC2 with all precautions
        - confirm that FC2 boots
        - see that Windoze boots and sigh in relief . . . OR
        - see that Windoze does not boot and proceed
        - back up FC2 partition(s) using partimage (per script)
        - restore MBR with dd (manually, maybe . . .)
        - restore partition table with sfdisk (manually, maybe . . .)
        - see that Windoze now boots and sigh in relief . . . (at least 
that's what's hoped at this point . . .)
        - see that now FC2 does not boot and proceed
        - if needed, destroy and recreate partitions for FC2 (manually 
with parted - Partition Magic could also be mentioned as an optional tool)
        - restore FC2 partition(s) using partimage (per script)
        - see that FC2 boots and sigh in relief 
        - go do something more interesting

I haven't personally gone thru the whole procedure myself, but judging for 
my experience with parts of it I have no reason to suspect it won't work. 
Of course I might have missed something, but that would require someone 
willing to go thru the whole shebang at once. It might take a few hours 
(mostly for I/O on backup and restore operations), but the setup is 
straightforward if shell scripts are used.

Maybe it will not be 'politically correct' to suggest third-party tools 
such as 'System Rescue CD' to recover from a Fedora-specific problem. 
However I'm suggesting this with a vision of broader 'Open Source' and 
'community' concepts.

Thanx all for your attention.

Thiers




From aaron.bennett at olin.edu  Thu May 27 19:18:08 2004
From: aaron.bennett at olin.edu (Aaron Bennett)
Date: Thu, 27 May 2004 15:18:08 -0400
Subject: OT: Livna.org rsync access down?
Message-ID: <40B63EF0.9050809@olin.edu>

Hello,

Sorry for the off-topic post -- I'm hoping there will be others reading 
this list with the same issue...

I haven't been able to rsync from rpm.livna.org for a few weeks.  At 
http://liva.org is a message saying their system is down.  Has anyone 
else found this?  Anyone have an rsync-able livna.org mirror? 

Cheers,

Aaron Bennett
UNIX Administrator
Olin College





From nando at ccrma.Stanford.EDU  Fri May 28 00:25:39 2004
From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano)
Date: 27 May 2004 17:25:39 -0700
Subject: fc2, xorg, 2.6.x, scheduling latency peaks
Message-ID: <1085703938.3993.334.camel@cmn37.stanford.edu>

Hi all. I'm trying to track the cause of high scheduling latency peaks
in FC2 that make the system unusable for low latency audio work. 

Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon
video chipset. How I test: I run the Jack (Jack Audio Connection Kit)
sound server with 2 or 3 128 frame buffers for low latency operation
through the Qjackctl gui front-end. I then start GUI apps that use Jack
(for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer
xruns of varying durations during the app load process and afterwards.
The same (laptop) system booting FC1 + XFree + 2.4.26 + low latency
patches has rock solid performance and no xruns in the same conditions.
If I boot FC2 into 2.4.26 + low latency patches I _still_ see xruns, so
it looks like the kernel itself is not triggering them. At least not all
of them. 

I have no hard data but the xruns appear to coincide with X activity. If
I turn off video acceleration I see _more_ xruns (significantly more).
If I switch to the vesa driver I still see xruns (so it would seem that
the radeon driver itself is not to blame). 

Does anyone out there know if something has changed between XFree and
xorg that may account for this change in behavior?

Thanks for _any_ help.... (I also tried several other configuration
options for xorg.conf with no effect whatsoever[*]). 

-- Fernando

[*] and even tried to downgrade to FC1's XFree86 just to see if I could
isolate the cause but the result was too unstable and messy to draw any
conclusions :-)





From nando at ccrma.Stanford.EDU  Fri May 28 00:39:27 2004
From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano)
Date: 27 May 2004 17:39:27 -0700
Subject: fc2, xorg, 2.6.x, scheduling latency peaks
In-Reply-To: <1085703938.3993.334.camel@cmn37.stanford.edu>
References: <1085703938.3993.334.camel@cmn37.stanford.edu>
Message-ID: <1085704767.3992.357.camel@cmn37.stanford.edu>

On Thu, 2004-05-27 at 17:25, Fernando Pablo Lopez-Lezcano wrote:
> Hi all. I'm trying to track the cause of high scheduling latency peaks
> in FC2 that make the system unusable for low latency audio work. 
> 
> Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon
> video chipset. How I test: I run the Jack (Jack Audio Connection Kit)
> sound server with 2 or 3 128 frame buffers for low latency operation
> through the Qjackctl gui front-end. I then start GUI apps that use Jack
> (for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer
> xruns of varying durations during the app load process and afterwards.

More data I forgot to include:
Jack is running with SCHED_FIFO priority. For achieving that I run a
custom kernel (currently based on Arjan's 1.391) with preempt enabled
and the realcap kernel module (by Jack O'Quin) added. I also run an up
to date version of ALSA with full debugging enabled so that I can get
kernel stack traces when xruns occur. 

-- Fernando





From fedora at andrewfarris.com  Fri May 28 01:13:35 2004
From: fedora at andrewfarris.com (Andrew Farris)
Date: Thu, 27 May 2004 18:13:35 -0700
Subject: OT: Livna.org rsync access down?
In-Reply-To: <40B63EF0.9050809@olin.edu>
References: <40B63EF0.9050809@olin.edu>
Message-ID: <1085706815.10052.1.camel@CirithUngol>

On Thu, 2004-05-27 at 15:18 -0400, Aaron Bennett wrote:

> I haven't been able to rsync from rpm.livna.org for a few weeks.  At 
> http://liva.org is a message saying their system is down.  Has anyone 
> else found this?  Anyone have an rsync-able livna.org mirror? 

rpm.livna.org contact is through bugzilla, they have a General component
for things to do with the website, etc.
http://bugzilla.livna.org/show_bug.cgi?id=134

Apparently rsync is down and they are aware of it (I've never rsync'd
the repo myself).

-- 
Andrew Farris, CPE senior (California Polytechnic State University, SLO)
fedora at andrewfarris.com :: lordmorgul on irc.freenode.net




From arjanv at redhat.com  Fri May 28 05:58:43 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Fri, 28 May 2004 07:58:43 +0200
Subject: fc2, xorg, 2.6.x, scheduling latency peaks
In-Reply-To: <1085704767.3992.357.camel@cmn37.stanford.edu>
References: <1085703938.3993.334.camel@cmn37.stanford.edu>
	<1085704767.3992.357.camel@cmn37.stanford.edu>
Message-ID: <1085723922.2782.8.camel@laptop.fenrus.com>

On Fri, 2004-05-28 at 02:39, Fernando Pablo Lopez-Lezcano wrote:
> On Thu, 2004-05-27 at 17:25, Fernando Pablo Lopez-Lezcano wrote:
> > Hi all. I'm trying to track the cause of high scheduling latency peaks
> > in FC2 that make the system unusable for low latency audio work. 
> > 
> > Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon
> > video chipset. How I test: I run the Jack (Jack Audio Connection Kit)
> > sound server with 2 or 3 128 frame buffers for low latency operation
> > through the Qjackctl gui front-end. I then start GUI apps that use Jack
> > (for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer
> > xruns of varying durations during the app load process and afterwards.
> 
> More data I forgot to include:
> Jack is running with SCHED_FIFO priority. For achieving that I run a
> custom kernel (currently based on Arjan's 1.391) with preempt enabled
> and the realcap kernel module (by Jack O'Quin) added.

can you disable preempt? That should improve latencies....
-------------- 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/20040528/57f84a2d/attachment.sig>

From arnaud.abelard at sciences.univ-nantes.fr  Fri May 28 07:49:53 2004
From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard)
Date: Fri, 28 May 2004 09:49:53 +0200
Subject: OT: Livna.org rsync access down?
In-Reply-To: <1085706815.10052.1.camel@CirithUngol>
References: <40B63EF0.9050809@olin.edu> <1085706815.10052.1.camel@CirithUngol>
Message-ID: <40B6EF21.8040208@sciences.univ-nantes.fr>


rpm.livna.org main server located in Paris had a hardware failure a few weeks 
ago. It's not running anymore. rpm.livna.org is now pointing to an american 
mirror that doesn't allow rsync mirroring anymore.

Anvil is expecting a new server to be delivered very soon (it was actually 
expected 2 weeks ago). Once the new server is installed the rsync access will 
be re-opened.

Arnaud

Andrew Farris wrote:
> On Thu, 2004-05-27 at 15:18 -0400, Aaron Bennett wrote:
> 
> 
>>I haven't been able to rsync from rpm.livna.org for a few weeks.  At 
>>http://liva.org is a message saying their system is down.  Has anyone 
>>else found this?  Anyone have an rsync-able livna.org mirror? 
> 
> 
> rpm.livna.org contact is through bugzilla, they have a General component
> for things to do with the website, etc.
> http://bugzilla.livna.org/show_bug.cgi?id=134
> 
> Apparently rsync is down and they are aware of it (I've never rsync'd
> the repo myself).
> 

-- 
Arnaud Ab?lard
Administrateur r?seaux et syst?mes
Irin / Facult? des Sciences
Universit? de Nantes




From pmatilai at welho.com  Fri May 28 10:09:13 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Fri, 28 May 2004 13:09:13 +0300 (EEST)
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
Message-ID: <Pine.LNX.4.58.0405281304300.10094@chip.laiskiainen.org>

On Wed, 26 May 2004, Nicolas Mailhot wrote:
> Le mar, 25/05/2004 ?? 16:57 -0400, Matthew Miller a ??crit :
> 
> > But that's not my suggestion. I think Group has become too ugly to be
> > properly saved. Applications like synaptic should instead use the comps file
> > groups for organizational purposes. 
> 
> Comps is totally unsuitable since it limits you to whatever packages
> where known to the distribution at the time of its release. (ie bye bye
> third-party packages).

Seconded, I seriously hate the idea of *having* to edit some xml file just 
to place a random rpm into some category. 

> 
> Like for spec file i18n we need a solution that permits standalone
> self-contained packages. Anything else will sort-of work with RedHat and
> be rejected by anyone else.
> 
> Now if you want mon opinion on rpm organisation, a mix of a Keywords
> in-spec field (Matches: java, games, x11) and external group
> declarations (external group descriptors, including user-provided group
> overlays and perhaps grouping policy files) is the way to go. Really
> this is much the same problem as menu building for example.

Sounds a whole lot like debtags to me :) Check out
http://deb-usability.alioth.debian.org/debtags/ (I'm not familiar with how 
it's actually implemented in Debian but that's pretty much irrelevant) 
And yes I would like to have such a system in rpm as well.

	- Panu -




From Nicolas.Mailhot at laPoste.net  Fri May 28 10:48:10 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Fri, 28 May 2004 12:48:10 +0200
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <Pine.LNX.4.58.0405281304300.10094@chip.laiskiainen.org>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
	<Pine.LNX.4.58.0405281304300.10094@chip.laiskiainen.org>
Message-ID: <1085741290.11290.3.camel@m64.net81-64-154.noos.fr>

Le ven, 28/05/2004 ? 13:09 +0300, Panu Matilainen a ?crit :
> On Wed, 26 May 2004, Nicolas Mailhot wrote:

> > Now if you want mon opinion on rpm organisation, a mix of a Keywords
> > in-spec field (Matches: java, games, x11) and external group
> > declarations (external group descriptors, including user-provided group
> > overlays and perhaps grouping policy files) is the way to go. Really
> > this is much the same problem as menu building for example.
> 
> Sounds a whole lot like debtags to me :) Check out
> http://deb-usability.alioth.debian.org/debtags/ (I'm not familiar with how 
> it's actually implemented in Debian but that's pretty much irrelevant) 
> And yes I would like to have such a system in rpm as well.

Why am I not surprised;) ?
The different packaging groups like to think they are totaly original
and separate, but really there is not so many workable solutions at a
point of time given the state of the art.

Another reason why patenting software is a really bad idea.

Regards,

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

From skvidal at phy.duke.edu  Fri May 28 12:23:07 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 28 May 2004 08:23:07 -0400
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <Pine.LNX.4.58.0405281304300.10094@chip.laiskiainen.org>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
	<Pine.LNX.4.58.0405281304300.10094@chip.laiskiainen.org>
Message-ID: <1085746987.29946.6.camel@binkley>

> > 
> > Comps is totally unsuitable since it limits you to whatever packages
> > where known to the distribution at the time of its release. (ie bye bye
> > third-party packages).
> 
> Seconded, I seriously hate the idea of *having* to edit some xml file just 
> to place a random rpm into some category. 

but you'd rather edit a spec file and rebuild an rpm to do it?

-sv





From Nicolas.Mailhot at laPoste.net  Fri May 28 13:11:04 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Fri, 28 May 2004 15:11:04 +0200
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085746987.29946.6.camel@binkley>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
	<Pine.LNX.4.58.0405281304300.10094@chip.laiskiainen.org>
	<1085746987.29946.6.camel@binkley>
Message-ID: <1085749864.11914.31.camel@m64.net81-64-154.noos.fr>

Le ven, 28/05/2004 ? 08:23 -0400, seth vidal a ?crit :
> > > 
> > > Comps is totally unsuitable since it limits you to whatever packages
> > > where known to the distribution at the time of its release. (ie bye bye
> > > third-party packages).
> > 
> > Seconded, I seriously hate the idea of *having* to edit some xml file just 
> > to place a random rpm into some category. 
> 
> but you'd rather edit a spec file and rebuild an rpm to do it?

Yes.

It's no different than rebuilding to change the license tag for example.
Why so much hate for grouping metadata ? specs are full of tags that
require rebuilding to be changed, and no one is even suggesting to strip
them (at least I would hope so)

I understand the convenience argument from people that have direct admin
access to big package repositories. But if we'd were to take a real poll
there are a lot more package maintainers than repository maintainers,
and I doubt all the packager lowlife (as opposed to the happy few that
move in the rarefied ethereal mists of big repo maintership) would
surrender they ability to freely categorise the packages they choose to
publish.

Unless you advocate a 1-1 mapping between package maintainers and
repository owners, which would be a tad rich coming on a list like
fedora-devel that has still to make its peace with the all the other big
third-party rpm repositories.

Let's be honest, centralizing grouping in a few xml files plays the game
of the core distributions and bigest repositories. The previous post
that actually proposed to dump all packages not installed through
yum/apt in lala-lala land had the merit of being clear and coherent with
Fedora.us past disregard of other packaging efforts.

BTW I could probably play this game via the admin accesses I have at
jpackage. But even in the context of a single reposiry like jpackage is,
this proposal fails to impress me. Not every project is as thoroughly
centralised as Fedora.us - I'd hate to have a grouping file to update
each time I submit a new package to the repository. (and I'm not even
talking about nosrc.rpm management that is still not really covered by
comps.xml)

Regards,

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

From buildsys at redhat.com  Fri May 28 13:11:29 2004
From: buildsys at redhat.com (Build System)
Date: Fri, 28 May 2004 09:11:29 -0400
Subject: rawhide report: 20040528 changes
Message-ID: <200405281311.i4SDBTZ23393@porkchop.devel.redhat.com>

New package selinux-policy-strict
	SELinux strict policy configuration

New package selinux-policy-targeted
	SELinux targeted policy configuration


 
Updated Packages:

PyQt-3.12-1
-----------
* Thu May 27 2004 Than Ngo <than at redhat.com> 3.12-1

- update to 3.12
- add BuildRequires on python-devel sip-devel , bug #124417

cups-1.1.20-12
--------------
* Thu May 27 2004 Tim Waugh <twaugh at redhat.com> 1:1.1.20-12

- D-BUS changes.

* Wed May 26 2004 Tim Waugh <twaugh at redhat.com> 1:1.1.20-11

- Build requires make >= 3.80 (bug #124472).

dovecot-0.99.10.5-1
-------------------
* Thu May 27 2004 David Woodhouse <dwmw2 at redhat.com> 0.99.10.5-1

- Update to 0.99.10.5 to fix maildir segfaults (#123022)

elinks-0.9.1-2
--------------
* Fri May 28 2004 Tim Waugh <twaugh at redhat.com> 0.9.1-2

- Use UTF-8 by default (bug #76445).

exim-4.34-1
-----------
* Wed May 12 2004 David Woodhouse <dwmw2 at redhat.com> 4.34-1

- Update to Exim 4.34, exiscan-acl 4.34-21

glibc-2.3.3-31
--------------
* Fri May 28 2004 Jakub Jelinek <jakub at redhat.com> 2.3.3-31

- update from CVS
- <bits/string2.h> and <bits/mathinline.h> changes for GCC 3.{2,4,5}+
- make c_stubs buildable even with GCC 3.2.x (#123042)

joe-3.0-2.3
-----------
* Thu May 27 2004 Lon Hohberger <lhh at redhat.com> 3.0-2.3

- Include HINTS NEWS LIST in %doc line (#124464)

* Mon May 03 2004 Lon Hohberger <lhh at redhat.com> 3.0-2.1

- Fix /etc/joe/joe/* sysconf dirs; the new Makefile.am handles this for us.
- Ensure we reference correct directories in manpages and joe-configs.

* Wed Apr 28 2004 Lon Hohberger <lhh at redhat.com> 3.0-2

- Rebuild.


kernel-2.6.6-1.394
------------------
* Thu May 27 2004 Dave Jones <davej at redhat.com>

- Fix the crashes on boot on Asus P4P800 boards. (#121819)

* Wed May 26 2004 Dave Jones <davej at redhat.com>

- Lots more updates to the SCSI whitelist for various
  USB card readers. (#112778, among others..)

libselinux-1.13.1-1
-------------------
* Thu May 27 2004 Dan Walsh <dwalsh at redhat.com> 1.13.1-1

- Change to use new policy mechanism

* Mon May 17 2004 Dan Walsh <dwalsh at redhat.com> 1.12-2

- add man patch

* Fri May 14 2004 Dan Walsh <dwalsh at redhat.com> 1.12-1

- Update with latest from NSA


openssl-0.9.7a-36
-----------------
* Tue May 25 2004 Nalin Dahyabhai <nalin at redhat.com> 0.9.7a-36

- handle %{_arch}=i486/i586/i686/athlon cases in the intermediate
  header (#124303)

php-4.3.6-5
-----------
* Wed May 19 2004 Joe Orton <jorton at redhat.com> 4.3.6-5

- don't obsolete php-imap (#123580)
- unconditionally build -imap subpackage

* Thu May 13 2004 Joe Orton <jorton at redhat.com> 4.3.6-4

- remove trigger

* Thu Apr 22 2004 Joe Orton <jorton at redhat.com> 4.3.6-3

- fix umask reset "feature" (#121454)
- don't use DL_GLOBAL when dlopen'ing extension modules


policycoreutils-1.13-3
----------------------
* Tue May 25 2004 Dan Walsh <dwalsh at redhat.com> 1.13-3

- Change location of file_context file

* Tue May 25 2004 Dan Walsh <dwalsh at redhat.com> 1.13-2

- Change to use /etc/sysconfig/selinux to determine location of policy files

rpmdb-fedora-2-0.20040528
-------------------------

sip-3.10.2-1
------------
* Thu May 27 2004 Than Ngo <than at redhat.com> 3.10.2-1

- update to 3.10.2

stunnel-4.05-2
--------------
* Thu May 27 2004 Nalin Dahyabhai <nalin at redhat.com> 4.05-2

- move the sample configuration to %doc, it shouldn't be used as-is (#124373)

subversion-1.0.4-1
------------------
* Sat May 22 2004 Joe Orton <jorton at redhat.com> 1.0.4-1

- update to 1.0.4

* Fri May 21 2004 Joe Orton <jorton at redhat.com> 1.0.3-2

- build /usr/bin/* as PIEs
- add fix for libsvn_client symbol namespace violation (r9608)

* Wed May 19 2004 Joe Orton <jorton at redhat.com> 1.0.3-1

- update to 1.0.3


switchdesk-4.0.4-1
------------------
* Wed May 26 2004 Than Ngo <than at redhat.com> 4.0.4-1

- fix wrong RB id of enlightenment which causes switchdesk crashed #124408
- fix bug in setting default wm, bug #124292, #122260
- fix bug in creating .Xclients, bug #123545
- add selection button for System Default #110312

system-config-securitylevel-1.3.13-2
------------------------------------
* Thu May 27 2004 Dan Walsh <dwalsh at redhat.com> 1.3.13-2

- Change lokkit to support new SELinux mode

usermode-1.70-4
---------------
* Tue May 25 2004 Dan Walsh <dwalsh at redhat.com> 1.70-4

- Support new policy files

* Thu May 20 2004 Dan Walsh <dwalsh at redhat.com> 1.70-3

- Change user context to default name if username context not in passwd file

vnc-4.0-1.beta5.3
-----------------
* Thu May 27 2004 Tim Waugh <twaugh at redhat.com> 4.0-1.beta5.3

- Fix ppc64 build.
- Fix debuginfo package.
- Another fix for REGION_INIT usage.




From pmatilai at welho.com  Fri May 28 14:25:42 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Fri, 28 May 2004 17:25:42 +0300 (EEST)
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <1085746987.29946.6.camel@binkley>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
	<Pine.LNX.4.58.0405281304300.10094@chip.laiskiainen.org>
	<1085746987.29946.6.camel@binkley>
Message-ID: <Pine.LNX.4.58.0405281715100.10386@chip.laiskiainen.org>

On Fri, 28 May 2004, seth vidal wrote:

> > > 
> > > Comps is totally unsuitable since it limits you to whatever packages
> > > where known to the distribution at the time of its release. (ie bye bye
> > > third-party packages).
> > 
> > Seconded, I seriously hate the idea of *having* to edit some xml file just 
> > to place a random rpm into some category. 
> 
> but you'd rather edit a spec file and rebuild an rpm to do it?

Yes. How often does a package change it's fundamental functionalities so 
that the grouping would need to be changed? The only times I've had to 
change the group are
a) fixing typos 
b) originally incorrect (non-standard or otherwise silly) entries

Since the rpm contains the information it's set *once*, if it's buried
into some group.xml each repository needs to do the same work again and
again. I've absolutely nothing against having yumgroups.xml or similar as
an extra layer above the information in the package itself to provide a
"friendlier" grouping of things but the package should carry the
information with it. Hmm.. if it had tags (well, keywords) in rpm you 
could even automate the groups.xml generation by just querying the 
packages and sorting them to groups as you please based on the keywords 
they "provide"

	- Panu -




From heinlein at madboa.com  Fri May 28 15:01:21 2004
From: heinlein at madboa.com (Paul Heinlein)
Date: Fri, 28 May 2004 08:01:21 -0700 (PDT)
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <Pine.LNX.4.58.0405281715100.10386@chip.laiskiainen.org>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
	<Pine.LNX.4.58.0405281304300.10094@chip.laiskiainen.org>
	<1085746987.29946.6.camel@binkley>
	<Pine.LNX.4.58.0405281715100.10386@chip.laiskiainen.org>
Message-ID: <Pine.LNX.4.60.0405280736060.1444@pecos.madboa.com>

On Fri, 28 May 2004, Panu Matilainen wrote:

>> but you'd rather edit a spec file and rebuild an rpm to do it?
>
> Yes.

It seems to me that the hardwiring solution will lead either to more 
bickering among distros or more complexity for upstream developers:

a) If groups change between distro revs, the package's .spec doesn't
    have to maintain a silly set of %if statements to set the correct
    group for each distribution release.

b) The maintainer of the .spec -- who, in an ideal world, is the
    upstream developer -- needn't worry about inter-distribution
    politics (or take sides) when setting the group header.

Plus, a separate resource like comps.xml makes it reasonably easy for 
a package to maintain multiple group memberships.

That's not to say that comps.xml is a wonderful solution -- but at 
least it allows each distro/rev some independence.

-- Paul Heinlein <heinlein at madboa.com>




From twoerner at redhat.com  Fri May 28 16:05:13 2004
From: twoerner at redhat.com (Thomas Woerner)
Date: Fri, 28 May 2004 18:05:13 +0200
Subject: udev in initrd
Message-ID: <40B76339.2080304@redhat.com>


There are test packages in http://people.redhat.com/twoerner/UDEV/ for using 
udev in initrd with persistent devices.

Usage
-----

- If you want to enable udev in initrd, then install the test packages and
   create an initrd with mkinitrd.
- If you want to turn off udev, set USE_UDEV="no" in /etc/sysconfig/udev.
- For another udev root directory (not /dev) set udev_root="/some dir/" in
   /etc/udev/udev.conf - This will not disable udev in initrd. The result is an
   unusable initrd
- For disabling persistent /dev filesystem set UDEV_KEEP_DEV="no" in
   /etc/sysconfig/udev. Your /dev filesystem will not be the same in inird and
   the running system.
- You have to recreate the initrd after changing any of these options.


Warnings
--------

- The new mkinitrd is not tested heavily (especially lvm support).
- It will not work with devfs.
- Make a backup copy of the original initrd (best is to make an additional
   boot entry in grub with the new initrd)


Information about udev and the new mkinitrd
-------------------------------------------

The benefit of udev is that there are only those device nodes which are bound 
to devices in your computer and that you can have additional device naming 
schemes like 'by label' or 'by id'.
However there is a small problem with dynamic device nodes: For all devices, 
which are not recognized before a specific module is loaded, there will be no 
device node until the driver is loaded either by hand of by a program. kudzu 
would be a good candidate for this, but it has to be started earlier, then.

udev is using helpers for additional device naming schemes, which are c 
programs or shell scripts. Therefore it is necessary to put tools like sed, 
awk, grep and so on in the initrd. These programs are not small and the initrd 
would be very big. The solution for this is to use a static compiled busybox, 
which combines tiny versions of many utilities into a single executable.

Thus the new mkinitrd is using busybox for the initrd with udev support. 
Disabling udev results in a normal initrd with nash. It is easy to modify 
mkinitrd to build the normal initrd with busybox.


Here are the flowcharts for the standard initrd of fc2 (without lvm support) 
and the udev version:

Standard initrd - using nash
----------------------------
1) mount /proc and /sys in initrd
2) load modules (eg: controller, filesystem)
3) umount /sys
4) locate root device
5) create block devices
6) mount system root on /sysroot
7) change root to /sysroot and initrd to /sysroot/initrd
8) umount /initrd/proc


udev initrd - using busybox and ramfs
-------------------------------------
1) mount /proc and /sys
2) mount /dev as ramfs
3) create initial devices (eg: console, null, zero, loopX) and links for std
    files
4) start udev, use udevsend as hotplug
5) load modules (eg. controller, filesystem)
6) umount /sys
7) locate root device
8) mount system root on /sysroot
9) bind /dev to /sysroot [UDEV_KEEP_DEV="yes"]
10) change root to /sysroot and initrd to /sysroot/initrd
11) umount /initrd/proc
12) umount /initrd/dev [UDEV_KEEP_DEV="yes"]



Have fun,
Thomas

-- 
Thomas Woerner, Software Developer     Phone: +49-711-96437-0
Red Hat GmbH                           Fax  : +49-711-96437-111
Hauptstaetterstr. 58                   Email: twoerner at redhat.com
D-70178 Stuttgart                      Web  : http://www.redhat.de/




From notting at redhat.com  Fri May 28 16:42:54 2004
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 28 May 2004 12:42:54 -0400
Subject: small improvements for fedora 3: sound mixing
In-Reply-To: <1085657429.28535.9.camel@localhost.localdomain>
References: <1085657429.28535.9.camel@localhost.localdomain>
Message-ID: <20040528164254.GA12755@nostromo.devel.redhat.com>

Christian Paratschek (christian.paratschek at reflex.at) said: 
> hi people on this list, i am a new member!
> 
> first of all: fedora core 2 is a very fine system. i have been an avid
> user of red hat 7.3, 8.0,9 and fc1 and i am quite a loyal user...
> 
> i have some small gripes with fc2 and i wanna tell you, so that fc3 is
> an even better product:

The problem is that dmix doesn't work for all apps.

http://article.gmane.org/gmane.comp.video.xine.devel/7058/

is an article of one complaint, for example.

Bill




From Nicolas.Mailhot at laPoste.net  Fri May 28 17:47:18 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Fri, 28 May 2004 19:47:18 +0200
Subject: rpm groups and fedora: a modest proposal
In-Reply-To: <Pine.LNX.4.60.0405280736060.1444@pecos.madboa.com>
References: <20040525205723.GA25684@jadzia.bu.edu>
	<1085552240.10293.50.camel@m64.net81-64-154.noos.fr>
	<Pine.LNX.4.58.0405281304300.10094@chip.laiskiainen.org>
	<1085746987.29946.6.camel@binkley>
	<Pine.LNX.4.58.0405281715100.10386@chip.laiskiainen.org>
	<Pine.LNX.4.60.0405280736060.1444@pecos.madboa.com>
Message-ID: <1085766438.13129.31.camel@m64.net81-64-154.noos.fr>

Le ven, 28/05/2004 ? 08:01 -0700, Paul Heinlein a ?crit :
> On Fri, 28 May 2004, Panu Matilainen wrote:
> 
> >> but you'd rather edit a spec file and rebuild an rpm to do it?
> >
> > Yes.
> 
> It seems to me that the hardwiring solution will lead either to more 
> bickering among distros or more complexity for upstream developers:
> 
> a) If groups change between distro revs, the package's .spec doesn't
>     have to maintain a silly set of %if statements to set the correct
>     group for each distribution release.
> 
> b) The maintainer of the .spec -- who, in an ideal world, is the
>     upstream developer -- needn't worry about inter-distribution
>     politics (or take sides) when setting the group header.
> 
> Plus, a separate resource like comps.xml makes it reasonably easy for 
> a package to maintain multiple group memberships.
> 
> That's not to say that comps.xml is a wonderful solution -- but at 
> least it allows each distro/rev some independence.

Since I do contribute to a repository that targets multiple
distributions let me say we *never* had to use any %if tweaks in any of
our specs for Groups (and this even with the current sorry state of the
Group tag). So this is an absolute non-problem. The problem is :
- Group is mono-valuated
- there is no smart or even dead-stupid processing of its values - when
they are used they are used as-is

With multi-values you can have packages belonging to many groups if you
want to (or in different groups depending on the focus of the
distribution)

With even a little processing you can cover distro differences (ie
games=amusement=time-wasters), define organisational policies, etc.

This is what the freedesktop menu does every day in real-time even. This
is what any given mp3/ogg jukebox does with id3 tags. This is software
101.

Now one can argue package organization does not deserve the time one
might spent fixing the Group mess. But surely if it does it should be
fixed properly, not with the hack comps is.

As far as I'm concerned a repository is nothing more than a glorified
ftp area. It indexes packages for performance reasons - and even then
all the index info is pulled from the packages themselves. It's a
convenience. A useful one, granted but tools like autorpm were able to
work on rawhide even long before apt was ported to rpm. And it is
*optional*. The system behaves the same if the rpm was taken from a
repository, a CD/DVD, hacked localy in half an hour or delivered via
tcp-over-messenger-birds protocols. 

Policy does not belong at the repository level. Policy is included in
the rpm themselves and that's how things should stay. All this
incestious mingling of two separate layers for convenience reasons
screams future problems to me. It's always much easier to break barriers
than untangle the resulting mess.

Regards,

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

From nando at ccrma.Stanford.EDU  Fri May 28 18:01:31 2004
From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano)
Date: 28 May 2004 11:01:31 -0700
Subject: fc2, xorg, 2.6.x, scheduling latency peaks
In-Reply-To: <1085723922.2782.8.camel@laptop.fenrus.com>
References: <1085703938.3993.334.camel@cmn37.stanford.edu>
	<1085704767.3992.357.camel@cmn37.stanford.edu>
	<1085723922.2782.8.camel@laptop.fenrus.com>
Message-ID: <1085767291.6347.23.camel@cmn37.stanford.edu>

On Thu, 2004-05-27 at 22:58, Arjan van de Ven wrote:
> On Fri, 2004-05-28 at 02:39, Fernando Pablo Lopez-Lezcano wrote:
> > On Thu, 2004-05-27 at 17:25, Fernando Pablo Lopez-Lezcano wrote:
> > > Hi all. I'm trying to track the cause of high scheduling latency peaks
> > > in FC2 that make the system unusable for low latency audio work. 
> > > 
> > > Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon
> > > video chipset. How I test: I run the Jack (Jack Audio Connection Kit)
> > > sound server with 2 or 3 128 frame buffers for low latency operation
> > > through the Qjackctl gui front-end. I then start GUI apps that use Jack
> > > (for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer
> > > xruns of varying durations during the app load process and afterwards.
> > 
> > More data I forgot to include:
> > Jack is running with SCHED_FIFO priority. For achieving that I run a
> > custom kernel (currently based on Arjan's 1.391) with preempt enabled
> > and the realcap kernel module (by Jack O'Quin) added.
> 
> can you disable preempt? That should improve latencies....

I'll try that and report back. A while back - probably 2.6.4-1.279 or
whereabouts - I did a comparison (because of reports that it should be
better that preempt be off) and latencytest reported better latencies
with preempt on. Maybe something has changed since then (or I made some
silly mistake). 

-- Fernando





From cmadams at hiwaay.net  Fri May 28 18:43:37 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 28 May 2004 13:43:37 -0500
Subject: kernel-smp missing in updates/testing?
Message-ID: <20040528184337.GB1205270@hiwaay.net>

There is a kernel update in updates/testing/2/i386, but there is no
corresponding kernel-smp.  Is this intentional, a mistake in the newer
build process for the kernel packaging, or something 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 notting at redhat.com  Fri May 28 18:52:49 2004
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 28 May 2004 14:52:49 -0400
Subject: kernel-smp missing in updates/testing?
In-Reply-To: <20040528184337.GB1205270@hiwaay.net>
References: <20040528184337.GB1205270@hiwaay.net>
Message-ID: <20040528185248.GB14083@nostromo.devel.redhat.com>

Chris Adams (cmadams at hiwaay.net) said: 
> There is a kernel update in updates/testing/2/i386, but there is no
> corresponding kernel-smp.  Is this intentional, a mistake in the newer
> build process for the kernel packaging, or something else?

Looks like a build bug.

Bill




From cmadams at hiwaay.net  Fri May 28 18:56:53 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 28 May 2004 13:56:53 -0500
Subject: kernel-smp missing in updates/testing?
In-Reply-To: <20040528185248.GB14083@nostromo.devel.redhat.com>
References: <20040528184337.GB1205270@hiwaay.net>
	<20040528185248.GB14083@nostromo.devel.redhat.com>
Message-ID: <20040528185653.GC1205270@hiwaay.net>

Once upon a time, Bill Nottingham <notting at redhat.com> said:
> Chris Adams (cmadams at hiwaay.net) said: 
> > There is a kernel update in updates/testing/2/i386, but there is no
> > corresponding kernel-smp.  Is this intentional, a mistake in the newer
> > build process for the kernel packaging, or something else?
> 
> Looks like a build bug.

Okay, bugzillaed as #124715.
-- 
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 gbpeck at sbcglobal.net  Fri May 28 19:43:22 2004
From: gbpeck at sbcglobal.net (Gary Peck)
Date: Fri, 28 May 2004 12:43:22 -0700
Subject: selinux disabled in new kernel
Message-ID: <20040528194322.GA25483@realify.com>

i just upgraded to the latest rawhide, including kernel-2.6.6-1.394 and
selinux-policy-*-1.13.1-1 among others, and when i reboot selinux is no
longer enabled.

dmesg shows the following lines:
    ...
    Calibrating delay loop... 1708.03 BogoMIPS
    Security Scaffold v1.0.0 initialized
*** SELinux:  Disabled at boot.
    Capability LSM initialized
    Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
    ...
however, my boot line was:
    kernel /vmlinuz-2.6.6-1.394 ro root=/dev/mapper/Volume00-Fedora
and /etc/sysconfig/selinux and /etc/selinux/config both contain:
    SELINUX=permissive

if i boot back into kernel-2.6.6-1.381, then selinux seems to get
initialized correctly.

gary




From fedora at rooker.dyndns.org  Fri May 28 20:22:16 2004
From: fedora at rooker.dyndns.org (Peter Maas)
Date: Fri, 28 May 2004 15:22:16 -0500
Subject: 3ware 9500
Message-ID: <005001c444f1$7b519dd0$3205a8c0@pixl>

Dear Sirs:

3ware had released new drivers for there 9500S series ide raid cards under
the GNU GPL, the current kernel drivers support up to the 8500 Series. What
is necessary to have to have these drivers added to the redhat
kernel(hopefully linus's kernel also)? I have the source that is shipped
with the card if needed.

Thank You
Peter Maas
fedora at rooker.dyndns.org




From rdieter at math.unl.edu  Fri May 28 20:26:08 2004
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 28 May 2004 15:26:08 -0500 (CDT)
Subject: 3ware 9500
In-Reply-To: <005001c444f1$7b519dd0$3205a8c0@pixl>
References: <005001c444f1$7b519dd0$3205a8c0@pixl>
Message-ID: <Pine.LNX.4.58.0405281525490.10501@sting.unl.edu>

On Fri, 28 May 2004, Peter Maas wrote:

> 3ware had released new drivers for there 9500S series ide raid cards under
> the GNU GPL, the current kernel drivers support up to the 8500 Series. What
> is necessary to have to have these drivers added to the redhat
> kernel(hopefully linus's kernel also)? I have the source that is shipped
> with the card if needed.

http://bugzilla.redhat.com/

-- Rex




From tibbs at math.uh.edu  Fri May 28 20:59:02 2004
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 28 May 2004 15:59:02 -0500
Subject: 3ware 9500
In-Reply-To: <005001c444f1$7b519dd0$3205a8c0@pixl>
References: <005001c444f1$7b519dd0$3205a8c0@pixl>
Message-ID: <ufau0y0w9nt.fsf@epithumia.math.uh.edu>

>>>>> "PM" == Peter Maas <fedora at rooker.dyndns.org> writes:

PM> What is necessary to have to have these drivers added to the
PM> redhat kernel(hopefully linus's kernel also)?

They were accepted into the official kernel as of 2.6.7-rc1, so they
will automatically make it into later Red Hat-built kernels.

 - J<




From fedora at rooker.dyndns.org  Fri May 28 21:21:04 2004
From: fedora at rooker.dyndns.org (Peter Maas)
Date: Fri, 28 May 2004 16:21:04 -0500
Subject: 3ware 9500
References: <005001c444f1$7b519dd0$3205a8c0@pixl>
	<ufau0y0w9nt.fsf@epithumia.math.uh.edu>
Message-ID: <006401c444f9$af1ac850$3205a8c0@pixl>

I have just looked at the kernel patched to 2.6.7-rc1-bk5 and it does not
appear that is the case, though I have not compiled and tested to be
absolutely sure, the device ids for the 9500's.

(#define TW_DEVICE_ID_9000 (0x1002) /* 9000 series controller */)

have not been added to 3w-xxxx header files in the main-line kernel.

Peter

----- Original Message ----- 
From: "Jason L Tibbitts III" <tibbs at math.uh.edu>
To: "Development discussions related to Fedora Core"
<fedora-devel-list at redhat.com>
Sent: Friday, May 28, 2004 3:59 PM
Subject: Re: 3ware 9500


> >>>>> "PM" == Peter Maas <fedora at rooker.dyndns.org> writes:
>
> PM> What is necessary to have to have these drivers added to the
> PM> redhat kernel(hopefully linus's kernel also)?
>
> They were accepted into the official kernel as of 2.6.7-rc1, so they
> will automatically make it into later Red Hat-built kernels.
>
>  - J<
>
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>




From alan at redhat.com  Fri May 28 22:26:31 2004
From: alan at redhat.com (Alan Cox)
Date: Fri, 28 May 2004 18:26:31 -0400
Subject: 3ware 9500
In-Reply-To: <005001c444f1$7b519dd0$3205a8c0@pixl>
References: <005001c444f1$7b519dd0$3205a8c0@pixl>
Message-ID: <20040528222631.GC20077@devserv.devel.redhat.com>

On Fri, May 28, 2004 at 03:22:16PM -0500, Peter Maas wrote:
> 3ware had released new drivers for there 9500S series ide raid cards under
> the GNU GPL, the current kernel drivers support up to the 8500 Series. What
> is necessary to have to have these drivers added to the redhat
> kernel(hopefully linus's kernel also)? I have the source that is shipped
> with the card if needed.

3ware should be submitting them to Andrew Morton and/or linux-scsi list. I'm
suprised they haven't already if they are ready for them to be merged as they
are normally pretty on the ball.

You might want to ask them and Andrew what the status is <akpm at osdl.org>




From sflory at rackable.com  Fri May 28 22:36:32 2004
From: sflory at rackable.com (Samuel Flory)
Date: Fri, 28 May 2004 15:36:32 -0700
Subject: 3ware 9500
In-Reply-To: <006401c444f9$af1ac850$3205a8c0@pixl>
References: <005001c444f1$7b519dd0$3205a8c0@pixl>	<ufau0y0w9nt.fsf@epithumia.math.uh.edu>
	<006401c444f9$af1ac850$3205a8c0@pixl>
Message-ID: <40B7BEF0.3040403@rackable.com>

Peter Maas wrote:

>I have just looked at the kernel patched to 2.6.7-rc1-bk5 and it does not
>appear that is the case, though I have not compiled and tested to be
>absolutely sure, the device ids for the 9500's.
>
>(#define TW_DEVICE_ID_9000 (0x1002) /* 9000 series controller */)
>
>have not been added to 3w-xxxx header files in the main-line kernel.
>
>  
>
  It uses a new driver 3w-9xx.  Note I'm not sure if the driver is in 
2.6 yet.




From greg at kroah.com  Fri May 28 23:29:50 2004
From: greg at kroah.com (Greg KH)
Date: Fri, 28 May 2004 16:29:50 -0700
Subject: udev in initrd
In-Reply-To: <40B76339.2080304@redhat.com>
References: <40B76339.2080304@redhat.com>
Message-ID: <20040528232950.GA14432@kroah.com>

On Fri, May 28, 2004 at 06:05:13PM +0200, Thomas Woerner wrote:
> 
> There are test packages in http://people.redhat.com/twoerner/UDEV/ for 
> using udev in initrd with persistent devices.

Sweet, thanks for posting this, I really appreciate it.

One small question:

> udev initrd - using busybox and ramfs
> -------------------------------------
> 1) mount /proc and /sys
> 2) mount /dev as ramfs
> 3) create initial devices (eg: console, null, zero, loopX) and links for std
>    files
> 4) start udev, use udevsend as hotplug

What do you do to "start udev"?  Run udevstart?

> 5) load modules (eg. controller, filesystem)
> 6) umount /sys
> 7) locate root device
> 8) mount system root on /sysroot
> 9) bind /dev to /sysroot [UDEV_KEEP_DEV="yes"]
> 10) change root to /sysroot and initrd to /sysroot/initrd
> 11) umount /initrd/proc
> 12) umount /initrd/dev [UDEV_KEEP_DEV="yes"]

Are you looking into making a initramfs instead of a initrd for the next
FC3 release?

thanks,

greg k-h




From buildsys at redhat.com  Sat May 29 13:00:14 2004
From: buildsys at redhat.com (Build System)
Date: Sat, 29 May 2004 09:00:14 -0400
Subject: rawhide report: 20040529 changes
Message-ID: <200405291300.i4TD0Es20929@porkchop.devel.redhat.com>

 

 
Updated Packages:

SysVinit-2.85-27
----------------
* Thu May 27 2004 Dan Walsh <dwalsh at redhat.com> 2.85-26

- Use selinux_getenforcemode

* Tue May 25 2004 Dan Walsh <dwalsh at redhat.com> 2.85-25

- Change to use /etc/sysconfig/selinux to find policy file.

anaconda-10.0.1-0.20040528163734
--------------------------------
* Fri May 28 2004 Anaconda team <bugzilla at redhat.com>

- built new version from CVS

* Fri Apr 30 2004 Jeremy Katz <katzj at redhat.com>

- Update description, remove prereq on stuff that was only needed 
  for reconfig mode

* Tue Feb 24 2004 Jeremy Katz <katzj at redhat.com>

- buildrequire libselinux-devel


devlabel-0.48.01-3
------------------
* Fri May 28 2004 Bill Nottingham <notting at redhat.com> 0.48.01-3

- fix warnings (#124442, <harald at redhat.com>)

kernel-2.6.6-1.397
------------------
* Thu May 27 2004 Pete Zaitcev <zaitcev at redhat.com>

- Fix qeth and zfcp (s390 drivers): align qib by 256, embedded into qdio_irq.

libselinux-1.13.2-1
-------------------
* Fri May 28 2004 Dan Walsh <dwalsh at redhat.com> 1.13.2-1

-Update with latest from NSA

rpmdb-fedora-2-0.20040529
-------------------------

selinux-policy-strict-1.13.2-2
------------------------------
* Fri May 28 2004 Dan Walsh <dwalsh at redhat.com> 1.13.2-2

- Only update policy if this policy is running

* Fri May 28 2004 Dan Walsh <dwalsh at redhat.com> 1.13.2-1

- Update to match NSA

* Thu May 27 2004 Dan Walsh <dwalsh at redhat.com> 1.13.1-2

- Change location of file_contexts and add new security contexts


selinux-policy-targeted-1.13.2-2
--------------------------------
* Fri May 28 2004 Dan Walsh <dwalsh at redhat.com> 1.13.2-2

- Only update policy if this policy is running

* Fri May 28 2004 Dan Walsh <dwalsh at redhat.com> 1.13.2-1

- Update to match NSA

* Thu May 27 2004 Dan Walsh <dwalsh at redhat.com> 1.13.1-2

- Change location of file_contexts and add new security contexts


subversion-1.0.4-1.1
--------------------
* Fri May 28 2004 Joe Orton <jorton at redhat.com> 1.0.4-1.1

- rebuild for new swig

vnc-4.0-1.beta5.4
-----------------
* Fri May 28 2004 Tim Waugh <twaugh at redhat.com> 4.0-1.beta5.4

- Further vnc.def fix.
- Fix cursor handling for hotspots outside the bounding rectangle.




From christian.paratschek at reflex.at  Sat May 29 14:49:23 2004
From: christian.paratschek at reflex.at (Christian Paratschek)
Date: Sat, 29 May 2004 16:49:23 +0200
Subject: small improvements for fedora 3: sound mixing
In-Reply-To: <fc.3b9aca00f3fc6fd23b9aca009d663a79.3510a83@reflex.at>
References: <1085657429.28535.9.camel@localhost.localdomain>
	<fc.3b9aca00f3fc6fd23b9aca009d663a79.3510a83@reflex.at>
Message-ID: <1085842163.2542.5.camel@localhost.localdomain>


> The problem is that dmix doesn't work for all apps.
> 
> http://article.gmane.org/gmane.comp.video.xine.devel/7058/
> 
> is an article of one complaint, for example.
> 
> Bill
> 

hmmm... i wouldn't call that a problem. it only needs to work for the
apps that are included. who cares if xine works - it is not included in
fedora anyway.   

my point is: proper soundmixing should be a goal for fc3. i don't know
which ways there are to achieve this goal, if its dmix or anything else,
but it needs to be done (imho).

christian  




From tibbs at math.uh.edu  Sat May 29 15:01:51 2004
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 29 May 2004 10:01:51 -0500
Subject: 3ware 9500
In-Reply-To: <006401c444f9$af1ac850$3205a8c0@pixl>
References: <005001c444f1$7b519dd0$3205a8c0@pixl>
	<ufau0y0w9nt.fsf@epithumia.math.uh.edu>
	<006401c444f9$af1ac850$3205a8c0@pixl>
Message-ID: <ufazn7rwa3k.fsf@epithumia.math.uh.edu>

>>>>> "PM" == Peter Maas <fedora at rooker.dyndns.org> writes:

PM> I have just looked at the kernel patched to 2.6.7-rc1-bk5 and it
PM> does not appear that is the case, though I have not compiled and
PM> tested to be absolutely sure, the device ids for the 9500's.

Well, I recall that the new driver (3w-9xxx) made it into
2.6.6-mm(something) and then was listed in the 2.6.7-rc1-mm1 changelog
as being merged into mainline.  Currently rc1-mm1 has additional 3ware
patches in it:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7-rc1/2.6.7-rc1-mm1/broken-out/3ware-9000-sata-raid-1.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7-rc1/2.6.7-rc1-mm1/broken-out/3ware-9000-sata-raid-2.patch

I think these will percolate into the main tree with haste.  Note that
this is a new driver; you can't look in the old driver and find info
for these cards.

 - J<




From tony at tgds.net  Sat May 29 17:27:49 2004
From: tony at tgds.net (Tony Grant)
Date: Sat, 29 May 2004 19:27:49 +0200
Subject: small improvements for fedora 3: sound mixing
In-Reply-To: <1085842163.2542.5.camel@localhost.localdomain>
References: <1085657429.28535.9.camel@localhost.localdomain>
	<fc.3b9aca00f3fc6fd23b9aca009d663a79.3510a83@reflex.at>
	<1085842163.2542.5.camel@localhost.localdomain>
Message-ID: <1085851668.7642.199.camel@localhost.localdomain>

Le sam 29/05/2004 ? 16:49, Christian Paratschek a ?crit :

> who cares if xine works - it is not included in
> fedora anyway.   

All of us using it to watch and record TV with vdr and vdr-xine. All of
us using it to watch DVDs in our living room...

All two of us?

Tony

-- 
www.tgds.net Library management software toolkit





From mike at navi.cx  Sat May 29 19:37:38 2004
From: mike at navi.cx (Mike Hearn)
Date: Sat, 29 May 2004 20:37:38 +0100
Subject: small improvements for fedora 3: sound mixing
References: <1085657429.28535.9.camel@localhost.localdomain>
	<20040528164254.GA12755@nostromo.devel.redhat.com>
Message-ID: <pan.2004.05.29.19.37.38.349076@navi.cx>

On Fri, 28 May 2004 12:42:54 -0400, Bill Nottingham wrote:
> The problem is that dmix doesn't work for all apps.
> 
> http://article.gmane.org/gmane.comp.video.xine.devel/7058/
> 
> is an article of one complaint, for example.

This was fixed in ALSA 1.0.4 I think (or was it 1.0.3?). Anyway, Xine was
one of the last holdout apps that was stopping dmix working correctly in
all cases, and as that has now been nailed I agree that getting proper
ALSA asym/dmix/dsnoop functionality into FC3 should absolutely be a
priority.

The tips given in the fedoranews.org article can be improved upon.
Redefining the default device is the best way to do this, that way you
don't need to tweak every apps settings.

Basically the change just involves adjusting .asoundrc or /etc/alsa.conf.
If nothing else, please try it in the FC3 testing cycle and see if there
are any complaints.

thanks -mike




From zleite at mminternet.com  Sat May 29 21:47:55 2004
From: zleite at mminternet.com (Z)
Date: Sat, 29 May 2004 14:47:55 -0700
Subject: The return of the acute-cedilla problem
In-Reply-To: <oraczwilj6.fsf@free.redhat.lsd.ic.unicamp.br>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
	<20040524215310.GJ18881@rednote.net> <1085453830.4695.7.camel@z>
	<oraczwilj6.fsf@free.redhat.lsd.ic.unicamp.br>
Message-ID: <1085867275.15316.15.camel@z>

On Tue, 2004-05-25 at 08:17, Alexandre Oliva wrote:

> Well, ? surely exists in some languages, and you have to agree that it
> would be damn surprising if ? were to prefer ? over ?.  Why the heck
> is the acute accent *under* the letter, one would think...
> 
> If your locale is pt (or pt_BR?), gtk apps will map 'c to ?, but X
> will still compose 'c into ?.  That's bad, and inconsistent.  The
> solution (untested) is to create a file in
> /usr/lib/X11/locale/pt_BR.UTF-8/Compose, adapted from
> /usr/lib/X11/locale/en_US.UTF-8/Compose, in which the combinations of
> <dead_acute> and <c> or <C> are mapped to the ? and ? characters,
> instead of ? and ? as they are.  Then adjust compose.dir in the parent
> directory such that pt_BR.UTF-8 is mapped to this new Compose rules.

> 
> As far as I can tell you're mistaken.  From personal experience, FC1
> (and probably RHL9) worked just the same in this regard, at least as
> far as X11 is concerned.  I haven't checked for changes in gtk within
> pt_BR locales, though; this might have changed.  Maybe you had
> different i18n settings.  For example, switching from ISO-8859-1 to
> UTF-8, or from pt_BR to en_US would have changed the 'c compose rules
> on at least some applications.

Actually, you're right on all counts. I'm using en_US.UTF-8, but I write
a lot in portuguese (I'm brazilian too). I was using en_US before.
Now would you (or the list) happen to know why xorg does not follow the
usual usual us_intl composition rules? As it is now, gtk and, more
importantly, openoffice follow the old style. Is there a standard? Also,
how come the console won't show accented charachters on en_US.UTF-8?
In the meantime I'll probably patch en_US.UTF-8/Compose to be consistent
with gtk, so my users won't complain...




From csm at fx.ro  Sat May 29 22:01:55 2004
From: csm at fx.ro (Cosmin Hanulescu)
Date: Sun, 30 May 2004 01:01:55 +0300
Subject: =?iso-8859-1?q?Intel=AE_536ep_V=2E92_modem_=28PCI=29_chipset_dri?=
 =?iso-8859-1?q?ver_=26_2=2E6_kernel_under_FC2?=
Message-ID: <40B90853.2010104@fx.ro>

Has anyone been able to port the driver provided by Intel for the modem
chipset mentioned in the subject line to the 2.6 kernel?

Regards,






From arjanv at redhat.com  Sun May 30 08:12:20 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sun, 30 May 2004 10:12:20 +0200
Subject: =?iso-8859-1?q?Intel=AE?= 536ep V.92 modem (PCI) chipset
	driver & 2.6 kernel under FC2
In-Reply-To: <40B90853.2010104@fx.ro>
References: <40B90853.2010104@fx.ro>
Message-ID: <1085904739.2720.2.camel@laptop.fenrus.com>

On Sun, 2004-05-30 at 00:01, Cosmin Hanulescu wrote:
> Has anyone been able to port the driver provided by Intel for the modem
> chipset mentioned in the subject line to the 2.6 kernel?

since that is a binary only kernel module that will be really hard for
anyone except intel to do.

However you may be lucky if your modem is supported by the snd_intel8x0m
alsa driver, that exports your modem as sound device to userspace, and a
userspace app to "whistle" modem sounds into that exists.
-------------- 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/20040530/ea618665/attachment.sig>

From buildsys at redhat.com  Sun May 30 10:50:38 2004
From: buildsys at redhat.com (Build System)
Date: Sun, 30 May 2004 06:50:38 -0400
Subject: rawhide report: 20040530 changes
Message-ID: <200405301050.i4UAocY27176@porkchop.devel.redhat.com>

 

 
Updated Packages:

rpmdb-fedora-2-0.20040530
-------------------------




From aoliva at redhat.com  Sun May 30 11:35:13 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 30 May 2004 08:35:13 -0300
Subject: The return of the acute-cedilla problem
In-Reply-To: <1085867275.15316.15.camel@z>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my> <1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
	<20040524215310.GJ18881@rednote.net> <1085453830.4695.7.camel@z>
	<oraczwilj6.fsf@free.redhat.lsd.ic.unicamp.br>
	<1085867275.15316.15.camel@z>
Message-ID: <orn03qno5q.fsf@livre.redhat.lsd.ic.unicamp.br>

On May 29, 2004, Z <zleite at mminternet.com> wrote:

> Now would you (or the list) happen to know why xorg does not follow the
> usual usual us_intl composition rules?

Err...  Usual?  If it's international, and some languages have
legitimate uses for ?, then it wouldn't be, erhm, international to map
'c to ?, would it?

So I would think xorg is doing the right thing in this regard, and so
is gtk.  The difference is that gtk has custom compose rules for pt_BR
locales, and xorg doesn't.

The other difference is that the us-acentos keyboard layout, used for
the text console when US International configuration is selected, also
happens to generate ? from 'c.  Nor surprising, since us-acentos was
created in Brazil, and never adjusted to match the improved (?) X11
Compose settings.  Unfortunately, if this change was made, there'd be
no way (AFAICT) to generate ? in the text console.  Oh well...

> As it is now, gtk and, more
> importantly, openoffice follow the old style.

?!?

I've just started OOo within a en_US.UTF-8 locale and US International
keyboard compose rules, and 'c does generate ?, like everywhere else.
Ditto if I start it as LANG=pt_BR.UTF-8 ooffice within my en_US.UTF-8
X session.  This if FC2, BTW.

> Also, how come the console won't show accented charachters on
> en_US.UTF-8?

IIRC the text console is limited to 256-character fonts, so it can't
display full Unicode character sets.  That's a shame, but I think this
limitation comes from the PC BIOS, so it's a bit hard to overcome
without going for bitmapped text consoles :-(

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From Nicolas.Mailhot at laPoste.net  Sun May 30 13:20:50 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sun, 30 May 2004 15:20:50 +0200
Subject: The return of the acute-cedilla problem
In-Reply-To: <orn03qno5q.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
	<20040524215310.GJ18881@rednote.net> <1085453830.4695.7.camel@z>
	<oraczwilj6.fsf@free.redhat.lsd.ic.unicamp.br>
	<1085867275.15316.15.camel@z>
	<orn03qno5q.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <1085923250.2763.4.camel@m64.net81-64-154.noos.fr>

Le dim, 30/05/2004 ? 08:35 -0300, Alexandre Oliva a ?crit :
> On May 29, 2004, Z <zleite at mminternet.com> wrote:
> 
> > Now would you (or the list) happen to know why xorg does not follow the
> > usual usual us_intl composition rules?
> 
> Err...  Usual?  If it's international, and some languages have
> legitimate uses for ?, then it wouldn't be, erhm, international to map
> 'c to ?, would it?
> 
> So I would think xorg is doing the right thing in this regard, and so
> is gtk.  The difference is that gtk has custom compose rules for pt_BR
> locales, and xorg doesn't.

If I remember well, this change also went into XFree86 just before the
split. The  argument being : there are legitimate uses for ?, therefore 
'c to ? does not make sense, especially when you can compose ? using ,
and c (which seems a bit more logical).

I'm afraid I didn't pay a lot of attention, on my fr-latin9 french
layout ? and ? are obtained without composition whatsoever

Regards,

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

From toshio at tiki-lounge.com  Sun May 30 15:28:34 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Sun, 30 May 2004 11:28:34 -0400
Subject: QA Application XML save formats.
Message-ID: <1085930911.13569.110.camel@Madison.badger.com>

Hi,

I've got a first cut of an xml save format for my QA Assistant App.  If
Aur?lien, Erik, and others interested in tools that help write QA
reports want to take a look, I'd be glad of any input.  I'm only a
novice xml author so my format could probably use some work.

The save format has three main elements:
* A checklist that specifies the checklist this save file was created
with.
* Properties associated with this instance of a checklist (SRPM
filename, bugzilla number, etc).
* Checklist entries that have been modified.

My program uses this information to load the original checklist and then
overlay the modifications that make up this instance of the checklist.

DTD and sample file are attached and at:
http://qa-assistant.sf.net/qasave/0.1/qasave.dtd
http://qa-assistant.sf.net/qasave/0.1/sample-save.xml

Checklist DTD the qasave file is intended to work with and a checklist
that tries to conform to the Fedora QA checklist are at:
http://qa-assistant.sf.net/checklist/0.2/checklist.dtd
http://qa-assistant.sf.net/lists/fedoraus.xml

-Toshio
-- 
_______S________U________B________L________I________M________E_______
  t  o  s  h  i  o  +  t  i  k  i  -  l  o  u  n  g  e  .  c  o  m
                                                          GA->ME 1999
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qasave.dtd
Type: text/xml
Size: 1399 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040530/15c8c66a/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample-save.xml
Type: text/xml
Size: 828 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040530/15c8c66a/attachment-0001.xml>
-------------- 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/20040530/15c8c66a/attachment.sig>

From cpedersen at c-note.dk  Sun May 30 15:41:22 2004
From: cpedersen at c-note.dk (Casper Pedersen)
Date: Sun, 30 May 2004 17:41:22 +0200
Subject: Missing ethereal after installation of FC2
Message-ID: <1085931682.25972.2.camel@tuxdsk.c-note.dk>

Hi,

I have found a bug in ethereal-0.10.3.2 which is installed with FC2.

I've filed bug 124721, and here is the fix for it(also attached to the
bug):
*** ethereal.spec.orig  2004-04-15 16:45:44.000000000 +0200
--- ethereal.spec       2004-05-30 17:35:18.242635656 +0200
***************
*** 111,116 ****
--- 111,118 ----
  %files
  %defattr(-,root,root)
  %doc AUTHORS COPYING ChangeLog INSTALL NEWS README* doc/
+ %{_bindir}/ethereal
+ %{_sbindir}/ethereal
  %{_sbindir}/editcap
  %{_sbindir}/idl2eth
  %{_sbindir}/tethereal


Regards/Casper

-- 
GPG Public key is available from: http://www.keyserver.net/
Fingerprint = 56ED 74A4 7B00 20E2 B493 0C1A 6B4E BF8F A086 FE57

-------------- 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/20040530/4f4349a0/attachment.sig>

From cra at WPI.EDU  Sun May 30 15:47:45 2004
From: cra at WPI.EDU (Charles R. Anderson)
Date: Sun, 30 May 2004 11:47:45 -0400
Subject: Missing ethereal after installation of FC2
In-Reply-To: <1085931682.25972.2.camel@tuxdsk.c-note.dk>
References: <1085931682.25972.2.camel@tuxdsk.c-note.dk>
Message-ID: <20040530154745.GB21370@angus.ind.WPI.EDU>

On Sun, May 30, 2004 at 05:41:22PM +0200, Casper Pedersen wrote:
> I have found a bug in ethereal-0.10.3.2 which is installed with FC2.
> I've filed bug 124721, and here is the fix for it
> + %{_bindir}/ethereal
> + %{_sbindir}/ethereal

Those two files are not supposed to be in the ethereal package, since 
they are in the ethereal-gnome package.




From aoliva at redhat.com  Sun May 30 16:19:01 2004
From: aoliva at redhat.com (Alexandre Oliva)
Date: 30 May 2004 13:19:01 -0300
Subject: The return of the acute-cedilla problem
In-Reply-To: <1085923250.2763.4.camel@m64.net81-64-154.noos.fr>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my> <1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
	<20040524215310.GJ18881@rednote.net> <1085453830.4695.7.camel@z>
	<oraczwilj6.fsf@free.redhat.lsd.ic.unicamp.br>
	<1085867275.15316.15.camel@z>
	<orn03qno5q.fsf@livre.redhat.lsd.ic.unicamp.br>
	<1085923250.2763.4.camel@m64.net81-64-154.noos.fr>
Message-ID: <oraczpopl6.fsf@livre.redhat.lsd.ic.unicamp.br>

On May 30, 2004, Nicolas Mailhot <Nicolas.Mailhot at laPoste.net> wrote:

> If I remember well, this change also went into XFree86 just before the
> split.

What split?  It's been like this at least since RHL9, so it's
certainly not the XFree86/Xorg split.

> The  argument being : there are legitimate uses for ?, therefore 
> 'c to ? does not make sense, especially when you can compose ? using ,
> and c (which seems a bit more logical).

Exactly.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}




From b.j.smith at ieee.org  Mon May 31 00:48:31 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Sun, 30 May 2004 20:48:31 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
Message-ID: <1085964510.5650.163.camel@bitman.oviedo.smithconcepts.com>

Willem Riede wrote:  
> Why? I've read the barrage of mails this triggered, and I see
> absolutely no benefit. I can understand the desire to have a more
> minimal "minimal" install package set, and the packages that would be
> in that set will probably all sit on the first CD. But that doesn't
> translate into the need to limit the size of the distribution.

For companies who need a "base" to start with, I disagree.  Not many
companies want to install the entire "Core."  And by maintaining a
local "Apt" repository, there is little need to either.

> Convenience for those of us (like me) that use a more extensive
> package set should not be compromised.

And it will not since "Core" itself will _not_ be touched.
I too like to install the _full_ Fedora "Core" on my personal
workstations and servers at home.

But for a corporation which maintains its own configuration management,
this is not good IMHO.

That's why I suggested making this subset separate.  I called it
Fedora "Quark."  It is the "common denominator" that all other,
customized systems can be built from using other "Core" packages,
while offering a basic GUI (which the 90MB "minimal" install
does not).


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From b.j.smith at ieee.org  Mon May 31 01:00:27 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Sun, 30 May 2004 21:00:27 -0400
Subject: Making Fedora Core CD #1 Standalone -- the "common denominator"
Message-ID: <1085965227.5650.179.camel@bitman.oviedo.smithconcepts.com>

Chris Chabot wrote:  
> Ah finaly something we disagree on :-) Small is suprisingly easy to
> accomplish.. However to make this install usefull to to the average
> user, thats something different i.m.o.
> We might not share the same vision here.. I envision a 1 CD
> instalation that allows ppl to get up and running, and do all the
> basic server and/or workstation stuff that you would expect.. So basic
> IM, browsing, office document editing, graphic packages, full
> gnome/nautilus with basic utilities.. etc. Not the expanded list that
> makes it 4 cd's, but enough to have the same experiance as you would
> have using Windows 9x / XP.. even just a little more. For a lot of
> people this 1 CD instalation should already be enough to start 'using
> linux'. If after that they want to install another desktop
> envirioment, databases, etc.. then they will need the extra cd's or
> download things from internet repositories.

"Useful" isn't the ultimate goal of Quark, at least what I'm striving
for.  I'm looking at a "minimal GUI install."  Why?

Everyone will _disagree_ what is "minimal."  One company might have
standardized on OpenOffice.org, while another might use CrossOver Office
with MS Office, while another still might not use a word processor
altogether (and use something like LyX or Scribus, etc...).

The idea here is to give corporations a "minimal" install they _always_
plop down on their workstations, then run a script that apt-gets
everything else.  Maybe later on we can create a "Quark plus" builder
that fills an ISO with more applications.  But it will always be
_customized_ at the end user, not in Fedora "Quark" itself.

Fedora "Quark" should be the 90MB "minimal" install plus GUI and basic
client/service componets for authentication and network access.  That's
all.  Everything else and you start getting people who differ.  ;-ppp

> Thus my 'quark' (to use your definition) vision is different from
> yours.. While i like the concept of "just basics please", i can see
> this confusing people why they have to download the 4 cd's anyway
> (thus not solving that problem). While for advanced users this
> pure-basics 1 cd usefull, i think it misses the point for the "average
> user"

You're talking to the guy that cuts DVD-Rs with both Fedora "Core" and
"Extras" on it.  ;-ppp

But for "Quark," I'm not looking at the "average user."  I'm looking at:
1. The IT Professional who wants a "common base"
2. The Developer who wants to know what libraries to "aim for"

And other details.  Once we define what Fedora "Quark" is, we can give
more flexibility (like that "Quark plus" builder script I mentioned).
But right now we need to define what should be in Quark itself -- a
common base that _no_one_ will disagree with what is included, and
can grow to include more basic packages in the future.

> I gues a terminology i'd use to describe my 1st cd vision is 'assumed
> functionality'.

And you're right, that's where we differ.
"Assumed functionality" differs between different users.

I'm talking about the minimal GUI/client/service install that _all_
"assumed functionality" will _always_ have.

I'm not just talking about fitting a distro on 1 CD.
That can be done with tools already out there.

And you can do this by taking Fedora "Quark" and adding what you want to
fit on 1 CD.  The same for anyone else.  The key here is to define that
"Quark" that has packages that will be in _all_ offspring.

> Last argument i have on this is wasting CD space.. if CD1 only has
> 200Mb of stuff on it, there's a big risk this will add another cd to
> the instalation, and thus be more expensive to publish/burn, make for
> more cd swapping, and make ppl scream bloat even more then they do
> now..

And that's where the "Quark plus" comes in.  You have "Quark," and then
you bundle other stuff on it with the "Quark plus" builder.  The key is
that the _end_user_ does this, not the "Quark" spec.

This could eventually be part of the Fedora "Core" builder.  Fedora is
built upon "Quark" and all the popular stuff added into CD #1.  But I'm
looking ahead of the game, but that is an eventual goal.


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From aperez at student.santarosa.edu  Mon May 31 05:40:14 2004
From: aperez at student.santarosa.edu (Alex Perez)
Date: Sun, 30 May 2004 22:40:14 -0700
Subject: Self-Introduction: Alex Perez
Message-ID: <40BAC53E.1010905@student.santarosa.edu>

[If you get this twice, my sincere apologies.]

Hi there, my name is Alexander Joseph Perez, and I'm a co-maintainer of
the GNUstep.org website and have been using GNUstep.org for several
years. I'm from Santa Rosa, California, in the USA, am a full time
anthropology student at Santa Rosa Junior College and work part time as
a lowly help desk technician for the City of Santa Rosa, California.

I'm writing this e-mail because I've recently noticed that the most
recent release of Fedora Core (2) does not contain any GNUstep packages,
and as I've just installed it after getting sick and tired of Debian,
I'd like to change that. I am intimately famaliar with the build
process, and have a significant amount of personal contact online with
the GNUstep core development team on a daily basis. I'd be willing to do
QA on my packages as long as the requirements were reasonable. In short,
I'd like to expose GNUstep to a wider audience now that it is ready for
such exposure. GNUstep has been a long-lived project, and "we're not
dead yet" seems to have become our mantra. GNUstep is not dead. In fact
it's alive and well, and with the inclusion of GNUstep packages into
Fedora Core, one of the more popular distributions of Linux, we will
gain the potential to expose many more people to GNUstep and its offerings.

As I said previously, I'm a current GNUstep.org website maintainer, and
am working on unifying the disparate GNUstep-related documentation
sources which are/have been strewn across the expanse of the Internet
until recently (much of it still is). I love the simplicity and true
Object-Oriented nature of the Objective-C programming language, which
GNUstep is based on. My associate, Andrew Pinski, is the GCC libobjc
(GCC Objective-C runtime) maintainer and works periodically for apple as
his college career permits. I recently worked with him to make sure that
some of the patches to the Objective-C runtime were integrated into
libobjc head.

If anyone here has any questions, please feel free to contact me at
aperezATstudentDOTsantarosaDOTedu as I'd be glad to answer or clarify
any points I've made here. I am not subscribed to the fedora-devel
mailing list and do not wish to be unless I am "accepted" and allowed to
create and provide GNUstep packages to Fedora.

My GPG fingerprint is 2F36 2A89 14B4 B58F 176B  1B26 5E4D 5FCA 9190 2041
and this has been uploaded to pgp.mit.edu

Cheers,
Alex Perez
--
pub  1024D/91902041 2004-05-31 Alex Perez (MrBIOS)
<aperez at student.santarosa.edu>
      Key fingerprint = 2F36 2A89 14B4 B58F 176B  1B26 5E4D 5FCA 9190 2041
sub  2048g/380DB427 2004-05-31





From dragoran at feuerpokemon.de  Mon May 31 07:22:04 2004
From: dragoran at feuerpokemon.de (dragoran)
Date: Mon, 31 May 2004 09:22:04 +0200
Subject: Why are there only i686 and i586 Version of glibc and kernel?
Message-ID: <40BADD1C.4030205@feuerpokemon.de>

Why not add a glibc and kernel which are optimized for pentium 4 in FC3 
? This would increase the perfomance on newer PC but also works on older 
ones by still including the i686 and i586 versions.




From wtogami at redhat.com  Mon May 31 07:24:21 2004
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 30 May 2004 21:24:21 -1000
Subject: Spamassassin [Fwd: 3.0.0 schedule]
Message-ID: <40BADDA5.6060506@redhat.com>

FYI.  Rawhide now contains a snapshot of spamassassin-3.0.0, which will 
be updated next week when the official pre-release happens.  I encourage 
all spamassassin users to rebuild the rawhide spamassassin SRPM for use 
on FC1 or FC2 in order to provide production testing, and report bugs in 
upstream Bugzilla.  I personally have been using 3.0.0 svn snapshots on 
my personal server for a few weeks now, and it has been much better than 
spamassassin-2.63 for me.

Warren Togami
wtogami at redhat.com

-------- Original Message --------
Subject: 3.0.0 schedule
Date: 28 May 2004 17:41:24 -0700
From: Daniel Quinlan <quinlan at pathname.com>
Reply-To: quinlan at pathname.com
To: spamassassin-dev at incubator.apache.org

So, here's the new schedule, based on Theo's last schedule:

(a) bug squashing is not part of schedule; this can and should be
     scheduled independently
(b) there is no concept of "all bugs" any more, only "critical bugs"
(c) warning people about mass-check runs is also decoupled as that can
     be done independently -- we can warn people now, even
(d) critical bugs had better darn well show up in red in my bugzilla
     screen (that is, "Severity" field set to "critical") or the bug
     doesn't count as critical.

feature freeze:

   05/31: feature freeze, enter Review-then-Commit mode at 0900 UTC to
	 enforce feature freeze

pre-release cycle:

   06/03: first pre-release

   do {
      3 to 7 days of testing of pre-release
      issue new pre-release
   } while (critical bugs found in testing)

mass-check cycle:

   day 0: announce mass-check run 1 (sets 0 and 1), run 7 days

   day +7: generate scores, etc.

   day +9: new pre-release with new scores, announce mass-check run 2
           (sets 2 and 3), run 7 days

   day +11: generate scores, etc.

release-candidate cycle:

   day 0: release 3.0.0-rc1

   do {
      3 to 7 days of testing of release candidate
      issue new release candidate
   } while (critical bugs found in testing)

   day ?: issue 3.0.0-final

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

RATIONALE:

First, we need R-T-C to have the feature freeze.  Second, my experience
is that we actually move faster once we enter R-T-C mode because
everyone is following development closer.

We should not try to get everything done or close every bug before
moving forward with pre-releases (which must precede the mass-checks to
get the bugs out) because we'll always have bugs being added.  2.63 is
not as good as 3.0, so let's release and help out our users.

So, no more bug squashing events, no more delays, let's enter R-T-C mode
on Monday and do a pre-release next week.  WE ARE READY.

Also, if someone wants to replace the scores, then you have a week.
Open a bug.  ;-)

I believe tying everything together in the schedule is adding delays and
making it easier to slip more and more stuff into the release.  We never
had to lock-step things before, we just reviewed the open bugs at each
stage of the simple schedule and decided whether or not we were ready to
proceed to the next step or if we had to cut a new pre/rc release.  It's
how most open source projects work.  Assigning dates far out in the
future is pretty pointless and just makes things frustrating.

As you can see, I've attempted to streamline the schedule, for example,
by allowing for as little as 3 days of testing (if a bug can be verified
as fixed quickly) so we can plow through rather than stay stuck in the
mud.  I limited things to 3 days, though, so we don't issue new releases
every day or every other day.

Finally, since we're not in R-T-C mode yet, I'm calling this the 3.0.0
schedule.  If you want to veto...

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/




From hpa at zytor.com  Mon May 31 07:32:12 2004
From: hpa at zytor.com (H. Peter Anvin)
Date: Mon, 31 May 2004 00:32:12 -0700
Subject: VPN solution(s) for Fedora Core
In-Reply-To: <1085342194.2580.2.camel@rivendell.home.local>
References: <1085154729.6414.44.camel@draco.sault.org>
	<1085342194.2580.2.camel@rivendell.home.local>
Message-ID: <40BADF7C.6040305@zytor.com>

Florin Andrei wrote:
> On Fri, 2004-05-21 at 08:52, Jason Tackaberry wrote:
>                     
>>I think the other main contender for VPN software in Fedora Core would
>>be Openswan.  OpenVPN is portable, comfortable (being in userspace),
>>flexible, and easy, but Openswan implements IPsec which is (mostly)
>>standardized across vendors, and that's certainly a strong selling
>>point, in spite of its complexity.
> 
> Openswan is good to keep around, just in case you need to talk to IPSec
> devices. But it's a pain in the butt; it's NAT-unfriendly, free and good
> Windows clients are lacking, interoperability is problematic, etc.
> 

Eh?

OpenSWAN 2.1.2 works fine, interoperates fine with *most* IPSec clients, 
including WinXP, and supports NAT-T (a.k.a. IPSec over UDP), so there 
shouldn't be any problems.

I have been running OpenSWAN for a while now and the only problem I've 
had with it is its somewhat limited handling of aggressive mode (which 
FreeSWAN didn't implement due to its known security holes.)

	-hpa




From arjanv at redhat.com  Mon May 31 07:45:31 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Mon, 31 May 2004 09:45:31 +0200
Subject: Why are there only i686 and i586 Version of glibc and kernel?
In-Reply-To: <40BADD1C.4030205@feuerpokemon.de>
References: <40BADD1C.4030205@feuerpokemon.de>
Message-ID: <1085989529.2708.1.camel@laptop.fenrus.com>

On Mon, 2004-05-31 at 09:22, dragoran wrote:
> Why not add a glibc and kernel which are optimized for pentium 4 in FC3 
> ? This would increase the perfomance on newer PC but also works on older 
> ones by still including the i686 and i586 versions.

P4's are compatible with i686 and the optimisations are also quite
similar, although not entirely. Most likely we'll be optimising the
entire distro for P4 while keeping compatibility with i386 or i486. 
(Code optimized for P4 runs just as fast as code for pII/pIII on those).

-------------- 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/20040531/2242f825/attachment.sig>

From david at fubar.dk  Mon May 31 10:02:07 2004
From: david at fubar.dk (David Zeuthen)
Date: Mon, 31 May 2004 12:02:07 +0200
Subject: submount?
In-Reply-To: <20040525072308.GC5395@devserv.devel.redhat.com>
References: <200405241448.14725.ndbecker2@verizon.net>
	<c8uppe$k1o$1@sea.gmane.org>
	<1085468198.2783.4.camel@laptop.fenrus.com>
	<20040525072308.GC5395@devserv.devel.redhat.com>
Message-ID: <1085997727.18691.29.camel@tux.fubar.dk>

On Tue, 2004-05-25 at 09:23, Alan Cox wrote:
> On Tue, May 25, 2004 at 08:56:38AM +0200, Arjan van de Ven wrote:
> > The problem it tries to solve is hard. It will require fundamental
> > kernel changes to get right I fear, and just trying to paper over the
> > underlying kernel with a small module ain't gonna fix it, it will remain
> > just papering over ;(
> 
> Or user space 8). volumagic proves you can do it that way for only a small
> hit
> 

I've just put some code in HAL to detect whether the eject button is
pressed (using MMC-2) so ideally HAL would relay this to gnome-vfs which
would emit a PreUnmount signal such that apps closes their files and
then it can do the unmount(1), eject(1) dance. Thing is, I don't know
how many drives correctly implement this MMC-2 bit, any insight?

Maybe it would be smarter to get HAL to use some of the volumagic code
[1], since I guess a similar technique can be used for partitions on a
USB drive to give safe removal when the drive is not in use. Would this
be a good idea? Or are there kernel changes on the horizon to solve all
of these problems?

Thanks,
David

[1] : I think it can be done without changing the HAL API, which means
vendors can ship HAL with or without volumagic stuff, here's the thread

http://freedesktop.org/pipermail/hal/2004-May/000244.html




From macshy at tom.com  Mon May 31 10:06:10 2004
From: macshy at tom.com (Mac)
Date: Mon, 31 May 2004 18:06:10 +0800
Subject: Howto use the "pxeboot" directory?
Message-ID: <200405311006.i4VA68Xn020263@mx3.redhat.com>

Hello devel-list,
  I'm trying to install FC2 from my FAT driver without CDs/USBStorages, but FC2 doesn't supply a comfortable way to do so.
  And I tried to use  the vmlinuz and initrd.img in the directory of /images/pxeboot with the help of LOADLIN, but failed.
  How to use the files in "pxeboot" directory?
  How to install FC2 from FAT-Formatted Harddrive without burning CDs.
  Thanks. 
 				

????????Mac
????????macshy at tom.com
??????????2004-05-31




From csm at fx.ro  Mon May 31 10:04:46 2004
From: csm at fx.ro (Cosmin Hanulescu)
Date: Mon, 31 May 2004 13:04:46 +0300
Subject: =?iso-8859-1?q?Intel=AE_536ep_V=2E92_modem_=28PCI=29_chipset_?=
 =?iso-8859-1?q?driver_=26_2=2E6_kernel_under_FC2?=
In-Reply-To: <1085904739.2720.2.camel@laptop.fenrus.com>
References: <40B90853.2010104@fx.ro>
	<1085904739.2720.2.camel@laptop.fenrus.com>
Message-ID: <40BB033E.9010008@fx.ro>

Arjan van de Ven wrote:

> since that is a binary only kernel module that will be really hard for
> anyone except intel to do.

Well, I thought that the binary part of the bundle Intel provides is 
pretty much the same, only the the code that wrap around it and does the 
interfacing with the kernel should be changed according to 2.6. But I 
must admit that I can't tell more for I lack skills in the kernel 
internals area.

I did compile the thing, changing here and there the headers, but, 
obviously, the resulting object file didn't work, as I was expecting..

> However you may be lucky if your modem is supported by the snd_intel8x0m
> alsa driver, that exports your modem as sound device to userspace, and a
> userspace app to "whistle" modem sounds into that exists.

Now that's a funny thing, I'll have a look at it.

Thank you

-- 
I submit that the world would be much happier, if men were as fully able 
to keep silence as they are to speak. - Spinoza




From peter.backlund at home.se  Mon May 31 11:01:52 2004
From: peter.backlund at home.se (Peter Backlund)
Date: Mon, 31 May 2004 13:01:52 +0200
Subject: Howto use the "pxeboot" directory?
In-Reply-To: <200405311006.i4VA68Xn020263@mx3.redhat.com>
References: <200405311006.i4VA68Xn020263@mx3.redhat.com>
Message-ID: <1086001312.5332.7.camel@localhost.localdomain>

On m?n, 2004-05-31 at 18:06 +0800, Mac wrote:
> Hello devel-list,
        ^^^^^
This is probably not the correct list to ask these types of questions.

>   I'm trying to install FC2 from my FAT driver without CDs/USBStorages, but FC2 doesn't supply a comfortable way to do so.
>   And I tried to use  the vmlinuz and initrd.img in the directory of /images/pxeboot with the help of LOADLIN, but failed.
>   How to use the files in "pxeboot" directory?
>   How to install FC2 from FAT-Formatted Harddrive without burning CDs.

I'm not sure I understand your situation correctly...pxeboot is for
network booting, i.e. you need to have a tftp/dhcp server somewhere that
hands you boot media (kernel/initrd) and ip number. However, it sounds
like you have the iso files on a fat-formatted drive, on the same (?)
computer that you want to install FC2 on. In that case, you need to boot
from either floppy or CD (using boot.iso, rescuecd.iso or FC2-iso1),
selecting "linux askmethod" at the boot prompt and then go for Hard disc
install.

Yes, you need to burn one cd (unless you use the floppy method), but
both boot.iso (5 megs) and rescuecd.iso (75 megs) are small enough to
write onto a CD/RW, if you're concerned about CDR waste.

/Peter

>   Thanks. 
>  				
> 
> ????????Mac
> ????????macshy at tom.com
> ??????????2004-05-31
> 
> 
-- 
Peter Backlund <peter.backlund at home.se>




From buildsys at redhat.com  Mon May 31 12:02:36 2004
From: buildsys at redhat.com (Build System)
Date: Mon, 31 May 2004 08:02:36 -0400
Subject: rawhide report: 20040531 changes
Message-ID: <200405311202.i4VC2aY26003@porkchop.devel.redhat.com>

 

 
Updated Packages:

bitstream-vera-fonts-1.10-4
---------------------------
* Sun May 30 2004 Florian La Roche <Florian.LaRoche at redhat.de>

- change post/postun scripts

gaim-0.78-2
-----------
* Sun May 30 2004 Warren Togami <wtogami at redhat.com> 0.78-2

- update to 0.78 (without SILC support for now)

kernel-2.6.6-1.403
------------------
* Sun May 30 2004 Arjan van de Ven <arjanv at redhat.com>

- 2.6.7-rc2
- set the ACPI OS name to "Microsoft Windows XP" for better compatibility

rpmdb-fedora-2-0.20040531
-------------------------




From jakub at redhat.com  Mon May 31 13:39:36 2004
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 31 May 2004 09:39:36 -0400
Subject: Why are there only i686 and i586 Version of glibc and kernel?
In-Reply-To: <40BADD1C.4030205@feuerpokemon.de>
References: <40BADD1C.4030205@feuerpokemon.de>
Message-ID: <20040531133936.GJ4736@devserv.devel.redhat.com>

On Mon, May 31, 2004 at 09:22:04AM +0200, dragoran wrote:
> Why not add a glibc and kernel which are optimized for pentium 4 in FC3 
> ? This would increase the perfomance on newer PC but also works on older 
> ones by still including the i686 and i586 versions.

Starting with FC3, .i386.rpm and .i686.rpm packages will be compiled
with -march{3,6}86 -mtune=pentium4, so although they will run on
i386 (resp. i686), they will be optimized for P4 (Athlons and newer AMD
chips run P4 optimized code without noticeable performance hit).

	Jakub




From rezso at rdsor.ro  Mon May 31 20:50:59 2004
From: rezso at rdsor.ro (Balint Cristian)
Date: Mon, 31 May 2004 16:50:59 -0400
Subject: Why are there only i686 and i586 Version of glibc and kernel?
In-Reply-To: <20040531133936.GJ4736@devserv.devel.redhat.com>
References: <40BADD1C.4030205@feuerpokemon.de>
	<20040531133936.GJ4736@devserv.devel.redhat.com>
Message-ID: <200405311650.59528.rezso@rdsor.ro>

On Monday 31 May 2004 09:39, Jakub Jelinek wrote:
> On Mon, May 31, 2004 at 09:22:04AM +0200, dragoran wrote:
> > Why not add a glibc and kernel which are optimized for pentium 4 in FC3 
> > ? This would increase the perfomance on newer PC but also works on older 
> > ones by still including the i686 and i586 versions.
> 
> Starting with FC3, .i386.rpm and .i686.rpm packages will be compiled
> with -march{3,6}86 -mtune=pentium4, so although they will run on
> i386 (resp. i686), they will be optimized for P4 (Athlons and newer AMD
> chips run P4 optimized code without noticeable performance hit).

Hi !

Is there difference betwwen -mtune=pentium4 and -mtune=athlon ?
Pentium4 sounds intel-ish centric but what about AMD ?.


cristian




From wrrhdev at riede.org  Mon May 31 14:09:57 2004
From: wrrhdev at riede.org (Willem Riede)
Date: Mon, 31 May 2004 10:09:57 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
In-Reply-To: <1085964510.5650.163.camel@bitman.oviedo.smithconcepts.com> (from
	b.j.smith@ieee.org on Sun, May 30, 2004 at 20:48:31 -0400)
References: <1085964510.5650.163.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <20040531140957.GK13627@serve.riede.org>

On 2004.05.30 20:48, Bryan J. Smith wrote:
> Willem Riede wrote:  
> > Why? I've read the barrage of mails this triggered, and I see
> > absolutely no benefit. I can understand the desire to have a more
> > minimal "minimal" install package set, and the packages that would be
> > in that set will probably all sit on the first CD. But that doesn't
> > translate into the need to limit the size of the distribution.
> 
> For companies who need a "base" to start with, I disagree.  Not many
> companies want to install the entire "Core."  And by maintaining a
> local "Apt" repository, there is little need to either.
> 
> > Convenience for those of us (like me) that use a more extensive
> > package set should not be compromised.
> 
> And it will not since "Core" itself will _not_ be touched.
> I too like to install the _full_ Fedora "Core" on my personal
> workstations and servers at home.
> 
> But for a corporation which maintains its own configuration management,
> this is not good IMHO.
> 
> That's why I suggested making this subset separate.  I called it
> Fedora "Quark."  It is the "common denominator" that all other,
> customized systems can be built from using other "Core" packages,
> while offering a basic GUI (which the 90MB "minimal" install
> does not).

One thing I'm still not sure I understand: Are you advocating a separate
CD image, or an additional, separate, package set in comps that you can
choose to install, in which case you happen to only need CD 1?

Thanks, Willem Riede.




From jakub at redhat.com  Mon May 31 14:10:26 2004
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 31 May 2004 10:10:26 -0400
Subject: Why are there only i686 and i586 Version of glibc and kernel?
In-Reply-To: <200405311650.59528.rezso@rdsor.ro>
References: <40BADD1C.4030205@feuerpokemon.de>
	<20040531133936.GJ4736@devserv.devel.redhat.com>
	<200405311650.59528.rezso@rdsor.ro>
Message-ID: <20040531141026.GK4736@devserv.devel.redhat.com>

On Mon, May 31, 2004 at 04:50:59PM -0400, Balint Cristian wrote:
> > Starting with FC3, .i386.rpm and .i686.rpm packages will be compiled
> > with -march{3,6}86 -mtune=pentium4, so although they will run on
> > i386 (resp. i686), they will be optimized for P4 (Athlons and newer AMD
> > chips run P4 optimized code without noticeable performance hit).
>
> Is there difference betwwen -mtune=pentium4 and -mtune=athlon ?
> Pentium4 sounds intel-ish centric but what about AMD ?.

Yes, there is.  The thing is, Intel chips are far more sensitive to
instruction scheduling than AMD chips.
So, if you run code tuned for AMD on P4, the performance hit is big,
if you run P4 optimized code on AMD, the performance hit compared to
running AMD tuned code on AMD is really small.

	Jakub




From b.j.smith at ieee.org  Mon May 31 14:55:49 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Mon, 31 May 2004 10:55:49 -0400
Subject: Reduce "Core" to 1 Binary CD? -- WAS: Request for Packages in
	Fedora Core 3
Message-ID: <1086015349.5650.264.camel@bitman.oviedo.smithconcepts.com>

Willem Riede wrote:  
> One thing I'm still not sure I understand:
> Are you advocating a separate CD image,

Well, to start, I'm not advocating anything for Fedora itself.
Although the thread started with Stephen Pritchard making a
comment, and I built upon them, ultimately I'm not in a position
to even do so right now.

Although I started with reducing Core, or reorganizing Core CD #1,
that is no longer the case.  So read on, I see your questions as very
good ones.

> or an additional, separate, package set in comps that you can
> choose to install, in which case you happen to only need CD 1?

Again, good questions.  Here's the deal:  

1.  I'm creating a separate package set in comps.xml

2.  I will use that package set to create a "Quark" CD

3.  This CD will be well under the 500MB or so of packages one
normally fits on a CD (plus the Anaconda installer)

4.  I'm also (eventually) build a "Quark builder" so it is easy
to build a "full" CD customized #1

Depending on the merits of "Quark," we _may_ then have:

5.  The Fedora "Core" team may end up using "Quark" to create
Fedora "Core" CD #1, including the additional sets from
Quark's comps.xml

But I'll leave that to when Fedora "Quark" is no longer vaporware.

I've stepped back and recognized that everyone will disagree
on what a "full" CD #1 should be.  So that's why I've pulled
back farther and came up with "Quark."  I've been through the
August/September 2003 archives and done some other goal setting.

Which is where I came up with Fedora "Quark."  It's not an
"assumed functionality" as someone else said, because that
differs between users.  But it is a "common denominator" that
_all_ derrived "assumed functionality" is built upon.

I'm starting to look at some of the dependency hell.  It has
improved since I did some similar stuff back in RHL 7, but there
are still a few "interesting" ones.

You'll hear from me next when you hear from me next.  But I'm
not advocating the Fedora "Core" team or the project look at this
again until *I* actually start producing more than vapor.  I'm
off the summer (I'm a school teacher) so I have the time.


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org





From kas11 at tampabay.rr.com  Mon May 31 15:41:21 2004
From: kas11 at tampabay.rr.com (K. Spearel)
Date: Mon, 31 May 2004 11:41:21 -0400
Subject: Why are there only i686 and i586 Version of glibc and kernel?
In-Reply-To: <20040531141026.GK4736@devserv.devel.redhat.com>
References: <40BADD1C.4030205@feuerpokemon.de>
	<20040531133936.GJ4736@devserv.devel.redhat.com>
	<200405311650.59528.rezso@rdsor.ro>
	<20040531141026.GK4736@devserv.devel.redhat.com>
Message-ID: <1086018080.30305.43.camel@neptune>

On Mon, 2004-05-31 at 10:10, Jakub Jelinek wrote:
> On Mon, May 31, 2004 at 04:50:59PM -0400, Balint Cristian wrote:
> > > Starting with FC3, .i386.rpm and .i686.rpm packages will be compiled
> > > with -march{3,6}86 -mtune=pentium4, so although they will run on
> > > i386 (resp. i686), they will be optimized for P4 (Athlons and newer AMD
> > > chips run P4 optimized code without noticeable performance hit).
> >
> > Is there difference betwwen -mtune=pentium4 and -mtune=athlon ?
> > Pentium4 sounds intel-ish centric but what about AMD ?.
> 
> Yes, there is.  The thing is, Intel chips are far more sensitive to
> instruction scheduling than AMD chips.
> So, if you run code tuned for AMD on P4, the performance hit is big,
> if you run P4 optimized code on AMD, the performance hit compared to
> running AMD tuned code on AMD is really small.
> 
> 	Jakub

I think it is only fair that someone quantify the performance hit that
K7 and 32bit K8 users can expect versus the improvement that P4 users
will see before this is implemented.  Is this change in anticipation of
the Prescott with its even deeper instruction pipeline?  It is my
understanding that 32bit-only K8s are shipping already...since they are
being pitch at all areas outside the NA and Europe, they ought to be
considered also before a final decision is made here.

If I am reading this right, not only the kernel and glibc will be
affected...it was stated that the *entire* distro will be optimized for
the P4.  People seem to have accepted the idea that K7 optimized kernels
aren't worth the effort...but if we are now talking a performance hit
across the board on all apps not run on Intel hardware, there may be
some unhappy campers.  With the 7% performance hit once mentioned here
due to SELinux, just what is a "really small" performance hit?  I'm not
sure I will happily accept another 5% loss because I don't run P4s. 
Rolling my own kernel is one thing...having to rebuild everything on all
my boxes isn't...I might as well go back to LFS or Gentoo if this is the
case.

It would be interesting to know the ratio of P4 to K7 Fedora users to
determine if this optimization is a great idea since this thread implies
that it would require more resources that RH is willing to apply to also
give us K7 optimized RPMs...or is the logic because corporate America
continues to be sucked in by Intel's marketing?  While I have no doubt
that Intel dominates the RHEL market, I do wonder if the same can be
said for the Fedora community.


KAS






From ijuma82 at f2s.com  Mon May 31 15:46:49 2004
From: ijuma82 at f2s.com (Ismael Juma)
Date: Mon, 31 May 2004 16:46:49 +0100
Subject: Why are there only i686 and i586 Version of glibc and kernel?
In-Reply-To: <20040531133936.GJ4736@devserv.devel.redhat.com>
References: <40BADD1C.4030205@feuerpokemon.de>
	<20040531133936.GJ4736@devserv.devel.redhat.com>
Message-ID: <40BB5369.9060306@f2s.com>

Jakub Jelinek wrote:
> On Mon, May 31, 2004 at 09:22:04AM +0200, dragoran wrote:
> 
>>Why not add a glibc and kernel which are optimized for pentium 4 in FC3 
>>? This would increase the perfomance on newer PC but also works on older 
>>ones by still including the i686 and i586 versions.
> 
> 
> Starting with FC3, .i386.rpm and .i686.rpm packages will be compiled
> with -march{3,6}86 -mtune=pentium4, so although they will run on
> i386 (resp. i686), they will be optimized for P4 (Athlons and newer AMD
> chips run P4 optimized code without noticeable performance hit).
> 
> 	Jakub
> 
> 

Out of curiosity, how do those optimisations affect Pentium M processors?

Regards,
Ismael




From arjanv at redhat.com  Mon May 31 16:15:07 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Mon, 31 May 2004 18:15:07 +0200
Subject: Why are there only i686 and i586 Version of glibc and kernel?
In-Reply-To: <1086018080.30305.43.camel@neptune>
References: <40BADD1C.4030205@feuerpokemon.de>
	<20040531133936.GJ4736@devserv.devel.redhat.com>
	<200405311650.59528.rezso@rdsor.ro>
	<20040531141026.GK4736@devserv.devel.redhat.com>
	<1086018080.30305.43.camel@neptune>
Message-ID: <1086020106.2708.6.camel@laptop.fenrus.com>


> I think it is only fair that someone quantify the performance hit that
> K7 and 32bit K8 users can expect versus the improvement that P4 users
> will see before this is implemented.

The biggest change is NOT using a few forms of instructions (INC/DEC
hurt p4's while ADD/SUB by one are fast), AMD cpus seem to not care
really which form is chosen, it seens AMD optimizes in the cpu beyond
this level. You'll be *really* hard pressed to find (artificial)
examples where this would slow down AMD cpus even 0.1%....
-------------- 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/20040531/f7473231/attachment.sig>

From zleite at mminternet.com  Mon May 31 17:05:41 2004
From: zleite at mminternet.com (Z)
Date: Mon, 31 May 2004 10:05:41 -0700
Subject: The return of the acute-cedilla problem
In-Reply-To: <orn03qno5q.fsf@livre.redhat.lsd.ic.unicamp.br>
References: <40A67456.2010703@pl.jaring.my>
	<1085044931.21879.19.camel@max.localdomain>
	<40AE37BA.3000509@pl.jaring.my>
	<1085357981.3935.11.camel@Curran415>
	<20040524170408.GB19161@devserv.devel.redhat.com>
	<20040524195912.GG18881@rednote.net>
	<604aa79104052413124388efd9@mail.gmail.com>
	<20040524215310.GJ18881@rednote.net> <1085453830.4695.7.camel@z>
	<oraczwilj6.fsf@free.redhat.lsd.ic.unicamp.br>
	<1085867275.15316.15.camel@z>
	<orn03qno5q.fsf@livre.redhat.lsd.ic.unicamp.br>
Message-ID: <1086023141.13992.6.camel@z>

On Sun, 2004-05-30 at 04:35, Alexandre Oliva wrote:

> I've just started OOo within a en_US.UTF-8 locale and US International
> keyboard compose rules, and 'c does generate ?, like everywhere else.
> Ditto if I start it as LANG=pt_BR.UTF-8 ooffice within my en_US.UTF-8
> X session.  This if FC2, BTW.

Mine was inadvertently set to en_US. Oops, sorry :-( .





From alan at redhat.com  Mon May 31 18:30:00 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 31 May 2004 14:30:00 -0400
Subject: submount?
In-Reply-To: <1085997727.18691.29.camel@tux.fubar.dk>
References: <200405241448.14725.ndbecker2@verizon.net>
	<c8uppe$k1o$1@sea.gmane.org>
	<1085468198.2783.4.camel@laptop.fenrus.com>
	<20040525072308.GC5395@devserv.devel.redhat.com>
	<1085997727.18691.29.camel@tux.fubar.dk>
Message-ID: <20040531183000.GB22379@devserv.devel.redhat.com>

On Mon, May 31, 2004 at 12:02:07PM +0200, David Zeuthen wrote:
> I've just put some code in HAL to detect whether the eject button is
> pressed (using MMC-2) so ideally HAL would relay this to gnome-vfs which
> would emit a PreUnmount signal such that apps closes their files and
> then it can do the unmount(1), eject(1) dance. Thing is, I don't know
> how many drives correctly implement this MMC-2 bit, any insight?

My Dad has an HP drive that does. Its the only one I've ever seen

> Maybe it would be smarter to get HAL to use some of the volumagic code
> [1], since I guess a similar technique can be used for partitions on a
> USB drive to give safe removal when the drive is not in use. Would this
> be a good idea? Or are there kernel changes on the horizon to solve all
> of these problems?

Volumagic takes a very different approach to the entire problem. Basically
it looks like this

	/mnt/cdrom <---NFS--->volumagic daemon <--mount on demand--> CD iso fs

It uses the unfsd code which has path persistant handles for a given volume so
works even with the CD being mounted and unmounted by the nfs/volumagic daemon.

I wrote it as a hack after Al Viro reckoned it could be done that way just
to evaluate the idea. Really the same logic needs to be more kernel side so
that streaming file I/O bypasses the mount daemon logic.





From david at fubar.dk  Mon May 31 18:53:44 2004
From: david at fubar.dk (David Zeuthen)
Date: Mon, 31 May 2004 20:53:44 +0200
Subject: submount?
In-Reply-To: <20040531183000.GB22379@devserv.devel.redhat.com>
References: <200405241448.14725.ndbecker2@verizon.net>
	<c8uppe$k1o$1@sea.gmane.org>
	<1085468198.2783.4.camel@laptop.fenrus.com>
	<20040525072308.GC5395@devserv.devel.redhat.com>
	<1085997727.18691.29.camel@tux.fubar.dk>
	<20040531183000.GB22379@devserv.devel.redhat.com>
Message-ID: <1086029624.21702.33.camel@tux.fubar.dk>

On Mon, 2004-05-31 at 20:30, Alan Cox wrote:
> On Mon, May 31, 2004 at 12:02:07PM +0200, David Zeuthen wrote:
> > I've just put some code in HAL to detect whether the eject button is
> > pressed (using MMC-2) so ideally HAL would relay this to gnome-vfs which
> > would emit a PreUnmount signal such that apps closes their files and
> > then it can do the unmount(1), eject(1) dance. Thing is, I don't know
> > how many drives correctly implement this MMC-2 bit, any insight?
> 
> My Dad has an HP drive that does. Its the only one I've ever seen
> 

The only one you seen that it works on? Really? I'm talking about this
piece of code

http://www.ussg.iu.edu/hypermail/linux/kernel/0202.0/att-0603/01-cd_poll.c

FWIW, it works on my Liteon CDRW drive (only drive I tested). Jens
Axboe, seems a bit more confident in the availability of this

http://www.uwsg.iu.edu/hypermail/linux/kernel/0308.3/0511.html

so much in fact that he, uhmm, thinks magicdev should use it.

Thanks,
David




From alan at redhat.com  Mon May 31 18:52:27 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 31 May 2004 14:52:27 -0400
Subject: Why are there only i686 and i586 Version of glibc and kernel?
In-Reply-To: <1086020106.2708.6.camel@laptop.fenrus.com>
References: <40BADD1C.4030205@feuerpokemon.de>
	<20040531133936.GJ4736@devserv.devel.redhat.com>
	<200405311650.59528.rezso@rdsor.ro>
	<20040531141026.GK4736@devserv.devel.redhat.com>
	<1086018080.30305.43.camel@neptune>
	<1086020106.2708.6.camel@laptop.fenrus.com>
Message-ID: <20040531185227.GH22379@devserv.devel.redhat.com>

On Mon, May 31, 2004 at 06:15:07PM +0200, Arjan van de Ven wrote:
> hurt p4's while ADD/SUB by one are fast), AMD cpus seem to not care
> really which form is chosen, it seens AMD optimizes in the cpu beyond
> this level. You'll be *really* hard pressed to find (artificial)
> examples where this would slow down AMD cpus even 0.1%....

Likewise my own testing has always found that the Athlon really doesn't care
much how you order instructions. If you think about it AMD have spent years
dealing with everyone optimising for random intel processor of the year and
adapted appropriately. Except on things like 3dnow and prefetch stuff the
AMD really doesn't seem to care.





From alan at redhat.com  Mon May 31 18:55:27 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 31 May 2004 14:55:27 -0400
Subject: submount?
In-Reply-To: <1086029624.21702.33.camel@tux.fubar.dk>
References: <200405241448.14725.ndbecker2@verizon.net>
	<c8uppe$k1o$1@sea.gmane.org>
	<1085468198.2783.4.camel@laptop.fenrus.com>
	<20040525072308.GC5395@devserv.devel.redhat.com>
	<1085997727.18691.29.camel@tux.fubar.dk>
	<20040531183000.GB22379@devserv.devel.redhat.com>
	<1086029624.21702.33.camel@tux.fubar.dk>
Message-ID: <20040531185527.GI22379@devserv.devel.redhat.com>

On Mon, May 31, 2004 at 08:53:44PM +0200, David Zeuthen wrote:
> FWIW, it works on my Liteon CDRW drive (only drive I tested). Jens
> Axboe, seems a bit more confident in the availability of this
> 
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0308.3/0511.html
> 
> so much in fact that he, uhmm, thinks magicdev should use it.

If it works sure. Ultimately I'd like to find a clean way to do a volumagic
like thing with the I/O layer in kernel space. Let the daemon do handle
translations and let the kernel do the I/O paths




From david at fubar.dk  Mon May 31 19:18:40 2004
From: david at fubar.dk (David Zeuthen)
Date: Mon, 31 May 2004 21:18:40 +0200
Subject: submount?
In-Reply-To: <20040531185527.GI22379@devserv.devel.redhat.com>
References: <200405241448.14725.ndbecker2@verizon.net>
	<c8uppe$k1o$1@sea.gmane.org>
	<1085468198.2783.4.camel@laptop.fenrus.com>
	<20040525072308.GC5395@devserv.devel.redhat.com>
	<1085997727.18691.29.camel@tux.fubar.dk>
	<20040531183000.GB22379@devserv.devel.redhat.com>
	<1086029624.21702.33.camel@tux.fubar.dk>
	<20040531185527.GI22379@devserv.devel.redhat.com>
Message-ID: <1086031120.21702.40.camel@tux.fubar.dk>

On Mon, 2004-05-31 at 20:55, Alan Cox wrote:
> On Mon, May 31, 2004 at 08:53:44PM +0200, David Zeuthen wrote:
> > FWIW, it works on my Liteon CDRW drive (only drive I tested). Jens
> > Axboe, seems a bit more confident in the availability of this
> > 
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0308.3/0511.html
> > 
> > so much in fact that he, uhmm, thinks magicdev should use it.
> 
> If it works sure. Ultimately I'd like to find a clean way to do a volumagic
> like thing with the I/O layer in kernel space. Let the daemon do handle
> translations and let the kernel do the I/O paths
> 

Wouldn't it suffice with just an option to mount(1), e.g. have as few
changes to how this impact user space as possible. I mean, at the end of
the day, isn't this just about the kernel locking/unlocking the drive
(same for e.g. USB storage) only when there is I/O?

Thanks,
David




From alan at redhat.com  Mon May 31 19:30:12 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 31 May 2004 15:30:12 -0400
Subject: submount?
In-Reply-To: <1086031120.21702.40.camel@tux.fubar.dk>
References: <200405241448.14725.ndbecker2@verizon.net>
	<c8uppe$k1o$1@sea.gmane.org>
	<1085468198.2783.4.camel@laptop.fenrus.com>
	<20040525072308.GC5395@devserv.devel.redhat.com>
	<1085997727.18691.29.camel@tux.fubar.dk>
	<20040531183000.GB22379@devserv.devel.redhat.com>
	<1086029624.21702.33.camel@tux.fubar.dk>
	<20040531185527.GI22379@devserv.devel.redhat.com>
	<1086031120.21702.40.camel@tux.fubar.dk>
Message-ID: <20040531193012.GA10552@devserv.devel.redhat.com>

On Mon, May 31, 2004 at 09:18:40PM +0200, David Zeuthen wrote:
> > If it works sure. Ultimately I'd like to find a clean way to do a volumagic
> > like thing with the I/O layer in kernel space. Let the daemon do handle
> > translations and let the kernel do the I/O paths
> 
> Wouldn't it suffice with just an option to mount(1), e.g. have as few
> changes to how this impact user space as possible. I mean, at the end of
> the day, isn't this just about the kernel locking/unlocking the drive
> (same for e.g. USB storage) only when there is I/O?

To do it properly you need a bit more because users may change CD-ROMs and you
probably want to do "Please insert 'Install Disk 2'" type dialogs. 

Internally the kernel really doesn't deal with disks going away when they are
wanted. Volumagic can cope with

	cd /mnt/cdrom
	eject
	insert new cd
	ls

and also with requests when the disk is removed - not all file systems handle
media vanishing as a routine thing.

Stephen Tweedie had some 2.2 patches "supermount" which tried to address this
whole thing properly and while there have been 2.4 and 2.6 attempts I've not
seen one that addresses it all cleanly. 




From david at fubar.dk  Mon May 31 19:54:56 2004
From: david at fubar.dk (David Zeuthen)
Date: Mon, 31 May 2004 21:54:56 +0200
Subject: submount?
In-Reply-To: <20040531193012.GA10552@devserv.devel.redhat.com>
References: <200405241448.14725.ndbecker2@verizon.net>
	<c8uppe$k1o$1@sea.gmane.org>
	<1085468198.2783.4.camel@laptop.fenrus.com>
	<20040525072308.GC5395@devserv.devel.redhat.com>
	<1085997727.18691.29.camel@tux.fubar.dk>
	<20040531183000.GB22379@devserv.devel.redhat.com>
	<1086029624.21702.33.camel@tux.fubar.dk>
	<20040531185527.GI22379@devserv.devel.redhat.com>
	<1086031120.21702.40.camel@tux.fubar.dk>
	<20040531193012.GA10552@devserv.devel.redhat.com>
Message-ID: <1086033296.21702.52.camel@tux.fubar.dk>

On Mon, 2004-05-31 at 21:30, Alan Cox wrote:
> > Wouldn't it suffice with just an option to mount(1), e.g. have as few
> > changes to how this impact user space as possible. I mean, at the end of
> > the day, isn't this just about the kernel locking/unlocking the drive
> > (same for e.g. USB storage) only when there is I/O?
> 
> To do it properly you need a bit more because users may change CD-ROMs and you
> probably want to do "Please insert 'Install Disk 2'" type dialogs. 
> 
> Internally the kernel really doesn't deal with disks going away when they are
> wanted. Volumagic can cope with
> 
> 	cd /mnt/cdrom
> 	eject
> 	insert new cd
> 	ls
> 
> and also with requests when the disk is removed - not all file systems handle
> media vanishing as a routine thing.
> 

In my, possibly uninformed, opinion it would be nicest if optical discs
just appeared to the user like the other block devices out there e.g.

 /sys/block/hdc
 /sys/block/hdc/hdc1

Then your change notification would just be a hotplug event. Further,
for a mixed CD-ROM disc you would also have

 /sys/block/hdc/hdc2 

so you can access the data and audio parts simultaneously. This works on
Mac OS X, though the drive makes a lot of noise. I'm not sure how to
achieve this on Linux.

David





From bilbo13 at campus.ctcolonies.com  Mon May 31 19:49:11 2004
From: bilbo13 at campus.ctcolonies.com (Joseph Hurst/BILBO13)
Date: Mon, 31 May 2004 14:49:11 -0500
Subject: Not sure where to post this message
Message-ID: <001c01c44748$5895db90$6501a8c0@Laptop>

Hello,

    I'm not exactly sure where to post this message. So I thought that since this is a developers group that it might be a decent place to start.


    I'm wanting to find information about a newsletter for Fedora Core if there is one or not. I would like to help work on it if there is or if there isn't, I'd like to help get it started. I'm also considering making a fedora core website. Not an official fedora website but a site that has documents and downloads and such. 

    If there is anyone out there that can give me the information that I need please email me.


Best Regards,
Joseph Hurst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040531/1f96d757/attachment.htm>

From alan at redhat.com  Mon May 31 20:18:13 2004
From: alan at redhat.com (Alan Cox)
Date: Mon, 31 May 2004 16:18:13 -0400
Subject: Not sure where to post this message
In-Reply-To: <001c01c44748$5895db90$6501a8c0@Laptop>
References: <001c01c44748$5895db90$6501a8c0@Laptop>
Message-ID: <20040531201813.GC25502@devserv.devel.redhat.com>

On Mon, May 31, 2004 at 02:49:11PM -0500, Joseph Hurst/BILBO13 wrote:
> Hello,
> 
>     I'm not exactly sure where to post this message. So I thought that since this is a developers group that it might be a decent place to start.

Is http://www.fedoranews.org what you are looking for  ?




From bilbo13 at campus.ctcolonies.com  Mon May 31 20:21:27 2004
From: bilbo13 at campus.ctcolonies.com (Joseph Hurst)
Date: Mon, 31 May 2004 15:21:27 -0500
Subject: Not sure where to post this message
References: <001c01c44748$5895db90$6501a8c0@Laptop>
	<20040531201813.GC25502@devserv.devel.redhat.com>
Message-ID: <002f01c4474c$da513c20$6501a8c0@Laptop>

Yes that covers the news part of my question.
----- Original Message ----- 
From: "Alan Cox" <alan at redhat.com>
To: "Development discussions related to Fedora Core"
<fedora-devel-list at redhat.com>
Sent: Monday, May 31, 2004 3:18 PM
Subject: Re: Not sure where to post this message


> On Mon, May 31, 2004 at 02:49:11PM -0500, Joseph Hurst/BILBO13 wrote:
> > Hello,
> >
> >     I'm not exactly sure where to post this message. So I thought that
since this is a developers group that it might be a decent place to start.
>
> Is http://www.fedoranews.org what you are looking for  ?
>
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>





From b.j.smith at ieee.org  Mon May 31 23:35:22 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Mon, 31 May 2004 19:35:22 -0400
Subject: Why are there only i686 and i586 Version of glibc and kernel?
Message-ID: <1086046522.1330.91.camel@bitman.oviedo.smithconcepts.com>

Alan Cox wrote:  
> Likewise my own testing has always found that the Athlon really
> doesn't care much how you order instructions. If you think about it
> AMD have spent years dealing with everyone optimising for random intel
> processor of the year and adapted appropriately.

I have to agree with Alan on this.  Having assembled Athlon-based
clusters from  Athlon's introduction until a year ago, the i686 (Pentium
Pro) optimizations get you very close, like within 5%, of ideal on
Athlon32.

> Except on things like 3dnow and prefetch stuff the AMD really doesn't
> seem to care.

Plus any floating point. 

Athlon32/Athlon64/Opteron has 3 FPUs, two complex and one simple.

Pentium II to Pentium IV has 2 FPUs, of which you can only do either
one complex (while one is idle) or two simple.

While the Athlon does a lot of run-time optimization via out-of-order
execution and register renaming, the compile-time optimizations can
affect things upto 40%.

But that's more of an application thing -- maybe only a few GLibC calls
(?).

-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org