From mgalvin at nycap.rr.com Thu Apr 1 00:13:59 2004
From: mgalvin at nycap.rr.com (mgalvin at nycap.rr.com)
Date: Wed, 31 Mar 2004 19:13:59 -0500
Subject: FC Dev 1.91 on PPC
Message-ID: <2dad4b2d5e5d.2d5e5d2dad4b@nyroc.rr.com>
So I d/l'd the FC Dev boot.iso for PPC. I am trying to get FC running
on my Mac. I was able to boot from the CD i created from this iso...
but for some reason the keyboard doesn't work, or better yet, the
boot image doesn't recgognize my keyboard. Its a regular Mac USB
keyboard, and I my box is a Dual G4 500 "GigE" PM. I also could
not find a ppc-list so i am posting here in hopes that someone has
had a similar issues.
Any help is greatly appreciated
Thanks in advance
-------------------------
M Galvin
Lead Programmer
Simplified Complexity
http://www.simplifiedcomplexity.com
From dax at gurulabs.com Thu Apr 1 00:48:37 2004
From: dax at gurulabs.com (Dax Kelson)
Date: Wed, 31 Mar 2004 17:48:37 -0700
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080772701.3848.96.camel@localhost.localdomain>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
Message-ID: <1080780517.2783.32.camel@mentor.gurulabs.com>
On Wed, 2004-03-31 at 15:38, Havoc Pennington wrote:
> Hi,
>
> A possibly related discussion; we've been wondering if we can make the
> OS image read-only (mounting it that way, or via selinux).
>
> Then have /tmp and probably /var in RAM (or wiped on boot), and have
> home directories and server/app data such as web pages to be served on
> network mounts.
>
> This allows you to maintain the OS image in a central location and the
> homedirs and server/app data in central locations, and have a single
> network-wide master copy of all important state.
>
> Any filesystem rearrangement probably impacts this plan (some
> rearrangement may be needed for this plan).
You need to talk to the kernel guys to get this workable. The file
/etc/mtab will bite you.
Having it be a symlink to /proc/mounts is not sufficient.
The /etc/mtab file is where the mount options are stored. This is
something that /proc/mounts doesn't have (other than rw/ro).
Additionally, /proc/mounts has non-meaningful entries like:
rootfs / rootfs rw 0 0
/dev/root / ext3 rw 0 0
It would be nice to get this fixed (incidentally Solaris does this
correctly). Go bug Al Viro :)
Dax Kelson
Guru Labs
From mattdm at mattdm.org Thu Apr 1 02:45:55 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 31 Mar 2004 21:45:55 -0500
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080772701.3848.96.camel@localhost.localdomain>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
Message-ID: <20040401024555.GA11706@jadzia.bu.edu>
On Wed, Mar 31, 2004 at 05:38:21PM -0500, Havoc Pennington wrote:
> Then have /tmp and probably /var in RAM (or wiped on boot), and have
> home directories and server/app data such as web pages to be served on
> network mounts.
Once there's in kernel AFS with caching support....
--
Matthew Miller mattdm at mattdm.org
Boston University Linux ------>
From jkeating at j2solutions.net Thu Apr 1 04:45:59 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 31 Mar 2004 22:45:59 -0600
Subject: FC Dev 1.91 on PPC
In-Reply-To: <2dad4b2d5e5d.2d5e5d2dad4b@nyroc.rr.com>
References: <2dad4b2d5e5d.2d5e5d2dad4b@nyroc.rr.com>
Message-ID: <200403312245.59509.jkeating@j2solutions.net>
On Wednesday 31 March 2004 18:13, mgalvin at nycap.rr.com wrote:
> So I d/l'd the FC Dev boot.iso for PPC. I am trying to get FC running
> on my Mac. I was able to boot from the CD i created from this iso...
> but for some reason the keyboard doesn't work, or better yet, the
> boot image doesn't recgognize my keyboard. Its a regular Mac USB
> keyboard, and I my box is a Dual G4 500 "GigE" PM. I also could
> not find a ppc-list so i am posting here in hopes that someone has
> had a similar issues.
>
> Any help is greatly appreciated
The ppc isn't for mac, it's for IBM ppc stuff. There is an effort to get
fedora running on mac, and their list is hosted by the YDL folks:
http://lists.ydl.net/mailman/listinfo/fedora-ppc
--
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 jamethknorth at hotmail.com Thu Apr 1 05:10:05 2004
From: jamethknorth at hotmail.com (Jamethiel Knorth)
Date: Thu, 01 Apr 2004 00:10:05 -0500
Subject: [RFC] User Accesable Filesystem Hierarchy Standard
Message-ID:
>From: Robert Marcano
>Date: Wed, 31 Mar 2004 16:51:55 -0400
>
>On Wed, 2004-03-31 at 15:47, Gary L Greene Jr wrote:
>
> > On Saturday 27 March 2004 06:05 pm, Robert Marcano wrote:
>...
> > >
> > > I am sure that the filesystem can be arranged in order to make it more
> > > easy to use to the desktop user, Your ideas of a shared directory is
> > > nice, but letting the user "Easily install software without escalating
> > > their privileges" is something that I don't like. The only way that I
> > > like a shared directory is if it is mounted from a filesystem with the
> > > "noexec" flag.
> > >
> > > I think that the software installation can be made easy with the help
>of
> > > a better "Add/Remove Programs", and the security aspect could be
> > > enhanced with the help of a SELinux policy for this program(s) (I am
>not
> > > an expert in SELinux, so I could be wrong)
> >
> > The problem with adding software installation only through the root
> > directories is that you still need to have root privileges to install a
> > program. This proposal is to allow people to install programs, but not
>as
> > root. This adds no new abilities. None. It just makes it easier.
>Already,
> > people can install any program in their home directory, it is just a lot
>of
> > hassle. This is just a way to organize it.
>
>For what I have learned of SELinux, I think that it could be used to
>give special privileges to certain processes (for example the Add/Remove
>programs of the distribution) to do whatever it wants on the system by
>defining the appropriate SELinux policy. For example the policy can
>allow to a program to install new files on /usr/{bin,lib,share,...} or
>update the files of a previously installed version of the application
>without asking any root credentials to some users of the system, or all
>if wanted. This is the more secure way I think it can be done
SELinux is a tool with the ability to provide a secure way to access other
directories. However, this is not a Linux standard in particular. If it is
intended to be a standard, it needs to support any system which uses a
hierarchal filesystem in the usual Unix manner. However much I like
SELinux's abilities, that seems to be an extension which needs to be added
by a distribution.
>... continues ...
>
> > The purpose is for home installation. Here is a sample setup: I have a
> > computer used by four people. I own it and want to run it. I want to
>allow
> > the other people to install programs without asking me. This lets them
>do
> > installations without needing to be root.
> >
> > This doesn't pose a security issue because the programs installed thus
>do not
> > have higher privileges than those of the user that installed them.
> >
> > This will in fact improve security on many home installations because
>users
> > will not need to be constantly entering their root password and will be
>less
> > likely to just turn the root password off.
>
>Leaving to another time my differences with your proposal ;-), I think
>that you must add to your document information about the search order of
>the PATH, LD_LIBRARY_PATH, etc. You can include for example that for
>security reasons it is mandatory that the system libraries and
>executables need to be loaded before any user installed ones; or the
>other way: in order to allow the upgrade of system installed
>applications the search path is reversed to allow that. What the
>standard will recommend? changes to LD implementation in order to allow
>the load of the user installed shared libraries. or the usage of the
>environment variable LD_LIBRARY_PATH
Interestingly enough, the order of items in the PATH and LD_LIBRARY_PATH are
not part of the previous FHS standard and I see no reason to standardize
them in an extension. This merely deals with the directory layout. That is a
separate level which might need a separate standard of its own.
>Do you know that a lot of user oriented applications store files on
>/usr/share (and others)?, and that directory is defined at compile time
>(nearly on every application that uses it), so you will need to build
>the application specially for the directory you are deploying, and on
>"home installations" the users will not build their custom versions
I was under the impression, from personal experience, that almost all of
them define a $PREFIX and can use any share which is appropriate to that
prefix. Moving the directories into a format more like '~/.system/bin/'
would give a full set of standard directories to install to, just as is
currently available to allow installation into several areas.
Although some binary distributions may not support this, that is
unavoidable. It is supportable, and they should support it, and there is
little that can be done if they do not. (If there is a work around, please
inform me.)
>
> > Also, note that this is not intended for server installs, as is stated
>in the
> > proposal.
> >
> > Thank you for the feedback.
>
>Hope this helps
>
>--
>Robert Marcano
_________________________________________________________________
Get rid of annoying pop-up ads with the new MSN Toolbar ? FREE!
http://toolbar.msn.com/go/onm00200414ave/direct/01/
From ckloiber at redhat.com Thu Apr 1 05:18:33 2004
From: ckloiber at redhat.com (Chris Kloiber)
Date: Thu, 01 Apr 2004 13:18:33 +0800
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080738195.869.0.camel@teapot.felipe-alfaro.com>
References: <1080687441.10735.55.camel@opus>
<1080688557.1212.3.camel@shahms.mesd.k12.or.us>
<1080738195.869.0.camel@teapot.felipe-alfaro.com>
Message-ID: <1080796713.7795.0.camel@roadrash.rdu.redhat.com>
On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote:
> On Wed, 2004-03-31 at 01:15, Shahms King wrote:
>
> > > /media - all the removable media and silliness there.
> >
> > And why isn't /mnt adequate for removable media?
>
> I don't think /mnt has anything wrong with it, but FHS specifies that
> /media is a better name for a removable device and indeed, /media is
> what SuSE uses.
If SuSe decides to jump off the Brooklyn Bridge, are we expected to
blindly follow?
--
Chris Kloiber, RHCX
Red Hat, Inc.
From dburcaw at terrasoftsolutions.com Thu Apr 1 06:19:07 2004
From: dburcaw at terrasoftsolutions.com (Dan Burcaw)
Date: Wed, 31 Mar 2004 23:19:07 -0700
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080796713.7795.0.camel@roadrash.rdu.redhat.com>
References: <1080687441.10735.55.camel@opus>
<1080688557.1212.3.camel@shahms.mesd.k12.or.us>
<1080738195.869.0.camel@teapot.felipe-alfaro.com>
<1080796713.7795.0.camel@roadrash.rdu.redhat.com>
Message-ID: <1080800347.21566.24.camel@skyfox.terraplex.com>
On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote:
> On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote:
> > On Wed, 2004-03-31 at 01:15, Shahms King wrote:
> >
> > > > /media - all the removable media and silliness there.
> > >
> > > And why isn't /mnt adequate for removable media?
> >
> > I don't think /mnt has anything wrong with it, but FHS specifies that
> > /media is a better name for a removable device and indeed, /media is
> > what SuSE uses.
>
> If SuSe decides to jump off the Brooklyn Bridge, are we expected to
> blindly follow?
Is SuSE doing something reason not to do it in Fedora/RHEL, etc?
From warren at togami.com Thu Apr 1 06:13:24 2004
From: warren at togami.com (Warren Togami)
Date: Wed, 31 Mar 2004 20:13:24 -1000
Subject: switchdesk bug?
Message-ID: <406BB304.5040000@togami.com>
I am pretty sure this is a bug, but I don't know enough about how the
desktop starts. I suspect this makes no functional difference?
1) Run switchdesk.
2) Do not change anything, but Click OK.
3) cat .Xclients-default
#! /bin/bash
# Created by Red Hat Desktop Switcher
WMPATH="/usr/bin /opt/bin /usr/local/bin /usr/X11R6/bin"
for wm in $WMPATH ; do
[ -x $wm/startkde ] && exec $wm/startkde
done
exit 1
4) Run switchdesk.
5) Click on KDE, Click on GNOME, Click OK.
6) cat .Xclients-default
# Created by Red Hat Desktop Switcher
exec gnome-session
From fedora-devel at cryptosystem.us Thu Apr 1 07:45:46 2004
From: fedora-devel at cryptosystem.us (Aaron Matteson)
Date: Wed, 31 Mar 2004 23:45:46 -0800
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080800347.21566.24.camel@skyfox.terraplex.com>
References: <1080687441.10735.55.camel@opus>
<1080688557.1212.3.camel@shahms.mesd.k12.or.us>
<1080738195.869.0.camel@teapot.felipe-alfaro.com>
<1080796713.7795.0.camel@roadrash.rdu.redhat.com>
<1080800347.21566.24.camel@skyfox.terraplex.com>
Message-ID: <20040401074546.5766.qmail@mail.avlug.org>
Dan Burcaw became daring and sent these 0.7K bytes,
> On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote:
> > On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote:
> > > On Wed, 2004-03-31 at 01:15, Shahms King wrote:
> > >
> > > > > /media - all the removable media and silliness there.
> > > >
> > > > And why isn't /mnt adequate for removable media?
> > >
> > > I don't think /mnt has anything wrong with it, but FHS specifies that
> > > /media is a better name for a removable device and indeed, /media is
> > > what SuSE uses.
> >
> > If SuSe decides to jump off the Brooklyn Bridge, are we expected to
> > blindly follow?
>
> Is SuSE doing something reason not to do it in Fedora/RHEL, etc?
Now, in english please?
--
0 1 0 Aaron M Matteson - 0xD144B7FF
0 0 1 CCNA
1 1 1 Windows/Linux C++/C# Developer
------------------------------------------------------------------------
The engineer in neither optimist nor pessimist. He sees the proverbial
half-full/empty glass and says, "The glass is twice as big as there is
and need for it to be."
------------------------------------------------------------------------
http://cryptosystem.us/ - Project
http://cryptosystem.us/blog/ - Blog
From nphilipp at redhat.com Thu Apr 1 08:14:34 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Thu, 01 Apr 2004 10:14:34 +0200
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080800347.21566.24.camel@skyfox.terraplex.com>
References: <1080687441.10735.55.camel@opus>
<1080688557.1212.3.camel@shahms.mesd.k12.or.us>
<1080738195.869.0.camel@teapot.felipe-alfaro.com>
<1080796713.7795.0.camel@roadrash.rdu.redhat.com>
<1080800347.21566.24.camel@skyfox.terraplex.com>
Message-ID: <1080807274.3985.31.camel@wombat.tiptoe.de>
On Thu, 2004-04-01 at 08:19, Dan Burcaw wrote:
> On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote:
> > On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote:
> > > On Wed, 2004-03-31 at 01:15, Shahms King wrote:
> > >
> > > > > /media - all the removable media and silliness there.
> > > >
> > > > And why isn't /mnt adequate for removable media?
> > >
> > > I don't think /mnt has anything wrong with it, but FHS specifies that
> > > /media is a better name for a removable device and indeed, /media is
> > > what SuSE uses.
> >
> > If SuSe decides to jump off the Brooklyn Bridge, are we expected to
> > blindly follow?
>
> Is SuSE doing something reason not to do it in Fedora/RHEL, etc?
No, it isn't really, though we have some umm reservations on device
naming, file system naming related stuff when it comes from Nuremberg
;-).
/media being used by SuSE is not a reason to do it nor to not do it. So
it would be best to leave "SuSE does/doesn't do this that way" aside as
an argument.
Nils
--
Nils Philippsen / Red Hat / nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
From arjanv at redhat.com Thu Apr 1 08:27:46 2004
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 01 Apr 2004 10:27:46 +0200
Subject: FC Dev 1.91 on PPC
In-Reply-To: <2dad4b2d5e5d.2d5e5d2dad4b@nyroc.rr.com>
References: <2dad4b2d5e5d.2d5e5d2dad4b@nyroc.rr.com>
Message-ID: <1080808063.4680.5.camel@laptop.fenrus.com>
On Thu, 2004-04-01 at 02:13, mgalvin at nycap.rr.com wrote:
> So I d/l'd the FC Dev boot.iso for PPC. I am trying to get FC running
> on my Mac. I was able to boot from the CD i created from this iso...
> but for some reason the keyboard doesn't work, or better yet, the
> boot image doesn't recgognize my keyboard. Its a regular Mac USB
> keyboard, and I my box is a Dual G4 500 "GigE" PM. I also could
> not find a ppc-list so i am posting here in hopes that someone has
> had a similar issues.
afaik that was a bug in the boot image generator that got fixed
yesterday or so ....
-------------- 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:
From Nicolas.Mailhot at laPoste.net Thu Apr 1 10:03:16 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Thu, 01 Apr 2004 12:03:16 +0200
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080807274.3985.31.camel@wombat.tiptoe.de>
References: <1080687441.10735.55.camel@opus>
<1080688557.1212.3.camel@shahms.mesd.k12.or.us>
<1080738195.869.0.camel@teapot.felipe-alfaro.com>
<1080796713.7795.0.camel@roadrash.rdu.redhat.com>
<1080800347.21566.24.camel@skyfox.terraplex.com>
<1080807274.3985.31.camel@wombat.tiptoe.de>
Message-ID: <1080813795.31656.2.camel@ulysse.olympe.o2t>
Le jeu, 01/04/2004 ? 10:14 +0200, Nils Philippsen a ?crit :
> /media being used by SuSE is not a reason to do it nor to not do it. So
> it would be best to leave "SuSE does/doesn't do this that way" aside as
> an argument.
Well, let people in the know argue for /media if they want it. So far no
one here seems to have understood what it's supposed to win over /mnt.
/srv OTOH seems to have been well received by a sizable part of the
posters - can it go in without being blocked by /media for now ?
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:
From davej at redhat.com Thu Apr 1 10:54:36 2004
From: davej at redhat.com (Dave Jones)
Date: Thu, 01 Apr 2004 11:54:36 +0100
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080772701.3848.96.camel@localhost.localdomain>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
Message-ID: <1080816876.24581.17.camel@delerium.codemonkey.org.uk>
On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
> A possibly related discussion; we've been wondering if we can make the
> OS image read-only (mounting it that way, or via selinux).
If we do this, apt/yum/up2date/rpm will also need smarts to remount rw
when upgrading. Having to do this by hand each time would annoy the hell
out of me enough to just make it permanently rw again.
> Then have /tmp and probably /var in RAM (or wiped on boot)
Errr, if /var/log disappeared, I'd be very annoyed.
Ditto /var/spool. Imagine a scenario where I had a few hundred emails
in /var/spool/mqueue, and for some reason the box locked up.
Right now, I can reboot, and they'll still be there, and I can just
restart the MTA and everything carries on. With your proposal, that
spool is *gone*.
Same is possibly true for other bits of /var too.
> This allows you to maintain the OS image in a central location and the
> homedirs and server/app data in central locations, and have a single
> network-wide master copy of all important state.
This sounds problematic for laptops. Things like AFS sound like a solution,
but from what I've heard about it, I'm not sure I'm ready to trust my
/home to it.
Dave
From db at zigo.dhs.org Thu Apr 1 11:58:57 2004
From: db at zigo.dhs.org (Dennis Bjorklund)
Date: Thu, 1 Apr 2004 13:58:57 +0200 (CEST)
Subject: gphoto2 and libgphoto2
Message-ID:
Is there a reason why gphoto2 and libgphoto2 are in the same package and
not two seperate ones? I'd like a separate libgphoto2 package. The library
is used by more frontends then just gphoto2.
--
/Dennis Bj?rklund
From twaugh at redhat.com Thu Apr 1 12:49:03 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Thu, 1 Apr 2004 13:49:03 +0100
Subject: gphoto2 and libgphoto2
In-Reply-To:
References:
Message-ID: <20040401124903.GV22468@redhat.com>
On Thu, Apr 01, 2004 at 01:58:57PM +0200, Dennis Bjorklund wrote:
> Is there a reason why gphoto2 and libgphoto2 are in the same package
> and not two seperate ones? I'd like a separate libgphoto2
> package. The library is used by more frontends then just gphoto2.
What's the advantage of separating the (tiny) gphoto2 binary out?
Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From hvdkooij at vanderkooij.org Thu Apr 1 13:16:59 2004
From: hvdkooij at vanderkooij.org (Hugo van der Kooij)
Date: Thu, 1 Apr 2004 15:16:59 +0200 (CEST)
Subject: gphoto2 and libgphoto2
In-Reply-To:
References:
Message-ID:
On Thu, 1 Apr 2004, Dennis Bjorklund wrote:
> Is there a reason why gphoto2 and libgphoto2 are in the same package and
> not two seperate ones? I'd like a separate libgphoto2 package. The library
> is used by more frontends then just gphoto2.
gphoto2 is all about libraries. There just happens to be a tiny
implementation that somewhat resembles the old gphoto tool.
Hugo.
--
All email sent to me is bound to the rules described on my homepage.
hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/
Don't meddle in the affairs of sysadmins,
for they are subtle and quick to anger.
From buildsys at redhat.com Thu Apr 1 13:20:48 2004
From: buildsys at redhat.com (Build System)
Date: Thu, 1 Apr 2004 08:20:48 -0500
Subject: rawhide report: 20040401 changes
Message-ID: <200404011320.i31DKmS07826@porkchop.devel.redhat.com>
Updated Packages:
Glide3-20010520-25
------------------
* Wed Jan 22 2003 Tim Powers
- rebuilt
* Fri Dec 20 2002 Mike A. Harris 20010520-24
- Reworded the -devel package description for bug (#79477)
* Mon Nov 25 2002 Mike A. Harris 20010520-23
- Bump and rebuild to pick up Alpha which did not get built in -22 somehow
SDL-1.2.7-3
-----------
* Wed Mar 31 2004 Harald Hoyer - 1.2.7-3
- fixed gcc34 compilation issues
acl-2.2.7-5
-----------
* Wed Mar 31 2004 Stephen C. Tweedie 2.2.7-5
- Add missing %defattr
apr-util-0.9.4-13
-----------------
* Tue Mar 30 2004 Joe Orton 0.9.4-13
- remove fundamentally broken check_sbcs() from xlate code
at-spi-1.4.0-1
--------------
* Wed Mar 31 2004 Mark McLoughlin 1.4.0-1
- Update to 1.4.0
attr-2.4.1-4
------------
* Wed Mar 31 2004 Stephen C. Tweedie 2.4.1-4
- Add missing %defattr
gail-1.6.0-1
------------
* Wed Mar 31 2004 Mark McLoughlin
- Update to 1.6.0
gconf-editor-2.6.0-1
--------------------
* Wed Mar 31 2004 Mark McLoughlin 2.6.0-1
- Update to 2.6.0
gdb-6.0post-0.20040223.8
------------------------
* Sun Mar 21 2004 Elena Zannoni 0.20040223.8
- Add support for debugging of PIE executables.
* Tue Mar 09 2004 Elena Zannoni 0.20040223.7
- Bump version number.
* Mon Mar 08 2004 Jeff Johnston 0.20040223.6
- Fix thread support to recognize new threads even when they reuse
tids of expired threads. Also ensure that terminal is held by gdb
while determining if a thread-create event has occurred.
gedit-2.6.0-1
-------------
* Wed Mar 31 2004 Dan Williams 1:2.6.0-1
- Update to gedit-2.6.0 sources
gimp-print-4.2.6-11
-------------------
* Wed Mar 31 2004 Tim Waugh 4.2.6-11
- Rebuilt.
* Thu Mar 18 2004 Nils Philippsen 4.2.6-10
- Rebuild against new gimp.
gnome-desktop-2.6.0.1-1
-----------------------
* Wed Mar 31 2004 Mark McLoughlin 2.6.0.1-1
- Update to 2.6.0.1
gnome-mag-0.10.10-1
-------------------
* Wed Mar 31 2004 Mark McLoughlin 0.10.10-1
- Update to 0.10.10
gnome-panel-2.6.0-1
-------------------
* Wed Mar 31 2004 Mark McLoughlin 2.6.0-1
- Update to 2.6.0
gnome-session-2.6.0-1
---------------------
* Wed Mar 31 2004 Mark McLoughlin 2.6.0-1
- Update to 2.6.0
gnome-terminal-2.6.0-1
----------------------
* Wed Mar 31 2004 Mark McLoughlin 2.6.0-1
- Update to 2.6.0
gnome-themes-2.6.0-1
--------------------
* Wed Mar 31 2004 Mark McLoughlin 2.6.0-1
- Update to 2.6.0
gnopernicus-0.8.1-1
-------------------
* Wed Mar 31 2004 Mark McLoughlin 0.8.1-1
- Update to 0.8.1
gok-0.9.11-1
------------
* Wed Mar 31 2004 Mark McLoughlin 0.9.11-1
- Update to 0.9.11
gpm-1.20.1-46
-------------
* Wed Mar 31 2004 Adrian Havill 1.20.1-46
- revise nodebug patch as liblow reporting the VC to the console through
stderr has re-appeared (#117676)
gstreamer-plugins-0.8.0-3
-------------------------
* Wed Mar 31 2004 Colin Walters 0.8.0-3
- Second attempt at rebuild to pick up new libdv
gtkam-0.1.10-4
--------------
* Wed Mar 31 2004 Nils Philippsen 0.1.10-4
- rebuilt
* Thu Mar 18 2004 Nils Philippsen 0.1.10-3
- rebuilt
httpd-2.0.49-2
--------------
* Fri Mar 26 2004 Joe Orton 2.0.49-2
- mod_ssl: fix session cache memory leak (Madhu Mathihalli)
- mod_ssl: fix SEGV when trying to shutdown during pool cleanup
- merge the mod_proxy HTTP/1.1-compliance fixes
- apply fix for #118020
kinput2-v3.1-18
---------------
* Tue Mar 23 2004 Akira TAGOH v3.1-18
- rebuilt to satisfy the dependency.
* Wed Feb 18 2004 Akira TAGOH v3.1-16
- kinput2-v3.1-activate_im_with_kanji.patch: applied to activate the input method against Kanji key.
- kinput2-v3.1-jp106_xfer.patch: applied to support Henkan key.
* Fri Feb 13 2004 Elliot Lee
- rebuilt
kon2-0.3.9b-22
--------------
* Wed Mar 31 2004 Akira TAGOH 0.3.9b-22
- kon2-0.3.9b-unix98pty.patch: applied to support Unix98 PTY. (FC2 BLOCKER #119426)
kudzu-1.1.54-1
--------------
* Thu Apr 01 2004 Bill Nottingham - 1.1.54-1
- fix overrun in usb code (#119654)
- fix use-after-free in network code (#119655, )
* Wed Mar 24 2004 Bill Nottingham
- mouse configuration fixes
libwnck-2.6.0.1-1
-----------------
* Wed Mar 31 2004 Mark McLoughlin 2.6.0.1-1
- Update to 2.6.0.1
man-1.5m2-6
-----------
* Wed Mar 31 2004 Adrian Havill 1.5m2-6
- reorder MANSECT so that normal pages (with translations) take
precedence over the English-only POSIX pages (#119554)
nvi-m17n-1.79-20011024.19
-------------------------
* Thu Apr 01 2004 Akira TAGOH 1.79-20011024.19
- rebuilt to satisfy the dependency.
* Fri Feb 13 2004 Elliot Lee 1.79-20011024.18
- rebuilt
* Mon Feb 09 2004 Akira TAGOH 1.79-20011024.17
- nvi-1.79-fix-gcc-warnings.patch: applied to fix gcc warnings. (#115194)
octave-2.1.50-9
---------------
* Tue Mar 30 2004 Karsten Hopp 2.1.50-9
- remove builddir references from file list (#119112)
policy-1.9.2-1
--------------
* Wed Mar 31 2004 Dan Walsh 1.9.1-6
- Turn on policy.16
- Fix userhelper
* Wed Mar 31 2004 Dan Walsh 1.9.1-5
- Add postfix fix
policycoreutils-1.9-19
----------------------
* Mon Mar 29 2004 Dan Walsh 1.9-19
- Fix sestatus to not double free
- Fix sestatus.conf to be unix format
postfix-2.0.18-4
----------------
* Wed Mar 31 2004 John Dennis 2:2.0.18-4
- remove version from pflogsumm subpackage, it was resetting the
version used in the doc directory, fixes bug 119213
rpm-4.3.1-0.1
-------------
* Tue Mar 30 2004 Jeff Johnson 4.3.1-0.1
- fix: don't add leading space to %* argv expansion (#119059).
- scareMem = 0 everywhere, document deprecation phase out.
- fix: add u+w to FIXPERMS.
- add buildtime to rpmds, methods to retrieve.
- python: hide labelCompare() underneath ds.cmp(a,b).
rpmdb-fedora-1.91-0.20040401
----------------------------
sendmail-8.12.11-4.2
--------------------
* Wed Mar 31 2004 Thomas Woerner 8.12.11-4.2
- fixed spec file
* Wed Mar 31 2004 Thomas Woerner 8.12.11-4.1
- added authinfo to possible sendmail maps: /etc/mail/Makefile (#119010)
- fixed minor version in changelog
* Wed Mar 17 2004 Thomas Woerner 8.12.11-4
- new slave in alternatives for sendmail man page
skkinput-2.06.4-3
-----------------
* Mon Feb 16 2004 Jens Petersen - 2.06.4-3
- own man and app-defaults dirs (Enrico Scholz)
- install binary and manpages under /usr rather than /usr/X11R6 (mharris)
- don't need to gzip ja manpage
sudo-1.6.7p5-24
---------------
* Tue Mar 30 2004 Colin Walters 1.6.7p5-24
- Enhance sesh.c to fork/exec children itself, to avoid
having sudo reap all domains.
- Only reinstall default signal handlers immediately before
exec of child with SELinux patch
system-config-httpd-1.2.0-3
---------------------------
system-config-users-1.2.11-1
----------------------------
* Wed Mar 31 2004 Brent Fox 1.2.11-1
- first stab at SELinux bits
* Wed Mar 24 2004 Brent Fox 1.2.10-1
- reset user home dir check button (bug #119068)
* Tue Feb 03 2004 Brent Fox 1.2.9-1
- remove comparison to gtk.TRUE (bug #114266)
tcpdump-3.8.2-2
---------------
* Wed Mar 31 2004 Harald Hoyer - 14:3.8.2-2
- update to libpcap-0.8.3 (tcpdump-3.8.3 seems to be older that 3.8.2!!)
ttfprint-0.9-12
---------------
* Thu Apr 01 2004 Leon Ho
- fix for cast-as-lvalue (law at redhat.com)
usermode-1.70-1
---------------
* Wed Mar 31 2004 Nalin Dahyabhai 1.70-1
- fix accidental mixup of role and type setting up new selinux context
- log the new selinux context if we're running an app in a new selinux context
vnc-4.0-1.beta4.10
------------------
* Wed Mar 31 2004 Tim Waugh 4.0-1.beta4.10
- Back down to XFree86 again, since the Xvnc binary in 4.0-1.beta4.9 doesn't
work at all.
xsane-0.92-9
------------
* Wed Mar 31 2004 Tim Waugh 0.92-9
- Rebuilt.
* Thu Mar 18 2004 Nils Philippsen 0.92-8
- Rebuild against new gimp.
xscreensaver-4.14-4
-------------------
* Wed Mar 31 2004 Karsten Hopp 4.14-4
- fix fortune stand-in (#115369)
From twaugh at redhat.com Thu Apr 1 13:24:08 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Thu, 1 Apr 2004 14:24:08 +0100
Subject: rawhide report: 20040401 changes
In-Reply-To: <200404011320.i31DKmS07826@porkchop.devel.redhat.com>
References: <200404011320.i31DKmS07826@porkchop.devel.redhat.com>
Message-ID: <20040401132408.GW22468@redhat.com>
Today's rawhide surprise is that packages get installed in
alphabetical order rather than the more usual topological dependency
sort.
The result is that %pre scriptlets for things like kernel and
coreutils fail, and the packages are skipped. The installation won't
boot. :-(
Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From laroche at redhat.com Thu Apr 1 13:24:25 2004
From: laroche at redhat.com (Florian La Roche)
Date: Thu, 1 Apr 2004 15:24:25 +0200
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080813795.31656.2.camel@ulysse.olympe.o2t>
References: <1080687441.10735.55.camel@opus>
<1080688557.1212.3.camel@shahms.mesd.k12.or.us>
<1080738195.869.0.camel@teapot.felipe-alfaro.com>
<1080796713.7795.0.camel@roadrash.rdu.redhat.com>
<1080800347.21566.24.camel@skyfox.terraplex.com>
<1080807274.3985.31.camel@wombat.tiptoe.de>
<1080813795.31656.2.camel@ulysse.olympe.o2t>
Message-ID: <20040401132425.GB8179@dudweiler.stuttgart.redhat.com>
> /srv OTOH seems to have been well received by a sizable part of the
> posters - can it go in without being blocked by /media for now ?
We should further evaluate that. Is LSB-2.0 requireing it? What about
compatibility to older versions and upgrade support to current rpms?
Compat symlinks often cause problems, just as well as changing an
existing structure. That is often a bigger problem than the advantage
of the location of the new directory.
Along the same lines Red Hat satyed conservative by sticking to
sendmail instead of changing over to postfix/exim. (I still remember
the Linux kongress way back in 1995 where Alan Cox, Linus and a few
other said sendmail is not something you should start using on Linux. ;-)
greetings,
Florian La Roche
P.S.: Starting the MTA is not meant to disturbe the discussion. I think it
is valuable to understand that any change in behaviour is bad, but
Red Hat definitely should look at what point it is important to have
enough benefits for e.g. /srv and other new paths.
From leon at geon.donetsk.ua Thu Apr 1 13:24:20 2004
From: leon at geon.donetsk.ua (Leon Kanter)
Date: Thu, 01 Apr 2004 16:24:20 +0300
Subject: Install CDROM boot problems
In-Reply-To: <1080317762.6519.16.camel@shahms.mesd.k12.or.us>
References: <1080317762.6519.16.camel@shahms.mesd.k12.or.us>
Message-ID: <406C1804.7000905@geon.donetsk.ua>
Shahms King ?????:
>Neither FC1 nor FC2 test 1 install CDROMs will boot from my laptop's
>firewire cdrom. It's not a problem of the installer not working, I
>don't see any indication that any attempt was made to boot from CDROM at
>all, no ISOLINUX message, nothing. The CDs boot just fine in my desktop
>and the RedHat 9 discs will boot (and install) without a problem.
>
>I found some similar bugs in bugzilla when going from RH7.3 -> RH8, but
>nothing more recent than that. Is this a known issue? What changed from
>RH9 -> FC1 that might be causing this?
>
>
Looks like something is wrong with boot CD format. My desktop box is
unable to boot from FC2-test2-i386-disc1.iso, while laptop booted OK.
Media itself was successfully verified on desktop box that did not want
to boot from it, so I think the problem is between bios and boot record.
From ndbecker2 at verizon.net Thu Apr 1 13:25:56 2004
From: ndbecker2 at verizon.net (Neal Becker)
Date: Thu, 1 Apr 2004 08:25:56 -0500
Subject: Just what you always wanted: pstoedit
Message-ID: <200404010826.00794.ndbecker2@verizon.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have created RPMS for pstoedit. Just what you always wanted! Finally, you
can convert ps or pdf graphics to powerpoint to give to your pointy headed
boss!
pstoedit needs libEMF and plotutils. I have made RPMS for all 3.
Now, what exactly do I need to do to submit? Where to upload?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAbBhmMDqogpR5tkMRAoEcAKCEl4nrlQIJd9IgismtfgaLb4EKqACcDHZ2
zDzw1/oDLxgOhUBlECcVxiM=
=DW4q
-----END PGP SIGNATURE-----
From sds at epoch.ncsc.mil Thu Apr 1 13:30:15 2004
From: sds at epoch.ncsc.mil (Stephen Smalley)
Date: Thu, 01 Apr 2004 08:30:15 -0500
Subject: rawhide report: 20040331 changes
In-Reply-To: <20040331160715.GR22468@redhat.com>
References: <200403311522.i2VFM5215709@porkchop.devel.redhat.com>
<20040331160715.GR22468@redhat.com>
Message-ID: <1080826215.25431.25.camel@moss-spartans.epoch.ncsc.mil>
On Wed, 2004-03-31 at 11:07, Tim Waugh wrote:
> A word of warning: the version number of the policy file has changed
> in the kernel but some userland bits aren't in sync with it, causing
> file context labelling not to get done. Fresh installs are likely to
> fail.
What userland bits caused a problem, so that we can avoid similar
problems in the future? Compatibility should have been preserved:
- the new kernel included code to accept either the new or old policy
format
- checkpolicy already included support for generating either policy
format
- SysVinit already included support for loading either policy format
It is true that the newer policy features can't be used until the policy
package is updated to start building the new policy format, but that
shouldn't have prevented continued operation of the new kernel with the
older policy.
--
Stephen Smalley
National Security Agency
From db at zigo.dhs.org Thu Apr 1 14:09:03 2004
From: db at zigo.dhs.org (Dennis Bjorklund)
Date: Thu, 1 Apr 2004 16:09:03 +0200 (CEST)
Subject: gphoto2 and libgphoto2
In-Reply-To: <20040401124903.GV22468@redhat.com>
Message-ID:
On Thu, 1 Apr 2004, Tim Waugh wrote:
> On Thu, Apr 01, 2004 at 01:58:57PM +0200, Dennis Bjorklund wrote:
>
> > Is there a reason why gphoto2 and libgphoto2 are in the same package
> > and not two seperate ones? I'd like a separate libgphoto2
> > package. The library is used by more frontends then just gphoto2.
>
> What's the advantage of separating the (tiny) gphoto2 binary out?
Same as always, one can upgrade (or omit) gphoto2 independently from
libgphoto2.
Having the lib packaged nicely makes it possible to install several
versions of the lib.
gphoto2 pulls in some (not many) dependencies that libgphoto does not
(still, gphoto2 can be built with libaa support, but it is not in fedora).
I just didn't see any reason to put one of the frontends into the lib
package, no matter how tiny it was. It's usually not done that way when a
lib is used by many programs, that's all.
--
/Dennis Bj?rklund
From buildsys at redhat.com Thu Apr 1 14:12:38 2004
From: buildsys at redhat.com (Build System)
Date: Thu, 01 Apr 2004 17:12:38 +0300
Subject: rawhide report: 20040401 changes
Message-ID: <1080828758.5304.4.camel@marte.biciclete.ro>
Removed Packages:
gnome-*
kde-*
mozilla-*
Added Packages:
blackbox-0.65-1
twm-0.98-1
amaya-8.3-1
From feliciano.matias at free.fr Thu Apr 1 14:22:58 2004
From: feliciano.matias at free.fr (Matias Feliciano)
Date: Thu, 01 Apr 2004 16:22:58 +0200
Subject: Install CDROM boot problems
In-Reply-To: <1080317762.6519.16.camel@shahms.mesd.k12.or.us>
References: <1080317762.6519.16.camel@shahms.mesd.k12.or.us>
Message-ID: <1080829377.18988.0.camel@localhost.localdomain>
Le ven 26/03/2004 ? 17:16, Shahms King a ?crit :
> Neither FC1 nor FC2 test 1 install CDROMs will boot from my laptop's
> firewire cdrom. It's not a problem of the installer not working, I
> don't see any indication that any attempt was made to boot from CDROM at
> all, no ISOLINUX message, nothing. The CDs boot just fine in my desktop
> and the RedHat 9 discs will boot (and install) without a problem.
>
> I found some similar bugs in bugzilla when going from RH7.3 -> RH8, but
> nothing more recent than that. Is this a known issue? What changed from
> RH9 -> FC1 that might be causing this?
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119386
> --
> Shahms King
>
From feliciano.matias at free.fr Thu Apr 1 14:40:54 2004
From: feliciano.matias at free.fr (Matias Feliciano)
Date: Thu, 01 Apr 2004 16:40:54 +0200
Subject: rawhide report: 20040401 changes
In-Reply-To: <1080828758.5304.4.camel@marte.biciclete.ro>
References: <1080828758.5304.4.camel@marte.biciclete.ro>
Message-ID: <1080830454.18988.10.camel@localhost.localdomain>
Le jeu 01/04/2004 ? 16:12, Build System a ?crit :
> Removed Packages:
>
> gnome-*
> kde-*
> mozilla-*
>
> Added Packages:
>
> blackbox-0.65-1
> twm-0.98-1
> amaya-8.3-1
Drop amaya and put lynk please.
Many people around me have simple PC with some cheap cpu like XP 2000
and only 512 Mo.
And what about floppy rather than DVD ?
btw : twm is already there (xorg-x11-twm).
Thanks.
From bubbob at ntlworld.com Thu Apr 1 14:50:12 2004
From: bubbob at ntlworld.com (Steve Randall)
Date: Thu, 01 Apr 2004 15:50:12 +0100
Subject: rawhide report: 20040401 changes
In-Reply-To: <1080828758.5304.4.camel@marte.biciclete.ro>
References: <1080828758.5304.4.camel@marte.biciclete.ro>
Message-ID: <406C2C24.4090802@ntlworld.com>
Build System wrote:
>Removed Packages:
>
>gnome-*
>kde-*
>mozilla-*
>
>Added Packages:
>
>blackbox-0.65-1
>twm-0.98-1
>amaya-8.3-1
>
>
>
>
>
>
hahahaha (checks date) - you nearly got me then!
SR
From arnaud.abelard at sciences.univ-nantes.fr Thu Apr 1 14:57:39 2004
From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard)
Date: Thu, 01 Apr 2004 16:57:39 +0200
Subject: rawhide report: 20040401 changes
In-Reply-To: <1080828758.5304.4.camel@marte.biciclete.ro>
References: <1080828758.5304.4.camel@marte.biciclete.ro>
Message-ID: <406C2DE3.1010501@sciences.univ-nantes.fr>
blackbox isn't maintained anymore... shouldn't it be replaced by fluxbox which
is available from fedora.us stable (very old) and testing (most recent version) ?
Arnaud (packager of fluxbox 0.9.8 on fedora.us)
Build System wrote:
> Removed Packages:
>
> gnome-*
> kde-*
> mozilla-*
>
> Added Packages:
>
> blackbox-0.65-1
> twm-0.98-1
> amaya-8.3-1
>
>
>
>
--
Arnaud Ab?lard
Administrateur r?seaux et syst?mes
Irin / Facult? des Sciences
Universit? de Nantes
From leonard at den.ottolander.nl Thu Apr 1 15:17:14 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Thu, 01 Apr 2004 17:17:14 +0200
Subject: Guides for Fedora Core
Message-ID: <1080832634.4753.47.camel@athlon.localdomain>
Hi,
Just wondering if there are any plans to adapt the Red Hat Linux guides
for Fedora Core. These are very useful guides, but some newbies might
not understand it if you point them to RHL guides when they are using
Fedora Core. Also the information available in them will out date over
time.
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
From mandreiana at rdslink.ro Thu Apr 1 15:24:45 2004
From: mandreiana at rdslink.ro (Marius Andreiana)
Date: Thu, 01 Apr 2004 18:24:45 +0300
Subject: rawhide report: 20040401 changes
In-Reply-To: <406C2DE3.1010501@sciences.univ-nantes.fr>
References: <1080828758.5304.4.camel@marte.biciclete.ro>
<406C2DE3.1010501@sciences.univ-nantes.fr>
Message-ID: <1080833084.5304.9.camel@marte.biciclete.ro>
On Thu, 2004-04-01 at 17:57, Arnaud Abelard wrote:
> blackbox isn't maintained anymore... shouldn't it be replaced by fluxbox which
> is available from fedora.us stable (very old) and testing (most recent version) ?
ok. I'll also help delivering the ultimate desktop and will make rpms
for xpaint (deprecating gimp) and emacs-gtk (deprecating openoffice.org)
--
Marius Andreiana
Galuna - Solutii Linux in Romania
http://www.galuna.ro
From feliciano.matias at free.fr Thu Apr 1 15:22:20 2004
From: feliciano.matias at free.fr (Matias Feliciano)
Date: Thu, 01 Apr 2004 17:22:20 +0200
Subject: rawhide report: 20040401 changes
In-Reply-To: <1080833084.5304.9.camel@marte.biciclete.ro>
References: <1080828758.5304.4.camel@marte.biciclete.ro>
<406C2DE3.1010501@sciences.univ-nantes.fr>
<1080833084.5304.9.camel@marte.biciclete.ro>
Message-ID: <1080832940.21506.1.camel@localhost.localdomain>
Le jeu 01/04/2004 ? 17:24, Marius Andreiana a ?crit :
> On Thu, 2004-04-01 at 17:57, Arnaud Abelard wrote:
> > blackbox isn't maintained anymore... shouldn't it be replaced by fluxbox which
> > is available from fedora.us stable (very old) and testing (most recent version) ?
> ok. I'll also help delivering the ultimate desktop and will make rpms
> for xpaint (deprecating gimp) and emacs-gtk (deprecating openoffice.org)
>
RFC : replace gnome-game/freeciv by xbill.
From arnaud.abelard at sciences.univ-nantes.fr Thu Apr 1 15:28:05 2004
From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard)
Date: Thu, 01 Apr 2004 17:28:05 +0200
Subject: rawhide report: 20040401 changes
In-Reply-To: <1080833084.5304.9.camel@marte.biciclete.ro>
References: <1080828758.5304.4.camel@marte.biciclete.ro> <406C2DE3.1010501@sciences.univ-nantes.fr>
<1080833084.5304.9.camel@marte.biciclete.ro>
Message-ID: <406C3505.4020800@sciences.univ-nantes.fr>
Marius Andreiana wrote:
> On Thu, 2004-04-01 at 17:57, Arnaud Abelard wrote:
>
>>blackbox isn't maintained anymore... shouldn't it be replaced by fluxbox which
>>is available from fedora.us stable (very old) and testing (most recent version) ?
>
> ok. I'll also help delivering the ultimate desktop and will make rpms
> for xpaint (deprecating gimp) and emacs-gtk (deprecating openoffice.org)
>
What are you talking about?
blackbox was abandonned a few years ago and fluxbox's based on blackbox.
It's not like anyone will get bugfix for blackbox anymore.
phewww.. what's your problem, man.. do you have any arguments.... know what i
am talking about?
--
Arnaud Ab?lard
Administrateur r?seaux et syst?mes
Irin / Facult? des Sciences
Universit? de Nantes
From skvidal at phy.duke.edu Thu Apr 1 15:34:42 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 01 Apr 2004 10:34:42 -0500
Subject: rawhide report: 20040401 changes
In-Reply-To: <406C3505.4020800@sciences.univ-nantes.fr>
References: <1080828758.5304.4.camel@marte.biciclete.ro>
<406C2DE3.1010501@sciences.univ-nantes.fr>
<1080833084.5304.9.camel@marte.biciclete.ro>
<406C3505.4020800@sciences.univ-nantes.fr>
Message-ID: <1080833682.8596.11.camel@opus.phy.duke.edu>
On Thu, 2004-04-01 at 10:28, Arnaud Abelard wrote:
> What are you talking about?
> blackbox was abandonned a few years ago and fluxbox's based on blackbox.
> It's not like anyone will get bugfix for blackbox anymore.
>
> phewww.. what's your problem, man.. do you have any arguments.... know what i
> am talking about?
It's april fool's day. He's kidding around.
-sv
From arnaud.abelard at sciences.univ-nantes.fr Thu Apr 1 15:42:07 2004
From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard)
Date: Thu, 01 Apr 2004 17:42:07 +0200
Subject: rawhide report: 20040401 changes
In-Reply-To: <1080833682.8596.11.camel@opus.phy.duke.edu>
References: <1080828758.5304.4.camel@marte.biciclete.ro> <406C2DE3.1010501@sciences.univ-nantes.fr> <1080833084.5304.9.camel@marte.biciclete.ro> <406C3505.4020800@sciences.univ-nantes.fr>
<1080833682.8596.11.camel@opus.phy.duke.edu>
Message-ID: <406C384F.30405@sciences.univ-nantes.fr>
oh duh!
removing kde-* and gnome-* surely sounded weird.. but it reminded my of the
first build system mails.. i thought "ah.. definitely not perfect this system"
/me slaps himself
too much work, too much work, too much wo
sorry Marius ;-)
A.
seth vidal wrote:
> On Thu, 2004-04-01 at 10:28, Arnaud Abelard wrote:
>
>>What are you talking about?
>>blackbox was abandonned a few years ago and fluxbox's based on blackbox.
>>It's not like anyone will get bugfix for blackbox anymore.
>>
>>phewww.. what's your problem, man.. do you have any arguments.... know what i
>>am talking about?
>
>
> It's april fool's day. He's kidding around.
>
> -sv
>
>
>
--
Arnaud Ab?lard
Administrateur r?seaux et syst?mes
Irin / Facult? des Sciences
Universit? de Nantes
From daly at rio.sci.ccny.cuny.edu Thu Apr 1 15:04:53 2004
From: daly at rio.sci.ccny.cuny.edu (Tim Daly)
Date: Thu, 1 Apr 2004 10:04:53 -0500
Subject: rawhide report: 20040401 changes
In-Reply-To: <406C3505.4020800@sciences.univ-nantes.fr> (message from Arnaud
Abelard on Thu, 01 Apr 2004 17:28:05 +0200)
References: <1080828758.5304.4.camel@marte.biciclete.ro> <406C2DE3.1010501@sciences.univ-nantes.fr>
<1080833084.5304.9.camel@marte.biciclete.ro>
<406C3505.4020800@sciences.univ-nantes.fr>
Message-ID: <200404011504.i31F4rx31428@rio.sci.ccny.cuny.edu>
ummm, it's april first....
From gauret at free.fr Thu Apr 1 16:23:50 2004
From: gauret at free.fr (Aurelien Bompard)
Date: Thu, 01 Apr 2004 18:23:50 +0200
Subject: RFC: fedora.us QA approval format
Message-ID:
Hi all,
Erik and myself have been working on a QA check script to automate the QA
process at fedora.us. The script is getting quite correct, and can even be
useful ;-)
At the end of the checks, the script outputs a QA approval report, which can
be edited, gpg-signed, and pasted into bugzilla. The question is: what
should a QA approval look like to have all the minimum QA requirements and
be as parseable as possible by a publishing script for the release manager.
Erik and I have different minds on what has to be in the review, so we
though we should discuss it here, especially with the release managers.
I have setup a wiki page with a primary format proposal, and I invite you to
have a look at it and comment on it: http://www.fedora.us/wiki/QAFormat
If the script is to get into fedora-rpmdevtools, a complete newbie could
contribute meaningful QA's in a format which would be useful to the release
manager. This would lower the bar to QA, and standardize the process a
little bit more.
Please comment
Aur?lien
--
http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info
If you wish to live wisely, ignore sayings -- including this one.
From chabotc at 4-ice.com Thu Apr 1 16:23:18 2004
From: chabotc at 4-ice.com (Chris Chabot)
Date: Thu, 01 Apr 2004 18:23:18 +0200
Subject: My initial experiances with FC2-test2
In-Reply-To: <1080765960.20785.21.camel@orodruin.boston.redhat.com>
References: <406ABF55.5000503@4-ice.com>
<1080765960.20785.21.camel@orodruin.boston.redhat.com>
Message-ID: <406C41F6.3060601@4-ice.com>
I've tried xorg's generic radeon driver, and it worked fine! Gave it a
good try for a day, and haven't found any glitches.. My vote would be to
include the chipset id in hwdata :-)
Ps, performance is ofcource a bit slower then the ati drivers, but i
think for most ppl 'just works' is preferable over 'if you perform this
voodoo magic it might work, and a little faster' :-)
Thanks for the hints,
-- Chris
Jeremy Katz wrote:
>On Wed, 2004-03-31 at 14:53 +0200, Chris Chabot wrote:
>
>
>>1) My machine is currently equiped with a ATI Radeon 9800XT card,
>>XFree86 (scrap that, xorg nowadays) has no support for it, and your
>>forced to run in VESA mode. While this is fine for a server machine
>>where you only run the occasional vnc server or a system-config-...
>>tool, for a workstation it's just to damn dog slow..
>>
>>
>
>Can you trying using the radeon driver with xorg-x11? Although hwdata
>stuff hasn't been updated yet, the radeon driver in xorg-x11 should
>support a lot of the newer stuff (at least for 2d).
>
>Jeremy
>
>
>
>
From brads at redhat.com Thu Apr 1 14:00:14 2004
From: brads at redhat.com (Brad Smith)
Date: Thu, 01 Apr 2004 09:00:14 -0500
Subject: rawhide report: 20040401 changes
In-Reply-To: <1080830454.18988.10.camel@localhost.localdomain>
References: <1080828758.5304.4.camel@marte.biciclete.ro>
<1080830454.18988.10.camel@localhost.localdomain>
Message-ID: <1080828014.20295.19.camel@localhost.localdomain>
> btw : twm is already there (xorg-x11-twm).
This thread actually has me pining a bit for my beloved OLVWM. =:)
From katzj at redhat.com Thu Apr 1 17:15:18 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 01 Apr 2004 12:15:18 -0500
Subject: rawhide report: 20040401 changes
In-Reply-To: <20040401132408.GW22468@redhat.com>
References: <200404011320.i31DKmS07826@porkchop.devel.redhat.com>
<20040401132408.GW22468@redhat.com>
Message-ID: <1080839718.23310.7.camel@orodruin.boston.redhat.com>
On Thu, 2004-04-01 at 14:24 +0100, Tim Waugh wrote:
> Today's rawhide surprise is that packages get installed in
> alphabetical order rather than the more usual topological dependency
> sort.
It looks like the tree build didn't quite complete all of the necessary
steps. The genhdlist with package ordering failed and thus things go
badly.
April fool's install? :-)
Jeremy
From katzj at redhat.com Thu Apr 1 17:22:05 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 01 Apr 2004 12:22:05 -0500
Subject: rawhide report: 20040331 changes
In-Reply-To: <1080826215.25431.25.camel@moss-spartans.epoch.ncsc.mil>
References: <200403311522.i2VFM5215709@porkchop.devel.redhat.com>
<20040331160715.GR22468@redhat.com>
<1080826215.25431.25.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <1080840125.23310.10.camel@orodruin.boston.redhat.com>
On Thu, 2004-04-01 at 08:30 -0500, Stephen Smalley wrote:
> What userland bits caused a problem, so that we can avoid similar
> problems in the future? Compatibility should have been preserved:
> - the new kernel included code to accept either the new or old policy
> format
> - checkpolicy already included support for generating either policy
> format
> - SysVinit already included support for loading either policy format
anaconda loads the policy specified in policyvers _only_. Otherwise,
there's the fun question of how far back you go. Also, doing "fall back
a version" things mean that you can _never_ change in a way that's not
backwards compatible.
Jeremy
From pmatilai at welho.com Thu Apr 1 17:24:12 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Thu, 1 Apr 2004 20:24:12 +0300 (EEST)
Subject: RFC: fedora.us QA approval format
In-Reply-To:
References:
Message-ID:
On Thu, 1 Apr 2004, Aurelien Bompard wrote:
> Hi all,
>
> Erik and myself have been working on a QA check script to automate the QA
> process at fedora.us. The script is getting quite correct, and can even be
> useful ;-)
> At the end of the checks, the script outputs a QA approval report, which can
> be edited, gpg-signed, and pasted into bugzilla. The question is: what
> should a QA approval look like to have all the minimum QA requirements and
> be as parseable as possible by a publishing script for the release manager.
> Erik and I have different minds on what has to be in the review, so we
> though we should discuss it here, especially with the release managers.
> I have setup a wiki page with a primary format proposal, and I invite you to
> have a look at it and comment on it: http://www.fedora.us/wiki/QAFormat
For one it should be such that it's easy to verify that two reviews got
the same results. Currently since everybody uses slightly different format
of QA reviews you need to look very carefully to spot possible differences
(meaning the package has been changed since previous check which could
mean something nasty is going on) in two reviews and is prone to
human error.
For source md5sum's I'd say mark any source checked against upstream with
(ok) or such, for sources that can't be verified from web do include
md5sum for it anyway, it allows checking if the file has changed from one
version to another for example.
>
> If the script is to get into fedora-rpmdevtools, a complete newbie could
> contribute meaningful QA's in a format which would be useful to the release
> manager. This would lower the bar to QA, and standardize the process a
> little bit more.
This is very welcome.. while the QA cannot be completely automated (eg you
can't just blindly trust whatever happens to read as the package source
url, it could be somebody's own website with hacked tarball, human sanity
check is needed) removing boring, error prone manual steps from it is a
Good Thing.
- Panu -
From katzj at redhat.com Thu Apr 1 17:30:17 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 01 Apr 2004 12:30:17 -0500
Subject: rawhide report: 20040401 changes
In-Reply-To: <20040401132408.GW22468@redhat.com>
References: <200404011320.i31DKmS07826@porkchop.devel.redhat.com>
<20040401132408.GW22468@redhat.com>
Message-ID: <1080840617.23310.13.camel@orodruin.boston.redhat.com>
http://people.redhat.com/~katzj/updates-20040401.img should fix. Throw
it in Fedora/base/ of your local tree or dd it to a floppy and boot with
linux updates
Jeremy
From gauret at free.fr Thu Apr 1 17:56:46 2004
From: gauret at free.fr (Aurelien Bompard)
Date: Thu, 01 Apr 2004 19:56:46 +0200
Subject: RFC: fedora.us QA approval format
References:
Message-ID:
Panu Matilainen wrote:
> For one it should be such that it's easy to verify that two reviews got
> the same results. Currently since everybody uses slightly different format
> of QA reviews you need to look very carefully to spot possible differences
> (meaning the package has been changed since previous check which could
> mean something nasty is going on) in two reviews and is prone to
> human error.
This is the point of a standardized format, and the QA script can make it
easier.
> For source md5sum's I'd say mark any source checked against upstream with
> (ok) or such, for sources that can't be verified from web do include
> md5sum for it anyway, it allows checking if the file has changed from one
> version to another for example.
OK, I've applied your suggestions on the wiki page. Does this fill your
needs ?
> This is very welcome.. while the QA cannot be completely automated (eg you
> can't just blindly trust whatever happens to read as the package source
> url, it could be somebody's own website with hacked tarball, human sanity
> check is needed) removing boring, error prone manual steps from it is a
> Good Thing.
Totally agreed. Thanks for your support.
Aur?lien
--
http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info
L'exp?rience est quelquechose que l'on acquiert juste apr?s en avoir eu
besoin.
From toshio at tiki-lounge.com Thu Apr 1 18:31:31 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Thu, 01 Apr 2004 13:31:31 -0500
Subject: RFC: fedora.us QA approval format
In-Reply-To:
References:
Message-ID: <1080844288.32189.27.camel@Madison.badger.com>
On Thu, 2004-04-01 at 11:23, Aurelien Bompard wrote:
> Hi all,
>
> Erik and myself have been working on a QA check script to automate the QA
> process at fedora.us. The script is getting quite correct, and can even be
> useful ;-)
Hi Aurelian, Erik,
I've been working on something similar and it's also just about ready
for a first look. Could you tell me more about yours so I know if I
should join your effort, merge ideas back and forth with you, or keep
working independently?
Mine is a little pygnome app that basically presents the user with a
checklist that they then fill out in order to generate the QA Review.
It's working well enough for a testing release (one work-aroundable
bug) but I have to finish adding checklist items from Fedora.us today.
It looks (from seeing your sample review) that you've got a more
streamlined, automated script but I'm not sure.
-Toshio
--
Toshio
-------------- 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:
From smoogen at lanl.gov Thu Apr 1 18:44:36 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Thu, 01 Apr 2004 11:44:36 -0700
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080816876.24581.17.camel@delerium.codemonkey.org.uk>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
Message-ID: <1080845076.10901.22.camel@smoogen2.lanl.gov>
Ok I have a feeling I know where this sort of configuration would be
wanted :) :).. so I figured I should let you know the various problems
we have seen with diskless workstations, clusters and other things
On Thu, 2004-04-01 at 03:54, Dave Jones wrote:
> On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
>
> > A possibly related discussion; we've been wondering if we can make the
> > OS image read-only (mounting it that way, or via selinux).
>
> If we do this, apt/yum/up2date/rpm will also need smarts to remount rw
> when upgrading. Having to do this by hand each time would annoy the hell
> out of me enough to just make it permanently rw again.
>
The issues I see are the following:
python items that get recompiled. I have to treat my scripts to ok
various .pyc files that seem to change md5sums every now and then.
The following filesystems are heavily mutable and have to be rw
/etc
mtab
configurations and such being pushed out by cfengine, et al.
[Rebooting to get the new configuration is not why we switched to
Linux :)]
/dev
permission changes and such
One of the old Unix boxes here had the ability to set / ro (unless
single user) and then overmounted a rw /dev /etc with all the entries
that were mutable. The only problem we had was when the new sysadmin
(me) didnt know that booting single user didnt overmount, and so the
changes to /etc/passwd disappeared :).
Things that can be mounted via ramdisk
/tmp
/var/tmp
/var/spool/mqueue/xf/
## Also /var/spool/MIMEdefang/ if you use it.
Things that have to be available over a reboot/power-outage/etc
/var/spool/
/var/log/ [even with central logging it is needed to cross check
logs]
> > Then have /tmp and probably /var in RAM (or wiped on boot)
>
> Errr, if /var/log disappeared, I'd be very annoyed.
>
> Ditto /var/spool. Imagine a scenario where I had a few hundred emails
> in /var/spool/mqueue, and for some reason the box locked up.
> Right now, I can reboot, and they'll still be there, and I can just
> restart the MTA and everything carries on. With your proposal, that
> spool is *gone*.
>
> Same is possibly true for other bits of /var too.
>
> > This allows you to maintain the OS image in a central location and the
> > homedirs and server/app data in central locations, and have a single
> > network-wide master copy of all important state.
>
> This sounds problematic for laptops. Things like AFS sound like a solution,
> but from what I've heard about it, I'm not sure I'm ready to trust my
> /home to it.
>
I doubt very much you would want to run this configuration on a
laptop... :).
> Dave
--
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 gauret at free.fr Thu Apr 1 19:47:34 2004
From: gauret at free.fr (Aurelien Bompard)
Date: Thu, 01 Apr 2004 21:47:34 +0200
Subject: RFC: fedora.us QA approval format
References:
<1080844288.32189.27.camel@Madison.badger.com>
Message-ID:
Hi Toshio
> I've been working on something similar and it's also just about ready
> for a first look. Could you tell me more about yours so I know if I
> should join your effort, merge ideas back and forth with you, or keep
> working independently?
You can find our script here:
http://gauret.free.fr/fichiers/rpms/fedora/fedora-startqa
(that's a snapshot of the CVS)
> Mine is a little pygnome app that basically presents the user with a
> checklist that they then fill out in order to generate the QA Review.
> It's working well enough for a testing release (one work-aroundable
> bug) but I have to finish adding checklist items from Fedora.us today.
Hmm, interesting... Ours is a console only script which generates a pastable
output of the report as well as a few files containing the todo list,
rpmlint's output and the report itself. Its main features are:
- Download of the srpm, given the bug ID
- Check of the srpm md5sum (if it exists)
- Download of the sources, with md5sum check
- Check of the srpm GPG signature
- Build of the srpm in mach
- Display of rpmlint's "advice"
- Display of the files in the resulting binary rpm
- Display of the report, to be edited, signed and pasted in bugzilla
- Display of the TODO list (check that were not done, installation, etc...)
- Interactive mode where you can choose which tests to run (default)
- Batch mode where all the tests are run
- Debug mode
- Support for livna packages
(Erik please complete the list if I forgot something)
It's getting pretty usable, and needs some testing. The next big item in our
(at least my) TODO list is the fork the build in mach in order to save
time.
> It looks (from seeing your sample review) that you've got a more
> streamlined, automated script but I'm not sure.
You're very welcome to look at it, and even test it if you can ;-)
Thanks
Aur?lien
--
http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info
There are only 10 types of people in the world :
those who understand binary and those who don't.
From scribusdocs at atlantictechsolutions.com Thu Apr 1 19:49:49 2004
From: scribusdocs at atlantictechsolutions.com (Peter Linnell)
Date: Thu, 1 Apr 2004 14:49:49 -0500
Subject: Just what you always wanted: pstoedit
In-Reply-To: <20040401170010.012E9751B1@hormel.redhat.com>
References: <20040401170010.012E9751B1@hormel.redhat.com>
Message-ID: <200404011449.59428.scribusdocs@atlantictechsolutions.com>
>
> Message: 2
> Date: Thu, 1 Apr 2004 08:25:56 -0500
> From: Neal Becker
> Subject: Just what you always wanted: pstoedit
> To: fedora-devel-list at redhat.com
> Message-ID: <200404010826.00794.ndbecker2 at verizon.net>
> Content-Type: Text/Plain; charset="us-ascii"
>
> I have created RPMS for pstoedit. Just what you always wanted! Finally,
> you can convert ps or pdf graphics to powerpoint to give to your pointy
> headed boss!
>
> pstoedit needs libEMF and plotutils. I have made RPMS for all 3.
>
> Now, what exactly do I need to do to submit? Where to upload?
>
>
I hope I did not rain on your parade, but I have submitted pstoedit in the
Fedora QA bugzilla. This is a great app, which can work as a plug-in to
gsview 4.x. See: https://bugzilla.fedora.us/show_bug.cgi?id=1440
libEMF is busted building on Fedora-1 (properly) , even with gcc patches
poached from other distros. Needs some massaging and it is an abandoned
project AFAICT. I would be curious to see if it can be made to work properly
on FC-1 and FC-2..
I have not finished the plotutils package yet, so submitting this to QA would
be welcome.
Package submission guidelines and other pertinent info:
http://www.fedora.us/wiki/FedoraDocuments
Cheers,
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL:
From hp at redhat.com Thu Apr 1 19:56:53 2004
From: hp at redhat.com (Havoc Pennington)
Date: Thu, 01 Apr 2004 14:56:53 -0500
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080816876.24581.17.camel@delerium.codemonkey.org.uk>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
Message-ID: <1080849413.3841.27.camel@localhost.localdomain>
Hi,
To be clear, a read-only root would not be the only possible config,
it's a specific deployment methodology.
On Thu, 2004-04-01 at 05:54, Dave Jones wrote:
> On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
>
> > A possibly related discussion; we've been wondering if we can make the
> > OS image read-only (mounting it that way, or via selinux).
>
> If we do this, apt/yum/up2date/rpm will also need smarts to remount rw
> when upgrading. Having to do this by hand each time would annoy the hell
> out of me enough to just make it permanently rw again.
The whole point is to never run apt/yum/up2date/rpm on individual
machines, only on a central image ;-)
Avoid per-system state that can be configured incorrectly, haX0rd,
gotten out of sync.
> > Then have /tmp and probably /var in RAM (or wiped on boot)
>
> Errr, if /var/log disappeared, I'd be very annoyed.
Log to a server for example.
> Ditto /var/spool.
IMAP and remote smtp server, or something along those lines. Print
servers.
You could have "writable /var" as a possible configuration, too.
> > This allows you to maintain the OS image in a central location and the
> > homedirs and server/app data in central locations, and have a single
> > network-wide master copy of all important state.
>
> This sounds problematic for laptops. Things like AFS sound like a solution,
> but from what I've heard about it, I'm not sure I'm ready to trust my
> /home to it.
If we can't handle laptops this is still useful for server and
thin-client-desktop type setups
The way to do laptops though is that the RW master image of homedir is
on the laptop, and the laptop keeps a local RO cache of the OS image.
On connection to network, you sync the homedir from laptop to network,
and sync the OS image from network to laptop.
Or something, this isn't a mature idea, just a discussion that's come
up.
Havoc
From ms-nospam-0306 at arcor.de Thu Apr 1 19:58:47 2004
From: ms-nospam-0306 at arcor.de (Michael Schwendt)
Date: Thu, 1 Apr 2004 21:58:47 +0200
Subject: Just what you always wanted: pstoedit
In-Reply-To: <200404010826.00794.ndbecker2@verizon.net>
References: <200404010826.00794.ndbecker2@verizon.net>
Message-ID: <20040401215847.6ac9b7ae.ms-nospam-0306@arcor.de>
On Thu, 1 Apr 2004 08:25:56 -0500, Neal Becker wrote:
> I have created RPMS for pstoedit. Just what you always wanted! Finally, you
> can convert ps or pdf graphics to powerpoint to give to your pointy headed
> boss!
>
> pstoedit needs libEMF and plotutils. I have made RPMS for all 3.
>
> Now, what exactly do I need to do to submit? Where to upload?
http://fedora.redhat.com -> "Participate" has all the information you
need.
A package for pstoedit has been submitted at fedora.us:
https://bugzilla.fedora.us/show_bug.cgi?id=1440
From smoogen at lanl.gov Thu Apr 1 20:28:54 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Thu, 01 Apr 2004 13:28:54 -0700
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080849413.3841.27.camel@localhost.localdomain>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
<1080849413.3841.27.camel@localhost.localdomain>
Message-ID: <1080851333.10901.61.camel@smoogen2.lanl.gov>
On Thu, 2004-04-01 at 12:56, Havoc Pennington wrote:
> Hi,
>
> To be clear, a read-only root would not be the only possible config,
> it's a specific deployment methodology.
>
> On Thu, 2004-04-01 at 05:54, Dave Jones wrote:
> > On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
> >
> > > A possibly related discussion; we've been wondering if we can make the
> > > OS image read-only (mounting it that way, or via selinux).
> >
> > If we do this, apt/yum/up2date/rpm will also need smarts to remount rw
> > when upgrading. Having to do this by hand each time would annoy the hell
> > out of me enough to just make it permanently rw again.
>
> The whole point is to never run apt/yum/up2date/rpm on individual
> machines, only on a central image ;-)
>
Ah.. the problem for us has come that we need a ton of diskless systems,
but that many have to run different configurations that are out of step
from a central image. I had hoped this would be the exception rather
than the rule, but it has become more of the rule than anyone expected
(and seems to be the rule at other similar organizations.)
The issue comes down to that we need to have 1-2 central servers per
network for auditing purposes. The diskless clients may need to run
different versions/packages of RHL/Fed/etc off of that diskless server.
The current hacks look to be about 5-20 different ways of solving the
same problem :).
> Avoid per-system state that can be configured incorrectly, haX0rd,
> gotten out of sync.
>
One of the things, we have found is that the only way to maintain this
when the central box is updated is to kill all the diskless clients,
remove their per-system areas (/etc,/dev,/lib,/initrd) and then have
them all rebuild themselves a new set of images on reboot. The problem
is that 200+ systems doing UDP NFSv2 at nearly the same time kills the
linux NFS server.
> > > Then have /tmp and probably /var in RAM (or wiped on boot)
> >
> > Errr, if /var/log disappeared, I'd be very annoyed.
>
> Log to a server for example.
>
I am guessing for this configuration that would be the best way. You
would need to make sure that for some systems that they could log to
multiple log servers at the same time so that they can be independantly
audited.
> > Ditto /var/spool.
>
> IMAP and remote smtp server, or something along those lines. Print
> servers.
>
> You could have "writable /var" as a possible configuration, too.
>
You can get away with most of that except when the CxO box dies while an
email was being sent and its gone. Murphy seems to strike on this one
more than statistically should be possible...
> > > This allows you to maintain the OS image in a central location and the
> > > homedirs and server/app data in central locations, and have a single
> > > network-wide master copy of all important state.
> >
> > This sounds problematic for laptops. Things like AFS sound like a solution,
> > but from what I've heard about it, I'm not sure I'm ready to trust my
> > /home to it.
>
> If we can't handle laptops this is still useful for server and
> thin-client-desktop type setups
>
> The way to do laptops though is that the RW master image of homedir is
> on the laptop, and the laptop keeps a local RO cache of the OS image.
>
> On connection to network, you sync the homedir from laptop to network,
> and sync the OS image from network to laptop.
>
The best way to get this to scale I have seen of doing this is either
using 'other filesystems' than NFS or scripts like rsync. The reason is
that a couple of the solutions I have seen work with 1-4 laptops but
dont scale beyond that. The 'cool' version I saw was a hacked version of
rsync that did something like asyncrynous updates. [Whats newer on each
system, and according to config rules overwrite usually to the newer
version.] The other version was one that would partition the laptop disk
into 'mirrors' of itself.
/boot -- 1 I think
/1
/2
/home -- 1 I think
boot is set up to boot into say /1 the first time, and then the asyncd
updates /2 to whatever the network says it should be. Grub is changed
appropriately, and a root message is sent to an applet on the desktop
saying updates have been done, please reboot to get to the new
configuration. Reboot then starts up by default into /2 and if the user
is ok with it via the applet, then /1 can be updated to mirror /2. If
not then the user can reboot back into /1 and contact their sysadmin
about the problems. [Audits can also be set up to let the central
administration which boxes are running old copies in case the user
doesnt tell the sysadmins].
/home is backed up in the background to a central server in a similar
method.
> Or something, this isn't a mature idea, just a discussion that's come
> up.
>
Let me know if I can help any..
> Havoc
--
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 toshio at tiki-lounge.com Thu Apr 1 20:43:54 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Thu, 01 Apr 2004 15:43:54 -0500
Subject: RFC: fedora.us QA approval format
In-Reply-To:
References:
<1080844288.32189.27.camel@Madison.badger.com>
Message-ID: <1080852225.32189.81.camel@Madison.badger.com>
On Thu, 2004-04-01 at 14:47, Aurelien Bompard wrote:
> Hi Toshio
>
> > I've been working on something similar and it's also just about ready
> > for a first look. Could you tell me more about yours so I know if I
> > should join your effort, merge ideas back and forth with you, or keep
> > working independently?
>
> You can find our script here:
> http://gauret.free.fr/fichiers/rpms/fedora/fedora-startqa
> (that's a snapshot of the CVS)
>
Looking at it now. It looks like we're working on two different sides
of the problem (There's still review work left to do after you're script
runs. There's considerable automation that my script could do but
doesn't.) Although I probably wouldn't have started if this had been
available before :-) I'll do some testing later today and let you know
if I have any feedback.
I'd like to get the functionality you have into what I'm working on at
some point. After we're both up and running, let's talk about how I
could best contribute to your effort while improving mine.
-Toshio
--
Toshio
-------------- 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:
From pmatilai at welho.com Thu Apr 1 21:16:09 2004
From: pmatilai at welho.com (Panu Matilainen)
Date: Fri, 02 Apr 2004 00:16:09 +0300
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080816876.24581.17.camel@delerium.codemonkey.org.uk>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
Message-ID: <1080854169.17961.16.camel@weasel.net.laiskiainen.org>
On Thu, 2004-04-01 at 13:54, Dave Jones wrote:
> On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
>
> > A possibly related discussion; we've been wondering if we can make the
> > OS image read-only (mounting it that way, or via selinux).
>
> If we do this, apt/yum/up2date/rpm will also need smarts to remount rw
> when upgrading. Having to do this by hand each time would annoy the hell
> out of me enough to just make it permanently rw again.
That's trivial to do in apt with a little Lua-script plugged into right
slots - check http://laiskiainen.org/apt/lua/remount/
(yes there are error cases it doesn't handle, but hey, it's just a silly
example...)
- Panu -
From carwyn at carwyn.com Thu Apr 1 21:26:51 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Thu, 01 Apr 2004 22:26:51 +0100
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080851333.10901.61.camel@smoogen2.lanl.gov>
References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain>
<1080851333.10901.61.camel@smoogen2.lanl.gov>
Message-ID: <406C891B.9060601@carwyn.com>
Stephen Smoogen wrote:
>
>Ah.. the problem for us has come that we need a ton of diskless systems,
>but that many have to run different configurations that are out of step
>from a central image. I had hoped this would be the exception rather
>than the rule, but it has become more of the rule than anyone expected
>(and seems to be the rule at other similar organizations.)
>
>
There's some high level discussion on things related to this here:
http://www.gridweaver.org/
.. a high level look at the different large scale configuration systems
out there with a view to what's needed going forward to managing Grid
systems. There are case studies for a number of existing large scale
installations in there ranging from 120 nodes to 1100.
Carwyn
From noa at resare.com Thu Apr 1 21:31:31 2004
From: noa at resare.com (Noa Resare)
Date: Thu, 01 Apr 2004 23:31:31 +0200
Subject: Fedora Core 1 Update: gnome-session-2.4.0-3
In-Reply-To: <1080816281.13299.113.camel@laptop>
References: <1080816281.13299.113.camel@laptop>
Message-ID: <1080855090.7679.61.camel@marit.resare.com>
tor 2004-04-01 klockan 12.44 skrev Mark McLoughlin:
> ---------------------------------------------------------------------
> This update can be downloaded from:
> http://download.fedora.redhat.com/pub/fedora/linux/core/updates/1/
>
> 68ee6463e2194ac7d27889877a81383b SRPMS/gnome-session-2.4.0-3.src.rpm
> 3d028412188c2966852d865f31345341 i386/gnome-session-2.4.0-3.i386.rpm
[noa at molly i386]$ grep gnome-session headers/header.info
[noa at molly i386]$
It seems like someone forgot to run yum-arch in the relevant dir on
download.fedora.redhat.com. Please do :)
/noa
--
And the lions ate the christians and the christians burned the witches,
and even I am out of explanations -- Ola Salo
gpg fingerprint: F3C4 AC90 B885 FE15 344B 4D05 220B 7662 A190 6F09
From devscott at charter.net Thu Apr 1 22:29:17 2004
From: devscott at charter.net (Scott Sloan)
Date: Thu, 01 Apr 2004 16:29:17 -0600
Subject: Top secret bugs?
Message-ID: <1080858557.3004.4.camel@localhost.localdomain>
Was poking around and posting a bug in mozilla and rhythmbox this
afternoon and preview some other bugs that looked interesting. This one
caught my eye primarily for what I can't see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117908
Is this an bug in bugzilla or are their suppose to be bugs members can't
see for their protection? Or one really weird April Fool's joke?
From katzj at redhat.com Thu Apr 1 22:35:16 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 01 Apr 2004 17:35:16 -0500
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080851333.10901.61.camel@smoogen2.lanl.gov>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
<1080849413.3841.27.camel@localhost.localdomain>
<1080851333.10901.61.camel@smoogen2.lanl.gov>
Message-ID: <1080858915.23310.32.camel@orodruin.boston.redhat.com>
On Thu, 2004-04-01 at 13:28 -0700, Stephen Smoogen wrote:
> On Thu, 2004-04-01 at 12:56, Havoc Pennington wrote:
> > > Ditto /var/spool.
> >
> > IMAP and remote smtp server, or something along those lines. Print
> > servers.
> >
> > You could have "writable /var" as a possible configuration, too.
>
> You can get away with most of that except when the CxO box dies while an
> email was being sent and its gone. Murphy seems to strike on this one
> more than statistically should be possible...
If you're doing direct SMTP, then having a writable /var doesn't help in
this case, either. Hopefully your mail client saves to a file (which
would be in the home dir) and then does the smtp transaction, removing
the file from the home dir after that succeeds.
Jeremy
From smoogen at lanl.gov Thu Apr 1 22:36:09 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Thu, 01 Apr 2004 15:36:09 -0700
Subject: Top secret bugs?
In-Reply-To: <1080858557.3004.4.camel@localhost.localdomain>
References: <1080858557.3004.4.camel@localhost.localdomain>
Message-ID: <1080858969.10899.76.camel@smoogen2.lanl.gov>
On Thu, 2004-04-01 at 15:29, Scott Sloan wrote:
> Was poking around and posting a bug in mozilla and rhythmbox this
> afternoon and preview some other bugs that looked interesting. This one
> caught my eye primarily for what I can't see
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117908
>
> Is this an bug in bugzilla or are their suppose to be bugs members can't
> see for their protection? Or one really weird April Fool's joke?
>
Bugs like that are usually between a customer and Red Hat and may
include info that the customer doesnt want shared with everyone.
--
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 Thu Apr 1 22:46:40 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Thu, 01 Apr 2004 15:46:40 -0700
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080858915.23310.32.camel@orodruin.boston.redhat.com>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
<1080849413.3841.27.camel@localhost.localdomain>
<1080851333.10901.61.camel@smoogen2.lanl.gov>
<1080858915.23310.32.camel@orodruin.boston.redhat.com>
Message-ID: <1080859600.10899.82.camel@smoogen2.lanl.gov>
On Thu, 2004-04-01 at 15:35, Jeremy Katz wrote:
> On Thu, 2004-04-01 at 13:28 -0700, Stephen Smoogen wrote:
> > On Thu, 2004-04-01 at 12:56, Havoc Pennington wrote:
> > > > Ditto /var/spool.
> > >
> > > IMAP and remote smtp server, or something along those lines. Print
> > > servers.
> > >
> > > You could have "writable /var" as a possible configuration, too.
> >
> > You can get away with most of that except when the CxO box dies while an
> > email was being sent and its gone. Murphy seems to strike on this one
> > more than statistically should be possible...
>
> If you're doing direct SMTP, then having a writable /var doesn't help in
> this case, either. Hopefully your mail client saves to a file (which
> would be in the home dir) and then does the smtp transaction, removing
> the file from the home dir after that succeeds.
>
The boxes were configured to use the local SMTP for some reason (I dont
know.. I just had to debug the problem). Thus the mail went from
client -> sendmail/var/spool/clientmqueue -> power-outage ooops
The solution was to set up /var/spool/ as a NFS mounted rw. [Getting the
200+ clients to do direct writes and hoping the client did the write
thing with a temp file was left to a grad student who is probably still
rueing the day he crossed my path.]
> 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 katzj at redhat.com Fri Apr 2 01:23:13 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 01 Apr 2004 20:23:13 -0500
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080859600.10899.82.camel@smoogen2.lanl.gov>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
<1080849413.3841.27.camel@localhost.localdomain>
<1080851333.10901.61.camel@smoogen2.lanl.gov>
<1080858915.23310.32.camel@orodruin.boston.redhat.com>
<1080859600.10899.82.camel@smoogen2.lanl.gov>
Message-ID: <1080868993.23812.14.camel@orodruin.boston.redhat.com>
On Thu, 2004-04-01 at 15:46 -0700, Stephen Smoogen wrote:
> The boxes were configured to use the local SMTP for some reason (I dont
> know.. I just had to debug the problem). Thus the mail went from
> client -> sendmail/var/spool/clientmqueue -> power-outage ooops
Heh, that's just sick. How about my statement holding for when the
clients are set up correctly? :-) (ie, if you don't use local sendmail
and just do smtp, then local /var/spool isn't needed)
So yes, the ability to have it, perfectly reasonable. Having it as the
general case, perhaps overkill.
Jeremy
From cmadams at hiwaay.net Fri Apr 2 01:52:33 2004
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 1 Apr 2004 19:52:33 -0600
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080868993.23812.14.camel@orodruin.boston.redhat.com>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
<1080849413.3841.27.camel@localhost.localdomain>
<1080851333.10901.61.camel@smoogen2.lanl.gov>
<1080858915.23310.32.camel@orodruin.boston.redhat.com>
<1080859600.10899.82.camel@smoogen2.lanl.gov>
<1080868993.23812.14.camel@orodruin.boston.redhat.com>
Message-ID: <20040402015233.GB1019993@hiwaay.net>
Once upon a time, Jeremy Katz said:
> Heh, that's just sick. How about my statement holding for when the
> clients are set up correctly? :-) (ie, if you don't use local sendmail
> and just do smtp, then local /var/spool isn't needed)
Way too many programs expect to be able to call /usr/sbin/sendmail to
assume everything will use SMTP. And really, that is how it should be;
why should every program be required to have an SMTP client built-in?
The nice thing about that is that you are pretty much guaranteed that
you can send mail at any time, even if the network is down. Sendmail
(or another local mailer) will queue the mail locally and send it when
it can. It is not a good idea to have things like cron jobs get stuck
or lose their output because a remote SMTP server was unreachable.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
From florin at andrei.myip.org Fri Apr 2 02:24:41 2004
From: florin at andrei.myip.org (Florin Andrei)
Date: 01 Apr 2004 18:24:41 -0800
Subject: Lobby for the re-inclusion of php-imap (and imap c-client)
In-Reply-To: <20040330234005.m4kk8wws044cccwg@mail.hackunix.org>
References: <20040326220510.z408ckcsk808kw40@mail.hackunix.org>
<1080674720.2885.6.camel@rivendell.home.local>
<20040330234005.m4kk8wws044cccwg@mail.hackunix.org>
Message-ID: <1080872680.3147.0.camel@rivendell.home.local>
On Tue, 2004-03-30 at 21:40, Derek P. Moore wrote:
> > Ah, jeez, you mean php-imap is not anymore in the test versions?
> > Why's that?
>
> http://www.redhat.com/archives/fedora-devel-list/2004-February/msg00713.html
>
> Essentially, nobody at Red Hat cares to maintain it.
What???
But how'bout all those webmail servers out there? Doesn't Red Hat care
about them running RH Linux instead of something else?
--
Florin Andrei
http://florin.myip.org/
From toshio at tiki-lounge.com Fri Apr 2 03:05:20 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Thu, 01 Apr 2004 22:05:20 -0500
Subject: qa-assistant version 0.1
Message-ID: <1080875115.28654.50.camel@Madison.badger.com>
Hello all,
As mentioned earlier today, I have been working on a graphical python
app to help with Quality Assurance of Fedora Extras. While it doesn't
have all the features I have planned for it, it does provide enough to
allow a QA newbie to run through the standard checklist and generate a
review template to upload to Fedora.us bugzilla.
Tarball is at:
http://www.tiki-lounge.com/~toshio/software/qa-assistant/qa-assistant-0.1.tar.gz
Since this is a python script, there's no compiling to be done. You
need to have python2.2 (2.3 is untested right now), libxml2-python,
pygtk2, pygtk2-libglade, gnome-python2, and rpm-python (If you have yum
and a few redhat-config-* utilities, these should already be
installed.) Just download, untar, cd into the directory, and
./qa-assistant [PATH TO SRPM]
QA Assistant is a bit inflexible about loading an SRPM to begin the
review, right now. You have to specify it on the commandline. Once
loaded, the application will present you with a checklist that you can
cycle through, checking off Pass, Fail, Non-Blocker, or Not-Applicable
and selecting whether to send the output to the review or not. Clicking
on a cell in the Output Column will allow you to edit the message.
Pressing Ctrl-T will toggle the Preview Pane which shows you
approximately what the Review will look like. Pressing Ctrl-P will
"Publish" the review to a file.
Screenshot of QA-Assistant's Main Interface:
http://www.tiki-lounge.com/~toshio/software/qa-assistant/Main.png
Screenshot of QA-Assistant's Preview Pane:
http://www.tiki-lounge.com/~toshio/software/qa-assistant/Preview.png
Screenshot of a completed Review:
http://www.tiki-lounge.con/~toshio/software/qa-asistant/Review.jpg
I need some help moving QA-Assistant forward. If you'd care to
contribute I need:
- Feedback! What works, what doesn't. What should I fix first and what
should I hold off on?
- XML authors to look at my checklist format and spot anything that
should be implemented some other way
- XML writers to add, subtract, multiply, and divide the fedoraus.xml
checklist description or create new checklists from it.
- Programmers who can take a look at some of my pygtk hacks and tell me
how I could improve the speed and beauty of the app. (I had to write a
custom cell renderer for the checklist's Treeview and another custom
widget for the Preview Pane which is why both of them are tolerable but
not perfect.)
- Programmers to tackle any items in the TODO file.
Suggestions and code welcome.
-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:
From tdiehl at rogueind.com Fri Apr 2 03:33:48 2004
From: tdiehl at rogueind.com (Tom Diehl)
Date: Thu, 1 Apr 2004 22:33:48 -0500 (EST)
Subject: Lobby for the re-inclusion of php-imap (and imap c-client)
In-Reply-To: <1080872680.3147.0.camel@rivendell.home.local>
References: <20040326220510.z408ckcsk808kw40@mail.hackunix.org>
<1080674720.2885.6.camel@rivendell.home.local>
<20040330234005.m4kk8wws044cccwg@mail.hackunix.org>
<1080872680.3147.0.camel@rivendell.home.local>
Message-ID:
On Thu, 1 Apr 2004, Florin Andrei wrote:
> On Tue, 2004-03-30 at 21:40, Derek P. Moore wrote:
> > > Ah, jeez, you mean php-imap is not anymore in the test versions?
> > > Why's that?
> >
> > http://www.redhat.com/archives/fedora-devel-list/2004-February/msg00713.html
> >
> > Essentially, nobody at Red Hat cares to maintain it.
Not true. Please see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115535
> What???
>
> But how'bout all those webmail servers out there? Doesn't Red Hat care
> about them running RH Linux instead of something else?
I do not see why they would care. they never cared b4 why start now.
Squirrelmail does not need it, so in reality it is not as bad as you think.
IAFAIK it is not required for any packages currently included in FC or RHEL.
It is required for things like imp but imp has never been included in any
RHEL, RHL or FC releases. So instead of whining about something that was
discussed to death weeks ago please check your facts first.
HTH,
Tom
From toshio at tiki-lounge.com Fri Apr 2 03:52:12 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Thu, 01 Apr 2004 22:52:12 -0500
Subject: fedora-startqa
In-Reply-To:
References:
<1080844288.32189.27.camel@Madison.badger.com>
Message-ID: <1080877929.28654.70.camel@Madison.badger.com>
Looks good (although mach is giving me problems again so I can't test
all of it.)
Some feedback:
- A NEEDSWORK review is just as valuable as a PUBLISH +1 review. I'd
like to see the script generate that as well.
- (Showing my ignorance of mach) How safe is it to build untrusted
sources within mach? since mach builds the package before the user gets
a chance to go look at whether the Source URL is canonical, I was
wondering....
- Review has "Installs, runs, and uninstalls fine on FC1" but I haven't
done any of that yet -- should it be in TODO?
- The first time I ran it, the script errored out because there was an
old version of an md5sum file on the server that didn't have the package
version I had up there. However, GPG signed SRPMs are equivalent to
checking a GPG signed md5sum file that has an md5sum for the SRPM. So
my view is if the GPG signature on the SRPM is good and the MD5SUM file
doesn't contradict it (ie: different signing keys, different MD5Sums for
the same file) it shouldn't error out.
- I'd like to be able to point at an SRPM instead of into bugzilla in
case I have an SRPM already on my machine that I'd like to check.
-Toshio
--
Toshio
-------------- 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:
From mandreiana at rdslink.ro Fri Apr 2 05:16:24 2004
From: mandreiana at rdslink.ro (Marius Andreiana)
Date: Fri, 02 Apr 2004 08:16:24 +0300
Subject: rawhide report: 20040401 changes
In-Reply-To: <406C384F.30405@sciences.univ-nantes.fr>
References: <1080828758.5304.4.camel@marte.biciclete.ro>
<406C2DE3.1010501@sciences.univ-nantes.fr>
<1080833084.5304.9.camel@marte.biciclete.ro>
<406C3505.4020800@sciences.univ-nantes.fr>
<1080833682.8596.11.camel@opus.phy.duke.edu>
<406C384F.30405@sciences.univ-nantes.fr>
Message-ID: <1080882984.5038.1.camel@marte.biciclete.ro>
On Thu, 2004-04-01 at 18:42, Arnaud Abelard wrote:
> oh duh!
>
> removing kde-* and gnome-* surely sounded weird.. but it reminded my of the
> first build system mails.. i thought "ah.. definitely not perfect this system"
:))
> sorry Marius ;-)
glad I fooled you :P
--
Marius Andreiana
Galuna - Solutii Linux in Romania
http://www.galuna.ro
From hp at redhat.com Fri Apr 2 05:22:02 2004
From: hp at redhat.com (Havoc Pennington)
Date: Fri, 02 Apr 2004 00:22:02 -0500
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <20040402015233.GB1019993@hiwaay.net>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
<1080849413.3841.27.camel@localhost.localdomain>
<1080851333.10901.61.camel@smoogen2.lanl.gov>
<1080858915.23310.32.camel@orodruin.boston.redhat.com>
<1080859600.10899.82.camel@smoogen2.lanl.gov>
<1080868993.23812.14.camel@orodruin.boston.redhat.com>
<20040402015233.GB1019993@hiwaay.net>
Message-ID: <1080883322.3850.87.camel@localhost.localdomain>
On Thu, 2004-04-01 at 20:52, Chris Adams wrote:
> Once upon a time, Jeremy Katz said:
> > Heh, that's just sick. How about my statement holding for when the
> > clients are set up correctly? :-) (ie, if you don't use local sendmail
> > and just do smtp, then local /var/spool isn't needed)
>
> Way too many programs expect to be able to call /usr/sbin/sendmail to
> assume everything will use SMTP. And really, that is how it should be;
> why should every program be required to have an SMTP client built-in?
>
> The nice thing about that is that you are pretty much guaranteed that
> you can send mail at any time, even if the network is down. Sendmail
> (or another local mailer) will queue the mail locally and send it when
> it can. It is not a good idea to have things like cron jobs get stuck
> or lose their output because a remote SMTP server was unreachable.
I think we have to assume that a managed read-only OS image sort of
deployment would have some limitations in possible configurations and
what apps could do. After all the whole point is to lock things down.
One setup would be that each user has an outgoing mail queue in their
home directory, since homedir already has to be writeable by the user
and gets backed up and so forth. Surely you could provide a
/usr/sbin/sendmail that worked this way.
A queue in /var is suboptimal because it partially defeats the purpose
of the deployment model - it leaves per-machine state to be corrupted,
backed up, hacked, etc.
Havoc
From gauret at free.fr Fri Apr 2 06:43:26 2004
From: gauret at free.fr (Aurelien Bompard)
Date: Fri, 02 Apr 2004 08:43:26 +0200
Subject: fedora-startqa
References:
<1080844288.32189.27.camel@Madison.badger.com>
<1080877929.28654.70.camel@Madison.badger.com>
Message-ID:
Thanks for the feedback Toshio !
Toshio wrote:
> - A NEEDSWORK review is just as valuable as a PUBLISH +1 review.??I'd
> like to see the script generate that as well.
Good idea, right now, the idea is to stop if a QA showstopper is found (no
signature, build fails in mach), and let the QA'er write the NEEDSWORK
review. This can be automated a little I think. Added on the TODO list.
> - (Showing my ignorance of mach) How safe is it to build untrusted
> sources within mach???since?mach?builds?the?package?before?the?user?gets
> a chance to go look at whether the Source URL is canonical, I was
> wondering....
Well, you can read the spec file before building in mach, so you can look at
the URLs for the sources, start you browser and have a look. Is that what
you mean ?
> - Review has "Installs, runs, and uninstalls fine on FC1" but I haven't
> done any of that yet -- should it be in TODO?
It is always in the TODO anyway. Erik also thinks that it should not be
there, so I'll remove it, but I've put it there to remember the user to
tell which distro he has tested the package on, and to check
uninstallation. I think that nothing prevents a user from doing a false
review anyway, and I wanted to make a template where nothing but the
"notes" had to be added. Anyway, if the majority thinks it's wrong, let's
remove it.
> - The first time I ran it, the script errored out because there was an
> old version of an md5sum file on the server that didn't have the package
> version I had up there.
Can you give me a bug id ?
> However,?GPG?signed?SRPMs?are?equivalent?to
> checking a GPG signed md5sum file that has an??md5sum?for?the?SRPM.??So
> my view is if the GPG signature on the SRPM is good and the MD5SUM file
> doesn't contradict it (ie: different signing keys, different MD5Sums for
> the same file) it shouldn't error out.
Yes, there is this -c option to disable srpm md5sum checking.
> - I'd like to be able to point at an SRPM instead of into bugzilla in
> case I have an SRPM already on my machine that I'd like to check.
This is already on my TODO list :-)
Thanks for your review
Aur?lien
--
http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info
Hacker vaillant, rien d'impossible.
From russell at coker.com.au Fri Apr 2 06:42:35 2004
From: russell at coker.com.au (Russell Coker)
Date: Fri, 2 Apr 2004 16:42:35 +1000
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080883322.3850.87.camel@localhost.localdomain>
References: <1080687441.10735.55.camel@opus>
<20040402015233.GB1019993@hiwaay.net>
<1080883322.3850.87.camel@localhost.localdomain>
Message-ID: <200404021642.35695.russell@coker.com.au>
On Fri, 2 Apr 2004 15:22, Havoc Pennington wrote:
> One setup would be that each user has an outgoing mail queue in their
> home directory, since homedir already has to be writeable by the user
> and gets backed up and so forth. Surely you could provide a
> /usr/sbin/sendmail that worked this way.
I'm not sure that the user should require write access to their own home
directory, I can think of quite a few cases where denying such access is
desirable. But it's a reasonable trade-off.
The next issue is, how do we get the data out of the user home dir and send it
via SMTP? Do we have a system cron job that goes through user home
directories? If so we would have to make sure it changes it's UID to the
user in question first so sym-link attacks against other users can't be done.
We would also probably want to deny read access to sym-links in SE Linux
policy.
If we don't have a system cron job we could have a script run on startup (same
security issues as a system cron job) and have the "sendmail" program put
itself in the background to keep re-trying the delivery. Of course as
sendmail will run in the user context a "slay" operation or a temporary
problem (such as OOM) will inconveniently stop mail delivery for that user
until the next time the machine is rebooted or the next time that they send a
message. So it seems that a system cron job to go through all users'
directories is the best solution.
Another issue is what happens when the user runs out of quota. We want the
"sendmail" process to run in the user context on non-SE systems so it can't
do any harm, but that means that it gets the same quota. It would be
annoying if the user ran a cron job which used up all their quota and then
rendered itself unable to mail a warning message about being unable to work
due to lack of quota... Of course on SE Linux we can have a SUID program
that is restricted by SE Linux policy, but we do want it to be reasonably
secure on non-SE machines too.
I think that any solution along these lines will have some trade-offs, but
they will be worth it for some users and it will be a good thing to offer.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
From NOS at Utel.no Fri Apr 2 06:52:28 2004
From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=)
Date: Fri, 02 Apr 2004 08:52:28 +0200
Subject: My initial experiances with FC2-test2
In-Reply-To: <000001c41720$39811650$14aaa8c0@utelsystems.local>
References: <000001c41720$39811650$14aaa8c0@utelsystems.local>
Message-ID: <1080888748.18172.9.camel@nos-rh.utelsystems.local>
On Wed, 2004-03-31 at 15:01, Chris Chabot wrote:
> Hi All, just wanted to share a few of my observations while running
> FC2-test2, and maybe make life a little easier for people with the same
> problems as me.
[snip'o'bugs]
> -- Chris
I hope you add these to bugzilla, else they might get lost..
--
Nils Olav Sel?sdal
System Engineer
w w w . u t e l s y s t e m s . c o m
From pertusus at free.fr Fri Apr 2 08:38:54 2004
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 2 Apr 2004 10:38:54 +0200
Subject: RFC: fedora.us QA approval format
In-Reply-To:
References:
<1080844288.32189.27.camel@Madison.badger.com>
Message-ID: <20040402083854.GA2184@free.fr>
> - Check of the srpm md5sum (if it exists)
Maybe here there could be a check that the srpm doesn't install anything wrong
(that is doesn't contain paths) ?
> - Download of the sources, with md5sum check
Maybe the download should't be automatic, such that it is possible to check
that the download url is really the right url (presumably searching first the
project home page with google, in order not to use the url provided in the
srpm, and verifying that it is the right download page), and not one with
bad package ?
> - Support for livna packages
What does this mean ?
Anyway this script is a very good idea.
Pat
From alan at redhat.com Fri Apr 2 09:21:19 2004
From: alan at redhat.com (Alan Cox)
Date: Fri, 2 Apr 2004 04:21:19 -0500
Subject: Lobby for the re-inclusion of php-imap (and imap c-client)
In-Reply-To: <1080872680.3147.0.camel@rivendell.home.local>
References: <20040326220510.z408ckcsk808kw40@mail.hackunix.org>
<1080674720.2885.6.camel@rivendell.home.local>
<20040330234005.m4kk8wws044cccwg@mail.hackunix.org>
<1080872680.3147.0.camel@rivendell.home.local>
Message-ID: <20040402092118.GC22652@devserv.devel.redhat.com>
On Thu, Apr 01, 2004 at 06:24:41PM -0800, Florin Andrei wrote:
> What???
>
> But how'bout all those webmail servers out there? Doesn't Red Hat care
> about them running RH Linux instead of something else?
I was under the impression squirrel didnt need php-imap
From dennis at ausil.us Fri Apr 2 09:26:45 2004
From: dennis at ausil.us (Dennis Gilmore)
Date: Fri, 2 Apr 2004 19:26:45 +1000
Subject: Lobby for the re-inclusion of php-imap (and imap c-client)
In-Reply-To: <20040402092118.GC22652@devserv.devel.redhat.com>
References: <20040326220510.z408ckcsk808kw40@mail.hackunix.org>
<1080872680.3147.0.camel@rivendell.home.local>
<20040402092118.GC22652@devserv.devel.redhat.com>
Message-ID: <200404021926.51918.dennis@ausil.us>
Once upon a time Friday 02 April 2004 7:21 pm, Alan Cox wrote:
> On Thu, Apr 01, 2004 at 06:24:41PM -0800, Florin Andrei wrote:
> > What???
> >
> > But how'bout all those webmail servers out there? Doesn't Red Hat care
> > about them running RH Linux instead of something else?
>
> I was under the impression squirrel didnt need php-imap
It doesnt it uses its own imap implementation.
Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL:
From helios82 at optushome.com.au Fri Apr 2 11:33:45 2004
From: helios82 at optushome.com.au (Matt H)
Date: Fri, 02 Apr 2004 21:33:45 +1000
Subject: anaconda help RFE and other Fedora developmental queries
Message-ID: <1080905625.3100.53.camel@fc1>
Hi guys
I have a few items I'd like to mention:
* I suggest the Help sidebar for the firewall setup section of the
anaconda installation procedure (test2+) should contain some notes
explaining the SELinux extension options available. (i.e. Disabled,
Warn, Active). Sure, people should have read the release notes but
adding this keeps with the trend of briefly documenting each section of
the install procedure.
* Within the system-config-network tool, it is now possible to set up
IPSEC VPN links. ( great!) However, the /usr/bin/internet-druid tools
still lists a wizard for setting up CIPE tunnels. Further, it even fails
mentioning that package "cipe" is needed to continue with the setup.
Now, clearly, this is a hold-over of previous OS releases and as such
should be removed from this Internet Config Tool should it not? (esp.
since Red Hat have explained its dropping of the package from the
distribution due to insecurity issues; see recent discussion on the
fedora-test-list)
On that note, would it not be reasonable to replace this CIPE wizard
with the IPSEC one?
* Fedora Core's rhn-applet still associates somewhat with Red Hat's RHN
service now used exclusively with Enterprise products. (Such as
right-click, "RHN Website", etc.) Is it not reasonable to remove any
mention of "RHN" from this applet's configuration screens/options so as
to not mislead/confuse new users into thinking up2date is still
associated with RNH?
- A small side-issue for up2date: Is there any need to continue
inclusion of the "View Advisory" button within up2date screens?
Currently it provides no intended purpose; is there maybe a future
infrastructure being developed to enable a functional button for this?
My apologies if these issues have already been discussed and/or a
work-in-progress.
Regards,
Matt Hansen.
--
mhelios - www.fedoraforum.org
Registered Linux User #348963 / counter.li.org
GnuPG KeyID: 0xCE9F8922 / gnupg.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:
From ndbecker2 at verizon.net Fri Apr 2 12:20:00 2004
From: ndbecker2 at verizon.net (Neal Becker)
Date: Fri, 2 Apr 2004 07:20:00 -0500
Subject: Just what you always wanted: pstoedit
In-Reply-To: <200404011449.59428.scribusdocs@atlantictechsolutions.com>
References: <20040401170010.012E9751B1@hormel.redhat.com>
<200404011449.59428.scribusdocs@atlantictechsolutions.com>
Message-ID: <200404020720.11003.ndbecker2@verizon.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 01 April 2004 2:49 pm, Peter Linnell wrote:
> > Message: 2
> > Date: Thu, 1 Apr 2004 08:25:56 -0500
> > From: Neal Becker
> > Subject: Just what you always wanted: pstoedit
> > To: fedora-devel-list at redhat.com
> > Message-ID: <200404010826.00794.ndbecker2 at verizon.net>
> > Content-Type: Text/Plain; charset="us-ascii"
> >
> > I have created RPMS for pstoedit. Just what you always wanted! Finally,
> > you can convert ps or pdf graphics to powerpoint to give to your pointy
> > headed boss!
> >
> > pstoedit needs libEMF and plotutils. I have made RPMS for all 3.
> >
> > Now, what exactly do I need to do to submit? Where to upload?
>
> I hope I did not rain on your parade, but I have submitted pstoedit in the
> Fedora QA bugzilla. This is a great app, which can work as a plug-in to
> gsview 4.x. See: https://bugzilla.fedora.us/show_bug.cgi?id=1440
You packaged pstoedit without libEMF? Without libEMF, you can't write WMF,
and that was the whole point (for me, at least).
> libEMF is busted building on Fedora-1 (properly) , even with gcc patches
> poached from other distros. Needs some massaging and it is an abandoned
> project AFAICT. I would be curious to see if it can be made to work
> properly on FC-1 and FC-2..
>
>
libEMF needed only minor patches. I have fed them back to libEMF author, who
approved of them.
I will try to submit, but if you're in a hurry I can post spec files and
patches to all 3 packages here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAbVp5MDqogpR5tkMRAqnsAJ0YuWPHXgrAlQb/XKiyBOFpdBmqgACfSnmK
WiREICkatWFWiY5BmM3G/OQ=
=+zo9
-----END PGP SIGNATURE-----
From twaugh at redhat.com Fri Apr 2 12:21:42 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Fri, 2 Apr 2004 13:21:42 +0100
Subject: rawhide report: 20040331 changes
In-Reply-To: <1080826215.25431.25.camel@moss-spartans.epoch.ncsc.mil>
References: <200403311522.i2VFM5215709@porkchop.devel.redhat.com>
<20040331160715.GR22468@redhat.com>
<1080826215.25431.25.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <20040402122142.GB22468@redhat.com>
On Thu, Apr 01, 2004 at 08:30:15AM -0500, Stephen Smalley wrote:
> On Wed, 2004-03-31 at 11:07, Tim Waugh wrote:
> > A word of warning: the version number of the policy file has changed
> > in the kernel but some userland bits aren't in sync with it, causing
> > file context labelling not to get done. Fresh installs are likely to
> > fail.
>
> What userland bits caused a problem, so that we can avoid similar
> problems in the future?
The script that builds the install image -- it had hard-coded
'policy.15' as one of the files to install, so we weren't actually
getting any policy loaded at all.
I've fixed this in CVS, but until anaconda is rebuilt you can make an
RHupdates directory (next to Fedora/ and images/) and put a policy.16
file, which you can get from rpm2cpio'ing the policy package, in that.
Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From gauret at free.fr Fri Apr 2 12:27:45 2004
From: gauret at free.fr (Aurelien Bompard)
Date: Fri, 02 Apr 2004 14:27:45 +0200
Subject: RFC: fedora.us QA approval format
References:
<1080844288.32189.27.camel@Madison.badger.com>
<20040402083854.GA2184@free.fr>
Message-ID:
Hi Patrice,
>> - Check of the srpm md5sum (if it exists)
>
> Maybe here there could be a check that the srpm doesn't install anything
> wrong (that is doesn't contain paths) ?
Could you clarify that ? I thought the srpm could only contain the sources
and the spec file, without paths. Can it be different ?
>> - Download of the sources, with md5sum check
>
> Maybe the download should't be automatic, such that it is possible to
> check that the download url is really the right url (presumably searching
> first the project home page with google, in order not to use the url
> provided in the srpm, and verifying that it is the right download page),
> and not one with bad package ?
Right now, you get to look at the spec file after the sources check. Then
you can paste the url in you browser and check the location.
>> - Support for livna packages
>
> What does this mean ?
Packages in the non-us section of fedora.us are at rpm.livna.org (usualy,
the problem is software patents or DMCA). This is equivalent to non-us in
Debian and PLF in Mandrake. They use a bugzilla at bugzilla.livna.org and
have the same procedure as fedora.us
> Anyway this script is a very good idea.
Thanks for you support !
Aur?lien
--
http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info
"They that can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." -- Benjamin Franklin
From ndbecker2 at verizon.net Fri Apr 2 12:34:08 2004
From: ndbecker2 at verizon.net (Neal Becker)
Date: Fri, 2 Apr 2004 07:34:08 -0500
Subject: Self-Introduction: Neal Becker
Message-ID: <200404020734.10199.ndbecker2@verizon.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
1. Neal David Becker
2. USA, MD
3. Electrical Engineer
4. Hughes Network Systems
5.
6. I have contributed in small ways to a great number of FOSS projects for
many years. This includes porting many gnu apps to hpux and later to linux.
Most of my contributions are porting, patching, and testing. I am one of the
early supporters of gnu and foss. I have a picture of Linus, and many others
with myself at a picnic in 1995, so you know I can be trusted :)
My programming expertise covers c++ and python, and 20 years of unix sysadmin.
7. gpg --fingerprint 0x9479b643
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
pub 1024D/9479B643 2003-05-14 Neal D. Becker
Key fingerprint = 140C 9552 5895 917E C544 1CEB 303A A882 9479 B643
sub 1024g/7626F584 2003-05-14
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAbV3AMDqogpR5tkMRAi8cAJ9S4YC4IwrdTXf4SEiF9zcEWu2hgQCgjKkW
6BjE+pLHIUtIfS1cF/z4k9U=
=qixb
-----END PGP SIGNATURE-----
From linux at bytebot.net Fri Apr 2 12:56:56 2004
From: linux at bytebot.net (Colin Charles)
Date: Fri, 02 Apr 2004 22:56:56 +1000
Subject: Guides for Fedora Core
In-Reply-To: <1080832634.4753.47.camel@athlon.localdomain>
References: <1080832634.4753.47.camel@athlon.localdomain>
Message-ID: <1080910616.25817.149.camel@hermione>
On Fri, 2004-04-02 at 01:17, Leonard den Ottolander wrote:
> Just wondering if there are any plans to adapt the Red Hat Linux guides
> for Fedora Core. These are very useful guides, but some newbies might
> not understand it if you point them to RHL guides when they are using
> Fedora Core. Also the information available in them will out date over
> time.
This is what the Fedora Docs Project is all about - they have a mailing
list too: fedora-docs-list at redhat.com
And no, they are creating docs from scratch rather than using the
current RHL guides. Further discussion about this should be done at the
above mailing list
--
Colin Charles, byte at aeon.com.my
http://www.bytebot.net/
From ndbecker2 at verizon.net Fri Apr 2 13:02:58 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Fri, 02 Apr 2004 08:02:58 -0500
Subject: anaconda help RFE and other Fedora developmental queries
References: <1080905625.3100.53.camel@fc1>
Message-ID:
Matt H wrote:
> Hi guys
>
> I have a few items I'd like to mention:
>
[...]
> * Within the system-config-network tool, it is now possible to set up
> IPSEC VPN links. ( great!) However, the /usr/bin/internet-druid tools
> still lists a wizard for setting up CIPE tunnels. Further, it even fails
> mentioning that package "cipe" is needed to continue with the setup.
> Now, clearly, this is a hold-over of previous OS releases and as such
> should be removed from this Internet Config Tool should it not? (esp.
> since Red Hat have explained its dropping of the package from the
> distribution due to insecurity issues; see recent discussion on the
> fedora-test-list)
> On that note, would it not be reasonable to replace this CIPE wizard
> with the IPSEC one?
It would be great to add openvpn as well. This is much simpler to setup and
admin than ipsec. IMHO, openvpn should be preferred and ipsec only used
where necessary for interoperability.
From ms-nospam-0306 at arcor.de Fri Apr 2 13:08:13 2004
From: ms-nospam-0306 at arcor.de (Michael Schwendt)
Date: Fri, 2 Apr 2004 15:08:13 +0200
Subject: RFC: fedora.us QA approval format
In-Reply-To: <20040402083854.GA2184@free.fr>
References:
<1080844288.32189.27.camel@Madison.badger.com>
<20040402083854.GA2184@free.fr>
Message-ID: <20040402150813.22caedeb.ms-nospam-0306@arcor.de>
On Fri, 2 Apr 2004 10:38:54 +0200, Patrice Dumas wrote:
> > - Download of the sources, with md5sum check
>
> Maybe the download should't be automatic, such that it is possible to check
> that the download url is really the right url (presumably searching first the
> project home page with google, in order not to use the url provided in the
> srpm, and verifying that it is the right download page), and not one with
> bad package ?
Reviewers should also notice when upstream projects provide detached GPG
signatures, which can be used to verify the published tarballs.
From rms at 1407.org Fri Apr 2 13:12:27 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 02 Apr 2004 14:12:27 +0100
Subject: please include the synaptics X11 driver on FC2
Message-ID: <1080911547.6614.8.camel@roque>
Hi,
I've been using Paul Nasrat's synaptics driver package for some time
without any problems, both with XFree86 and xorg-x11.
This driver is quite essential for many touchpads, so it _would_ be
very nice to include it (starting with test3) in FC2.
Hugs, Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From rms at 1407.org Fri Apr 2 13:17:19 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 02 Apr 2004 14:17:19 +0100
Subject: kudzu blows Linux
Message-ID: <1080911839.6614.14.camel@roque>
Hi,
With acpi=on kudzu blows Linux on this laptop, so I suspect it is
something to do with acpi.
If the problem can't be easily solved, is there any list kudzu checks
for known problems, and is there something that can be used to identify
models like mine so it doesn't blow up?
Here goes lspci, for instance:
00:00.0 Host bridge: ATI Technologies Inc: Unknown device cbb2 (rev 02)
00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M]
00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link
Controller Audio Device (rev 02)
00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV]
00:08.0 Modem: ALi Corporation Intel 537 [M5457 AC-Link Modem]
00:0a.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller
00:0b.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0
controller] (rev 50)
00:0b.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0
controller] (rev 50)
00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
00:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21
IEEE-1394a-2000 Controller (PHY/Link)
00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
00:11.0 Bridge: ALi Corporation M7101 PMU
00:12.0 Ethernet controller: National Semiconductor Corporation DP83815
(MacPhyter) Ethernet Controller
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 340M
If there's something that I can search to give more info, please shoot!
Hugs, Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From laroche at redhat.com Fri Apr 2 13:21:19 2004
From: laroche at redhat.com (Florian La Roche)
Date: Fri, 2 Apr 2004 15:21:19 +0200
Subject: please include the synaptics X11 driver on FC2
In-Reply-To: <1080911547.6614.8.camel@roque>
References: <1080911547.6614.8.camel@roque>
Message-ID: <20040402132119.GA12664@dudweiler.stuttgart.redhat.com>
On Fri, Apr 02, 2004 at 02:12:27PM +0100, Rui Miguel Seabra wrote:
> Hi,
>
> I've been using Paul Nasrat's synaptics driver package for some time
> without any problems, both with XFree86 and xorg-x11.
>
> This driver is quite essential for many touchpads, so it _would_ be
> very nice to include it (starting with test3) in FC2.
Where is that package available?
greetings,
Florian La Roche
From rms at 1407.org Fri Apr 2 13:24:49 2004
From: rms at 1407.org (Rui Miguel Seabra)
Date: Fri, 02 Apr 2004 14:24:49 +0100
Subject: please include the synaptics X11 driver on FC2
In-Reply-To: <20040402132119.GA12664@dudweiler.stuttgart.redhat.com>
References: <1080911547.6614.8.camel@roque>
<20040402132119.GA12664@dudweiler.stuttgart.redhat.com>
Message-ID: <1080912289.6614.18.camel@roque>
On Fri, 2004-04-02 at 15:21 +0200, Florian La Roche wrote:
> On Fri, Apr 02, 2004 at 02:12:27PM +0100, Rui Miguel Seabra wrote:
> > I've been using Paul Nasrat's synaptics driver package for some time
> > without any problems, both with XFree86 and xorg-x11.
> >
> > This driver is quite essential for many touchpads, so it _would_ be
> > very nice to include it (starting with test3) in FC2.
>
> Where is that package available?
http://pauln.truemesh.com/rpms/
Linux 2.6 + Synaptics touchpads == lots of problems without the driver.
I use the following config, currently:
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 "BLCornerButton" "2"
EndSection
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From Fred.New at microlink.ee Fri Apr 2 13:28:46 2004
From: Fred.New at microlink.ee (Fred New)
Date: Fri, 2 Apr 2004 16:28:46 +0300
Subject: rawhide report: 20040331 changes
Message-ID: <345764DCB65C0C4FACC44529DE273C1809C250@eemail1.microlink.lan>
2. aprill 2004. a. 15:22 kirjutas Tim Waugh
> To: Development discussions related to Fedora Core
> Subject: Re: rawhide report: 20040331 changes
>
> On Thu, Apr 01, 2004 at 08:30:15AM -0500, Stephen Smalley wrote:
>
> > On Wed, 2004-03-31 at 11:07, Tim Waugh wrote:
> > > A word of warning: the version number of the policy file has
changed
> > > in the kernel but some userland bits aren't in sync with it,
causing
> > > file context labelling not to get done. Fresh installs are likely
to
> > > fail.
> >
> > What userland bits caused a problem, so that we can avoid similar
> > problems in the future?
>
> The script that builds the install image -- it had hard-coded
> 'policy.15' as one of the files to install, so we weren't actually
> getting any policy loaded at all.
>
> I've fixed this in CVS, but until anaconda is rebuilt you can make an
> RHupdates directory (next to Fedora/ and images/) and put a policy.16
> file, which you can get from rpm2cpio'ing the policy package, in that.
>
> Tim.
> */
>
Would this be why we are getting "/home/" doesn't exist
messages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119597)?
So far, we've found that fixfiles relabel hasn't fixed anything.
Fred
From twaugh at redhat.com Fri Apr 2 13:30:35 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Fri, 2 Apr 2004 14:30:35 +0100
Subject: rawhide report: 20040331 changes
In-Reply-To: <345764DCB65C0C4FACC44529DE273C1809C250@eemail1.microlink.lan>
References: <345764DCB65C0C4FACC44529DE273C1809C250@eemail1.microlink.lan>
Message-ID: <20040402133035.GC22468@redhat.com>
On Fri, Apr 02, 2004 at 04:28:46PM +0300, Fred New wrote:
> Would this be why we are getting "/home/" doesn't exist
> messages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119597)?
> So far, we've found that fixfiles relabel hasn't fixed anything.
If that's the only error message you're getting, no. :-)
This is more likely to be a recently-fixed policy bug.
Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From leonard at den.ottolander.nl Fri Apr 2 14:07:16 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Fri, 02 Apr 2004 16:07:16 +0200
Subject: Guides for Fedora Core
In-Reply-To: <1080910616.25817.149.camel@hermione>
References: <1080832634.4753.47.camel@athlon.localdomain>
<1080910616.25817.149.camel@hermione>
Message-ID: <1080914835.4753.8.camel@athlon.localdomain>
Hi Colon,
> > Just wondering if there are any plans to adapt the Red Hat Linux guides
> > for Fedora Core.
> This is what the Fedora Docs Project is all about - they have a mailing
> list too: fedora-docs-list at redhat.com
>
> And no, they are creating docs from scratch rather than using the
> current RHL guides. Further discussion about this should be done at the
> above mailing list
Ok. Yet another mailing list. But could you explain the rationale behind
that decision here? The devel list seems an appropriate place to at
least hold a summary of such decisions in it's archive. With all these
lists and channels information is fragmented enough as it is.
I can't find such extensive docs for Fedora yet (howto != guide), so why
not maintain them until alternatives are available?
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
From mgalvin at nycap.rr.com Fri Apr 2 14:17:30 2004
From: mgalvin at nycap.rr.com (mgalvin at nycap.rr.com)
Date: Fri, 02 Apr 2004 09:17:30 -0500
Subject: Dependencies not available
Message-ID: <2f748e2f73da.2f73da2f748e@nyroc.rr.com>
sudo yum update
Gathering header information file(s) from server(s)
Server: Fedora Core 1.91 - Development Tree
Finding updated packages
Downloading needed headers
Resolving dependencies
.Package dvgrab needs libdv.so.2, this is not available.
Package pwlib needs libdv.so.2, this is not available.
Package xemacs needs libRKC.so.1.2, this is not available.
Package xemacs needs libcanna.so.1.2, this is not available.
Package ethereal needs libpcap.so.0.8.1, this is not available.
Package ethereal-gnome needs libpcap.so.0.8.1, this is not available.
i get this from all mirrors. are these available somewhere, and if not, when might they be?
-------------------------
M Galvin
Lead Programmer
Simplified Complexity
http://www.simplifiedcomplexity.com
From pauln at truemesh.com Fri Apr 2 14:13:33 2004
From: pauln at truemesh.com (Paul Nasrat)
Date: Fri, 2 Apr 2004 14:13:33 +0000
Subject: Guides for Fedora Core
In-Reply-To: <1080914835.4753.8.camel@athlon.localdomain>
References: <1080832634.4753.47.camel@athlon.localdomain>
<1080910616.25817.149.camel@hermione>
<1080914835.4753.8.camel@athlon.localdomain>
Message-ID: <20040402141333.GY23468@lichen.truemesh.com>
On Fri, Apr 02, 2004 at 04:07:16PM +0200, Leonard den Ottolander wrote:
> Hi Colon,
>
> > > Just wondering if there are any plans to adapt the Red Hat Linux guides
> > > for Fedora Core.
>
> > This is what the Fedora Docs Project is all about - they have a mailing
> > list too: fedora-docs-list at redhat.com
> >
> > And no, they are creating docs from scratch rather than using the
> > current RHL guides. Further discussion about this should be done at the
> > above mailing list
>
> Ok. Yet another mailing list. But could you explain the rationale behind
> that decision here?
The docs project was one of the initial ones setup it's heavily mentioned at
fedora.redhat.com http://fedora.redhat.com/projects/docs/
> The devel list seems an appropriate place to at
> least hold a summary of such decisions in it's archive. With all these
> lists and channels information is fragmented enough as it is.
devel is noisy enough, documentation discussion would just get drowned.
Working on documentation and translation is a different enough activity to
warrant seperation. Where there is overlab - eg the selinux faq cross list
discussion does happen.
> I can't find such extensive docs for Fedora yet (howto != guide), so why
> not maintain them until alternatives are available?
Copyright/license issues I believe, I think this was covered on -docs-list
already, though a quick look through the archives I couldn't find the post.
Paul
From ijuma82 at f2s.com Fri Apr 2 14:21:20 2004
From: ijuma82 at f2s.com (Ismael Juma)
Date: Fri, 02 Apr 2004 15:21:20 +0100
Subject: Arts and dmix.
Message-ID: <406D76E0.7090707@f2s.com>
Hi,
The current released version of Arts does not work with Alsa's dmix
according to:
http://bugs.kde.org/show_bug.cgi?id=76413
http://bugs.kde.org/show_bug.cgi?id=70802
Both bugs have been recently fixed in CVS. I was wondering if there is
any chance of having that patch included in FC2.
Thanks in advance,
Ismael
From linux at bytebot.net Fri Apr 2 14:21:51 2004
From: linux at bytebot.net (Colin Charles)
Date: Sat, 03 Apr 2004 00:21:51 +1000
Subject: Guides for Fedora Core
In-Reply-To: <1080914835.4753.8.camel@athlon.localdomain>
References: <1080832634.4753.47.camel@athlon.localdomain>
<1080910616.25817.149.camel@hermione>
<1080914835.4753.8.camel@athlon.localdomain>
Message-ID: <1080915711.27164.182.camel@hermione>
On Sat, 2004-04-03 at 00:07, Leonard den Ottolander wrote:
> Hi Colon,
Colin, thanks :)
> > This is what the Fedora Docs Project is all about - they have a mailing
> > list too: fedora-docs-list at redhat.com
> >
> > And no, they are creating docs from scratch rather than using the
> > current RHL guides. Further discussion about this should be done at the
> > above mailing list
>
> Ok. Yet another mailing list. But could you explain the rationale behind
> that decision here? The devel list seems an appropriate place to at
> least hold a summary of such decisions in it's archive. With all these
> lists and channels information is fragmented enough as it is.
Erm, its not my decision to create a separate docs project - the docs
project's task is clearly stated at:
http://fedora.redhat.com/projects/docs/
Its just like we don't do translations on f-d-l, as there's
fedora-trans-list
> I can't find such extensive docs for Fedora yet (howto != guide), so why
> not maintain them until alternatives are available?
That's because they're mostly in creation, and aren't ready yet for
prime time. Why not use existing RH9 documents? Karsten has a really
good answer (look at 3&4 together):
https://listman.redhat.com/archives/fedora-docs-list/2003-December/msg00065.html
--
Colin Charles, byte at aeon.com.my
http://www.bytebot.net/
From tdiehl at rogueind.com Fri Apr 2 14:24:00 2004
From: tdiehl at rogueind.com (Tom Diehl)
Date: Fri, 2 Apr 2004 09:24:00 -0500 (EST)
Subject: Guides for Fedora Core
In-Reply-To: <1080914835.4753.8.camel@athlon.localdomain>
References: <1080832634.4753.47.camel@athlon.localdomain>
<1080910616.25817.149.camel@hermione>
<1080914835.4753.8.camel@athlon.localdomain>
Message-ID:
On Fri, 2 Apr 2004, Leonard den Ottolander wrote:
> Hi Colon,
>
> > > Just wondering if there are any plans to adapt the Red Hat Linux guides
> > > for Fedora Core.
>
> > This is what the Fedora Docs Project is all about - they have a mailing
> > list too: fedora-docs-list at redhat.com
> >
> > And no, they are creating docs from scratch rather than using the
> > current RHL guides. Further discussion about this should be done at the
> > above mailing list
>
> Ok. Yet another mailing list. But could you explain the rationale behind
> that decision here? The devel list seems an appropriate place to at
> least hold a summary of such decisions in it's archive. With all these
> lists and channels information is fragmented enough as it is.
I guess because it is easier to keep track of the things going on when you
have a list that has < 50 messages a week. Some weeks it has 0. I would
think that things would tend to get lost in the noise on this list.
> I can't find such extensive docs for Fedora yet (howto != guide), so why
> not maintain them until alternatives are available?
Because Red Hat has them licensed in such a way that they cannot be used on
fedora. I forget the exact details but that is the bottom line.
HTH,
Tom
From dcbw at redhat.com Fri Apr 2 15:18:29 2004
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 02 Apr 2004 10:18:29 -0500
Subject: please include the synaptics X11 driver on FC2
In-Reply-To: <1080912289.6614.18.camel@roque>
References: <1080911547.6614.8.camel@roque>
<20040402132119.GA12664@dudweiler.stuttgart.redhat.com>
<1080912289.6614.18.camel@roque>
Message-ID: <1080919108.14625.2.camel@dcbw.boston.redhat.com>
This driver has worked quite well with FC1 and FC2 so far, a vote +1
from me.
Dan
On Fri, 2004-04-02 at 14:24 +0100, Rui Miguel Seabra wrote:
> On Fri, 2004-04-02 at 15:21 +0200, Florian La Roche wrote:
> > On Fri, Apr 02, 2004 at 02:12:27PM +0100, Rui Miguel Seabra wrote:
> > > I've been using Paul Nasrat's synaptics driver package for some time
> > > without any problems, both with XFree86 and xorg-x11.
> > >
> > > This driver is quite essential for many touchpads, so it _would_ be
> > > very nice to include it (starting with test3) in FC2.
> >
> > Where is that package available?
>
> http://pauln.truemesh.com/rpms/
>
> Linux 2.6 + Synaptics touchpads == lots of problems without the driver.
>
> I use the following config, currently:
>
> 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 "BLCornerButton" "2"
> EndSection
>
> Rui
> --
> + No matter how much you do, you never do enough -- unknown
> + Whatever you do will be insignificant,
> | but it is very important that you do it -- Gandhi
> + So let's do it...?
>
> Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
> See http://www.fsf.org/philosophy/no-word-attachments.html
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
From leonard at den.ottolander.nl Fri Apr 2 15:44:05 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Fri, 02 Apr 2004 17:44:05 +0200
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080851333.10901.61.camel@smoogen2.lanl.gov>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
<1080849413.3841.27.camel@localhost.localdomain>
<1080851333.10901.61.camel@smoogen2.lanl.gov>
Message-ID: <1080920644.4753.62.camel@athlon.localdomain>
Hi Stephen,
> The other version was one that would partition the laptop disk
> into 'mirrors' of itself.
I do something like this on a server, to be able to boot back into a
known good state if an update ruins the system.
> /boot -- 1 I think
In my setup I use two boot partitions (or actually /boot is part of /1
and /2). This is especially useful when doing kernel updates (instead of
installs), like SuSE does.
> /1
> /2
> /home -- 1 I think
Yes, user data is shared. Also share /var/log and /var/spool (and /srv),
but not /var/lib (rpmdb etc). Another proof of how messy /var is...
> boot is set up to boot into say /1 the first time, and then the asyncd
> updates /2 to whatever the network says it should be.
I just rsync the known good system to /mnt/backsys (which is /2) before
an update, but then my setup is used to be able to roll back, not
forward :) .
> Grub is changed appropriately
In this roll back setup it is also important to adjust /etc/fstab
according to the / partition. It's an integral part of the rsync
scriplet I use. Seems to work flawlessly, but luckily I never had to
rely on it (knock on wood ;) .
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
From toshio at tiki-lounge.com Fri Apr 2 15:46:24 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Fri, 02 Apr 2004 10:46:24 -0500
Subject: fedora-startqa
In-Reply-To:
References:
<1080844288.32189.27.camel@Madison.badger.com>
<1080877929.28654.70.camel@Madison.badger.com>
Message-ID: <1080920782.28654.92.camel@Madison.badger.com>
On Fri, 2004-04-02 at 01:43, Aurelien Bompard wrote:
> > - (Showing my ignorance of mach) How safe is it to build untrusted
> > sources within mach? since mach builds the package before the user gets
> > a chance to go look at whether the Source URL is canonical, I was
> > wondering....
>
> Well, you can read the spec file before building in mach, so you can look at
> the URLs for the sources, start you browser and have a look. Is that what
> you mean ?
Two problems:
1) In batch mode, the human element is missing. If it is insecure,
there needs to be a way to disable mach building from the commandline.
2) If the script is aimed at newbies, there should be a warning of the
potential dangers of building the source package and what can be done to
reduce that risk. In qa-assistant's checklist, I tried to create a list
of High Security items that should be evaluate before the reviewer
started doing anything else. Maybe a list like that (minus things that
are checked automatically) spit out to the screen before viewing the
spec file?
> > - The first time I ran it, the script errored out because there was an
> > old version of an md5sum file on the server that didn't have the package
> > version I had up there.
>
> Can you give me a bug id ?
>
I corrected the out of date md5sum file (It was with a package that I
had control over.) I'll try re-provoking the bug (or tracing it in the
code) when I have a bit of time.
> > However, GPG signed SRPMs are equivalent to
> > checking a GPG signed md5sum file that has an md5sum for the SRPM. So
> > my view is if the GPG signature on the SRPM is good and the MD5SUM file
> > doesn't contradict it (ie: different signing keys, different MD5Sums for
> > the same file) it shouldn't error out.
>
> Yes, there is this -c option to disable srpm md5sum checking.
>
I'll give this a try too. I think, though, what I want is for the
script to automatically make a decision that an SRPM with a valid GPG
does not have to have it's md5sum checked.
Slightly more paranoid is to make the following checks:
1] GPG signature of SRPM
2] Is the md5sum of the relevant SRPM in the md5sum file?
3] GPG signature of md5sum file
4] Did the same key sign both files?
If all pass, then pass the test.
If 1] Pass and 2] Is fail, pass the test.
All other cases fail.
--
_______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:
From pauln at truemesh.com Fri Apr 2 15:38:28 2004
From: pauln at truemesh.com (Paul Nasrat)
Date: Fri, 2 Apr 2004 15:38:28 +0000
Subject: please include the synaptics X11 driver on FC2
In-Reply-To: <1080919108.14625.2.camel@dcbw.boston.redhat.com>
References: <1080911547.6614.8.camel@roque>
<20040402132119.GA12664@dudweiler.stuttgart.redhat.com>
<1080912289.6614.18.camel@roque>
<1080919108.14625.2.camel@dcbw.boston.redhat.com>
Message-ID: <20040402153827.GC23468@lichen.truemesh.com>
On Fri, Apr 02, 2004 at 10:18:29AM -0500, Dan Williams wrote:
> This driver has worked quite well with FC1 and FC2 so far, a vote +1
> from me.
The main issue remaining is letting system-config-mouse configure it
appropriately. The changes don't look too hard but if the driver is to go in
having the configuration done automatically makes sense. kudzu already probes
for synaptics.
Paul
From leonard at den.ottolander.nl Fri Apr 2 15:53:14 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Fri, 02 Apr 2004 17:53:14 +0200
Subject: Guides for Fedora Core
In-Reply-To: <20040402141333.GY23468@lichen.truemesh.com>
References: <1080832634.4753.47.camel@athlon.localdomain>
<1080910616.25817.149.camel@hermione>
<1080914835.4753.8.camel@athlon.localdomain>
<20040402141333.GY23468@lichen.truemesh.com>
Message-ID: <1080921194.4753.68.camel@athlon.localdomain>
Hi Paul,
> devel is noisy enough, documentation discussion would just get drowned.
> Working on documentation and translation is a different enough activity to
> warrant seperation. Where there is overlab - eg the selinux faq cross list
> discussion does happen.
I was not suggesting to have all those discussions here, just the reason
why we don't use the Red Hat guides as a starting point. Ie, just the
conclusion of a discussion that has taken place elsewhere.
> Copyright/license issues I believe, I think this was covered on -docs-list
> already, though a quick look through the archives I couldn't find the post.
Ok. I didn't know these weren't open docs.
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
From katzj at redhat.com Fri Apr 2 15:57:00 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 02 Apr 2004 10:57:00 -0500
Subject: anaconda help RFE and other Fedora developmental queries
In-Reply-To: <1080905625.3100.53.camel@fc1>
References: <1080905625.3100.53.camel@fc1>
Message-ID: <1080921420.17714.8.camel@isengard>
On Fri, 2004-04-02 at 06:33, Matt H wrote:
> * I suggest the Help sidebar for the firewall setup section of the
> anaconda installation procedure (test2+) should contain some notes
> explaining the SELinux extension options available. (i.e. Disabled,
> Warn, Active). Sure, people should have read the release notes but
> adding this keeps with the trend of briefly documenting each section of
> the install procedure.
It will, it's just difficult to get it documented when I'm adding it at
the very last minute ;-) Especially as that screen is probably going to
be slightly in flux as I try to make things a little clearer, so I don't
want to have too much documentation needing to be written more than
once.
Jeremy
From leonard at den.ottolander.nl Fri Apr 2 15:57:31 2004
From: leonard at den.ottolander.nl (Leonard den Ottolander)
Date: Fri, 02 Apr 2004 17:57:31 +0200
Subject: Guides for Fedora Core
In-Reply-To: <1080915711.27164.182.camel@hermione>
References: <1080832634.4753.47.camel@athlon.localdomain>
<1080910616.25817.149.camel@hermione>
<1080914835.4753.8.camel@athlon.localdomain>
<1080915711.27164.182.camel@hermione>
Message-ID: <1080921450.4753.74.camel@athlon.localdomain>
Hi Colin,
> > Hi Colon,
>
> Colin, thanks :)
LOL. It was not my intention to be calling you names ;-) .
> Erm, its not my decision to create a separate docs project - the docs
> project's task is clearly stated at:
> http://fedora.redhat.com/projects/docs/
The thought just came up, but I know I should be doing some reading up.
> Why not use existing RH9 documents? Karsten has a really
> good answer (look at 3&4 together):
> https://listman.redhat.com/archives/fedora-docs-list/2003-December/msg00065.html
Ok, reading up on that right now.
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
From buildsys at redhat.com Fri Apr 2 16:40:46 2004
From: buildsys at redhat.com (Build System)
Date: Fri, 2 Apr 2004 11:40:46 -0500
Subject: rawhide report: 20040402 changes
Message-ID: <200404021640.i32GekV16080@porkchop.devel.redhat.com>
Updated Packages:
apr-util-0.9.4-14
-----------------
* Thu Apr 01 2004 Joe Orton 0.9.4-14
- fix use of SHA1 passwords (#119651)
boost-1.31.0-4
--------------
* Tue Mar 30 2004 Benjamin Kosnik
- Remove bjam dependency. (via Graydon).
- Fix installed library names.
- Fix SONAMEs in shared libraries.
- Fix installed header location.
- Fix installed permissions.
* Fri Feb 13 2004 Elliot Lee
- rebuilt
bug-buddy-2.6.0-1
-----------------
* Thu Apr 01 2004 Alex Larsson 1:2.6.0-1
- update to 2.6.0
ckermit-8.0.209-7
-----------------
* Thu Apr 01 2004 Jeff Johnson 8.0.209-7
- remove old copyright from description (#115952).
control-center-2.6.0.3-1
------------------------
* Fri Apr 02 2004 Alex Larsson 1:2.6.0.3-1
- update to 2.6.0.3
eel2-2.6.0-1
------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
eog-2.6.0-1
-----------
* Fri Apr 02 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
file-roller-2.6.0-1
-------------------
* Fri Apr 02 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
gaim-0.76-2
-----------
* Thu Apr 01 2004 Warren Togami 0.76-2
- 0.76
gdm-2.6.0.0-1
-------------
* Thu Apr 01 2004 Alex Larsson 1:2.6.0.0-1
- update to 2.6.0.0
ggv-2.6.0-1
-----------
* Fri Apr 02 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
glade2-2.5.0-1
--------------
* Fri Apr 02 2004 Mark McLoughlin 2.5.0-1
- Update to 2.5.0
gmp-4.1.2-14
------------
* Wed Mar 31 2004 Thomas Woerner 4.1.2-14
- dropped RPATH (#118506)
gnome-applets-2.6.0-1
---------------------
* Wed Mar 31 2004 Mark McLoughlin 2.6.0-1
- Update to 2.6.0
gnome-games-2.6.0.1-1
---------------------
* Fri Apr 02 2004 Mark McLoughlin 2.6.0.1-1
- Update to 2.6.0.1
gnome-icon-theme-1.2.0-1
------------------------
* Thu Apr 01 2004 Alex Larsson 1.2.0-1
- update to 1.2.0
gnome-keyring-0.2.0-1
---------------------
* Thu Apr 01 2004 Alex Larsson 0.2.0-1
- update to 0.2.0
gnome-media-2.6.0-1
-------------------
* Fri Apr 02 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
gnome-netstatus-2.6.0.1-1
-------------------------
* Wed Mar 31 2004 Mark McLoughlin 2.6.0.1-1
- Update to 2.6.0.1
- Re-do the symlinks for translated docs
gnome-system-monitor-2.6.0-1
----------------------------
* Fri Apr 02 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
gnome-user-docs-2.6.0.1-1
-------------------------
* Fri Apr 02 2004 Mark McLoughlin 2.6.0.1-1
- Update to 2.6.0.1
gnome-utils-2.6.0-1
-------------------
* Fri Apr 02 2004 Alex Larsson 1:2.6.0-1
- update to the 2.6 releases
gok-0.10.0-1
------------
* Fri Apr 02 2004 Mark McLoughlin 0.10.0-1
- Update to 0.10.0
gpdf-0.131-1
------------
* Fri Apr 02 2004 Mark McLoughlin 0.131-1
- Update to 0.131
gthumb-2.3.2-1
--------------
* Fri Apr 02 2004 Mark McLoughlin 2.3.2-1
- Update to 2.3.2
gtkam-0.1.10-5
--------------
* Fri Apr 02 2004 Tim Waugh 0.1.10-5
- Don't fork()/exit() since GTK+ quits; use system() instead (bug #119094).
gtkhtml2-2.6.0-1
----------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
gtksourceview-1.0.0-1
---------------------
* Fri Apr 02 2004 Alex Larsson 1.0.0-1
- update to 1.0.0
im-sdk-11.4-33
--------------
* Thu Apr 01 2004 Akira TAGOH 1:11.4-33
- rebuilt against the latest Canna to satisfy the dependency.
* Sun Mar 28 2004 Yu Shao 1:11.4-32
- fixed typos in -bin_dir.patch
* Fri Mar 26 2004 Yu Shao 1:11.4-31
- moved all binaries to /usr/sbin to make SElinux happy
kdenetwork-3.2.1-5
------------------
* Thu Apr 01 2004 Than Ngo 3.2.1-5
- fix kget issue, bug #117395
* Mon Mar 29 2004 Than Ngo 3.2.1-4
- cleanup KDE/GNOME menus
kernel-2.6.4-1.303
------------------
* Tue Mar 30 2004 Arjan van de Ven
- 2.6.5-rc3
- fix PCI posting bug in i830 DRM
* Mon Mar 29 2004 Arjan van de Ven
- 2.6.5-rc2-bk8
* Mon Mar 29 2004 Dave Jones
- Include latest agpgart fixes.
libbonoboui-2.6.0-1
-------------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
libgnome-2.6.0-1
----------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
* Thu Mar 11 2004 Alex Larsson 2.5.91-2
- enable gtk-doc
* Wed Mar 10 2004 Mark McLoughlin 2.5.91-1
- Update to 2.5.91
libgnomecanvas-2.6.0-1
----------------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
libgnomeprint22-2.6.0-1
-----------------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
libgnomeprintui22-2.6.0-1
-------------------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
libgnomeui-2.6.0-1
------------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
librsvg2-2.6.4-1
----------------
* Thu Apr 01 2004 Alex Larsson 2.6.4-1
- update to 2.6.4
libselinux-1.9-1
----------------
* Thu Apr 01 2004 Dan Walsh 1.9-1
- Update to match NSA
- Cleanup some man pages
* Tue Mar 30 2004 Dan Walsh 1.8-1
- Upgrade to latest from NSA
* Thu Mar 25 2004 Dan Walsh 1.6-6
- Add Russell's Man pages
libxklavier-1.00-1
------------------
* Fri Apr 02 2004 Alex Larsson 1.00-1
- update to 1.00
* Mon Mar 15 2004 Bill Nottingham
- fix typo (#118237)
libxslt-1.1.5-1
---------------
* Tue Mar 23 2004 Daniel Veillard
- upstream release 1.1.5 see http://xmlsoft.org/XSLT/news.html
* Sun Nov 02 2003 Daniel Veillard
- cleanup, removal of the deprecated breakpoint library and
automated libxml2 dependancy level in the generated spec file.
* Wed Oct 23 2002 Daniel Veillard
- revamped the spec file, cleaned up some rpm building problems
metacity-2.8.0-1
----------------
* Thu Apr 01 2004 Alex Larsson 2.8.0-1
- update to 2.8.0
nano-1.2.3-1
------------
* Fri Apr 02 2004 Florian La Roche
- 1.2.3
nautilus-2.6.0-1
----------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
* Tue Mar 16 2004 Mike A. Harrisn 2.5.91-2
- Changed BuildRequires: XFree86-libs >= 4.2.99 to BuildRequires: XFree86-devel
- Fixed BuildRoot to use _tmppath instead of /var/tmp
* Mon Mar 15 2004 Alex Larsson 2.5.91-1
- update to 2.5.91
nautilus-cd-burner-2.6.0-1
--------------------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
nautilus-media-0.8.0-1
----------------------
* Fri Apr 02 2004 Alex Larsson 0.8.0-1
- update to 0.8.0
policy-1.9.2-5
--------------
* Thu Apr 01 2004 Dan Walsh 1.9.2-5
- fix Makefile
* Thu Apr 01 2004 Dan Walsh 1.9.2-4
- fix login
* Thu Apr 01 2004 Dan Walsh 1.9.2-3
- Fix su to not read homedir
policycoreutils-1.9.1-1
-----------------------
* Thu Apr 01 2004 Dan Walsh 1.9.1-1
- Check return codes in sestatus.c
rp-pppoe-3.5-14
---------------
* Thu Apr 01 2004 Than Ngo 3.5-14
- fixed typo
rpmdb-fedora-1.91-0.20040402
----------------------------
sendmail-8.12.11-4.4
--------------------
* Fri Apr 02 2004 Thomas Woerner 8.12.11-4.4
- fixed alternatives slave for sendmail.sendmail
* Thu Apr 01 2004 Thomas Woerner 8.12.11-4.3
- set path to cyrus-imapd deliver
startup-notification-0.6-1
--------------------------
* Thu Apr 01 2004 Mark McLoughlin 0.6-1
- Update to 0.6
sudo-1.6.7p5-25
---------------
* Thu Apr 01 2004 Thomas Woerner 1.6.7p5-25
- fixed spec file: sesh in file section with selinux flag (#119682)
system-config-boot-0.2.5-1
--------------------------
* Fri Apr 02 2004 Harald Hoyer - 0.2.5-1
- translation updates
- renaming of desktop file
system-config-proc-0.28-1
-------------------------
* Fri Apr 02 2004 Harald Hoyer - 0.28-1
- translation update
* Mon Mar 15 2004 Harald Hoyer - 0.27-1
- translation update
usermode-1.70-2
---------------
* Thu Apr 01 2004 Dan Walsh 1.70-1
- Change user context to "root" if username context "user_t" not in passwd file
xorg-x11-0.6.6-0.2004_03_30.1
-----------------------------
* Tue Mar 30 2004 Mike A. Harris 0.6.6-0.2004_03_30.1
- Added xorg-ppc64-support-updates.patch back, as PPC64 fixes were reverted
upstream .
* Tue Mar 30 2004 Mike A. Harris 0.6.6-0.2004_03_30.0
- Updated main xorg tarball to CVS snapshot 2004_03_30 from today.
- Removed XFree86-4.3.0-radeon-dpms-on-dvi-v2.patch as it should no longer be
needed with current Radeon driver.
- Removed patches already merged into new upstream tarball, including:
- xorg-redhat-elfloader-linux-non-exec-stack.patch
- xorg-x11-addrinuse.patch
- xorg-x11-Xft-freetype-bitmap-font-fix.patch
- Split out xorg-redhat-ia64-plt-prot-exec-fix.patch from libGL-exec-shield
patch, as it was unrelated to libGL-exec-shield fixes. (#119324)
- Removed fonttosfnt* from the file lists as it has been removed upstream now
- Updated file list for libXft.so.2.1.2
yelp-2.6.0-1
------------
* Thu Apr 01 2004 Alex Larsson 2.6.0-1
- update to 2.6.0
From twaugh at redhat.com Fri Apr 2 17:10:41 2004
From: twaugh at redhat.com (Tim Waugh)
Date: Fri, 2 Apr 2004 18:10:41 +0100
Subject: rawhide report: 20040402 changes
In-Reply-To: <200404021640.i32GekV16080@porkchop.devel.redhat.com>
References: <200404021640.i32GekV16080@porkchop.devel.redhat.com>
Message-ID: <20040402171041.GD22468@redhat.com>
To boot today's boot.iso you'll need to supply 'vdso=0' on the boot
line.
Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From erik at totalcirculation.com Fri Apr 2 17:29:29 2004
From: erik at totalcirculation.com (Erik LaBianca)
Date: Fri, 2 Apr 2004 12:29:29 -0500
Subject: fedora-startqa
Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABB@smith.interlink.local>
> Two problems:
> 1) In batch mode, the human element is missing. If it is insecure,
> there needs to be a way to disable mach building from the commandline.
>
> 2) If the script is aimed at newbies, there should be a warning of the
> potential dangers of building the source package and what can be done
to
> reduce that risk. In qa-assistant's checklist, I tried to create a
list
> of High Security items that should be evaluate before the reviewer
> started doing anything else. Maybe a list like that (minus things
that
> are checked automatically) spit out to the screen before viewing the
> spec file?
>
The whole point of building from within mach is that it IS secure. If it
isn't, it is a bug in the linux chroot system or mach and must be fixed
there. Mach builds are also run as a user, so in order to destroy a
system the SRPM would have to be able to both break a chroot jail and
have a local root exploit applicable to the reviewers currently running
kernel.
In my opinion, we can assume that a build from within mach is secure.
Obviously, you should be doing QA under a dedicated user account as
well.
> I'll give this a try too. I think, though, what I want is for the
> script to automatically make a decision that an SRPM with a valid GPG
> does not have to have it's md5sum checked.
>
> Slightly more paranoid is to make the following checks:
> 1] GPG signature of SRPM
> 2] Is the md5sum of the relevant SRPM in the md5sum file?
> 3] GPG signature of md5sum file
> 4] Did the same key sign both files?
>
> If all pass, then pass the test.
> If 1] Pass and 2] Is fail, pass the test.
> All other cases fail.
I don't see the point in this. All it adds is protection against the
unlikely case that there is a bug in the MD5 checksum code or crypto
routines included in GPG. These tools are designed and tested to be
reliable, second guessing them is a waste of time. If you know enough
about crypto to prove its necessary, I suggest applying that knowledge
to improving those tools.
You still haven't necessarily verified the gpg signature against a web
of trust, which is FAR more likely to be the source of a problem. I'm
not really involved with any of these (webs of trust), but when we
convert the script over to checking RPM sigs using GPG (imminent) we can
indicate whether or not the signature that passed was a "trusted" one in
your review accounts gpg keyring.
In my opinion, the only reason to deal with MD5sums at all is they are
an easy "look at the screen and compare them" method of knowing the
reviewer's reviewed the same SRPM that the author posted. Otherwise, the
author could change the SRPM (but not the filename), resign it, and two
reviewers would end up reviewing different packages and never know it.
MD5Sums obviously provide an easy method of checking download integrity
as well.
Thanks for your input!
--erik
From erik at totalcirculation.com Fri Apr 2 17:38:51 2004
From: erik at totalcirculation.com (Erik LaBianca)
Date: Fri, 2 Apr 2004 12:38:51 -0500
Subject: RFC: fedora.us QA approval format
Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABC@smith.interlink.local>
> > > - Download of the sources, with md5sum check
> >
> > Maybe the download should't be automatic, such that it is possible
to
> check
> > that the download url is really the right url (presumably searching
> first the
> > project home page with google, in order not to use the url provided
in
> the
> > srpm, and verifying that it is the right download page), and not one
> with
> > bad package ?
Re: automatic downloading. My thought is that it's fine to be automatic,
since we print out the url that was downloaded in the TODO section to be
checked manually by the user as they see fit.
The TODO list is currently eliminated in batch mode, but not for long.
>
> Reviewers should also notice when upstream projects provide detached
GPG
> signatures, which can be used to verify the published tarballs.
>
Agreed. I think it's going to have to be left up to the documentation
for now though, since I'm not aware of many standards for how this is
done. We could probably check for SRPMFILENAME.sig or something though,
I guess. Any thoughts?
--erik
From erik at totalcirculation.com Fri Apr 2 17:49:22 2004
From: erik at totalcirculation.com (Erik LaBianca)
Date: Fri, 2 Apr 2004 12:49:22 -0500
Subject: fedora-startqa
Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@smith.interlink.local>
>
> > - A NEEDSWORK review is just as valuable as a PUBLISH +1 review.??I'd
> > like to see the script generate that as well.
>
> Good idea, right now, the idea is to stop if a QA showstopper is found (no
> signature, build fails in mach), and let the QA'er write the NEEDSWORK
> review. This can be automated a little I think. Added on the TODO list.
>
My personal opinion is that there shouldn't be a PUBLISH++ in the review template that is automatically output unless we are automatically doing ALL showstopper checks correctly, and the package passes. Currently we can't automate name checking, installation / uninstallation, or complete source checking, so we shouldn't print it out.
Whether or not we should print out "NEEDSWORK++" or something similar is up for debate, probably a good idea.
> > - (Showing my ignorance of mach) How safe is it to build untrusted
> > sources within mach???since?mach?builds?the?package?before?the?user?gets
> > a chance to go look at whether the Source URL is canonical, I was
> > wondering....
I think I tackled this on in another email. Synopsis: mach is defined as a secure build environment. If it breaks, we need to fix mach. The truly paranoid should do QA under a vserver, UML or even better on a dedicated machine.
>
> > - Review has "Installs, runs, and uninstalls fine on FC1" but I haven't
> > done any of that yet -- should it be in TODO?
>
> It is always in the TODO anyway. Erik also thinks that it should not be
> there, so I'll remove it, but I've put it there to remember the user to
> tell which distro he has tested the package on, and to check
> uninstallation. I think that nothing prevents a user from doing a false
> review anyway, and I wanted to make a template where nothing but the
> "notes" had to be added. Anyway, if the majority thinks it's wrong, let's
> remove it.
>
My preference is for the review template to have a series of "blanks" to be filled in by the reviewer. A script like qa-assistant could take the output of our automated program and provide hand-holding for the user through filling in the rest of the items.
I prefer to have a series of lines like this:
Builds OK?: YES (fc1,rh9) NO(rh8)
Name OK?: unchecked
(Un)Installs OK?: unchecked
Secure?: unchecked
The idea here being that the reviewer has a very brief idea of what is required to complete the review beyond what we do automatically, and must sign their name to the fact that they've checked those things when they change "unchecked" to YES.
If they didn't bother to do either, but posted the review anyway, it would still be a useful data point.
> > However,?GPG?signed?SRPMs?are?equivalent?to
> > checking a GPG signed md5sum file that has an??md5sum?for?the?SRPM.??So
> > my view is if the GPG signature on the SRPM is good and the MD5SUM file
> > doesn't contradict it (ie: different signing keys, different MD5Sums for
> > the same file) it shouldn't error out.
>
> Yes, there is this -c option to disable srpm md5sum checking.
>
Agreed. MD5sum's should just be printed out and noted to be checked if they don't exist or mismatch in my opinion. See rant in previous email.
--erik
From skvidal at phy.duke.edu Fri Apr 2 17:52:01 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 02 Apr 2004 12:52:01 -0500
Subject: fedora-startqa
In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@smith.interlink.local>
References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@smith.interlink.local>
Message-ID: <1080928321.16354.27.camel@opus.phy.duke.edu>
> I think I tackled this on in another email. Synopsis: mach is defined
> as a secure build environment. If it breaks, we need to fix mach. The
> truly paranoid should do QA under a vserver, UML or even better on a
> dedicated machine.
>
ok, no it's not defined that way.
mach is a program to let you build packages in known-consistent build
roots - it is not secure - someone could have an evil package spec file
that can get out of the chroot and destroy you and your system(and your
little dog, too)
mach+djinni - is much more secure - but not mach by itself.
mach was never intended to be so.
-sv
From erik at totalcirculation.com Fri Apr 2 17:59:00 2004
From: erik at totalcirculation.com (Erik LaBianca)
Date: Fri, 2 Apr 2004 12:59:00 -0500
Subject: fedora-startqa
Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABE@smith.interlink.local>
>
> > I think I tackled this on in another email. Synopsis: mach is
defined
> > as a secure build environment. If it breaks, we need to fix mach.
The
> > truly paranoid should do QA under a vserver, UML or even better on a
> > dedicated machine.
> >
>
> ok, no it's not defined that way.
>
> mach is a program to let you build packages in known-consistent build
> roots - it is not secure - someone could have an evil package spec
file
> that can get out of the chroot and destroy you and your system(and
your
> little dog, too)
>
> mach+djinni - is much more secure - but not mach by itself.
>
> mach was never intended to be so.
>
I don't disagree that mach wasn't designed to be secure, but otoh, the
methodology it uses isn't by definition insecure, either.
Well it DOES still chroot. It's not supposed to be easy to break a
chroot. Do you have an example package that breaks it? What is djinni,
and why isn't it included in mach if it makes it secure enough for
casual use?
--erik
From ndbecker2 at verizon.net Fri Apr 2 18:07:38 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Fri, 02 Apr 2004 13:07:38 -0500
Subject: Dependencies not available
References: <2f748e2f73da.2f73da2f748e@nyroc.rr.com>
Message-ID:
mgalvin at nycap.rr.com wrote:
> sudo yum update
> Gathering header information file(s) from server(s)
> Server: Fedora Core 1.91 - Development Tree
> Finding updated packages
> Downloading needed headers
> Resolving dependencies
> .Package dvgrab needs libdv.so.2, this is not available.
> Package pwlib needs libdv.so.2, this is not available.
> Package xemacs needs libRKC.so.1.2, this is not available.
> Package xemacs needs libcanna.so.1.2, this is not available.
> Package ethereal needs libpcap.so.0.8.1, this is not available.
> Package ethereal-gnome needs libpcap.so.0.8.1, this is not available.
>
> i get this from all mirrors. are these available somewhere, and if not,
> when might they be?
>
Just FYI, I get precisely the same result here.
From ms-nospam-0306 at arcor.de Fri Apr 2 18:10:29 2004
From: ms-nospam-0306 at arcor.de (Michael Schwendt)
Date: Fri, 2 Apr 2004 20:10:29 +0200
Subject: fedora-startqa
In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABE@smith.interlink.local>
References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABE@smith.interlink.local>
Message-ID: <20040402201029.6714958d.ms-nospam-0306@arcor.de>
On Fri, 2 Apr 2004 12:59:00 -0500, Erik LaBianca wrote:
> What is djinni,
> and why isn't it included in mach if it makes it secure enough for
> casual use?
http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/
From erik at totalcirculation.com Fri Apr 2 18:50:19 2004
From: erik at totalcirculation.com (Erik LaBianca)
Date: Fri, 2 Apr 2004 13:50:19 -0500
Subject: fedora-startqa
Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABF@smith.interlink.local>
> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-
> bounces at redhat.com] On Behalf Of Michael Schwendt
> Sent: Friday, April 02, 2004 1:10 PM
> To: Development discussions related to Fedora Core
> Subject: Re: fedora-startqa
>
> On Fri, 2 Apr 2004 12:59:00 -0500, Erik LaBianca wrote:
>
> > What is djinni,
> > and why isn't it included in mach if it makes it secure enough for
> > casual use?
>
> http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/
>
Ok so now I know what djinni is. And it does nothing to increase the
security of mach. It says "vserver-djinni is used to do privileged tasks
like directory mounting in unprivileged vservers.".
It is in fact a workaround to using a vserver kernel, which I did note
as a possible security improvement for someone willing to invest the
time to figure it out.
All that being said, to my knowledge vserver consists of a patched
chroot call, a series of capabilities and resource limitations, process
tree separation, and a bunch of tools to facilitate binding to a single
network alias, etc. Most of this stuff is irrelevant to building as an
unprivileged user.
I'd like someone to please demonstrate how building under a chroot
running under a non-privileged user is a true security risk to a
development machine. Moreso than, for instance, exposing an http or ssh
daemon. An SRPM will do fine. Again, the system is supposed to be secure
against local root exploits from unprivileged users to start off with,
and running in a chroot only provides an added level of security. If the
mach chroot installs weak suid binaries, then that's an os-level
problem, and for that matter one that could be fixed pretty easily in
mach by removing the suid bit on every file it installs.
I don't have a problem pointing out to prospective QA'ers that they may
get rooted, but by that line of reasoning we'd better start including
those disclaimers with every copy of bind, sshd, or apache that get
shipped with the OS too. There is an element of risk in everything, and
smart security is all about risk management, not paranoia.
If you're really concerned, there will never be a better option than a
dedicated machine without network access, but how usable is that? We're
trying to REDUCE barriers to entry, aren't we?
--erik
From smoogen at lanl.gov Fri Apr 2 19:17:21 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Fri, 2 Apr 2004 12:17:21 -0700 (MST)
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080868993.23812.14.camel@orodruin.boston.redhat.com>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
<1080849413.3841.27.camel@localhost.localdomain>
<1080851333.10901.61.camel@smoogen2.lanl.gov>
<1080858915.23310.32.camel@orodruin.boston.redhat.com>
<1080859600.10899.82.camel@smoogen2.lanl.gov>
<1080868993.23812.14.camel@orodruin.boston.redhat.com>
Message-ID:
On Thu, 1 Apr 2004, Jeremy Katz wrote:
>On Thu, 2004-04-01 at 15:46 -0700, Stephen Smoogen wrote:
>> The boxes were configured to use the local SMTP for some reason (I dont
>> know.. I just had to debug the problem). Thus the mail went from
>> client -> sendmail/var/spool/clientmqueue -> power-outage ooops
>
>Heh, that's just sick. How about my statement holding for when the
>clients are set up correctly? :-) (ie, if you don't use local sendmail
>and just do smtp, then local /var/spool isn't needed)
>
The counter argument from the guy in suspenders and a beard to his knees
is that 'when the hell did I get a windows box? Unix is better than
that.' :).
>So yes, the ability to have it, perfectly reasonable. Having it as the
>general case, perhaps overkill.
>
I think it is reasonable for a completely new environment to not have it
because you can mandate clients etc. For existing large environments
where people expect 40 year old editors written in Fortran to still
work... lets just say exceptions become the rule :(.
--
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 Fri Apr 2 19:23:16 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Fri, 2 Apr 2004 12:23:16 -0700 (MST)
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080883322.3850.87.camel@localhost.localdomain>
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
<1080849413.3841.27.camel@localhost.localdomain>
<1080851333.10901.61.camel@smoogen2.lanl.gov>
<1080858915.23310.32.camel@orodruin.boston.redhat.com>
<1080859600.10899.82.camel@smoogen2.lanl.gov>
<1080868993.23812.14.camel@orodruin.boston.redhat.com>
<20040402015233.GB1019993@hiwaay.net>
<1080883322.3850.87.camel@localhost.localdomain>
Message-ID:
On Fri, 2 Apr 2004, Havoc Pennington wrote:
>On Thu, 2004-04-01 at 20:52, Chris Adams wrote:
>> Once upon a time, Jeremy Katz said:
>> > Heh, that's just sick. How about my statement holding for when the
>> > clients are set up correctly? :-) (ie, if you don't use local sendmail
>> > and just do smtp, then local /var/spool isn't needed)
>>
>> Way too many programs expect to be able to call /usr/sbin/sendmail to
>> assume everything will use SMTP. And really, that is how it should be;
>> why should every program be required to have an SMTP client built-in?
>>
>> The nice thing about that is that you are pretty much guaranteed that
>> you can send mail at any time, even if the network is down. Sendmail
>> (or another local mailer) will queue the mail locally and send it when
>> it can. It is not a good idea to have things like cron jobs get stuck
>> or lose their output because a remote SMTP server was unreachable.
>
>I think we have to assume that a managed read-only OS image sort of
>deployment would have some limitations in possible configurations and
>what apps could do. After all the whole point is to lock things down.
>
>One setup would be that each user has an outgoing mail queue in their
>home directory, since homedir already has to be writeable by the user
>and gets backed up and so forth. Surely you could provide a
>/usr/sbin/sendmail that worked this way.
>
>A queue in /var is suboptimal because it partially defeats the purpose
>of the deployment model - it leaves per-machine state to be corrupted,
>backed up, hacked, etc.
>
How is printing done? How do cron jobs mail when a services home
directory may not exist and the shell is nologin? Not trying to poke
holes as much as think things out-loud. I wonder if queues should go
under /var at all?
--
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 Fri Apr 2 19:27:31 2004
From: smoogen at lanl.gov (Stephen Smoogen)
Date: Fri, 2 Apr 2004 12:27:31 -0700 (MST)
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To:
References: <1080687441.10735.55.camel@opus>
<1080772701.3848.96.camel@localhost.localdomain>
<1080816876.24581.17.camel@delerium.codemonkey.org.uk>
<1080849413.3841.27.camel@localhost.localdomain>
<1080851333.10901.61.camel@smoogen2.lanl.gov>
<1080858915.23310.32.camel@orodruin.boston.redhat.com>
<1080859600.10899.82.camel@smoogen2.lanl.gov>
<1080868993.23812.14.camel@orodruin.boston.redhat.com>
<20040402015233.GB1019993@hiwaay.net>
<1080883322.3850.87.camel@localhost.localdomain>
Message-ID:
On Fri, 2 Apr 2004, Stephen Smoogen wrote:
>On Fri, 2 Apr 2004, Havoc Pennington wrote:
>
>>A queue in /var is suboptimal because it partially defeats the purpose
>>of the deployment model - it leaves per-machine state to be corrupted,
>>backed up, hacked, etc.
>>
>
>How is printing done? How do cron jobs mail when a services home
>directory may not exist and the shell is nologin? Not trying to poke
>holes as much as think things out-loud. I wonder if queues should go
>under /var at all?
>
Actually, I think I am needing what the deployment model is and what it
is for... that would help me get my head around it and what would need
to be done. I may have a solution to the conundrum, but it needs a
better idea of what is wanted.
--
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 mattdm at mattdm.org Fri Apr 2 19:40:51 2004
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 2 Apr 2004 14:40:51 -0500
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <1080813795.31656.2.camel@ulysse.olympe.o2t>
References: <1080687441.10735.55.camel@opus>
<1080688557.1212.3.camel@shahms.mesd.k12.or.us>
<1080738195.869.0.camel@teapot.felipe-alfaro.com>
<1080796713.7795.0.camel@roadrash.rdu.redhat.com>
<1080800347.21566.24.camel@skyfox.terraplex.com>
<1080807274.3985.31.camel@wombat.tiptoe.de>
<1080813795.31656.2.camel@ulysse.olympe.o2t>
Message-ID: <20040402194051.GA27133@jadzia.bu.edu>
On Thu, Apr 01, 2004 at 12:03:16PM +0200, Nicolas Mailhot wrote:
> Well, let people in the know argue for /media if they want it. So far no
> one here seems to have understood what it's supposed to win over /mnt.
The FHS actually gives the rationalization: having mount points as
subdirectories under /mnt conflicts with an allegedly widespread practice of
using /mnt itself as a temporary mountpoint.
--
Matthew Miller mattdm at mattdm.org
Boston University Linux ------>
From jkeating at j2solutions.net Fri Apr 2 19:41:30 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 2 Apr 2004 11:41:30 -0800
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <20040402194051.GA27133@jadzia.bu.edu>
References: <1080687441.10735.55.camel@opus>
<1080813795.31656.2.camel@ulysse.olympe.o2t>
<20040402194051.GA27133@jadzia.bu.edu>
Message-ID: <200404021141.30336.jkeating@j2solutions.net>
On Friday 02 April 2004 11:40, Matthew Miller wrote:
> The FHS actually gives the rationalization: having mount points as
> subdirectories under /mnt conflicts with an allegedly widespread
> practice of using /mnt itself as a temporary mountpoint.
Alleged. Thats just it. I haven't ran across anybody who uses Linux
that uses /mnt as a mountpoint. Everybody I've talked to and worked
with will create their own temp dir under /mnt and mount things there.
--
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:
From Nandox7 at myrealbox.com Fri Apr 2 19:59:48 2004
From: Nandox7 at myrealbox.com (Nandox7)
Date: Fri, 02 Apr 2004 20:59:48 +0100
Subject: USB Storage auto-mount.
Message-ID: <1080935988.3e98219cNandox7@myrealbox.com>
Hi,
i'd like to know if anyone is working on this.
I believe, i read somewhere that the latest suse, as this feature implemented. The icon appear's in the deskop and so.
So i remember to ask. And if no one is working on it, if you guy's think this could be a thing to do. I know there are some programm around, that try to archive this, but not ported to fedora.
If someone as any thing about this, please let me know.
Thank you.
Nando
From pryce at ucla.edu Fri Apr 2 20:04:44 2004
From: pryce at ucla.edu (Paul Rigor)
Date: Fri, 02 Apr 2004 12:04:44 -0800
Subject: Promise ATA and FC1/2
Message-ID: <6.0.0.22.2.20040402120212.01e43450@mail.ucla.edu>
Hi all,
I was wondering if anyone is developing (b/c the manufacturer are *useless*
about it... you can request for my correspondence w/ them)...
anyways, i was wondering if anyone was developing a promise s150 ata
controller driver? if anything, i'd like to be involved; but i've never
written a driver before. i'm an okay programmer... could anyone point me
to the right direction, please?
cheers,
paul
_________
Paul Rigor
pryce at ucla.edu
Go Bruins!
From icon at linux.duke.edu Fri Apr 2 20:08:46 2004
From: icon at linux.duke.edu (Konstantin Ryabitsev)
Date: Fri, 02 Apr 2004 15:08:46 -0500
Subject: USB Storage auto-mount.
In-Reply-To: <1080935988.3e98219cNandox7@myrealbox.com>
References: <1080935988.3e98219cNandox7@myrealbox.com>
Message-ID: <406DC84E.4000601@linux.duke.edu>
Nandox7 wrote:
> Hi,
>
> i'd like to know if anyone is working on this.
> I believe, i read somewhere that the latest suse, as this feature implemented. The icon appear's in the deskop and so.
> So i remember to ask. And if no one is working on it, if you guy's think this could be a thing to do. I know there are some programm around, that try to archive this, but not ported to fedora.
>
> If someone as any thing about this, please let me know.
I used to provide something like this for the previous incarnations (rh9
and fc1), but my code doesn't work any more on fc2. I'll probably be
looking into it before too long.
Regards,
-icon
From greeneg at student.gvsu.edu Fri Apr 2 20:08:36 2004
From: greeneg at student.gvsu.edu (Gary L Greene Jr)
Date: Fri, 2 Apr 2004 15:08:36 -0500
Subject: USB Storage auto-mount.
In-Reply-To: <1080935988.3e98219cNandox7@myrealbox.com>
References: <1080935988.3e98219cNandox7@myrealbox.com>
Message-ID: <200404021508.49727.greeneg@student.gvsu.edu>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 02 April 2004 02:59 pm, Nandox7 wrote:
> Hi,
>
> i'd like to know if anyone is working on this.
> I believe, i read somewhere that the latest suse, as this feature
> implemented. The icon appear's in the deskop and so. So i remember to ask.
> And if no one is working on it, if you guy's think this could be a thing to
> do. I know there are some programm around, that try to archive this, but
> not ported to fedora.
>
> If someone as any thing about this, please let me know.
>
> Thank you.
>
> Nando
Mandrake also does this, along with Ark Linux and Debian. All that needs done
is to have the actions added to hotplug.
- --
Gary L. Greene, Jr.
Sent from uriel.gvsu.edu
15:04:58 up 2:03, 3 users, load average: 1.30, 0.99, 0.57
============================================================
Founder and president of the Grand Valley Linux Users Group
check out http://www.gvlug.org/ for more info.
PHONE : (616) 331-0849
EMAIL : greeneg at arklinux.org (my Ark Linux account)
EMAIL : greeneg at student.gvsu.edu (my student account)
============================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAbchKrTQE7CqFxs8RAn4sAKCTycNSvwE4DlFwM6MEsCT8wpaeQQCeOMsZ
sGcCKIGZDn40pii4hOTyWkk=
=4i2U
-----END PGP SIGNATURE-----
From helios82 at optushome.com.au Fri Apr 2 20:22:36 2004
From: helios82 at optushome.com.au (Matt H)
Date: Sat, 03 Apr 2004 06:22:36 +1000
Subject: anaconda help RFE and other Fedora developmental queries
In-Reply-To: <1080921420.17714.8.camel@isengard>
References: <1080905625.3100.53.camel@fc1> <1080921420.17714.8.camel@isengard>
Message-ID: <1080937356.3137.4.camel@fc1>
On Sat, 2004-04-03 at 01:57, Jeremy Katz wrote:
> On Fri, 2004-04-02 at 06:33, Matt H wrote:
> > * I suggest the Help sidebar for the firewall setup section of the
> > anaconda installation procedure (test2+) should contain some notes
> > explaining the SELinux extension options available. (i.e. Disabled,
> > Warn, Active). Sure, people should have read the release notes but
> > adding this keeps with the trend of briefly documenting each section of
> > the install procedure.
>
> It will, it's just difficult to get it documented when I'm adding it at
> the very last minute ;-) Especially as that screen is probably going to
> be slightly in flux as I try to make things a little clearer, so I don't
> want to have too much documentation needing to be written more than
> once.
>
> Jeremy
Great, thanks for the heads-up.:-) BTW, I though Tammy or Karsten would
have been responsible for this?
Regards,
-Matt Hansen
--
mhelios - www.fedoraforum.org
Registered Linux User #348963 / counter.li.org
GnuPG KeyID: 0xCE9F8922 / gnupg.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:
From nphilipp at redhat.com Fri Apr 2 20:22:42 2004
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 02 Apr 2004 22:22:42 +0200
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <20040402194051.GA27133@jadzia.bu.edu>
References: <1080687441.10735.55.camel@opus>
<1080688557.1212.3.camel@shahms.mesd.k12.or.us>
<1080738195.869.0.camel@teapot.felipe-alfaro.com>
<1080796713.7795.0.camel@roadrash.rdu.redhat.com>
<1080800347.21566.24.camel@skyfox.terraplex.com>
<1080807274.3985.31.camel@wombat.tiptoe.de>
<1080813795.31656.2.camel@ulysse.olympe.o2t>
<20040402194051.GA27133@jadzia.bu.edu>
Message-ID: <1080937362.2492.4.camel@gibraltar.stuttgart.redhat.com>
On Fri, 2004-04-02 at 21:40, Matthew Miller wrote:
> On Thu, Apr 01, 2004 at 12:03:16PM +0200, Nicolas Mailhot wrote:
> > Well, let people in the know argue for /media if they want it. So far no
> > one here seems to have understood what it's supposed to win over /mnt.
>
> The FHS actually gives the rationalization: having mount points as
> subdirectories under /mnt conflicts with an allegedly widespread practice of
> using /mnt itself as a temporary mountpoint.
"/mnt, the one singular temporary mount point you'll ever need", if they
really say that, I'll withhold my opinion about their way of thoughts.
Nils
--
Nils Philippsen / Red Hat / nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
From toshio at tiki-lounge.com Fri Apr 2 20:27:12 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Fri, 02 Apr 2004 15:27:12 -0500
Subject: fedora-startqa
In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABB@smith.interlink.local>
References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABB@smith.interlink.local>
Message-ID: <1080937631.28654.119.camel@Madison.badger.com>
On Fri, 2004-04-02 at 12:29, Erik LaBianca wrote:
> > I'll give this a try too. I think, though, what I want is for the
> > script to automatically make a decision that an SRPM with a valid GPG
> > does not have to have it's md5sum checked.
> >
> > Slightly more paranoid is to make the following checks:
> > 1] GPG signature of SRPM
> > 2] Is the md5sum of the relevant SRPM in the md5sum file?
> > 3] GPG signature of md5sum file
> > 4] Did the same key sign both files?
> >
> > If all pass, then pass the test.
> > If 1] Pass and 2] Is fail, pass the test.
> > All other cases fail.
>
> I don't see the point in this. All it adds is protection against the
> unlikely case that there is a bug in the MD5 checksum code or crypto
> routines included in GPG. These tools are designed and tested to be
> reliable, second guessing them is a waste of time. If you know enough
> about crypto to prove its necessary, I suggest applying that knowledge
> to improving those tools.
>
The pointlessness is why I started off by saying a valid GPG signature
makes checking the MS5sum unnecessary. (ie: only check step 1 above, all
the rest is unnecessary.)
The more paranoid method I describe checks for inconsistencies between
the SRPM and other documentation on the SRPM (same person signed both
files which seem to both refer to the same SRPM. A double check.) In
the real world, if someone could compromise an SRPM on a server, they
could probably also compromise the md5sum file.
This stems from a piece of my original post which you snipped which
states that I was testing fedora-startqa and it verified the SRPM GPG
but then errored out because the MD5sum file wasn't up-to-date (and so
couldn't find the SRPM listed there.) From your comments here, I think
you're planning on removing the md5sum checking so this problem is going
away.
> You still haven't necessarily verified the gpg signature against a web
> of trust, which is FAR more likely to be the source of a problem. I'm
> not really involved with any of these (webs of trust), but when we
> convert the script over to checking RPM sigs using GPG (imminent) we can
> indicate whether or not the signature that passed was a "trusted" one in
> your review accounts gpg keyring.
>
Yes, distributing trust is the real tricky problem of gpg.
-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:
From than at redhat.com Fri Apr 2 20:27:50 2004
From: than at redhat.com (Than Ngo)
Date: Fri, 02 Apr 2004 22:27:50 +0200
Subject: Arts and dmix.
In-Reply-To: <406D76E0.7090707@f2s.com>
References: <406D76E0.7090707@f2s.com>
Message-ID: <406DCCC6.7050201@redhat.com>
Ismael Juma schrieb:
> Hi,
>
> The current released version of Arts does not work with Alsa's dmix
> according to:
>
> http://bugs.kde.org/show_bug.cgi?id=76413
> http://bugs.kde.org/show_bug.cgi?id=70802
>
> Both bugs have been recently fixed in CVS.
i have already seen the commits in CVS ;-)
> I was wondering if there is any chance of having that patch included
> in FC2.
>
yes, it will be included in the next arts rebuild.
Than
From toshio at tiki-lounge.com Fri Apr 2 20:50:29 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Fri, 02 Apr 2004 15:50:29 -0500
Subject: fedora-startqa
In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@smith.interlink.local>
References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@smith.interlink.local>
Message-ID: <1080939028.28654.140.camel@Madison.badger.com>
On Fri, 2004-04-02 at 12:49, Erik LaBianca wrote:
> My personal opinion is that there shouldn't be a PUBLISH++ in the review template that is automatically output unless we are automatically doing ALL showstopper checks correctly, and the package passes. Currently we can't automate name checking, installation / uninstallation, or complete source checking, so we shouldn't print it out.
>
If this is votable I +1 :-) Make the reviewer do it because they have
to go through the TODO list anyhow.
[snip]
> My preference is for the review template to have a series of "blanks" to be filled in by the reviewer. A script like qa-assistant could take the output of our automated program and provide hand-holding for the user through filling in the rest of the items.
>
> I prefer to have a series of lines like this:
> Builds OK?: YES (fc1,rh9) NO(rh8)
> Name OK?: unchecked
> (Un)Installs OK?: unchecked
> Secure?: unchecked
>
Hmmm... After I define a save format for qa-assistant, I may approach
you with a --xml-output patch.
-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:
From barryn at pobox.com Fri Apr 2 21:04:43 2004
From: barryn at pobox.com (Barry K. Nathan)
Date: Fri, 2 Apr 2004 13:04:43 -0800
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <200404021141.30336.jkeating@j2solutions.net>
References: <1080687441.10735.55.camel@opus>
<1080813795.31656.2.camel@ulysse.olympe.o2t>
<20040402194051.GA27133@jadzia.bu.edu>
<200404021141.30336.jkeating@j2solutions.net>
Message-ID: <20040402210443.GA10384@ip68-4-98-123.oc.oc.cox.net>
On Fri, Apr 02, 2004 at 11:41:30AM -0800, Jesse Keating wrote:
> Alleged. Thats just it. I haven't ran across anybody who uses Linux
> that uses /mnt as a mountpoint. Everybody I've talked to and worked
> with will create their own temp dir under /mnt and mount things there.
Hmmm....
Maybe I shouldn't make a fool of myself in public ;) but I used to, at
some point in the past, use /mnt itself as a mountpoint. However, that
was several years ago; nowadays I create subdirectories in /mnt like
most other Linux users.
Using /mnt directly is often done on other Unix-like operating
systems, so anybody still doing that today is probably coming over from
another Unix-like OS. (For instance, I'm logged into a Solaris 8 box in
another xterm, and I just checked if /mnt there has subdirectories. It
doesn't.)
-Barry K. Nathan
From davej at redhat.com Fri Apr 2 21:26:28 2004
From: davej at redhat.com (Dave Jones)
Date: Fri, 02 Apr 2004 22:26:28 +0100
Subject: USB Storage auto-mount.
In-Reply-To: <1080935988.3e98219cNandox7@myrealbox.com>
References: <1080935988.3e98219cNandox7@myrealbox.com>
Message-ID: <1080941188.9449.1.camel@delerium.codemonkey.org.uk>
On Fri, 2004-04-02 at 20:59, Nandox7 wrote:
> i'd like to know if anyone is working on this.
> I believe, i read somewhere that the latest suse, as this feature implemented. The icon appear's in the deskop and so.
> So i remember to ask. And if no one is working on it, if you guy's think this could be a thing to do. I know there are some programm around, that try to archive this, but not ported to fedora.
>
> If someone as any thing about this, please let me know.
http://cyberelk.net/tim/usb-storage.html
Dave
From ijuma82 at f2s.com Fri Apr 2 21:36:02 2004
From: ijuma82 at f2s.com (Ismael Juma)
Date: Fri, 02 Apr 2004 22:36:02 +0100
Subject: Arts and dmix.
In-Reply-To: <406DCCC6.7050201@redhat.com>
References: <406D76E0.7090707@f2s.com> <406DCCC6.7050201@redhat.com>
Message-ID: <406DDCC2.4070705@f2s.com>
Than Ngo wrote:
> i have already seen the commits in CVS ;-)
>
>> I was wondering if there is any chance of having that patch included
>> in FC2.
>>
> yes, it will be included in the next arts rebuild.
>
>
> Than
>
>
That is good to hear ;)
Hopefully I will finally be able to switch on KDE notifications.
Regards,
Ismael
From jspaleta at princeton.edu Fri Apr 2 21:35:55 2004
From: jspaleta at princeton.edu (Jef Spaleta)
Date: Fri, 02 Apr 2004 16:35:55 -0500
Subject: USB Storage auto-mount.
Message-ID: <1080941755.22388.16.camel@spatula.pppl.gov>
Dave Jones wrote:
> http://cyberelk.net/tim/usb-storage.html
>
> Dave
I think the issue is...some people on this thread want the the usb mass
storage device to automounted, not just be recognized and added to the
right-click disks menu in nautilus. The want to skip steps 3 and 4 and
go right to step 5.
-jef
From aleksey at nogin.org Fri Apr 2 21:51:59 2004
From: aleksey at nogin.org (Aleksey Nogin)
Date: Fri, 02 Apr 2004 13:51:59 -0800
Subject: please include the synaptics X11 driver on FC2
In-Reply-To: <1080911547.6614.8.camel@roque>
References: <1080911547.6614.8.camel@roque>
Message-ID: <406DE07F.2040609@nogin.org>
On 02.04.2004 05:12, Rui Miguel Seabra wrote:
> Hi,
>
> I've been using Paul Nasrat's synaptics driver package for some time
> without any problems, both with XFree86 and xorg-x11.
>
> This driver is quite essential for many touchpads, so it _would_ be
> very nice to include it (starting with test3) in FC2.
See
https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=99351,103497,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 sflory at rackable.com Fri Apr 2 21:56:27 2004
From: sflory at rackable.com (Samuel Flory)
Date: Fri, 02 Apr 2004 13:56:27 -0800
Subject: Promise ATA and FC1/2
In-Reply-To: <6.0.0.22.2.20040402120212.01e43450@mail.ucla.edu>
References: <6.0.0.22.2.20040402120212.01e43450@mail.ucla.edu>
Message-ID: <406DE18B.9000304@rackable.com>
Paul Rigor wrote:
> Hi all,
>
> I was wondering if anyone is developing (b/c the manufacturer are
> *useless* about it... you can request for my correspondence w/ them)...
> anyways, i was wondering if anyone was developing a promise s150 ata
> controller driver? if anything, i'd like to be involved; but i've never
> written a driver before. i'm an okay programmer... could anyone point
> me to the right direction, please?
There are a number of s150 cards. The non raid controllers should
just work with 2.6, or a 2.4 kernel with libata patched in. The S150
tx2 just works for me with a patch 2.4, and with an unpatched 2.6.
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/
PS- If you are compiling your own kernel look under scsi--> scsi
low_level_drivers for the sata drivers.
--
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory
From webmaster at margo.bijoux.nom.br Fri Apr 2 21:56:40 2004
From: webmaster at margo.bijoux.nom.br (Pedro Macedo)
Date: Fri, 02 Apr 2004 18:56:40 -0300
Subject: USB Storage auto-mount.
In-Reply-To: <1080941755.22388.16.camel@spatula.pppl.gov>
References: <1080941755.22388.16.camel@spatula.pppl.gov>
Message-ID: <1080943000.5289.6.camel@quantum>
On Fri, 2004-04-02 at 18:35, Jef Spaleta wrote:
> I think the issue is...some people on this thread want the the usb mass
> storage device to automounted, not just be recognized and added to the
> right-click disks menu in nautilus. The want to skip steps 3 and 4 and
> go right to step 5.
>
> -jef
Sometime ago , someone posted on fedora-list a script that would mount
the device as soon as it was connected using updfstab. The only problem
with the script was that it did the mount as root and then only root
could write to the device... I wish I could search for the message (I
have saved it in my harddisk , but my computer is broken...) but it was
posted around december...
--
Pedro Macedo
From aleksey at nogin.org Fri Apr 2 22:02:32 2004
From: aleksey at nogin.org (Aleksey Nogin)
Date: Fri, 02 Apr 2004 14:02:32 -0800
Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at "restarting
tasks"
Message-ID: <406DE2F8.2010107@nogin.org>
I've been using the Raw Hide kernels recompiled with
CONFIG_SOFTWARE_SUSPEND enabled (and CONFIG_APM disabled) and using ACPI
software suspend. For a while it worked flawlessly, but then it broke -
now at resume time, it starts resuming OK, but shortly after it says
"restarting tasks", machine suddenly reboots.
Worked OK:
2.6.3-1.116 2.6.3-1.118
No longer OK:
2.6.3-2.1.253 2.6.3-2.1.253.2.1 2.6.4-1.298
Any ideas what might be going on? Thanks a lot!
P.S. Somewhere around the time it stopped working, I started
experimenting with enabling and using SELinux, so it might be
SELinux-related.
--
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 katzj at redhat.com Fri Apr 2 22:45:06 2004
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 02 Apr 2004 17:45:06 -0500
Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at
"restarting tasks"
In-Reply-To: <406DE2F8.2010107@nogin.org>
References: <406DE2F8.2010107@nogin.org>
Message-ID: <1080945906.25256.46.camel@orodruin.boston.redhat.com>
On Fri, 2004-04-02 at 14:02 -0800, Aleksey Nogin wrote:
> I've been using the Raw Hide kernels recompiled with
> CONFIG_SOFTWARE_SUSPEND enabled (and CONFIG_APM disabled) and using ACPI
> software suspend. For a while it worked flawlessly, but then it broke -
> now at resume time, it starts resuming OK, but shortly after it says
> "restarting tasks", machine suddenly reboots.
[snip]
> Any ideas what might be going on? Thanks a lot!
The newer kernels have the 4G/4G VM split enabled. When you resume with
this patch applied, the machine triple faults and then reboots. It's
being looked into...
Jeremy
From erik at totalcirculation.com Fri Apr 2 23:10:28 2004
From: erik at totalcirculation.com (Erik LaBianca)
Date: Fri, 2 Apr 2004 18:10:28 -0500
Subject: fedora-startqa
Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC3@smith.interlink.local>
> >
> The pointlessness is why I started off by saying a valid GPG signature
> makes checking the MS5sum unnecessary. (ie: only check step 1 above,
all
> the rest is unnecessary.)
>
> The more paranoid method I describe checks for inconsistencies between
> the SRPM and other documentation on the SRPM (same person signed both
> files which seem to both refer to the same SRPM. A double check.) In
> the real world, if someone could compromise an SRPM on a server, they
> could probably also compromise the md5sum file.
>
> This stems from a piece of my original post which you snipped which
> states that I was testing fedora-startqa and it verified the SRPM GPG
> but then errored out because the MD5sum file wasn't up-to-date (and so
> couldn't find the SRPM listed there.) From your comments here, I
think
> you're planning on removing the md5sum checking so this problem is
going
> away.
>
> > You still haven't necessarily verified the gpg signature against a
web
> > of trust, which is FAR more likely to be the source of a problem.
I'm
> > not really involved with any of these (webs of trust), but when we
> > convert the script over to checking RPM sigs using GPG (imminent) we
can
> > indicate whether or not the signature that passed was a "trusted"
one in
> > your review accounts gpg keyring.
> >
> Yes, distributing trust is the real tricky problem of gpg.
>
Cool. Looks like we are on the same page here then. My current
inclination is to require a valid gpg signature, but check md5sums if
possible and note to the user if anything is inconsistent. It certainly
wouldn't hurt to also check that the md5sums they are signed by the same
key as the SRPM, although I doubt many crooks will be caught by it :)
--erik
From perbj at stanford.edu Fri Apr 2 23:11:28 2004
From: perbj at stanford.edu (Per Bjornsson)
Date: Fri, 02 Apr 2004 15:11:28 -0800
Subject: Impact of 4G/4G split [Re: CONFIG_SOFTWARE_SUSPEND...]
In-Reply-To: <1080945906.25256.46.camel@orodruin.boston.redhat.com>
References: <406DE2F8.2010107@nogin.org>
<1080945906.25256.46.camel@orodruin.boston.redhat.com>
Message-ID: <1080947488.3749.51.camel@beechnut.Stanford.EDU>
On Fri, 2004-04-02 at 14:45, Jeremy Katz wrote:
> The newer kernels have the 4G/4G VM split enabled. When you resume with
> this patch applied, the machine triple faults and then reboots. It's
> being looked into...
What is the performance impact of the 4G/4G split? I thought that it was
actually somewhat severe (haven't measured it myself though), so that
enabling this would only be useful when you're actually using a lot of
memory. Is this the case, and if it is, would it be a good idea to have
separate kernels for desktop/"low-memory" configurations without the
4G/4G split enabled? (I seem to recall that there might have been
special "hugemem" kernels with compile options chosen to optimize for
handling loads of memory as opposed to the normal kernels.)
Best regards,
Per Bjornsson
From erik at totalcirculation.com Fri Apr 2 23:15:24 2004
From: erik at totalcirculation.com (Erik LaBianca)
Date: Fri, 2 Apr 2004 18:15:24 -0500
Subject: fedora-startqa
Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC4@smith.interlink.local>
> >
> If this is votable I +1 :-) Make the reviewer do it because they have
> to go through the TODO list anyhow.
>
+1 from me too, and at worst a 0 from Aurelien, so at the current time
we're in the majority. :)
> > My preference is for the review template to have a series of
"blanks" to
> be filled in by the reviewer. A script like qa-assistant could take
the
> output of our automated program and provide hand-holding for the user
> through filling in the rest of the items.
> >
> > I prefer to have a series of lines like this:
> > Builds OK?: YES (fc1,rh9) NO(rh8)
> > Name OK?: unchecked
> > (Un)Installs OK?: unchecked
> > Secure?: unchecked
> >
> Hmmm... After I define a save format for qa-assistant, I may approach
> you with a --xml-output patch.
>
XML Output is a great idea IMO. We can define a schema for a review, and
then use xslt to generate the actual review. We should all be able to
easily agree on the xml schema, and for those that love to tweak they
can always change the output template.
In all reality, there may be a certain amount of benefit to actually
posting the review in XML. It's obviously the easiest way of making the
reviews computer parseable.
This may already be what you're doing, I must apologize for not looking
at your code yet :)
--erik
From mail at optimized.org Fri Apr 2 23:53:21 2004
From: mail at optimized.org (Optimized)
Date: Sat, 03 Apr 2004 01:53:21 +0200
Subject: FC2 installation problems on existing software raid
Message-ID: <1080950001.7316.0.camel@mybox.optimized.org>
Hello,
I am trying to install Fedora Core 2 on an existing software raid volume
created during the Fedora Core 1 installation process.
When I get to the disk druid (manual configuration chosen) my /dev/md*
partitions' filesystem are shown as 'foreign' instead of 'ext3'.
I didn't risk anything from that point, I simply wish to dual boot FC1
and FC2 and really don't want to loose the FC1 installation.
I've found that previous post relating the same problem :
http://www.redhat.com/archives/rhl-beta-list/2004-February/msg00800.html
What should I do?
Many thanks for your time and help.
From alan at redhat.com Sat Apr 3 00:00:46 2004
From: alan at redhat.com (Alan Cox)
Date: Fri, 2 Apr 2004 19:00:46 -0500
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <200404021141.30336.jkeating@j2solutions.net>
References: <1080687441.10735.55.camel@opus>
<1080813795.31656.2.camel@ulysse.olympe.o2t>
<20040402194051.GA27133@jadzia.bu.edu>
<200404021141.30336.jkeating@j2solutions.net>
Message-ID: <20040403000046.GH4271@devserv.devel.redhat.com>
On Fri, Apr 02, 2004 at 11:41:30AM -0800, Jesse Keating wrote:
Content-Description: signed data
> Alleged. Thats just it. I haven't ran across anybody who uses Linux
> that uses /mnt as a mountpoint. Everybody I've talked to and worked
> with will create their own temp dir under /mnt and mount things there.
/media actually went to a poll and a vote with the various distros. Its
a pretty clear split between the /mnt/foo people and the others so they
picked one. Unfortunately half the people I know who run SuSE seem to
keep their movies and mp3 files in /media instead 8)
From aleksey at nogin.org Sat Apr 3 00:03:33 2004
From: aleksey at nogin.org (Aleksey Nogin)
Date: Fri, 02 Apr 2004 16:03:33 -0800
Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at
"restarting tasks"
In-Reply-To: <1080945906.25256.46.camel@orodruin.boston.redhat.com>
References: <406DE2F8.2010107@nogin.org>
<1080945906.25256.46.camel@orodruin.boston.redhat.com>
Message-ID: <406DFF55.2060904@nogin.org>
On 02.04.2004 14:45, Jeremy Katz wrote:
> The newer kernels have the 4G/4G VM split enabled. When you resume with
> this patch applied, the machine triple faults and then reboots. It's
> being looked into...
So if I do not care for 4G, but do care about software suspend, are
there some config options I can toglle to make it work for me? Thanks!
--
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 alan at redhat.com Sat Apr 3 00:08:28 2004
From: alan at redhat.com (Alan Cox)
Date: Fri, 2 Apr 2004 19:08:28 -0500
Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at
"restarting tasks"
In-Reply-To: <1080945906.25256.46.camel@orodruin.boston.redhat.com>
References: <406DE2F8.2010107@nogin.org>
<1080945906.25256.46.camel@orodruin.boston.redhat.com>
Message-ID: <20040403000828.GJ4271@devserv.devel.redhat.com>
On Fri, Apr 02, 2004 at 05:45:06PM -0500, Jeremy Katz wrote:
> The newer kernels have the 4G/4G VM split enabled. When you resume with
> this patch applied, the machine triple faults and then reboots. It's
> being looked into...
Interestingly this affects both APM and ACPI btw
From alan at redhat.com Sat Apr 3 00:10:16 2004
From: alan at redhat.com (Alan Cox)
Date: Fri, 2 Apr 2004 19:10:16 -0500
Subject: Impact of 4G/4G split [Re: CONFIG_SOFTWARE_SUSPEND...]
In-Reply-To: <1080947488.3749.51.camel@beechnut.Stanford.EDU>
References: <406DE2F8.2010107@nogin.org>
<1080945906.25256.46.camel@orodruin.boston.redhat.com>
<1080947488.3749.51.camel@beechnut.Stanford.EDU>
Message-ID: <20040403001016.GK4271@devserv.devel.redhat.com>
On Fri, Apr 02, 2004 at 03:11:28PM -0800, Per Bjornsson wrote:
> What is the performance impact of the 4G/4G split? I thought that it was
> actually somewhat severe (haven't measured it myself though), so that
I did some measurements on my laptop and its about 10%. Some things like
high speed networking seem to hurt a lot more and a few fairly bogus
tests like 1000 thread cycling are way worse.
Alan
From warren at togami.com Sat Apr 3 02:10:12 2004
From: warren at togami.com (Warren Togami)
Date: Fri, 02 Apr 2004 16:10:12 -1000
Subject: RFC: fedora.us QA approval format
In-Reply-To: <20040402150813.22caedeb.ms-nospam-0306@arcor.de>
References: <1080844288.32189.27.camel@Madison.badger.com>
<20040402083854.GA2184@free.fr>
<20040402150813.22caedeb.ms-nospam-0306@arcor.de>
Message-ID: <406E1D04.6080305@togami.com>
Michael Schwendt wrote:
> On Fri, 2 Apr 2004 10:38:54 +0200, Patrice Dumas wrote:
>
>
>>>- Download of the sources, with md5sum check
>>
>>Maybe the download should't be automatic, such that it is possible to check
>>that the download url is really the right url (presumably searching first the
>>project home page with google, in order not to use the url provided in the
>>srpm, and verifying that it is the right download page), and not one with
>>bad package ?
>
>
> Reviewers should also notice when upstream projects provide detached GPG
> signatures, which can be used to verify the published tarballs.
>
>
Reviewers should also harass upstream projects into providing GPG
signatures "or else". =)
We managed to convince gaim and scribus, but few other people...
Warren
From rhallyx at mindspring.com Sat Apr 3 02:26:09 2004
From: rhallyx at mindspring.com (Richard Hally)
Date: Fri, 02 Apr 2004 21:26:09 -0500
Subject: Dependency hell
Message-ID: <406E20C1.7020008@mindspring.com>
Please see the list of my attempts to update my system to rawhide.
The thing that seems most incorrect is that rpm or yum do not report
correctly the packages that need to be excluded. Since there always
seems to be some dependency problem (one gets fixed but another one
stops the update) it would seem that a reliable way to determine which
packages to exclude would be very helpful and save time that can be put
to better use. thanks for any help,
Richard Hally
> [root at localhost root]# yum upgrade
> Gathering header information file(s) from server(s)
> Server: Fedora Core 1 - i386 - Rawhide
> Finding updated packages
> Downloading needed headers
> Finding obsoleted packages
> Resolving dependencies
> ......Unable to satisfy dependencies
> Package pwlib needs libdv.so.2, this is not available.
> Package xemacs needs libRKC.so.1.2, this is not available.
> Package xemacs needs libcanna.so.1.2, this is not available.
> Package dvgrab needs libdv.so.2, this is not available.
> Package db4-java needs db4 = 4.1.25-14, this is not available.
Here is the second attempt with the packages that reported excluded
>
> [root at localhost root]# yum --exclude=pwlib --exclude=xemacs
> --exclude=dvgrab --exclude=db4-java upgrade
> Gathering header information file(s) from server(s)
> Server: Fedora Core 1 - i386 - Rawhide
> Finding updated packages
> Downloading needed headers
> Finding obsoleted packages
> Resolving dependencies
> ......Unable to satisfy dependencies
> Package gnomemeeting needs libpt.so.1.6.3, this is not available.
> Package gnomemeeting needs pwlib >= 1.6.3, this is not available.
> Package xemacs-info needs xemacs = 21.4.15, this is not available.
> Package openh323 needs libpt.so.1.6.3, this is not available.
> Package openh323 needs pwlib >= 1.6.3, this is not available.
> Package xemacs-el needs xemacs = 21.4.15, this is not available.
> Package pwlib-devel needs libpt.so.1.6.3, this is not available.
> Package pwlib-devel needs pwlib = 1.6.3, this is not available.
> Package db4-java needs db4 = 4.1.25-14, this is not available.
> [root at localhost root]#
>
From warren at togami.com Sat Apr 3 03:09:38 2004
From: warren at togami.com (Warren Togami)
Date: Fri, 02 Apr 2004 17:09:38 -1000
Subject: Dependency hell
In-Reply-To: <406E20C1.7020008@mindspring.com>
References: <406E20C1.7020008@mindspring.com>
Message-ID: <406E2AF2.9090104@togami.com>
Richard Hally wrote:
> Please see the list of my attempts to update my system to rawhide.
> The thing that seems most incorrect is that rpm or yum do not report
> correctly the packages that need to be excluded. Since there always
> seems to be some dependency problem (one gets fixed but another one
> stops the update) it would seem that a reliable way to determine which
> packages to exclude would be very helpful and save time that can be put
> to better use. thanks for any help,
> Richard Hally
1) Development and test releases never were supported and there is never
the expectation that upgrades will go smoothly all the time. We try our
best to prevent breakage whenever possible, but these things inevitably
periodically happen when you have dozens of developers working on many
interlocking pieces of the puzzle. We are working on improving the
standard processes to avoid more of these issues in the future, but
eliminating it completely may never happen.
2) apt-get upgrade (but not dist-upgrade) avoids the missing pieces
automatically. All the way through FC2 test1 to current rawhide it has
worked for me in not leaving a broken system. The current selinux
policy problem needs to be solved though. Panu have you communicated
with the selinux people about this?
Warren
From warren at togami.com Sat Apr 3 03:13:39 2004
From: warren at togami.com (Warren Togami)
Date: Fri, 02 Apr 2004 17:13:39 -1000
Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots
at "restarting tasks"
In-Reply-To: <20040403000828.GJ4271@devserv.devel.redhat.com>
References: <406DE2F8.2010107@nogin.org> <1080945906.25256.46.camel@orodruin.boston.redhat.com>
<20040403000828.GJ4271@devserv.devel.redhat.com>
Message-ID: <406E2BE3.9040606@togami.com>
Alan Cox wrote:
> On Fri, Apr 02, 2004 at 05:45:06PM -0500, Jeremy Katz wrote:
>
>>The newer kernels have the 4G/4G VM split enabled. When you resume with
>>this patch applied, the machine triple faults and then reboots. It's
>>being looked into...
>
>
> Interestingly this affects both APM and ACPI btw
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117032
4G/4G and broken S3 sleep
You can workaround this problem by recompiling the kernel with 4G/4G
disabled or use the i586 kernel. If you use the later workaround you
will run into NPTL problems like this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933
Warren
From rhally at mindspring.com Sat Apr 3 06:22:50 2004
From: rhally at mindspring.com (Richard Hally)
Date: Sat, 03 Apr 2004 01:22:50 -0500
Subject: Dependency hell
In-Reply-To: <406E2AF2.9090104@togami.com>
References: <406E20C1.7020008@mindspring.com> <406E2AF2.9090104@togami.com>
Message-ID: <406E583A.5000403@mindspring.com>
Warren Togami wrote:
> Richard Hally wrote:
>
>> Please see the list of my attempts to update my system to rawhide.
>> The thing that seems most incorrect is that rpm or yum do not report
>> correctly the packages that need to be excluded. Since there always
>> seems to be some dependency problem (one gets fixed but another one
>> stops the update) it would seem that a reliable way to determine
>> which packages to exclude would be very helpful and save time that
>> can be put to better use. thanks for any help,
>> Richard Hally
>
>
> 1) Development and test releases never were supported and there is
> never the expectation that upgrades will go smoothly all the time. We
> try our best to prevent breakage whenever possible, but these things
> inevitably periodically happen when you have dozens of developers
> working on many interlocking pieces of the puzzle. We are working on
> improving the standard processes to avoid more of these issues in the
> future, but eliminating it completely may never happen.
>
> 2) apt-get upgrade (but not dist-upgrade) avoids the missing pieces
> automatically. All the way through FC2 test1 to current rawhide it
> has worked for me in not leaving a broken system. The current selinux
> policy problem needs to be solved though. Panu have you communicated
> with the selinux people about this?
>
> Warren
>
>
Thanks Warren, I understand your 1) above, that is why it is important
to provide the mechanism to enable people to work around the problem in
a reasonably proficient manner.
I'll look into this apt-get , perhaps yet another "update mechanism"
will be the answer ;-)
p.s. I've been lurking on the SELinux list since early 2001 and my main
reason for getting involved with Fedora is to work on SELinux. Perhaps
I'll be able to "pick up a shovel" once I get past spending so much time
on this "dependency hell".
Thanks for your help,
Richard Hally
From fedora at andrewfarris.com Sat Apr 3 08:04:55 2004
From: fedora at andrewfarris.com (Andrew Farris)
Date: Sat, 03 Apr 2004 00:04:55 -0800
Subject: Dependency hell
In-Reply-To: <406E20C1.7020008@mindspring.com>
References: <406E20C1.7020008@mindspring.com>
Message-ID: <1080979495.19191.14.camel@CirithUngol>
On Fri, 2004-04-02 at 21:26 -0500, Richard Hally wrote:
> Please see the list of my attempts to update my system to rawhide.
> The thing that seems most incorrect is that rpm or yum do not report
> correctly the packages that need to be excluded. Since there always
> seems to be some dependency problem (one gets fixed but another one
> stops the update) it would seem that a reliable way to determine which
> packages to exclude would be very helpful and save time that can be put
> to better use. thanks for any help,
> Richard Hally
>
>
>
> > [root at localhost root]# yum upgrade
> > Package pwlib needs libdv.so.2, this is not available.
> > Package xemacs needs libRKC.so.1.2, this is not available.
> > Package xemacs needs libcanna.so.1.2, this is not available.
> > Package dvgrab needs libdv.so.2, this is not available.
> > Package db4-java needs db4 = 4.1.25-14, this is not available.
> > [root at localhost root]# yum --exclude=pwlib --exclude=xemacs
> > --exclude=dvgrab --exclude=db4-java upgrade
You have, like so many others, misunderstood the statements: they are
not telling you what packages are not available, they are telling you
what files are no longer available (due to the new version being
installed--libraries are being removed/updated).
libdv.so.2 is being removed, the new version of libdv does NOT supply
it, likewise for the other files mentioned. This is accurately telling
you what files are no longer present after the test upgrade (dependency
tests).
You should have instead excluded the library packages that were being
changed, not the packages you already have that require the old library
files. What you did was to exclude packages which you already have
installed--essentially doing nothing.
You may need to remove db4-java since that package requires an old
library (or find the update to it which should be built properly against
the new library).
yum --exclude=libdv* --exclude=Canna-lib* --exclude=db4 update
--
Andrew J Farris
afarris at calpoly.edu :: andrew at andrewfarris.com
California Polytechnic State University, San Luis Obispo CA
http://www.andrewfarris.com/
From rhally at mindspring.com Sat Apr 3 09:02:49 2004
From: rhally at mindspring.com (Richard Hally)
Date: Sat, 03 Apr 2004 04:02:49 -0500
Subject: Dependency hell
In-Reply-To: <1080979495.19191.14.camel@CirithUngol>
References: <406E20C1.7020008@mindspring.com>
<1080979495.19191.14.camel@CirithUngol>
Message-ID: <406E7DB9.3010106@mindspring.com>
Andrew Farris wrote:
>On Fri, 2004-04-02 at 21:26 -0500, Richard Hally wrote:
>
>
>
>>Please see the list of my attempts to update my system to rawhide.
>>The thing that seems most incorrect is that rpm or yum do not report
>>correctly the packages that need to be excluded. Since there always
>>seems to be some dependency problem (one gets fixed but another one
>>stops the update) it would seem that a reliable way to determine which
>>packages to exclude would be very helpful and save time that can be put
>>to better use. thanks for any help,
>>Richard Hally
>>
>>
>>
>>
>>
>>>[root at localhost root]# yum upgrade
>>>
>>>
>
>
>
>>>Package pwlib needs libdv.so.2, this is not available.
>>>Package xemacs needs libRKC.so.1.2, this is not available.
>>>Package xemacs needs libcanna.so.1.2, this is not available.
>>>Package dvgrab needs libdv.so.2, this is not available.
>>>Package db4-java needs db4 = 4.1.25-14, this is not available.
>>>
>>>
>
>
>
>>>[root at localhost root]# yum --exclude=pwlib --exclude=xemacs
>>>--exclude=dvgrab --exclude=db4-java upgrade
>>>
>>>
>
>You have, like so many others, misunderstood the statements: they are
>not telling you what packages are not available, they are telling you
>what files are no longer available (due to the new version being
>installed--libraries are being removed/updated).
>
>libdv.so.2 is being removed, the new version of libdv does NOT supply
>it, likewise for the other files mentioned. This is accurately telling
>you what files are no longer present after the test upgrade (dependency
>tests).
>
>You should have instead excluded the library packages that were being
>changed, not the packages you already have that require the old library
>files. What you did was to exclude packages which you already have
>installed--essentially doing nothing.
>
>You may need to remove db4-java since that package requires an old
>library (or find the update to it which should be built properly against
>the new library).
>yum --exclude=libdv* --exclude=Canna-lib* --exclude=db4 update
>
>
Thank you Andrew, you make my point for me in an indrect way. It takes
four paragraphs to try to explain what is going on and it is still as
clear as mud(no slam on your excellent exposition). I just want it to
tell me what packages to exclude, that's all. :)
But, to extend the instance, the result of your suggested yum command
line is shown below:
(I have installed apt since the previous attempt with yum (of course
that just adds to the problem))
Isn't that just wonderful...and it goes on, rpm-4.2.1-0.30 is
installed and provides librpm-4.2.so
but of course yum/rpm doesn't say it will not be available if I do this
update, it says *is not *available. should I add --exclude=rpm
--exclude=python2.2
I guess I have belabored the point, sorry
Thanks for your help,
Richard Hally
[root at localhost root]# yum --exclude=libdv* --exclude=Canna-lib
--exclude=db4 update
Gathering header information file(s) from server(s)
Server: Fedora Core 1 - i386 - Rawhide
Finding updated packages
Downloading needed headers
Resolving dependencies
.Package apt needs librpm-4.2.so, this is not available.
Package apt needs librpmdb-4.2.so, this is not available.
Package apt needs librpmio-4.2.so, this is not available.
Package db4-java needs db4 that has been excluded.
Package redhat-config-network-tui needs /usr/bin/python2.2, this is not
available.
Package redhat-config-users needs /usr/bin/python2.2, this is not
available.
Package redhat-config-nfs needs /usr/bin/python2.2, this is not available.
Package redhat-config-language needs /usr/bin/python2.2, this is not
available.
Package redhat-config-xfree86 needs /usr/bin/python2.2, this is not
available.
Package redhat-config-kickstart needs /usr/bin/python2.2, this is not
available.Package redhat-config-date needs /usr/bin/python2.2, this is
not available.
Package redhat-config-keyboard needs /usr/bin/python2.2, this is not
available.
Package redhat-config-mouse needs /usr/bin/python2.2, this is not
available.
Package redhat-config-securitylevel needs /usr/bin/python2.2, this is
not available.
Package redhat-config-soundcard needs /usr/bin/python2.2, this is not
available.Package redhat-config-samba needs /usr/bin/python2.2, this is
not available.
Package redhat-config-bind needs /usr/bin/python2.2, this is not available.
Package redhat-config-rootpassword needs /usr/bin/python2.2, this is not
available.
[root at localhost root]#
From blin at na.uni-tuebingen.de Sat Apr 3 09:38:26 2004
From: blin at na.uni-tuebingen.de (Kai Blin)
Date: Sat, 3 Apr 2004 11:38:26 +0200
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <200404021141.30336.jkeating@j2solutions.net>
References: <1080687441.10735.55.camel@opus>
<20040402194051.GA27133@jadzia.bu.edu>
<200404021141.30336.jkeating@j2solutions.net>
Message-ID: <200404031138.26561.blin@na.uni-tuebingen.de>
On Friday 02 April 2004 21:41, Jesse Keating wrote:
> Alleged. Thats just it. I haven't ran across anybody who uses Linux
> that uses /mnt as a mountpoint. Everybody I've talked to and worked
> with will create their own temp dir under /mnt and mount things there.
Fearing to warm up the old discussion, A quick look at some of the Linux
kernel Documentation/ directory reveals that most examples assume you're
using /mnt as a single mountpoint. Not that I think you should do it that
way, but I think that shows it's not too unusual. Agreed, RedHat didn't, but
a lot of other distros seem to do it that way.
Cheers,
Kai
--
Kai Blin, Sysop
Dept. of Numerical Algebra, University of T?bingen, Germany
From laroche at redhat.com Sat Apr 3 09:54:44 2004
From: laroche at redhat.com (Florian La Roche)
Date: Sat, 3 Apr 2004 11:54:44 +0200
Subject: Future: fhs 2.3 compliance for fc3
In-Reply-To: <200404031138.26561.blin@na.uni-tuebingen.de>
References: <1080687441.10735.55.camel@opus>
<20040402194051.GA27133@jadzia.bu.edu>
<200404021141.30336.jkeating@j2solutions.net>
<200404031138.26561.blin@na.uni-tuebingen.de>
Message-ID: <20040403095444.GA22976@dudweiler.stuttgart.redhat.com>
On Sat, Apr 03, 2004 at 11:38:26AM +0200, Kai Blin wrote:
> On Friday 02 April 2004 21:41, Jesse Keating wrote:
>
> > Alleged. Thats just it. I haven't ran across anybody who uses Linux
> > that uses /mnt as a mountpoint. Everybody I've talked to and worked
> > with will create their own temp dir under /mnt and mount things there.
>
> Fearing to warm up the old discussion, A quick look at some of the Linux
> kernel Documentation/ directory reveals that most examples assume you're
> using /mnt as a single mountpoint. Not that I think you should do it that
> way, but I think that shows it's not too unusual. Agreed, RedHat didn't, but
> a lot of other distros seem to do it that way.
Red Hat has an empty directory called "/mnt" and some people use it to
mount single further fs, some add further subdirs to mount more media.
By changing from "/mnt" to "/media" you have the same setup and anyone
can choose to use it how they like. As Alan Cox said, some might choose
to always mount their mp3 files to /media.
FHS helps a lot to set common rules for applications and standardize
them, it won't be able to educate all users or tell them how to use their
distribution.
Maybe "/srv" has more items on the cons side. What does debian and gentoo
do on that side?
greetings,
Florian La Roche
From felipe_alfaro at linuxmail.org Sat Apr 3 10:06:57 2004
From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana)
Date: Sat, 03 Apr 2004 12:06:57 +0200
Subject: Dependency hell
In-Reply-To: <406E7DB9.3010106@mindspring.com>
References: <406E20C1.7020008@mindspring.com>
<1080979495.19191.14.camel@CirithUngol>
<406E7DB9.3010106@mindspring.com>
Message-ID: <1080986816.1325.1.camel@teapot.felipe-alfaro.com>
On Sat, 2004-04-03 at 11:02, Richard Hally wrote:
>
> [root at localhost root]# yum --exclude=libdv* --exclude=Canna-lib
> --exclude=db4 update
> Gathering header information file(s) from server(s)
> Server: Fedora Core 1 - i386 - Rawhide
> Finding updated packages
> Downloading needed headers
> Resolving dependencies
> .Package apt needs librpm-4.2.so, this is not available.
> Package apt needs librpmdb-4.2.so, this is not available.
> Package apt needs librpmio-4.2.so, this is not available.
> Package db4-java needs db4 that has been excluded.
> Package redhat-config-network-tui needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-users needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-nfs needs /usr/bin/python2.2, this is not available.
> Package redhat-config-language needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-xfree86 needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-kickstart needs /usr/bin/python2.2, this is not
> available.Package redhat-config-date needs /usr/bin/python2.2, this is
> not available.
> Package redhat-config-keyboard needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-mouse needs /usr/bin/python2.2, this is not
> available.
> Package redhat-config-securitylevel needs /usr/bin/python2.2, this is
> not available.
> Package redhat-config-soundcard needs /usr/bin/python2.2, this is not
> available.Package redhat-config-samba needs /usr/bin/python2.2, this is
> not available.
> Package redhat-config-bind needs /usr/bin/python2.2, this is not available.
> Package redhat-config-rootpassword needs /usr/bin/python2.2, this is not
> available.
> [root at localhost root]#
All redhat-config-* packages have been superseded and obsoleted by
system-config-* packages. I think you will need to manually remove any
redhat-config-* package and install their equivalent system-config-*
ones.
From mmundy1 at umbc.edu Sat Apr 3 11:28:43 2004
From: mmundy1 at umbc.edu (mmundy1 at umbc.edu)
Date: Sat, 3 Apr 2004 06:28:43 -0500 (EST)
Subject: Dependency hell
In-Reply-To: <1080986816.1325.1.camel@teapot.felipe-alfaro.com>
References: <406E20C1.7020008@mindspring.com><1080979495.19191.14.camel@CirithUngol><406E7DB9.3010106@mindspring.com>
<1080986816.1325.1.camel@teapot.felipe-alfaro.com>
Message-ID: <4766.68.54.163.104.1080991723.squirrel@webmail.umbc.edu>
yes, I have run into these issues before. It helps to run `yum list
extras` to see which packages are installed, but are not in the yum.conf
repositories (removed in some cases such as the redhat-config-*). I do
not think that running yum upgrade would replace the redhat-config-* with
the appropriate system-config-* packages. Hope that idea clears up some
of the problems. I rarely get broken package upgrading these
after-extras-removed days :) (though libdv and the ethereal bugs did just
happen, they are the exception rather than the rule I think.)
---Matt
> On Sat, 2004-04-03 at 11:02, Richard Hally wrote:
>>
>> [root at localhost root]# yum --exclude=libdv* --exclude=Canna-lib
>> --exclude=db4 update
>> Gathering header information file(s) from server(s)
>> Server: Fedora Core 1 - i386 - Rawhide
>> Finding updated packages
>> Downloading needed headers
>> Resolving dependencies
>> .Package apt needs librpm-4.2.so, this is not available.
>> Package apt needs librpmdb-4.2.so, this is not available.
>> Package apt needs librpmio-4.2.so, this is not available.
>> Package db4-java needs db4 that has been excluded.
>> Package redhat-config-network-tui needs /usr/bin/python2.2, this is not
>> available.
>> Package redhat-config-users needs /usr/bin/python2.2, this is not
>> available.
>> Package redhat-config-nfs needs /usr/bin/python2.2, this is not
>> available.
>> Package redhat-config-language needs /usr/bin/python2.2, this is not
>> available.
>> Package redhat-config-xfree86 needs /usr/bin/python2.2, this is not
>> available.
>> Package redhat-config-kickstart needs /usr/bin/python2.2, this is not
>> available.Package redhat-config-date needs /usr/bin/python2.2, this is
>> not available.
>> Package redhat-config-keyboard needs /usr/bin/python2.2, this is not
>> available.
>> Package redhat-config-mouse needs /usr/bin/python2.2, this is not
>> available.
>> Package redhat-config-securitylevel needs /usr/bin/python2.2, this is
>> not available.
>> Package redhat-config-soundcard needs /usr/bin/python2.2, this is not
>> available.Package redhat-config-samba needs /usr/bin/python2.2, this is
>> not available.
>> Package redhat-config-bind needs /usr/bin/python2.2, this is not
>> available.
>> Package redhat-config-rootpassword needs /usr/bin/python2.2, this is not
>> available.
>> [root at localhost root]#
>
> All redhat-config-* packages have been superseded and obsoleted by
> system-config-* packages. I think you will need to manually remove any
> redhat-config-* package and install their equivalent system-config-*
> ones.
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>
From toshio at tiki-lounge.com Sat Apr 3 11:29:53 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Sat, 03 Apr 2004 06:29:53 -0500
Subject: fedora-startqa
In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC4@smith.interlink.local>
References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC4@smith.interlink.local>
Message-ID: <1080991787.28654.843.camel@Madison.badger.com>
On Fri, 2004-04-02 at 18:15, Erik LaBianca wrote:
> XML Output is a great idea IMO. We can define a schema for a review, and
> then use xslt to generate the actual review. We should all be able to
> easily agree on the xml schema, and for those that love to tweak they
> can always change the output template.
>
> In all reality, there may be a certain amount of benefit to actually
> posting the review in XML. It's obviously the easiest way of making the
> reviews computer parseable.
>
If we get to the point of having tools within which you can write a
complete review, we could have the tools post an xml review as an
attachment and a human formatted review as the attachment's comments.
(Although we then run into the problem of not everybody using the tools,
so the build architecture needs to understand this double posting as
opposed to a single posting method.)
(Hmmm... second thought, it may not be so bad. The build architecture
can scan for gpg signed review in either attachments or comments. Our
tools would only sign the XML review. Then it can compare the reviews
by version and output.)
> This may already be what you're doing, I must apologize for not looking
> at your code yet :)
>
I've defined a DTD for describing a checklist (So people with different
ideas of what a QA Checklist report could theoretically contribute new
checklists.) It needs some feedback and real-world stomping on.
There's two things that I want to do to extend it but I'm not sure how
at the moment.
My save file format is going to reflect this checklist DTD somehow.
It'll probably need to contain;
* checklist name (to link to the checklist)
* entry name (to link it back to the checklist item)
* display or hidden (So the information in the review is there, just not
shown)
* Resolution (Needs-Reviewing/Pass/Fail/Non-Blocker/Not-Applicable)
* potential output (The review information)
Since there is already potential output in the checklist, I'm not sure
what I'll limit it to. (one for every item? One for every output item
that has edited review output?) It'll be good to work with others on
defining these things.
-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:
From Nicolas.Mailhot at laPoste.net Sat Apr 3 11:38:58 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Sat, 03 Apr 2004 13:38:58 +0200
Subject: fedora-startqa
In-Reply-To: <1080991787.28654.843.camel@Madison.badger.com>
References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC4@smith.interlink.local>
<1080991787.28654.843.camel@Madison.badger.com>
Message-ID: <1080992338.6565.1.camel@m222.net81-64-248.noos.fr>
Le sam, 03/04/2004 ? 06:29 -0500, Toshio a ?crit :
> On Fri, 2004-04-02 at 18:15, Erik LaBianca wrote:
> > XML Output is a great idea IMO. We can define a schema for a review, and
> > then use xslt to generate the actual review. We should all be able to
> > easily agree on the xml schema, and for those that love to tweak they
> > can always change the output template.
> >
> > In all reality, there may be a certain amount of benefit to actually
> > posting the review in XML. It's obviously the easiest way of making the
> > reviews computer parseable.
> >
> If we get to the point of having tools within which you can write a
> complete review, we could have the tools post an xml review as an
> attachment and a human formatted review as the attachment's comments.
Just make the review the xml file and provide an xslt stylesheet which
converts it to something pretty.
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:
From russell at coker.com.au Sat Apr 3 12:18:51 2004
From: russell at coker.com.au (Russell Coker)
Date: Sat, 3 Apr 2004 22:18:51 +1000
Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at
"restarting tasks"
In-Reply-To: <406DE2F8.2010107@nogin.org>
References: <406DE2F8.2010107@nogin.org>
Message-ID: <200404032218.51868.russell@coker.com.au>
On Sat, 3 Apr 2004 08:02, Aleksey Nogin wrote:
> now at resume time, it starts resuming OK, but shortly after it says
> "restarting tasks", machine suddenly reboots.
[...]
> P.S. Somewhere around the time it stopped working, I started
> experimenting with enabling and using SELinux, so it might be
> SELinux-related.
If you suspect SE Linux of causing such problems then the thing to do is to
enable a serial console and capture the kernel messages to another machine.
I have never seen SE Linux cause a kernel problem without logging it to the
console (including serial console if one is enabled). I have on several
occasions seen SE Linux trigger a sudden reboot (by preventing the kernel
from doing what it wants) in a way that only a serial console could capture.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
From toshio at tiki-lounge.com Sat Apr 3 12:42:22 2004
From: toshio at tiki-lounge.com (Toshio)
Date: Sat, 03 Apr 2004 07:42:22 -0500
Subject: RFC: fedora.us QA approval format
In-Reply-To:
References:
Message-ID: <1080996135.28654.905.camel@Madison.badger.com>
On Thu, 2004-04-01 at 11:23, Aurelien Bompard wrote:
> I have setup a wiki page with a primary format proposal, and I invite you to
> have a look at it and comment on it: http://www.fedora.us/wiki/QAFormat
Comments on the Review Format:
I like lists and more succinct information. So I'd slim the output as
much as possible.
header:
Checked
* I would get rid of the first line altogether. Because these reviews
are going into bugzilla, the package name is already available. And it
doesn't provide any information the build system needs. Alternately,
you could make the first line:
so that it's useful for the build system. (But see my next entry.)
Files:
* I would change Files to MD5sums (or MD5SUMS) because at sometime in
the future the build system may support other hash types and it would be
good for it to be able to easily tell which is which one this is.
* I would specify that the always comes first in the HASH
section. This makes it easier for the release managers and the
buildsystem to parse the HASH-SRPM pairing from the other files.
It could also be separated by a blank line or other visible
demarcation.
Body:
I favor a Good/Blocker/Non-Blocker style with bulletted lists. For your
sample, I'd implement this as:
Good:
* Sources: bash-completion-20040331.tar.bz2 is valid
* Sources: bash-completion.profile is not web-accessible
* Signature: VALID - bcd241cb
* Installs, runs and uninstalls fine on FC1
* Spec file looks good.
Needswork:
Minor:
Notes:
[Put here the things you want to add about the package]
--TODO--
{Things todo when editing the review}
* Regarding the Sources lines: I'd include the full URL for the
tarball and say it comes from a canonical source rather than simply
"is valid".
* http://www.caliban.org/files/bash/bash-completion-20040331.tar.gz is
the canonical Source location
For the other source line, I'd want something like this:
* Sources: bash-completion.profile appears to be correct and proper
My reasoning is that I don't care so much about whether I can download
the files off the internet (More precisely: I only care if I can't.)
I do want to know what works been done verifying the sources (which
canonicalness of source tarballs helps for the first one and looking
at the file helps for the second.)
These could both go in the TODO section rather than the completed
review.
Anyhow, this looks like it'll be a tremendously helpful tool when
it's finished. Good work!
-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:
From skvidal at phy.duke.edu Sat Apr 3 14:26:24 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 03 Apr 2004 09:26:24 -0500
Subject: Dependency hell
In-Reply-To: <1080986816.1325.1.camel@teapot.felipe-alfaro.com>
References: <406E20C1.7020008@mindspring.com>
<1080979495.19191.14.camel@CirithUngol>
<406E7DB9.3010106@mindspring.com>
<1080986816.1325.1.camel@teapot.felipe-alfaro.com>
Message-ID: <1081002384.2617.16.camel@binkley>
> All redhat-config-* packages have been superseded and obsoleted by
> system-config-* packages. I think you will need to manually remove any
> redhat-config-* package and install their equivalent system-config-*
> ones.
>
running 'yum upgrade' will take care of the obsoleted packages.
-sv
From skvidal at phy.duke.edu Sat Apr 3 14:26:55 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 03 Apr 2004 09:26:55 -0500
Subject: Dependency hell
In-Reply-To: <4766.68.54.163.104.1080991723.squirrel@webmail.umbc.edu>
References: <406E20C1.7020008@mindspring.com>
<1080979495.19191.14.camel@CirithUngol><406E7DB9.3010106@mindspring.com>
<1080986816.1325.1.camel@teapot.felipe-alfaro.com>
<4766.68.54.163.104.1080991723.squirrel@webmail.umbc.edu>
Message-ID: <1081002415.2617.18.camel@binkley>
On Sat, 2004-04-03 at 06:28 -0500, mmundy1 at umbc.edu wrote:
> yes, I have run into these issues before. It helps to run `yum list
> extras` to see which packages are installed, but are not in the yum.conf
> repositories (removed in some cases such as the redhat-config-*). I do
> not think that running yum upgrade would replace the redhat-config-* with
> the appropriate system-config-* packages.
yum upgrade will replace the redhat-config-* with system-config-*
-sv
From gauret at free.fr Sat Apr 3 15:00:58 2004
From: gauret at free.fr (Aurelien Bompard)
Date: Sat, 03 Apr 2004 17:00:58 +0200
Subject: fedora-startqa
References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC4@smith.interlink.local>
Message-ID:
> > If this is votable I +1 :-)??Make?the?reviewer?do?it?because?they?have
> > to go through the TODO list anyhow.
>
> +1 from me too, and at worst a 0 from Aurelien, so at the current time
> we're in the majority. :)
That's completely OK by me. Let's do that. I trust users too much ;-)
Aur?lien
--
http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info
"Science sans conscience n'est que ruine de l'?me." -- Rabelais
From buildsys at redhat.com Sat Apr 3 15:54:33 2004
From: buildsys at redhat.com (Build System)
Date: Sat, 3 Apr 2004 10:54:33 -0500
Subject: rawhide report: 20040403 changes
Message-ID: <200404031554.i33FsXA24133@porkchop.devel.redhat.com>
New package gimp-help
Help files for the GIMP.
Removed package boost-jam
Updated Packages:
arts-1.2.1-2
------------
* Fri Apr 02 2004 Than Ngo 1.2.1-2
- add several fixes from stable branch
devhelp-0.9-1
-------------
* Fri Apr 02 2004 Mark McLoughlin 0.9-1
- Update to 0.9
- Install the schemas correctly
- Package /usr/bin/devhelp-bin
- Update requires/buildrequires
- Only build on platforms where mozilla is available
elfutils-0.95-2
---------------
* Fri Apr 02 2004 Jeff Johnson 0.95-2
- upgrade to 0.95.
gcc34-3.4.0-0.9
---------------
* Fri Apr 02 2004 Jakub Jelinek