From mike at flyn.org Sat Nov 1 00:33:41 2003 From: mike at flyn.org (W. Michael Petullo) Date: Fri, 31 Oct 2003 18:33:41 -0600 Subject: More loitering process curiosities In-Reply-To: <20031031214256.GA7403@imp.flyn.org> References: <20031030193231.E28D73156D@neuromancer.voxel.net> <1067547478.5823.25.camel@localhost.localdomain> <20031031005627.GA1536@imp.flyn.org> <1067577613.15833.61.camel@localhost.localdomain> <20031031175656.GA1020@imp.flyn.org> <20031031214256.GA7403@imp.flyn.org> Message-ID: <20031101003341.GA2681@imp.flyn.org> > We've made some progress getting gconfd-2 to exit when a user logs out > (see "gconfd-2 does not exit when a user log out, breaks unmounting > home" thread). Now I am interested in turning my attention to some > other processes that seem to loiter around after one logs out of a GNOME > 2.4.0 session. > > Pam_mount performs an lsof that claims the processes are still running > when pam_close_session is called, but the processes are gone after the > user is completely logged out (Unlike gconfd-2, which stayed running > for two minutes). > > The following processes hang around (with $HOME as their CWD): > > bonobo-activation-server > gnome-settings-daemon > xscreensaver > mapping-daemon > > While investigating these four processes, I have gotten myself very > confused. > > First, on my system, pstree says: > > init-+-aio/0 > |-atd > ... > |-bonobo-activati > ... > |-gdm-binary---gdm-binary-+-X > | `-gnome-session---ssh-agent > |-gnome-panel > |-gnome-settings-daemon > ... > > Why is init the parent process of /usr/libexec stuff like > bonobo-activation-server? How does that happen? > > Why does gnome-panel not have gnome-session as its parent? > > At first I thought that things like login and gdm sent HUP signals to > children when a user logs out. I had forgotten that it was in fact the > shell that performs this magic. So my idea of ensuring that gdm kill > -HUP'd all of a user's programs before calling pam_close_session was > faulty. > > The processes do seem to get killed (but after pam_close_session code) > but I'm not sure by what means. Could someone shed some light on this > or nudge me in the right direction for some documentation? > > I'd really like to fix pam_mount/gdm/GNOME. Okay, I just realized that having the X server stopped will cause X applications like xscreensaver to exit (duh). Gdm kills X when a user logs out and I think I can ensure this happens before pam_close_session is called. But I'm still curious about this process hierarchy. Why do processes like bonobo-activation-server and gnome-panel seem to execute with init as their parent? -- Mike :wq From barryn at pobox.com Sat Nov 1 01:35:34 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 31 Oct 2003 17:35:34 -0800 Subject: More loitering process curiosities In-Reply-To: <20031101003341.GA2681@imp.flyn.org> References: <20031030193231.E28D73156D@neuromancer.voxel.net> <1067547478.5823.25.camel@localhost.localdomain> <20031031005627.GA1536@imp.flyn.org> <1067577613.15833.61.camel@localhost.localdomain> <20031031175656.GA1020@imp.flyn.org> <20031031214256.GA7403@imp.flyn.org> <20031101003341.GA2681@imp.flyn.org> Message-ID: <20031101013534.GB29089@ip68-4-255-84.oc.oc.cox.net> On Fri, Oct 31, 2003 at 06:33:41PM -0600, W. Michael Petullo wrote: > But I'm still curious about this process hierarchy. Why do processes > like bonobo-activation-server and gnome-panel seem to execute with init > as their parent? Reparenting. When a child process's parent dies, but the child lives on, init becomes the child's new parent. Does that help? -Barry K. Nathan From salimma1 at yahoo.co.uk Sat Nov 1 05:36:07 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Sat, 01 Nov 2003 12:36:07 +0700 Subject: Fedora suggestion - build certain packages for i686? Message-ID: <1067664967.27833.37.camel@bushido.localdomain> Hello, What changed would need to be made to the current Fedora.us package autobuilder so that it could build packages for different target architectures? Maybe if the packager notes in a Bugzilla submission that such-and-such package should be built for (say) i686 to obtain MMX support, then the package could be added to a 'compile for i686' list which the autobuilder will consult when building a package? More ambitiously, perhaps a package should provide hints of which processor features it could make use of (MMX, SSE etc.) and the autobuilder will then build it for the relevant architectures *in addition* to the standard i386? This is not necessary for apps that autodetect CPU features like Mplayer, of course. Regards, Michel From mharris at redhat.com Sat Nov 1 07:14:00 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 1 Nov 2003 02:14:00 -0500 (EST) Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: <3FA2722D.6090504@togami.com> References: <3FA229D3.4000104@togami.com> <3FA2722D.6090504@togami.com> Message-ID: On Fri, 31 Oct 2003, Warren Togami wrote: >> Just a personal opinion that this might confuse people, and if a >> better name can be chosen that is short enough and clear, it >> might be better. > >Hmmm, I am in agreement. While we fedora.us people had no problem with >vepoch for many months, I can see where it is confusing. I designed the >name to be "Kind of like epoch, vepoch trumps all, but less." > >Perhaps "patchlevel" is a better word. I'm not sure patchlevel gives the right visual either.. It implies something to do with the number of patches being applied, or the version of a patch or something. >> I strongly agree with this approach. Probably because I stole it >> from bero, and I think you picked it up from me or from bero >> also. ;o) It works very well IMHO. It's also very useful with >> CVS based releases where you can embed the CVS date into the >> release field instead of the version field, thus avoiding having >> to use Epoch later on to override the large integer release >> number from a CVS date. > >Yes, when I originally designed this method I was pointing at bero's >packages as justification. "See! Look, Red Hat did it!" Yeah, this is a very good way to work around a not uncommon problem. >Err... you are completely right about it not being necessary in the >post-release case. I am not sure why our fedora.us policy retained that >even though it was unnecessary for all these months. The way I >understand the older version of rpm broken rpmvercmp behavior, this >wouldn't be a problem with those versions too. Ah. RHL 7.2 shipped with rpm-4.0.3-1.03, and 7.3 shipped with rpm-4.0.4-7x.18, both of which don't have this problem. rpm 4.0.4 is the current erratum for all distribution releases from RHL 7.0 and later (or a newer version of rpm). Older versions aparently did have the problem according to other mails I received, but I think it's safe to say that distro releases supported by Fedora are unaffected, and that at least as far back as a properly updated 7.0 system should also be unaffected. RHL 6.2 seems to have an older rpm version which may or may not be affected, but I think that's outside the care zone. ;o) >> Ick. Underscores in version/release are hideous IMHO. I'd use >> "." instead of "_". Your comment at the top of this section >> indicates a ".", so perhaps you just made a typo, and sequence of >> cut and paste errors? ;o) > >Oops. Yeah, fedora.us original plan was ".", however some here on >fedora-devel-list argued toward "_" as a more clear separator between >the patchlevel and disttag because it can be confusing with so many "." Hmm. Good point. Perhaps it just needs some getting used to. >I personally actually prefer the "." separator, but I really don't care >which is chosen. I suppose if it's a useful thing to people that we should keep an open mind about it, even if it is ugly. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From pzb at datastacks.com Sat Nov 1 10:46:52 2003 From: pzb at datastacks.com (Peter Bowen) Date: Sat, 01 Nov 2003 05:46:52 -0500 Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: <3FA229D3.4000104@togami.com> References: <3FA229D3.4000104@togami.com> Message-ID: <1067683612.3818.4.camel@10-0-0-233.boston.ximian.com> On Fri, 2003-10-31 at 04:22, Warren Togami wrote: > Example: > foobar-1.0a > foobar-1.0b > > The "1.0b" version is higher than "1.0a", but all versions of RPM > prior to rpm-4.2-0.55 are confused when it tries to compare letters. > Whichever package is first in the comparison "wins", thus this becomes > a two way upgrade problem. This a < b comparison works properly only > in RH9 and higher. a < b has worked in RPM from day one. The only issue in rpm's version comparison function was comparing a letter to a number, for example 1.a vs 1.1. All versions of rpm would get the example right. Thanks. Peter From nphilipp at redhat.com Sat Nov 1 11:21:59 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 01 Nov 2003 12:21:59 +0100 Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: <20031031180006.1b3cad50.ms-nospam-0306@arcor.de> References: <3FA229D3.4000104@togami.com> <3FA2722D.6090504@togami.com> <20031031180006.1b3cad50.ms-nospam-0306@arcor.de> Message-ID: <1067685719.18080.26.camel@wombat.tiptoe.de> On Fri, 2003-10-31 at 18:00, Michael Schwendt wrote: > On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote: [...] > > > Are there cases where rpm would consider imap-2000a as older than > > > imap-2000? > > > > > > jbj? > > > > > > > Err... you are completely right about it not being necessary in the > > post-release case. I am not sure why our fedora.us policy retained that > > even though it was unnecessary for all these months. The way I > > understand the older version of rpm broken rpmvercmp behavior, this > > wouldn't be a problem with those versions too. > > * To be able to go back from 2.1.7a to a patched 2.1.7 in case the > 2.1.7a post-release "fix" turns out to cause side-effects. Hmm I'm not sure if I buy that -- extrapolating form that, one should also be able to go back from 2.1.8 to 2.1.7 in case the new version turns out to cause side-effects (without any "--oldpackages" stuff or that point is moot). We could also set the version to "1" for all packages and use only serial numbers for releases -- that way updating always works ;-). I think the version should always be the upstream version where these are not incompatible with RPM version comparisons and real version numbers (and not CVS dates or the like because they may be substituted with real version numbers which are likley less RPM wise) and (optional) characters represent newer patch levels (and not prereleases). If that version number contains dashes, replacing them with underscores might be necessary. > * Consistency above all. Care to explain that one? Of course the idea I have about versioning seems most consistent to me but I'm sure you can shed some light on why version numbers differing from upstream are more consistent ;-). > * The road of least surprise (with regard to upstream versioning). That's what I want. > * To help avoid that users think foo-1.0a would be an unstable alpha > version, when in fact it is a post-release patch-level. I do not think that is the purpose of an RPM version tag. It exists so the user knows that this is the upstream version number-- how else would a user be able to submit bug reports upstream if he cannot supply the real version number/string/whatever. If users interpret version strings like "1.0a" as an alpha version when they're not -- well, that's tough luck but nothing that should be worked around by some RPM version trickeries. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at porkchop.devel.redhat.com Sat Nov 1 11:38:40 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sat, 1 Nov 2003 06:38:40 -0500 Subject: rawhide report: 20031101 changes Message-ID: <200311011138.hA1Bcdd26406@porkchop.devel.redhat.com> Updated Packages: fedora-release-1-3 ------------------ indexhtml-1-2 ------------- mozilla-1.4.1-17 ---------------- * Thu Oct 30 2003 Christopher Blizzard 37:1.4.1-17 - Add changes to get building with -pie working openh323-1.11.2-4 ----------------- * Wed Jan 22 2003 Tim Powers - rebuilt * Wed Jan 08 2003 Alexander Larsson 1.11.2-3 - Update the PIC patch for the speex codec. * Wed Jan 08 2003 Alexander Larsson 1.11.2-2 - Actually mkdir datadir/openh323 * Wed Jan 08 2003 Alexander Larsson 1.11.2-1 - Update to 1.11.2 - Removed extra speex source as it's now built in - Update build patches - Moved openh323u.mak to datadir/openh323 * Tue Jan 07 2003 Nalin Dahyabhai 1.9.10-5 - Rebuild * Wed Oct 23 2002 Alexander Larsson 1.9.10-4 - Add speex header files * Wed Oct 23 2002 Alexander Larsson 1.9.10-3 - Fix unpackages files * Wed Oct 23 2002 Alexander Larsson 1.9.10-2 - Fix speex linking - Remove custom strndup that was colliding with system one * Wed Oct 23 2002 Alexander Larsson 1.9.10-1 - Update to 1.9.10 - Include speex tarball * Wed Oct 09 2002 Alex Larsson 1.9.3-5 - Change to use _libdir etc. throughout specfile - Build with -fPIC * Sat Aug 10 2002 Elliot Lee - rebuilt with gcc-3.2 (we hope) * Tue Aug 06 2002 Alexander Larsson 1.9.3-3 - Removed excludearch ia64 * Mon Jul 22 2002 Tim Powers 1.9.3-2 - rebuild using gcc-3.2-0.1 * Thu Jul 11 2002 Alexander Larsson 1.9.3-1 - Update to 1.9.3 * Tue Jul 02 2002 Alexander Larsson 1.9.1-1 - Updated to 1.9.1, some changes borrowed from - the rpms by Carl-Johan Kjellander * Fri Mar 22 2002 Alex Larsson - Add versioned dependency on main package in devel package - Fix to long line in desctiption * Fri Mar 08 2002 Alex Larsson - Bump version to rebuild against new pwlib * Mon Feb 25 2002 Alex Larsson - Update to 1.8.0 * Fri Sep 28 2001 Alex Larsson 1.6.1-3 - made the devel package require the binary package * Mon Aug 13 2001 Alexander Larsson 1.6.0-2 - Changed libname to liboh323 * Mon Aug 13 2001 Alexander Larsson 1.6.0-1 - Upgraded to 1.6.0 * Thu Jul 05 2001 Elliot Lee 1.5.5-3 - Remove PLATFORM_TYPE from libname * Wed Jul 04 2001 Elliot Lee 1.5.5-2 - More fixups. The patch is not named IHATEYOU because of a loving relationship... * Wed Jul 04 2001 Jonathan Blandford - Initial build. redhat-artwork-0.88-1 --------------------- * Thu Oct 30 2003 Jonathan Blandford 0.88-1 - gdm fixes rpmdb-fedora-1-0.20031101 ------------------------- From ms-nospam-0306 at arcor.de Sat Nov 1 13:23:12 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 1 Nov 2003 14:23:12 +0100 Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: <1067685719.18080.26.camel@wombat.tiptoe.de> References: <3FA229D3.4000104@togami.com> <3FA2722D.6090504@togami.com> <20031031180006.1b3cad50.ms-nospam-0306@arcor.de> <1067685719.18080.26.camel@wombat.tiptoe.de> Message-ID: <20031101142312.1499dacb.ms-nospam-0306@arcor.de> On Sat, 01 Nov 2003 12:21:59 +0100, Nils Philippsen wrote: > On Fri, 2003-10-31 at 18:00, Michael Schwendt wrote: > > On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote: > [...] > > > > Are there cases where rpm would consider imap-2000a as older than > > > > imap-2000? > > > > > > > > jbj? > > > > > > > > > > Err... you are completely right about it not being necessary in the > > > post-release case. I am not sure why our fedora.us policy retained that > > > even though it was unnecessary for all these months. The way I > > > understand the older version of rpm broken rpmvercmp behavior, this > > > wouldn't be a problem with those versions too. > > > > * To be able to go back from 2.1.7a to a patched 2.1.7 in case the > > 2.1.7a post-release "fix" turns out to cause side-effects. > > Hmm I'm not sure if I buy that -- extrapolating form that, one should > also be able to go back from 2.1.8 to 2.1.7 in case the new version > turns out to cause side-effects (without any "--oldpackages" stuff or > that point is moot). That would be something different, since I assume 2.1.8 comes quite some time after 2.1.7. On the contrary, 2.1.7a would be sort of a quick brown paperbag fix attempt which would be released shortly after 2.1.7, often just a few hours later or on the same day. Including such an upstream fix prior to publishing a package is tempting, and sometimes it turns out right after release that the fix breaks other parts of the software in an unexpected way and the real fix takes more time. I'd a fan of serial numbers, but not when they're hidden. I would even like a scheme like name.serial.upstreamversion.arch.rpm > I think the version should always be the upstream version where these > are not incompatible with RPM version comparisons and real version > numbers (and not CVS dates or the like because they may be substituted > with real version numbers which are likley less RPM wise) and (optional) > characters represent newer patch levels (and not prereleases). If that > version number contains dashes, replacing them with underscores might be > necessary. Not "might be necessary", it is a strict requirement by RPM. > > * Consistency above all. > > Care to explain that one? Of course the idea I have about versioning > seems most consistent to me but I'm sure you can shed some light on why > version numbers differing from upstream are more consistent ;-). Since you understand the need for a pre-release version/release modification guideline, you do understand this guideline very well, too, and hence it doesn't need much of an explanation IMO. > > * The road of least surprise (with regard to upstream versioning). > > That's what I want. > > > * To help avoid that users think foo-1.0a would be an unstable alpha > > version, when in fact it is a post-release patch-level. > > I do not think that is the purpose of an RPM version tag. It exists so > the user knows that this is the upstream version number-- how else would > a user be able to submit bug reports upstream if he cannot supply the > real version number/string/whatever. The user should find the software version number in the "About" or "Help" sections, in the manual and should never rely on package versioning. E.g. KDE 3.1.4-6 is not an upstream version, GCC 2.96 wasn't either. Now don't tell me all users know what the release version is. Why should it be allowed (or make sense) to modify 1.0rc3-2 to 1.0-2.rc3, but not 1.0pl1-2 to 1.0-2.pl1? > If users interpret version strings > like "1.0a" as an alpha version when they're not -- well, that's tough > luck but nothing that should be worked around by some RPM version > trickeries. It's not a primary goal, but it helps. It should not be user's responsibility to know that Mozilla 1.5a is older than 1.5, but Foo 1.5a is a bug-fix release for Foo 1.5. The package release version should make that obvious. Else user keeps using the unstable Mozilla 1.5a as long as rpmseek.com doesn't list a newer version. I don't like the dependency on upstream versioning at all, cases such as 1.01 > 1.0.2, 0.6 > 0.50, 0.010 > 0.1, 1.2 < 1.02, 1.0a < 1.0 or 1.0a > 1.0, ... not all can be dealt with without modifying these version numbers. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tadejjanez at email.si Sat Nov 1 16:16:29 2003 From: tadejjanez at email.si (Tadej =?iso-8859-2?Q?Jane=BE?=) Date: Sat, 01 Nov 2003 17:16:29 +0100 Subject: rawhide report: 20031101 changes In-Reply-To: <200311011138.hA1Bcdd26406@porkchop.devel.redhat.com> References: <200311011138.hA1Bcdd26406@porkchop.devel.redhat.com> Message-ID: <1067703388.5844.5.camel@n800v-severn2> On Sat, 2003-11-01 at 12:38, Build System wrote: > Updated Packages: > > fedora-release-1-3 > ------------------ > > indexhtml-1-2 > ------------- > > mozilla-1.4.1-17 > ---------------- > > openh323-1.11.2-4 > ----------------- > > redhat-artwork-0.88-1 > --------------------- > > rpmdb-fedora-1-0.20031101 > ------------------------- Where are these packages and the ones from yesterday's rawhide update? At least I can't find them on ftp.redhat.com. Is rawhide and/or build-system having some difficulties? Tadej From mike at flyn.org Sat Nov 1 23:17:37 2003 From: mike at flyn.org (W. Michael Petullo) Date: Sat, 1 Nov 2003 17:17:37 -0600 Subject: More loitering process curiosities In-Reply-To: <20031101003341.GA2681@imp.flyn.org> References: <20031030193231.E28D73156D@neuromancer.voxel.net> <1067547478.5823.25.camel@localhost.localdomain> <20031031005627.GA1536@imp.flyn.org> <1067577613.15833.61.camel@localhost.localdomain> <20031031175656.GA1020@imp.flyn.org> <20031031214256.GA7403@imp.flyn.org> <20031101003341.GA2681@imp.flyn.org> Message-ID: <20031101231737.GA14764@imp.flyn.org> >> We've made some progress getting gconfd-2 to exit when a user logs out >> (see "gconfd-2 does not exit when a user log out, breaks unmounting >> home" thread). Now I am interested in turning my attention to some >> other processes that seem to loiter around after one logs out of a GNOME >> 2.4.0 session. >> >> Pam_mount performs an lsof that claims the processes are still running >> when pam_close_session is called, but the processes are gone after the >> user is completely logged out (Unlike gconfd-2, which stayed running >> for two minutes). >> >> The following processes hang around (with $HOME as their CWD): >> >> bonobo-activation-server >> gnome-settings-daemon >> xscreensaver >> mapping-daemon Modifying gdm to kill X before running pam_close_session() seems to fix my problem with xscreensaver and gnome-settings-daemon. Right now gdm does things in the opposite order. I should have a decent patch for the gdm folks soon. Further patching gnome-session to run bonobo-slay rids me of the loitering bonobo-activation-server process. Are their any objections to this? I'm not sure about the mapping-daemon process. Apparently it is a component of the nautilus-cd-burner package. There does not seem to be a nice facility for causing the process to quit. From looking at mapping-daemon.c, it appears that the daemon wakes up every 5000us, checks to see if it has any client nautilus processes and exits if it does not. So my modified gdm kills X/nautilus and then runs pam_close_session in less than 5000us. Does anyone have a suggestion for mapping-daemon? -- Mike :wq From yinyang at eburg.com Sat Nov 1 23:37:49 2003 From: yinyang at eburg.com (Gordon Messmer) Date: Sat, 01 Nov 2003 15:37:49 -0800 Subject: Packages RFC In-Reply-To: <3F9C2C70.5070304@koziarski.com> References: <20031026171130.GA9316@inxservices.com> <20031026182117.A7716@xos037.xos.nl> <1067190736.2328.22.camel@localhost.localdomain> <2250.172.211.221.208.1067198578.squirrel@tasonline.com> <20031026211505.C8309@xos037.xos.nl> <3F9C2C70.5070304@koziarski.com> Message-ID: <3FA443CD.8080605@eburg.com> Michael A. Koziarski wrote: > > The qmail license situation is a bit of a mess. What would be nice is a > guide to migrating to something that *can* be distributed by modern > distributions. > > I currently have several gigabytes of my family's mail in hundreds of > qmail Maildirs. An MDA that can read those as is, or can provide > conversion scripts, would be greatly appreciated. Consider Courier: http://www.courier-mta.org/ It's extremely similar to qmail in its function and configuration. Migration should be very easy. It was for me. From jm at jmason.org Sat Nov 1 23:37:44 2003 From: jm at jmason.org (Justin Mason) Date: Sat, 01 Nov 2003 15:37:44 -0800 Subject: More loitering process curiosities In-Reply-To: <20031101231737.GA14764@imp.flyn.org> Message-ID: <20031101233749.8FFC616F0E@jmason.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 W. Michael Petullo writes: >I'm not sure about the mapping-daemon process. Apparently it is a >component of the nautilus-cd-burner package. There does not seem to >be a nice facility for causing the process to quit. From looking at >mapping-daemon.c, it appears that the daemon wakes up every 5000us, >checks to see if it has any client nautilus processes and exits if it >does not. Are you certain that's every 5000us, as in microseconds? So this process wakes up, and runs a code loop *every 5 milliseconds*?! That'd be horrific for load, if so. - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Exmh CVS iD8DBQE/pEPIQTcbUG5Y7woRAg9EAKDeOrldMz11VxzKx0AyhblmSB2lFwCgnNdP zMzBq90+RAImxO9VZ+xtOAs= =nsdw -----END PGP SIGNATURE----- From chuckw at quantumlinux.com Sat Nov 1 23:39:08 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sat, 1 Nov 2003 15:39:08 -0800 (PST) Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: <1067615251.2792.1.camel@ulysse.olympe.o2t> Message-ID: > > I personally actually prefer the "." separator, but I really don't > > care which is chosen. > > For the record, I think underscores are hideous too. That makes it three > people that commented on this:) I hate me too posts... But... aw heck... me too... -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com A: Because we read from top to bottom, left to right. Q: Why should i start my reply below the quoted text? From tcallawa at redhat.com Sun Nov 2 02:57:37 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 01 Nov 2003 20:57:37 -0600 Subject: Self Introduction: Tom "spot" Callaway Message-ID: <1067741857.3651.160.camel@localhost.localdomain> Full Legal Name: Tom Callaway Location: Chicago, IL, USA Profession: Enterprise Architect Company: Red Hat My Goals in the Fedora Project: My goal is to work with Fedora to help advance Linux/SPARC. Right now, that is through the Aurora SPARC Linux Project (http://auroralinux.org), which I'm currently in charge of. I'm willing to do QA, although, I'd prefer to focus on SPARC specific QA testing. I don't have any specific packages that I'm pushing at the moment, but I reserve the right to amend that list as we move forward. Historical qualifications: What other projects have you worked on in the past? I'm currently project leader (and founder) for the Aurora SPARC Linux Project (http://auroralinux.org), with one successful major release under my belt, and another one in development. I've submitted some minor patches to various Red Hat Linux packages as a byproduct of my job, and troubleshooted advanced bugs and misconfigurations with enterprise customers. I also once wrote a nasty shell script to emulate Solaris's prtdiag. Why should we trust you? Red Hat trusts me. :) GPG KEYID and fingerprint: pub 1024D/93054260 2001-03-22 Tom Callaway (spot) Key fingerprint = D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260 sub 2048g/6F9658C0 2001-03-22 ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora SPARC Linux Project Leader "The author's mathematical treatment of the conception of purpose is novel and highly ingenious, but heretical and, so far as the present social order is concerned, dangerous and potentially subversive. Not to be published." -- Aldous Huxley From didierbe at sps.nus.edu.sg Sun Nov 2 06:56:03 2003 From: didierbe at sps.nus.edu.sg (Didier Casse) Date: Sun, 2 Nov 2003 14:56:03 +0800 (SGT) Subject: Questions about some default packages Fedora project Message-ID: Hi, I'm new at this Fedora concept and I would like to ask the following questions: 1. How come we only have a limited number of Window Managers in Fedora? i.e only (GNOME, KDE and twm) Why don't we include more robust or eye-candy desktops such as Fluxbox, Enlightenment, XFCE, etc... ? 2. If we have created some of our own programs, for instance I created pdfmerge/pdfmerge4unix (program which merges any number of pdf files), [I know it's a small thing but it was just an example! ;-p] which is on SF.net, and I wish to make it available to the Fedora project/users since it's a useful program. Where do I submit my rpm packages to? Is it possible to make it available to apt-repositories of Fedora? 3. Why don't we have a lot of packagers available at hand compared to Debian? I think all of you are aware that the apt of Debian covers a wider range of packages than Fedora/RH. Debian also have several maintainers which takes care of all their packages issues. Why don't we have the same concept in Fedora? With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg From warren at togami.com Sun Nov 2 09:05:38 2003 From: warren at togami.com (Warren Togami) Date: Sat, 01 Nov 2003 23:05:38 -1000 Subject: Questions about some default packages Fedora project In-Reply-To: References: Message-ID: <1067763937.14617.28.camel@laptop> On Sat, 2003-11-01 at 20:56, Didier Casse wrote: > Hi, > I'm new at this Fedora concept and I would like to ask the following > questions: > > 1. How come we only have a limited number of Window Managers in Fedora? > i.e only (GNOME, KDE and twm) I don't know the actual reason, but my guess is that the window managers and desktop environments were simplified to a minimal set in order to reduce the engineering load for the previous paid engineer hour distribution that was Red Hat Linux. With limited engineers and far too much work to do of much higher importance (i.e. NPTL, XFree86 drivers and a thousand other things), you simply cannot expect something like enlightenment to get the necessary time and care needed for a quality package. KISS principles rule when resources are limited. > > Why don't we include more robust or eye-candy desktops such as Fluxbox, > Enlightenment, XFCE, etc... ? Now that Fedora is moving toward community involvement in engineering, packaging, quality assurance, we can package these things. For fedora.redhat.com package submission is not ready, so you can submit packages to fedora.us to begin the community driven package acceptance process. I believe fluxbox is already submitted, or may already be published at fedora.us. > 2. If we have created some of our own programs, for instance I created > pdfmerge/pdfmerge4unix (program which merges any number of pdf files), > [I know it's a small thing but it was just an example! ;-p] > which is on SF.net, and I wish to make it available to the Fedora > project/users since it's a useful program. Where do I submit my rpm > packages to? > > Is it possible to make it available to apt-repositories of Fedora? > RH dislikes the idea of putting apt pkglists on official mirrors because they do not ship apt. I personally am unhappy about this, however I accept their decision. In the future there may be a resolution to this problem. Currently yum, apt, and up2date developers are working on standardizing a header format so all three clients use the same metadata. That way it doesn't matter what client you use, they are all officially supported by all mirrors. I don't know the status of this development though. > 3. Why don't we have a lot of packagers available at hand compared to > Debian? I think all of you are aware that the apt of Debian covers a wider > range of packages than Fedora/RH. http://www.fedora.us/wiki/PackageSubmissionQAPolicy Fedora Project needs to create our own community of packagers. Read this and get started by doing the Self-Introduction post. Then look at many examples of other people's package submissions, then submit your own packages. http://www.fedora.us/QA Look here to see all current packages that are in QA. We need more people to do quality QA analysis for these packages to become published. > > Debian also have several maintainers which takes care of all their > packages issues. Why don't we have the same concept in Fedora? > What do you mean by "packages issues"? Warren From jfm512 at free.fr Sun Nov 2 09:18:17 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 02 Nov 2003 10:18:17 +0100 Subject: Questions about some default packages Fedora project In-Reply-To: References: Message-ID: <1067764697.1147.26.camel@agnes.fremen.dune> On Sun, 2003-11-02 at 07:56, Didier Casse wrote: > Hi, > I'm new at this Fedora concept and I would like to ask the following > questions: > > 1. How come we only have a limited number of Window Managers in Fedora? > i.e only (GNOME, KDE and twm) > > Why don't we include more robust or eye-candy desktops such as Fluxbox, > Enlightenment, XFCE, etc... ? > A month ago I detailed the drawbacks of redundant software: -takes resources to package and test -some of it ends becoming unmaintained by original author and after a while no longer compiles -security holes: the more software, the more you have, specially when maintenance is not active -confuses users: "which window manager between 10? which web server between 8?" For including a piece of redundant software two conditions have to be met: a) it has a definite ecological niche where it is head and shoulders superior to the defending champion (and a lot of people are in this niche) and/or b) it has a sizable community of users (eg VI and Emacs) The above is for Fedora proper. Rules for repositories could be more relaxed. > 2. If we have created some of our own programs, for instance I created > pdfmerge/pdfmerge4unix (program which merges any number of pdf files), > [I know it's a small thing but it was just an example! ;-p] > which is on SF.net, and I wish to make it available to the Fedora > project/users since it's a useful program. Where do I submit my rpm > packages to? > > Is it possible to make it available to apt-repositories of Fedora? > > 3. Why don't we have a lot of packagers available at hand compared to > Debian? I think all of you are aware that the apt of Debian covers a wider > range of packages than Fedora/RH. > > Debian also have several maintainers which takes care of all their > packages issues. Why don't we have the same concept in Fedora? > Debian is IMHO a fine example of what NOT to do: the only time I got a headache installing Linux was with Debian while I struggled with program after program doing the same thing some of them with no ecological niche or one who was quickly closing. I will also recall again the problem of programs whose maintenance stops: you include a marginal program in the distribution, some users see it and use it because of this, the maintenance stops and after a while the program no longer compiles/works properly against new versions of libraries and kernel. If you withdraw it then you betray those users who adopted it because of YOU, if you keep it you will be burning a lot of resources for a program who concerns only a limited number of people > > With kind regards, > > Didier. > > --- > PhD student > > Singapore Synchrotron Light Source (SSLS) > 5 Research Link, > Singapore 117603 > > Email: slsbdfc at nus dot edu dot sg \or\ > didierbe at sps dot nus dot edu dot sg > Website: http://ssls.nus.edu.sg > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jean Francois Martinez From didierbe at sps.nus.edu.sg Sun Nov 2 09:30:24 2003 From: didierbe at sps.nus.edu.sg (Didier Casse) Date: Sun, 2 Nov 2003 17:30:24 +0800 (SGT) Subject: Questions about some default packages Fedora project In-Reply-To: <1067763937.14617.28.camel@laptop> Message-ID: On Nov 1, 2003, Warren Togami babbled: > With limited engineers and far too much work to do of much higher > importance (i.e. NPTL, XFree86 drivers and a thousand other things), you > simply cannot expect something like enlightenment to get the necessary > time and care needed for a quality package. But you still can get support from the Enlightenment team! I currently use Enlightenment and I'm often on their mailing list. I can tell you that they (and including me!) can provide full support for anybody who use E desktop on any distro. I currently use RH9 and willing to help anybody who has problems with E on RH9. > RH dislikes the idea of putting apt pkglists on official mirrors because > they do not ship apt. I personally am unhappy about this, however I > accept their decision. I'm unhappy too ;-p > > In the future there may be a resolution to this problem. Currently yum, > apt, and up2date developers are working on standardizing a header format > so all three clients use the same metadata. That way it doesn't matter > what client you use, they are all officially supported by all mirrors. > I don't know the status of this development though. > Cool! > > 3. Why don't we have a lot of packagers available at hand compared to > > Debian? I think all of you are aware that the apt of Debian covers a wider > > range of packages than Fedora/RH. > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > Fedora Project needs to create our own community of packagers. Read > this and get started by doing the Self-Introduction post. Then look at > many examples of other people's package submissions, then submit your > own packages. > Thanks for the tip. But I wonder why they don't put it on http://fedora.redhat.com > http://www.fedora.us/QA > Look here to see all current packages that are in QA. We need more > people to do quality QA analysis for these packages to become published. > > > > > Debian also have several maintainers which takes care of all their > > packages issues. Why don't we have the same concept in Fedora? > > > > What do you mean by "packages issues"? > Meaning: if you have problems with let's say Eterm on Debian. Then Michael Jennings (Author of Eterm) will not be the one that you bug for your Debian problems but you will rather bug the maintainer of Eterm on Debian (Currently: Laurence J. Lane --- Well i think so!) to solve your package issues! With kind regards, Didier --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg From windi at myrealbox.com Sun Nov 2 10:33:07 2003 From: windi at myrealbox.com (Stephan Windischmann) Date: Sun, 02 Nov 2003 11:33:07 +0100 Subject: Questions about some default packages Fedora project In-Reply-To: References: Message-ID: <1067769187.1266.5.camel@homer.home> On Sun, 2003-11-02 at 10:30, Didier Casse wrote: > But you still can get support from the Enlightenment team! I currently use > Enlightenment and I'm often on their mailing list. I can tell you that > they (and including me!) can provide full support for anybody who use > E desktop on any distro. I currently use RH9 and willing to help anybody > who has problems with E on RH9. Then the Enlightenment team (or any other projects team) should set up their own apt/yum repository for RH/Fedora. Due to different philosophies, I doubt that Fedora iseer going to have repositories as big as Debian, so for a number of projects, we will have to rely on 3d party repositories. -windi From warren at togami.com Sun Nov 2 10:54:16 2003 From: warren at togami.com (Warren Togami) Date: Sun, 02 Nov 2003 00:54:16 -1000 Subject: Questions about some default packages Fedora project In-Reply-To: <1067769187.1266.5.camel@homer.home> References: <1067769187.1266.5.camel@homer.home> Message-ID: <1067770456.14617.49.camel@laptop> On Sun, 2003-11-02 at 00:33, Stephan Windischmann wrote: > On Sun, 2003-11-02 at 10:30, Didier Casse wrote: > > But you still can get support from the Enlightenment team! I currently use > > Enlightenment and I'm often on their mailing list. I can tell you that > > they (and including me!) can provide full support for anybody who use > > E desktop on any distro. I currently use RH9 and willing to help anybody > > who has problems with E on RH9. > Then the Enlightenment team (or any other projects team) should set up > their own apt/yum repository for RH/Fedora. > Wrong. The enlightenment team should submit their official package to fedora QA for inclusion in the community's repository. > Due to different philosophies, I doubt that Fedora iseer going to have > repositories as big as Debian, so for a number of projects, we will have > to rely on 3d party repositories. Wrong again. 3rd party repositories will only be necessary mainly for packages that cannot exist in Fedora due to license or legal reasons. This is very similar to Debian's situation. Warren From buildsys at porkchop.devel.redhat.com Sun Nov 2 11:21:18 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sun, 2 Nov 2003 06:21:18 -0500 Subject: rawhide report: 20031102 changes Message-ID: <200311021121.hA2BLIb29879@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1-0.20031102 ------------------------- From Nicolas.Mailhot at laPoste.net Sun Nov 2 12:20:25 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 02 Nov 2003 13:20:25 +0100 Subject: Questions about some default packages Fedora project In-Reply-To: <1067770456.14617.49.camel@laptop> References: <1067769187.1266.5.camel@homer.home> <1067770456.14617.49.camel@laptop> Message-ID: <1067775625.3548.62.camel@m70.net81-64-235.noos.fr> Le dim 02/11/2003 ? 11:54, Warren Togami a ?crit : > On Sun, 2003-11-02 at 00:33, Stephan Windischmann wrote: > > On Sun, 2003-11-02 at 10:30, Didier Casse wrote: > > > But you still can get support from the Enlightenment team! I currently use > > > Enlightenment and I'm often on their mailing list. I can tell you that > > > they (and including me!) can provide full support for anybody who use > > > E desktop on any distro. I currently use RH9 and willing to help anybody > > > who has problems with E on RH9. > > Then the Enlightenment team (or any other projects team) should set up > > their own apt/yum repository for RH/Fedora. > > > > Wrong. The enlightenment team should submit their official package to > fedora QA for inclusion in the community's repository. And the QA/packaging rules part is very important. When you package in isolation your own stuff in your own repository it's altogether too easy to miss problems a larger community will have identified. > > Due to different philosophies, I doubt that Fedora iseer going to have > > repositories as big as Debian, so for a number of projects, we will have > > to rely on 3d party repositories. > > Wrong again. 3rd party repositories will only be necessary mainly for > packages that cannot exist in Fedora due to license or legal reasons. > This is very similar to Debian's situation. See jpackage for java as an example of 3rd party repository that is separate for licensing/legal reasons. (Well even if there was no licensing issues I don't think we'd merge with Fedora since it would leave our mdk members in the dust. Some form of close association/affiliation would be possible however) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From Axel.Thimm at physik.fu-berlin.de Sun Nov 2 19:20:58 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sun, 2 Nov 2003 20:20:58 +0100 Subject: "The Cathedral and the Bazaar" from a repository's POV (was: Questions ...) In-Reply-To: <1067770456.14617.49.camel@laptop> References: <1067769187.1266.5.camel@homer.home> <1067770456.14617.49.camel@laptop> Message-ID: <20031102192058.GD8274@puariko.nirvana> On Sun, Nov 02, 2003 at 12:54:16AM -1000, Warren Togami wrote: > On Sun, 2003-11-02 at 00:33, Stephan Windischmann wrote: > > On Sun, 2003-11-02 at 10:30, Didier Casse wrote: > > > But you still can get support from the Enlightenment team! I currently use > > > Enlightenment and I'm often on their mailing list. I can tell you that > > > they (and including me!) can provide full support for anybody who use > > > E desktop on any distro. I currently use RH9 and willing to help anybody > > > who has problems with E on RH9. > > Then the Enlightenment team (or any other projects team) should set up > > their own apt/yum repository for RH/Fedora. > > > > Wrong. The enlightenment team should submit their official package to > fedora QA for inclusion in the community's repository. > > > Due to different philosophies, I doubt that Fedora iseer going to have > > repositories as big as Debian, so for a number of projects, we will have > > to rely on 3d party repositories. > > Wrong again. 3rd party repositories will only be necessary mainly for > packages that cannot exist in Fedora due to license or legal reasons. > This is very similar to Debian's situation. There are more reasons for the existance of independent repositories than being illegal. > Warren -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From windi at myrealbox.com Sun Nov 2 21:41:16 2003 From: windi at myrealbox.com (Stephan Windischmann) Date: Sun, 02 Nov 2003 22:41:16 +0100 Subject: Questions about some default packages Fedora project In-Reply-To: <1067770456.14617.49.camel@laptop> References: <1067769187.1266.5.camel@homer.home> <1067770456.14617.49.camel@laptop> Message-ID: <1067809275.1595.2.camel@homer.home> On Sun, 2003-11-02 at 11:54, Warren Togami wrote: > Wrong again. 3rd party repositories will only be necessary mainly for > packages that cannot exist in Fedora due to license or legal reasons. > This is very similar to Debian's situation. Good to see that I'm wrong :) Having a fairly large repository is going to be a pretty big (IMO) plus point for the Fedora distro. -windi From windi at myrealbox.com Sun Nov 2 21:41:16 2003 From: windi at myrealbox.com (Stephan Windischmann) Date: Sun, 02 Nov 2003 22:41:16 +0100 Subject: Questions about some default packages Fedora project In-Reply-To: <1067770456.14617.49.camel@laptop> References: <1067769187.1266.5.camel@homer.home> <1067770456.14617.49.camel@laptop> Message-ID: <1067809275.1595.2.camel@homer.home> On Sun, 2003-11-02 at 11:54, Warren Togami wrote: > Wrong again. 3rd party repositories will only be necessary mainly for > packages that cannot exist in Fedora due to license or legal reasons. > This is very similar to Debian's situation. Good to see that I'm wrong :) Having a fairly large repository is going to be a pretty big (IMO) plus point for the Fedora distro. -windi From windi at myrealbox.com Sun Nov 2 19:08:15 2003 From: windi at myrealbox.com (Stephan Windischmann) Date: Sun, 02 Nov 2003 20:08:15 +0100 Subject: Questions about some default packages Fedora project In-Reply-To: <1067770456.14617.49.camel@laptop> References: <1067769187.1266.5.camel@homer.home> <1067770456.14617.49.camel@laptop> Message-ID: <1067800094.2527.3.camel@homer.home> On Sun, 2003-11-02 at 11:54, Warren Togami wrote: > Wrong again. 3rd party repositories will only be necessary mainly for > packages that cannot exist in Fedora due to license or legal reasons. > This is very similar to Debian's situation. Good to see that I was wrong. :) A large repository of software packages is a big plus point for any distro. -windi From mike at flyn.org Sun Nov 2 22:47:48 2003 From: mike at flyn.org (W. Michael Petullo) Date: Sun, 2 Nov 2003 16:47:48 -0600 Subject: More loitering process curiosities In-Reply-To: <20031101233749.8FFC616F0E@jmason.org> References: <20031101231737.GA14764@imp.flyn.org> <20031101233749.8FFC616F0E@jmason.org> Message-ID: <20031102224747.GA1237@imp.flyn.org> >> I'm not sure about the mapping-daemon process. Apparently it is a >> component of the nautilus-cd-burner package. There does not seem to >> be a nice facility for causing the process to quit. From looking at >> mapping-daemon.c, it appears that the daemon wakes up every 5000us, >> checks to see if it has any client nautilus processes and exits if it >> does not. > > Are you certain that's every 5000us, as in microseconds? > > So this process wakes up, and runs a code loop *every 5 milliseconds*?! > That'd be horrific for load, if so. Yes, I was three orders of magnitude off. Mapping-daemon uses g_timeout_add to check for remaining clients every 5000 /milliseconds/ (or less often if higher priority stuff is processing). The result still seems to be that mapping-daemon contines to execute when gdm calls pam_close_session. -- Mike :wq From P at draigBrady.com Mon Nov 3 09:41:53 2003 From: P at draigBrady.com (P at draigBrady.com) Date: Mon, 03 Nov 2003 09:41:53 +0000 Subject: Run prelink and other stuff not in cron but when screensaver is active. In-Reply-To: <200310312032.h9VKWP605083@devserv.devel.redhat.com> References: <200310312032.h9VKWP605083@devserv.devel.redhat.com> Message-ID: <3FA622E1.7010907@draigBrady.com> Alan Cox wrote: >>>This reminds me, that it's seriously annoying >>>that xscreensaver runs for vnc sessions. Seems >>>like an easy fix. >> >>How do you suggest? There are several possible approaches. > > Its actually useful in a thin client environment that it does. And the > user can configure blanking easily enough True, though I think xcreensaver should be off by default under vnc. P?draig. From shekhar.tiwatne at ensim.com Mon Nov 3 17:00:56 2003 From: shekhar.tiwatne at ensim.com (Shekhar) Date: 03 Nov 2003 22:30:56 +0530 Subject: mod_frontpage packaging In-Reply-To: <20031101170009.7554.92510.Mailman@listman.back-rdu.redhat.com> References: <20031101170009.7554.92510.Mailman@listman.back-rdu.redhat.com> Message-ID: <1067878855.27000.89.camel@stiwatne.india.ensim.com> We use mod_frontpage for package apache for our RH servers. It is already been included in Mandrake. I wonder can we [fedora] include this as part for distro. If it can be included I would put this request alongwith the package download URLs on fedora [.us?] site. New version of this module can be used as a DSO. TIA, -- shekhar From hp at redhat.com Mon Nov 3 17:08:04 2003 From: hp at redhat.com (Havoc Pennington) Date: Mon, 03 Nov 2003 12:08:04 -0500 Subject: More loitering process curiosities In-Reply-To: <20031101003341.GA2681@imp.flyn.org> References: <20031030193231.E28D73156D@neuromancer.voxel.net> <1067547478.5823.25.camel@localhost.localdomain> <20031031005627.GA1536@imp.flyn.org> <1067577613.15833.61.camel@localhost.localdomain> <20031031175656.GA1020@imp.flyn.org> <20031031214256.GA7403@imp.flyn.org> <20031101003341.GA2681@imp.flyn.org> Message-ID: <1067879284.6904.2.camel@localhost.localdomain> On Fri, 2003-10-31 at 19:33, W. Michael Petullo wrote: > But I'm still curious about this process hierarchy. Why do processes > like bonobo-activation-server and gnome-panel seem to execute with init > as their parent? When doing a fork/exec, GLib programs usually use the g_spawn_ family of functions; these fork twice, creating an intermediate child process that immediately exits and is reaped by the parent. The purpose is to avoid zombies, as usually in a GUI context parent/child doesn't mean much. (e.g. say Evolution launches your web browser there's no point really having the browser be a child of evolution) Havoc From pete.s.bradbury at btinternet.com Mon Nov 3 17:41:14 2003 From: pete.s.bradbury at btinternet.com (Pete Bradbury) Date: Mon, 3 Nov 2003 17:41:14 -0000 Subject: AMD 64 support Message-ID: <000901c3a231$ae12a2e0$0100a8c0@shubunkin> Will the fedora project support the AMD 64 processor? From skvidal at phy.duke.edu Mon Nov 3 17:42:48 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 03 Nov 2003 12:42:48 -0500 Subject: AMD 64 support In-Reply-To: <000901c3a231$ae12a2e0$0100a8c0@shubunkin> References: <000901c3a231$ae12a2e0$0100a8c0@shubunkin> Message-ID: <1067881368.29988.117.camel@opus> On Mon, 2003-11-03 at 12:41, Pete Bradbury wrote: > Will the fedora project support the AMD 64 processor? > please read through the mailing list archives. Thanks -sv From pete.s.bradbury at btinternet.com Mon Nov 3 17:57:40 2003 From: pete.s.bradbury at btinternet.com (Pete Bradbury) Date: Mon, 3 Nov 2003 17:57:40 -0000 Subject: AMD 64 - What can I do to help? Message-ID: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> Subject says it all. Like to help as I've just got an AMD 64 FX gizzmo. Just someone explain what I could do and I'll try to do some of the simpler tasks... From alan at redhat.com Mon Nov 3 18:38:40 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 3 Nov 2003 13:38:40 -0500 (EST) Subject: Questions about some default packages Fedora project In-Reply-To: from "Didier Casse" at Tach 02, 2003 02:56:03 Message-ID: <200311031838.hA3Ice200649@devserv.devel.redhat.com> > 1. How come we only have a limited number of Window Managers in Fedora? > i.e only (GNOME, KDE and twm) Because Fedora at the moment is turning from "Red Hat" to community. Within Red Hat the business needs didn't favour it. Duplication costs engineering time. It also annoys business customers who want what they perceive as consistency. With Fedora now of course the rules are different since anyone can begin adding packages (and indeed www.fedora.us has a collection so far, plus a need for more QA folks, so if your favourite toy is there help QA it) > Is it possible to make it available to apt-repositories of Fedora? Should be. The general favourite seems to be yum but apt works too. I'm not sure if yum direct off sf.net works with all their weird redirect stuff > Debian also have several maintainers which takes care of all their > packages issues. Why don't we have the same concept in Fedora? That is where a lot of the add on package stuff is heading, and over time maybe even core stuff. From skvidal at phy.duke.edu Mon Nov 3 18:45:31 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 03 Nov 2003 13:45:31 -0500 Subject: Questions about some default packages Fedora project In-Reply-To: <200311031838.hA3Ice200649@devserv.devel.redhat.com> References: <200311031838.hA3Ice200649@devserv.devel.redhat.com> Message-ID: <1067885131.29992.177.camel@opus> > Should be. The general favourite seems to be yum but apt works too. I'm > not sure if yum direct off sf.net works with all their weird redirect > stuff no, the crazy redirects from sf don't work for any of the downloaders I've seen, so far. Also work is continuing on providing a common metadata format for apt/yum/redcarpet/up2date and others. If we succeed in a new format then there will be no real difference b/t an apt repository and a yum repository. it will simply be a package repository. (and much rejoicing will be heard, hopefully ;) -sv From Nicolas.Mailhot at laPoste.net Mon Nov 3 18:46:01 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 03 Nov 2003 19:46:01 +0100 Subject: Questions about some default packages Fedora project In-Reply-To: <200311031838.hA3Ice200649@devserv.devel.redhat.com> References: <200311031838.hA3Ice200649@devserv.devel.redhat.com> Message-ID: <1067885161.8849.18.camel@m70.net81-64-235.noos.fr> Le lun 03/11/2003 ? 19:38, Alan Cox a ?crit : > > 1. How come we only have a limited number of Window Managers in Fedora? > > i.e only (GNOME, KDE and twm) > > Because Fedora at the moment is turning from "Red Hat" to community. > Within Red Hat the business needs didn't favour it. Duplication costs > engineering time. It also annoys business customers who want what they > perceive as consistency. > > With Fedora now of course the rules are different since anyone can begin > adding packages (and indeed www.fedora.us has a collection so far, plus > a need for more QA folks, so if your favourite toy is there help QA it) > > > Is it possible to make it available to apt-repositories of Fedora? > > Should be. The general favourite seems to be yum but apt works too. I'm > not sure if yum direct off sf.net works with all their weird redirect > stuff Sf has an "ftp-only" kind of service. We use it for JPackage apt/yum/urpmi repositories (many thanks to the sf team btw - the eu mirror sucks but the us one is great) 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 alan at redhat.com Mon Nov 3 18:55:41 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 3 Nov 2003 13:55:41 -0500 (EST) Subject: Run prelink and other stuff not in cron but when screensaver In-Reply-To: <3FA622E1.7010907@draigBrady.com> from "P@draigBrady.com" at Tach 03, 2003 09:41:53 Message-ID: <200311031855.hA3Itfp11525@devserv.devel.redhat.com> > > Its actually useful in a thin client environment that it does. And the > > user can configure blanking easily enough > > True, though I think xcreensaver should be off by default under vnc. Why ? From chuckw at quantumlinux.com Mon Nov 3 19:06:20 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 3 Nov 2003 11:06:20 -0800 (PST) Subject: Run prelink and other stuff not in cron but when screensaver In-Reply-To: <200311031855.hA3Itfp11525@devserv.devel.redhat.com> Message-ID: > > True, though I think xcreensaver should be off by default under vnc. > > Why ? Why send all of that traffic over a network? Even if it is local, it just seems like a waste to me... -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com A: Because we read from top to bottom, left to right. Q: Why should i start my reply below the quoted text? From P at draigBrady.com Mon Nov 3 19:14:12 2003 From: P at draigBrady.com (P at draigBrady.com) Date: Mon, 03 Nov 2003 19:14:12 +0000 Subject: Run prelink and other stuff not in cron but when screensaver In-Reply-To: <200311031855.hA3Itfp11525@devserv.devel.redhat.com> References: <200311031855.hA3Itfp11525@devserv.devel.redhat.com> Message-ID: <3FA6A904.8080201@draigBrady.com> Alan Cox wrote: >>>Its actually useful in a thin client environment that it does. And the >>>user can configure blanking easily enough >> >>True, though I think xcreensaver should be off by default under vnc. Because to ship screensaver output over vnc takes a lot of CPU and network resources. IMHO this should not happen by default, because newly setup machine with a few users running vncserver hammers the machine. If they want to setup screensavers explicitly, fine, but at least you can lart them for that :-) P?draig. From msnitzer at lnxi.com Mon Nov 3 19:34:01 2003 From: msnitzer at lnxi.com (Mike Snitzer) Date: Mon, 3 Nov 2003 12:34:01 -0700 Subject: AMD 64 support In-Reply-To: <1067881368.29988.117.camel@opus>; from skvidal@phy.duke.edu on Mon, Nov 03, 2003 at 12:42:48PM -0500 References: <000901c3a231$ae12a2e0$0100a8c0@shubunkin> <1067881368.29988.117.camel@opus> Message-ID: <20031103123401.A1468@lnxi.com> On Mon, Nov 03 2003 at 10:42, seth vidal wrote: > On Mon, 2003-11-03 at 12:41, Pete Bradbury wrote: > > Will the fedora project support the AMD 64 processor? > > > > please read through the mailing list archives. Given that there has only been a handfull of references to the future of fedora with regard to amd64... that's a bit cold no? Unless I missed a really inciteful amd64 thread: Yum has support for x86_64 (as of v2.0.4?). It would appear there are a few people interested in a Fedora Core port to x86_64 but there has been little formal discussion on getting that ball rolling. Mike From mike at flyn.org Mon Nov 3 20:12:33 2003 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 3 Nov 2003 14:12:33 -0600 Subject: More loitering process curiosities In-Reply-To: <1067879284.6904.2.camel@localhost.localdomain> References: <20031030193231.E28D73156D@neuromancer.voxel.net> <1067547478.5823.25.camel@localhost.localdomain> <20031031005627.GA1536@imp.flyn.org> <1067577613.15833.61.camel@localhost.localdomain> <20031031175656.GA1020@imp.flyn.org> <20031031214256.GA7403@imp.flyn.org> <20031101003341.GA2681@imp.flyn.org> <1067879284.6904.2.camel@localhost.localdomain> Message-ID: <20031103201233.GA11890@imp.flyn.org> >>> We've made some progress getting gconfd-2 to exit when a user logs out >>> (see "gconfd-2 does not exit when a user log out, breaks unmounting >>> home" thread). Now I am interested in turning my attention to some >>> other processes that seem to loiter around after one logs out of a GNOME >>> 2.4.0 session. >>> >>> Pam_mount performs an lsof that claims the processes are still running >>> when pam_close_session is called, but the processes are gone after the >>> user is completely logged out (Unlike gconfd-2, which stayed running >>> for two minutes). >>> >>> The following processes hang around (with $HOME as their CWD): >>> >>> bonobo-activation-server >>> gnome-settings-daemon >>> xscreensaver >>> mapping-daemon >> But I'm still curious about this process hierarchy. Why do processes >> like bonobo-activation-server and gnome-panel seem to execute with init >> as their parent? > > When doing a fork/exec, GLib programs usually use the g_spawn_ family of > functions; these fork twice, creating an intermediate child process that > immediately exits and is reaped by the parent. The purpose is to avoid > zombies, as usually in a GUI context parent/child doesn't mean much. > (e.g. say Evolution launches your web browser there's no point really > having the browser be a child of evolution) Thanks to all who explained. There is also a mail thread from 2000 on gnome-devel-list titled "Process Tree." I updated the gconfd-2-killing gnome-session patch I have submitted to GNOME's bugzilla to use execvp/waitpid instead of gnome_execute_async. Is there a more GNOME/glib-happy way to wait for a forked process? I also send the following very simple patch to the gdm folks. It fixes my problem with X programs hanging around when pam_close_session is called, but I'm not sure if it would break anything else. Here it is: diff -u --recursive gdm-2.4.4.5-vanilla/daemon/slave.c gdm-2.4.4.5/daemon/slave.c --- gdm-2.4.4.5-vanilla/daemon/slave.c 2003-10-16 11:38:45.000000000 -0500 +++ gdm-2.4.4.5/daemon/slave.c 2003-11-03 11:19:31.000000000 -0600 @@ -864,6 +864,8 @@ gdm_slave_quick_exit (DISPLAY_REMANAGE); } } + + gdm_verify_cleanup (d); } /* very very very evil, should never break, we can't return from here sanely */ @@ -4132,8 +4134,6 @@ /* things are going to be killed, so ignore errors */ XSetErrorHandler (ignore_xerror_handler); - gdm_verify_cleanup (d); - in_session_stop --; if (need_to_quit_after_session_stop) { -- Mike :wq From pete.s.bradbury at btinternet.com Mon Nov 3 20:16:18 2003 From: pete.s.bradbury at btinternet.com (Pete Bradbury) Date: Mon, 3 Nov 2003 20:16:18 -0000 Subject: AMD 64 support References: <000901c3a231$ae12a2e0$0100a8c0@shubunkin> <1067881368.29988.117.camel@opus> <20031103123401.A1468@lnxi.com> Message-ID: <000c01c3a247$677e3d10$0100a8c0@shubunkin> So should I infer from what you are saying that the AMD 64 port is some way off in the distant future and that until Fedora on the '86 platform is stabilised work is unlikely to proceed for this new processor? ----- Original Message ----- From: "Mike Snitzer" To: Sent: Monday, November 03, 2003 7:34 PM Subject: Re: AMD 64 support > On Mon, Nov 03 2003 at 10:42, > seth vidal wrote: > > > On Mon, 2003-11-03 at 12:41, Pete Bradbury wrote: > > > Will the fedora project support the AMD 64 processor? > > > > > > > please read through the mailing list archives. > > Given that there has only been a handfull of references to the future of > fedora with regard to amd64... that's a bit cold no? > > Unless I missed a really inciteful amd64 thread: Yum has support for > x86_64 (as of v2.0.4?). It would appear there are a few people interested > in a Fedora Core port to x86_64 but there has been little formal > discussion on getting that ball rolling. > > Mike > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From bos at serpentine.com Mon Nov 3 20:27:38 2003 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon, 03 Nov 2003 12:27:38 -0800 Subject: AMD 64 support In-Reply-To: <000c01c3a247$677e3d10$0100a8c0@shubunkin> References: <000901c3a231$ae12a2e0$0100a8c0@shubunkin> <1067881368.29988.117.camel@opus> <20031103123401.A1468@lnxi.com> <000c01c3a247$677e3d10$0100a8c0@shubunkin> Message-ID: <1067891258.17174.20.camel@serpentine.internal.keyresearch.com> On Mon, 2003-11-03 at 12:16, Pete Bradbury wrote: > So should I infer from what you are saying that the AMD 64 port is some way > off in the distant future and that until Fedora on the '86 platform is > stabilised work is unlikely to proceed for this new processor? At least one person is working on an AMD64 build in his spare time. Red Hat has made no official statements on native x86_64 support one way or the other, but it's probably safe to assume that it's not a high priority for now. You should expect 32-bit Fedora to just run out of the box on AMD64 systems. Message-ID: I wouldnt say that... people are working on an AMD64 fedora currently. Justin M. Forbes On Mon, 3 Nov 2003, Pete Bradbury wrote: > So should I infer from what you are saying that the AMD 64 port is some way > off in the distant future and that until Fedora on the '86 platform is > stabilised work is unlikely to proceed for this new processor? > > ----- Original Message ----- > From: "Mike Snitzer" > To: > Sent: Monday, November 03, 2003 7:34 PM > Subject: Re: AMD 64 support > > > > On Mon, Nov 03 2003 at 10:42, > > seth vidal wrote: > > > > > On Mon, 2003-11-03 at 12:41, Pete Bradbury wrote: > > > > Will the fedora project support the AMD 64 processor? > > > > > > > > > > please read through the mailing list archives. > > > > Given that there has only been a handfull of references to the future of > > fedora with regard to amd64... that's a bit cold no? > > > > Unless I missed a really inciteful amd64 thread: Yum has support for > > x86_64 (as of v2.0.4?). It would appear there are a few people interested > > in a Fedora Core port to x86_64 but there has been little formal > > discussion on getting that ball rolling. > > > > Mike > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From pete.s.bradbury at btinternet.com Mon Nov 3 20:33:07 2003 From: pete.s.bradbury at btinternet.com (Pete Bradbury) Date: Mon, 3 Nov 2003 20:33:07 -0000 Subject: AMD 64 support References: <000901c3a231$ae12a2e0$0100a8c0@shubunkin> <1067881368.29988.117.camel@opus> <20031103123401.A1468@lnxi.com> <000c01c3a247$677e3d10$0100a8c0@shubunkin> <1067891258.17174.20.camel@serpentine.internal.keyresearch.com> Message-ID: <002d01c3a249$b10b3580$0100a8c0@shubunkin> Thanks that last part - was what I was hoping :-) ----- Original Message ----- From: "Bryan O'Sullivan" To: Sent: Monday, November 03, 2003 8:27 PM Subject: Re: AMD 64 support > On Mon, 2003-11-03 at 12:16, Pete Bradbury wrote: > > So should I infer from what you are saying that the AMD 64 port is some way > > off in the distant future and that until Fedora on the '86 platform is > > stabilised work is unlikely to proceed for this new processor? > > At least one person is working on an AMD64 build in his spare time. Red > Hat has made no official statements on native x86_64 support one way or > the other, but it's probably safe to assume that it's not a high > priority for now. > > You should expect 32-bit Fedora to just run out of the box on AMD64 > systems. > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From stan at ccs.neu.edu Mon Nov 3 20:35:18 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Mon, 03 Nov 2003 15:35:18 -0500 Subject: Disabling /tmp watch in RawHide Message-ID: <1067890175.2582.33.camel@wvanl14.resnet.neu.edu> Hey, Over the last four years I have found and reported several vulnerabilities in various apps that have use /tmp insecurely. A great many of them were discovered by merely looking in /tmp once a week or so at some of the files left behind. By default you guys have tmpwatch turned on, and I think that in RawHide and test builds this should be disabled so these kinds of security bugs can be found easier before releases. Yes I know /tmp can get messy with legitimate files (though most of the files left in /tmp SHOULD NOT be there), however I think the benefits of disabling by default on testing environments will get a great many more eyes spotting general bugs with some program /tmp usage. For instance I installed Fedora Core Test 3 release last weekend. I turned off tmpwatch, and voila, without even trying I found 4 insecure file uses between 3 packages. I did nothing to find these except ls through my /tmp and then track down the offenders. I guess this is probably something that will be debated, or shot down immediately, but still I'm throwing it out there. Without tmpwatch people WILL notice more insecure /tmp usage, even if by only the broken usages (i.e. leaving the files behind). Any thoughts? -sb -------------- next part -------------- An embedded message was scrubbed... From: Stan Bubrouski Subject: Disabling /tmp watch in RawHide Date: Mon, 03 Nov 2003 13:59:16 -0500 Size: 1618 URL: -------------- 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 alan at redhat.com Mon Nov 3 20:39:36 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 3 Nov 2003 15:39:36 -0500 (EST) Subject: Run prelink and other stuff not in cron but when screensaver In-Reply-To: <3FA6A904.8080201@draigBrady.com> from "P@draigBrady.com" at Tach 03, 2003 07:14:12 Message-ID: <200311032039.hA3KdaF08650@devserv.devel.redhat.com> > Because to ship screensaver output over vnc takes a lot of CPU > and network resources. IMHO this should not happen by default, > because newly setup machine with a few users running vncserver > hammers the machine. Just as true for non Vnc screensavers > If they want to setup screensavers explicitly, fine, but > at least you can lart them for that :-) It sounds to me more of an argument for using 'blank' as the default screensaver except on localhost ? From johnsonm at redhat.com Mon Nov 3 20:40:55 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 3 Nov 2003 15:40:55 -0500 Subject: AMD 64 - What can I do to help? In-Reply-To: <001d01c3a233$f93c0d40$0100a8c0@shubunkin>; from pete.s.bradbury@btinternet.com on Mon, Nov 03, 2003 at 05:57:40PM -0000 References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> Message-ID: <20031103154055.A25665@devserv.devel.redhat.com> On Mon, Nov 03, 2003 at 05:57:40PM -0000, Pete Bradbury wrote: > Subject says it all. > > Like to help as I've just got an AMD 64 FX gizzmo. > > Just someone explain what I could do and I'll try to do some of the simpler > tasks... Well, most of the simple development tasks just get done as part of building the packages, at least right now. There's a community effort to put together Fedora Core 1 for AMD64 and Red Hat is participating. I'd say that since images should be available for testing soon, testing them on your hardware and reporting bugs, especially bugs that don't show up on x86, would be something very important. Also, once it is available, helping QA packages for AMD64 in the fedora.su QA queue would be useful. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From pete.s.bradbury at btinternet.com Mon Nov 3 20:46:06 2003 From: pete.s.bradbury at btinternet.com (Pete Bradbury) Date: Mon, 3 Nov 2003 20:46:06 -0000 Subject: AMD 64 - What can I do to help? References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> <20031103154055.A25665@devserv.devel.redhat.com> Message-ID: <004701c3a24b$8172b0d0$0100a8c0@shubunkin> Are these shown as distinct AMD64 packs or are they mixed in with the ISO's I've seen? ----- Original Message ----- From: "Michael K. Johnson" To: Sent: Monday, November 03, 2003 8:40 PM Subject: Re: AMD 64 - What can I do to help? > On Mon, Nov 03, 2003 at 05:57:40PM -0000, Pete Bradbury wrote: > > Subject says it all. > > > > Like to help as I've just got an AMD 64 FX gizzmo. > > > > Just someone explain what I could do and I'll try to do some of the simpler > > tasks... > > Well, most of the simple development tasks just get done as part of > building the packages, at least right now. > > There's a community effort to put together Fedora Core 1 for AMD64 > and Red Hat is participating. I'd say that since images should be > available for testing soon, testing them on your hardware and reporting > bugs, especially bugs that don't show up on x86, would be something > very important. > > Also, once it is available, helping QA packages for AMD64 in the > fedora.su QA queue would be useful. > > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From jkeating at j2solutions.net Mon Nov 3 20:50:25 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 3 Nov 2003 12:50:25 -0800 Subject: AMD 64 - What can I do to help? In-Reply-To: <004701c3a24b$8172b0d0$0100a8c0@shubunkin> References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> <20031103154055.A25665@devserv.devel.redhat.com> <004701c3a24b$8172b0d0$0100a8c0@shubunkin> Message-ID: <200311031250.25707.jkeating@j2solutions.net> On Monday 03 November 2003 12:46, Pete Bradbury wrote: > Are these shown as distinct AMD64 packs or are they mixed in with the > ISO's I've seen? There is an x86_64 directory in the rawhide directory. This dir holds all x86_64 built packages. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 oden.eriksson at kvikkjokk.net Mon Nov 3 20:55:51 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Mon, 3 Nov 2003 21:55:51 +0100 Subject: apache2 Message-ID: <200311032155.52099.oden.eriksson@kvikkjokk.net> Howdy folks. A lot of people is sending their resume this way. But I don't have a fancy CV or resume to pass. I just have to pass the work I have been doing for the past 2-3 years for Mandrake Linux and the apache2 suite I've been working with. Here's a resume of that: (the packages lives in the mandrake linux cooker contribs repository) http://www.deserve-it.com/modules_for_apache2.html I just wonder if the Redhat community would be interested in a similar approach. Or maybe you guys's just to strict? From pete.s.bradbury at btinternet.com Mon Nov 3 20:55:48 2003 From: pete.s.bradbury at btinternet.com (Pete Bradbury) Date: Mon, 3 Nov 2003 20:55:48 -0000 Subject: AMD 64 - What can I do to help? References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> <20031103154055.A25665@devserv.devel.redhat.com> <004701c3a24b$8172b0d0$0100a8c0@shubunkin> <200311031250.25707.jkeating@j2solutions.net> Message-ID: <005e01c3a24c$e1f1a4b0$0100a8c0@shubunkin> Thanks I'll take a look :-) ----- Original Message ----- From: "Jesse Keating" To: Sent: Monday, November 03, 2003 8:50 PM Subject: Re: AMD 64 - What can I do to help? On Monday 03 November 2003 12:46, Pete Bradbury wrote: > Are these shown as distinct AMD64 packs or are they mixed in with the > ISO's I've seen? There is an x86_64 directory in the rawhide directory. This dir holds all x86_64 built packages. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 johnsonm at redhat.com Mon Nov 3 21:01:11 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 3 Nov 2003 16:01:11 -0500 Subject: mod_frontpage packaging In-Reply-To: <1067878855.27000.89.camel@stiwatne.india.ensim.com>; from shekhar.tiwatne@ensim.com on Mon, Nov 03, 2003 at 10:30:56PM +0530 References: <20031101170009.7554.92510.Mailman@listman.back-rdu.redhat.com> <1067878855.27000.89.camel@stiwatne.india.ensim.com> Message-ID: <20031103160111.B25665@devserv.devel.redhat.com> On Mon, Nov 03, 2003 at 10:30:56PM +0530, Shekhar wrote: > We use mod_frontpage for package apache for our RH servers. It is > already been included in Mandrake. I wonder can we [fedora] include this > as part for distro. If it can be included I would put this request > alongwith the package download URLs on fedora [.us?] site. > New version of this module can be used as a DSO. A couple of thoughts... o Is "Frontpage" a trademark? o A google search on mod_frontpage shows several reimplementations and lots of security issues as the main hits... The first might be an issue for fedora.us (we want to be careful about legality); the second is more an issue of taste and might keep it out of Fedora Core even if it went into extras, from a concern for security standpoint. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From msnitzer at lnxi.com Mon Nov 3 21:03:49 2003 From: msnitzer at lnxi.com (Mike Snitzer) Date: Mon, 3 Nov 2003 14:03:49 -0700 Subject: AMD 64 support In-Reply-To: ; from 64bit_fedora@comcast.net on Mon, Nov 03, 2003 at 02:29:58PM -0600 References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> Message-ID: <20031103140349.B1468@lnxi.com> On Mon, Nov 03 2003 at 13:29, Justin M. Forbes <64bit_fedora at comcast.net> wrote: > I wouldnt say that... people are working on an AMD64 fedora currently. Sure, I'd imagine (based on previous mails you've sent) you are one of those people. But the fact remains that RedHat Inc. has full-blown support for a native x86_64 install in RHELv3; yet they haven't said a word about offering that technology to Fedora. This is quite likely by design as they want to see the financial fruits of all their effort before giving it away to the community they are fostering. RedHat employees have said they openly encourage people to port Fedora to other architectures. So the fedora community can take Fedora where they want it to go; but RedHat likely won't act as the catalyst for things like an x86_64 port. All understandable, its just frustrating in that they've obviously done the required work; and they are perfectly content with having the Fedora community duplicate that effort of formalizing 64bit library and 32bit library coexistance and so on. For all I know RedHat will weigh in and advise on such decisions. So that said, has there been any big picture planning for how x86_64 support will be added to Fedora Core? A list of which tasks need to be accomplished, who the stakeholders that will be contributing are, etc. We may even want a new fedora-amd64-devel at fedora.redhat.com mailing list for the cause. Actually it might be nice if a fedora--devel mailing list were created for each architecture the Fedora community deems worthy. Mike From msnitzer at lnxi.com Mon Nov 3 21:07:07 2003 From: msnitzer at lnxi.com (Mike Snitzer) Date: Mon, 3 Nov 2003 14:07:07 -0700 Subject: AMD 64 - What can I do to help? In-Reply-To: <20031103154055.A25665@devserv.devel.redhat.com>; from johnsonm@redhat.com on Mon, Nov 03, 2003 at 03:40:55PM -0500 References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> <20031103154055.A25665@devserv.devel.redhat.com> Message-ID: <20031103140707.C1468@lnxi.com> On Mon, Nov 03 2003 at 13:40, Michael K. Johnson wrote: > On Mon, Nov 03, 2003 at 05:57:40PM -0000, Pete Bradbury wrote: > > Subject says it all. > > > > Like to help as I've just got an AMD 64 FX gizzmo. > > > > Just someone explain what I could do and I'll try to do some of the simpler > > tasks... > > Well, most of the simple development tasks just get done as part of > building the packages, at least right now. > > There's a community effort to put together Fedora Core 1 for AMD64 > and Red Hat is participating. I'd say that since images should be > available for testing soon, testing them on your hardware and reporting > bugs, especially bugs that don't show up on x86, would be something > very important. > > Also, once it is available, helping QA packages for AMD64 in the > fedora.su QA queue would be useful. Awesome, its great to see RedHat is doing so much with AMD64 for Fedora so close to the release of its enterprise AMD64 offering. Very unexpected and cool! Mike From riel at redhat.com Mon Nov 3 21:12:57 2003 From: riel at redhat.com (Rik van Riel) Date: Mon, 3 Nov 2003 16:12:57 -0500 (EST) Subject: AMD 64 support In-Reply-To: <20031103140349.B1468@lnxi.com> Message-ID: On Mon, 3 Nov 2003, Mike Snitzer wrote: > Sure, I'd imagine (based on previous mails you've sent) you are one of > those people. But the fact remains that RedHat Inc. has full-blown > support for a native x86_64 install in RHELv3; yet they haven't said a > word about offering that technology to Fedora. All the RHEL3 source rpms are available for download; the Fedora Core userspace RPMs are most likely already being compiled for AMD64. We just need some volunteers to pull things together and put the AMD64 patches from Taroon into Fedora Core (which is more work than it sounds, because the Taroon kernel is close to RHL9, while Fedora is closer to the upstream 2.4 kernel). -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From stan at ccs.neu.edu Mon Nov 3 21:15:31 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Mon, 03 Nov 2003 16:15:31 -0500 Subject: mod_frontpage packaging In-Reply-To: <20031103160111.B25665@devserv.devel.redhat.com> References: <20031101170009.7554.92510.Mailman@listman.back-rdu.redhat.com> <1067878855.27000.89.camel@stiwatne.india.ensim.com> <20031103160111.B25665@devserv.devel.redhat.com> Message-ID: <1067894131.2582.40.camel@wvanl14.resnet.neu.edu> On Mon, 2003-11-03 at 16:01, Michael K. Johnson wrote: > A couple of thoughts... > > o Is "Frontpage" a trademark? > > o A google search on mod_frontpage shows several reimplementations > and lots of security issues as the main hits... > > The first might be an issue for fedora.us (we want to be careful about > legality); the second is more an issue of taste and might keep it out > of Fedora Core even if it went into extras, from a concern for security > standpoint. > > michaelkjohnson > Beyond this, is there even a need for it? Link to Frontpage trademark: http://tess2.uspto.gov/bin/gate.exe?f=doc&state=p46ru3.3.3 -sb -------------- 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 xose at wanadoo.es Mon Nov 3 21:22:00 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Mon, 03 Nov 2003 22:22:00 +0100 Subject: AMD 64 support References: Message-ID: <3FA6C6F8.1040909@wanadoo.es> Rik van Riel wrote: > (which is more work than it sounds, because the Taroon > kernel is close to RHL9, while Fedora is closer to the Sorry, but RHL9 and Taroon kernel are *very far* cousins. 2.4.21-4.EL is wonderful, 2.4.20-20.9 is not too good. -- HTML mails are going to trash automagically From Axel.Thimm at physik.fu-berlin.de Mon Nov 3 10:35:48 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 3 Nov 2003 11:35:48 +0100 Subject: Distags in rpm sort order (yes, versioning again ;) In-Reply-To: <20031031065846.GC4184@puariko.nirvana> References: <20031031065846.GC4184@puariko.nirvana> Message-ID: <20031103103548.GC16946@puariko.nirvana> No comments from RH? Should every repository and its cat come up with its own scheme creating more compatibility problems in the future? On Fri, Oct 31, 2003 at 07:58:46AM +0100, Axel Thimm wrote: > Bringing up this topic again, since it was left unresolved. > > I won't go into details again, about *why* a disttag is needed and why > it has to adhear to rpm internal sort algorithms. Please check the > following threads in doubt (and discuss the reasons there please, help > keeping this thread constructive this time ;): > > http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00272.html > http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00551.html > http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00263.html > > The bottom line is that distags are needed if one wants to create > packages for the same upstream sources but built for different > distributions. Disttags can then be embedded in the release tag to > ensure proper upgradability. > > ==================== Disttag schemes: pick one! > > Here are the discussed schemes (some others exist with small > variations, e.g. fc instead of fdr, or no fdr tag at all, the > discussion is the same). Default versioning is (no cvs/beta, kernel > modules and special cases, leave that for another thread): > > -- > e.g. simply > foo-1.2.3-4..johnsmith > > disttag can be: > A B C > Red Hat Linux 7.3 fdr0.7.3 rh7.3 rh7.3 > Red Hat Linux 8.0 fdr0.8.0 rh8.0 rh8.0 > Red Hat Linux 9 fdr0.9 rh9 rh9 > Fedora Core 1 fdr1 rh9.1 1fdr > Fedora Core 2 test1 fdr1.95 rh9.1.95 1.95fdr > > A) + consistent distid > + future tagging will be self-explanatory > + fits nicer into a general nameing scheme (e.g. not only RHL and > FDR, but RHEL and non-RH could use, or allready do use the > := idiom) > - obfuscates RHL <= 9 rpm versioning > - requires rebuilding of existing 3rd party repos for the sake of > versioning. > o requires a statement from redhat to allow calling RH 7.3 as FDR > 0.7.3 for instance, e.g. the "old" RHL product is officially > conamed Fedora 0.something > > B) + current practice for many repos offering rpms build form the same > upstream sources for more than one distribution. > + keeps current 3rd party repos from rebuilding all the old rpms > just for reversioning (and users from redownloading the same rpms > with a new name) > - does not pertain the strict separation RHL <-> FDR, and may cause > confusion. > o A) is preferable, but B) may be a nice transition solution for > existing installations. > > C) + visually pertains separation of rh and fdr releases > - is a kludgy workaround using rpm semantics present only after > RHL9, thus breaking upgrading from RH8.0 and less (note that rpm > errata for fixing this rpm bug and others are still not > officially available) > - number prefixing breaks when the preceding expression is numeric > separated with dots or underscores, e.g. > > foo-1.2.3-1.1_rh9 > foo-1.2.3-1_1fdr > > (the stems here are "foo-1.2.3-1.1" < "foo-1.2.3-1") > Using decimal release tags needs to be separately considered, but > the fact is that they are being used often. > - reverses order of distid and distversion > - Variant "1fdr" keeps order of distid and distversion, > but breaks in all other ways above, as well as introducing an > obfuscating decimal in the release tag. > > I hope RH agrees to using A) or a variant thereof. In any case it > would be beneficial if an "official" solution could be blessed, so > that 3rd party repos don't have to reinvent their own > versioning. > > Certainly many repos will start offering their packages (officially) > after FC1 is (officially) released, so there are only a few days left > ... > > In order to not molest users with forced downloads for reversioning > rpms for older RHL releases, I would suggest to use B) in a transition > phase for large rpms that do not need updating other than the > reversioning. After some time B) will have been phased out. > > C) is not really an option. It will break more than it is intended to > salvage. > > Also it would be nice to have rawhide versioning, e.g. immediately > after a release update fedora-release to the next test release > version or something below to indicate rawhide builds. > > Thank you for your time. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From brugolsky at telemetry-investments.com Mon Nov 3 21:24:19 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Mon, 3 Nov 2003 16:24:19 -0500 Subject: AMD 64 support In-Reply-To: <20031103140349.B1468@lnxi.com> References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> <20031103140349.B1468@lnxi.com> Message-ID: <20031103212419.GA22201@ti19.telemetry-investments.com> On Mon, Nov 03, 2003 at 02:03:49PM -0700, Mike Snitzer wrote: > RedHat employees have said they openly encourage people to port Fedora to > other architectures. So the fedora community can take Fedora where they > want it to go; but RedHat likely won't act as the catalyst for things like > an x86_64 port. All understandable, its just frustrating in that they've > obviously done the required work; and they are perfectly content with > having the Fedora community duplicate that effort of formalizing 64bit > library and 32bit library coexistance and so on. For all I know RedHat > will weigh in and advise on such decisions. There is no great hidden magic here. There are x86_64 package builds in Rawhide, and the RHEL base is available as SRPMS. Sure, a lot of work went into getting multi-arch to function properly in RHEL, and the fruits of that are already available to you. To really contribute, one will have to read and understand first, and the code is there for you to peruse. Perhaps someone has thrown together a whitepaper on multi-arch support. Or you can start by looking at the changelogs, patches, and spec files for things like gcc, binutils, gdb, glibc, rpm, etc. Regards, Bill Rugolsky From buildsys at porkchop.devel.redhat.com Mon Nov 3 12:32:13 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Mon, 3 Nov 2003 07:32:13 -0500 Subject: rawhide report: 20031103 changes Message-ID: <200311031232.hA3CWCi16751@porkchop.devel.redhat.com> Updated Packages: kudzu-1.1.36-1 -------------- * Fri Oct 31 2003 Bill Nottingham 1.1.36-1 - only reset rhgb details screen if we turned it on (#108712) openoffice.org-1.1.0-5.1 ------------------------ * Sun Nov 02 2003 Jakub Jelinek 1.1.0-5.1 - Tweak default fonts some more * Fri Oct 31 2003 Dan Williams 1.1.0-5 - Update default fonts, change Central/Eastern Europe to Nimbus from Luxi - Whack trademarked fonts (Helvetica, Times, etc) from Font Menu rpmdb-fedora-1-0.20031103 ------------------------- From johnsonm at redhat.com Mon Nov 3 14:36:39 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 3 Nov 2003 09:36:39 -0500 Subject: Questions about some default packages Fedora project In-Reply-To: ; from didierbe@sps.nus.edu.sg on Sun, Nov 02, 2003 at 05:30:24PM +0800 References: <1067763937.14617.28.camel@laptop> Message-ID: <20031103093639.A12074@devserv.devel.redhat.com> On Sun, Nov 02, 2003 at 05:30:24PM +0800, Didier Casse wrote: > Thanks for the tip. But I wonder why they don't put it on > http://fedora.redhat.com Because when I asked, there was some concern that the workload spike from saying it too loudly would hurt fedora.us michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From elanthis at awesomeplay.com Mon Nov 3 15:21:44 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 03 Nov 2003 10:21:44 -0500 Subject: Questions about some default packages Fedora project In-Reply-To: References: Message-ID: <1067872904.1112.4.camel@support02.civic.twp.ypsilanti.mi.us> On Sun, 2003-11-02 at 01:56, Didier Casse wrote: > Hi, > I'm new at this Fedora concept and I would like to ask the following > questions: > > 1. How come we only have a limited number of Window Managers in Fedora? > i.e only (GNOME, KDE and twm) > > Why don't we include more robust or eye-candy desktops such as Fluxbox, > Enlightenment, XFCE, etc... ? How many do we need? A computer only ever needs one desktop. Do you really want Fedora to need 8 CDs to install just to have the option of installing a "desktop" like Fluxbox or whatnot? Those things belong in Fedora Extras, not Fedora Core. (to be honest, I don't even think we should have all the DEs we have now in Core, but then we hit religious ground...) > > 2. If we have created some of our own programs, for instance I created > pdfmerge/pdfmerge4unix (program which merges any number of pdf files), > [I know it's a small thing but it was just an example! ;-p] > which is on SF.net, and I wish to make it available to the Fedora > project/users since it's a useful program. Where do I submit my rpm > packages to? > > Is it possible to make it available to apt-repositories of Fedora? Just make a repository and publish it. Or, when the Fedora architecture is ready, perhaps it can be part of Core or Extras. > > 3. Why don't we have a lot of packagers available at hand compared to > Debian? I think all of you are aware that the apt of Debian covers a wider > range of packages than Fedora/RH. First, Fedora is brand new. Of course it doesn't have as many developers. Second, I'm not sure Debian's plethora of under-skilled developers is anywhere near a good thing. 10,000 packages, most of which are sub-standardly packaged, and the vast majority of which aren't needed by even 1% of the user base, is a very poor situation. If people want to make packages, nothing stops them - they can just make repositories on their own and publish those. People who need the software can use them, and those that don't have no need to worry about needing 8 CDs to install from and mirrors don't have to worry about being required to carry 100GB of packages. ;-) > > Debian also have several maintainers which takes care of all their > packages issues. Why don't we have the same concept in Fedora? > > > With kind regards, > > Didier. > > --- > PhD student > > Singapore Synchrotron Light Source (SSLS) > 5 Research Link, > Singapore 117603 > > Email: slsbdfc at nus dot edu dot sg \or\ > didierbe at sps dot nus dot edu dot sg > Website: http://ssls.nus.edu.sg > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From gauret at free.fr Mon Nov 3 23:00:04 2003 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 04 Nov 2003 00:00:04 +0100 Subject: Self Introduction : Aurelien Bompard Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Name : Aurelien Bompard Address : Paris, France Profession : Sysadmin (graduated from college in June 2003) Company : Asynux, french Free Software Service Company, Paris, France. My goals in the Fedora Project : I've been using Linux since 2000, and I've always believed in a future for Linux on the desktop. I've always tried to bring people to try linux, sometimes with success, sometimes not. Until recently, I've been using, testing and contributing to Mandrake Linux. They have always represented the desktop version of linux for me. But since the version 8, RedHat, and now Fedora, has completely catched up with Mandrake in terms of desktop-friendliness, and in my opinion RedHat and Fedora is miles ahead in terms of stability, consistancy and standards-compliance (eg : freedesktop.org standards). I now feel that the distribution I should advise to new linux users is Fedora, even more since Fedora is a community-driven project. As my ultimate goal is to help Linux be as successful as possible on the desktop, I do wish to help Fedora with packaging and testing. Historical Qualifications I have been a member of the Mandrake Linux testing community for about 2 years, following "Cooker" (the Mandrake version of Rawhide), trying to find bugs, and contributing packages. I have actually been able to contribute only 1 program, but there are so many already available there ;-) I have very few skills in programming, mainly shell scripting, Java, and Python. I've been concentrating on python lately and my skills are improving quickly :-) Why you should trust me ? Well, I don't really have any objective reason for that. I am truly convinced of the bright future of Linux and Free Software. It *will* become mainstream. The only question is "When ?". And I really want to make it happen as soon as possible :-) There are plenty of better packagers than me in the linux world, but you should trust me for doing my very best :-) GPG key ID : 1024D/1B4259B3 Aurelien BOMPARD (perso) Key fingerprint = 4832 1239 8C18 F5F3 C466 AE69 21A6 2396 1B42 59B3 uid Aurelien BOMPARD (perso) sub 1024g/F1285CAF 2003-02-11 Bye, Aurelien - -- http://gauret.free.fr ~~~~~~~~~~~~~~~~~~~~~ There are only 10 types of people in the world : those who understand binary and those who don't. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: http://gauret.free.fr iD8DBQE/pt35IaYjlhtCWbMRAuAPAJ9SYCQmZm5MwcwOMKFZtg5H9La9LACfXgq1 MuZXg+zIpFRH+Ahni80gFH8= =HBcd -----END PGP SIGNATURE----- From paul at dishone.st Mon Nov 3 23:02:32 2003 From: paul at dishone.st (Paul Jakma) Date: Mon, 3 Nov 2003 23:02:32 +0000 (GMT) Subject: Disabling /tmp watch in RawHide In-Reply-To: <1067890175.2582.33.camel@wvanl14.resnet.neu.edu> References: <1067890175.2582.33.camel@wvanl14.resnet.neu.edu> Message-ID: On Mon, 3 Nov 2003, Stan Bubrouski wrote: > more insecure /tmp usage, even if by only the broken usages (i.e. > leaving the files behind). Any thoughts? Leaving the files behind does not automatically indicate the app created/used tmp files insecurely. what are the apps, and what is the insecure behaviour in them? > -sb regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: In 1750 Issac Newton became discouraged when he fell up a flight of stairs. From stan at ccs.neu.edu Mon Nov 3 23:33:07 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Mon, 03 Nov 2003 18:33:07 -0500 Subject: Disabling /tmp watch in RawHide In-Reply-To: References: <1067890175.2582.33.camel@wvanl14.resnet.neu.edu> Message-ID: <1067902386.2582.53.camel@wvanl14.resnet.neu.edu> On Mon, 2003-11-03 at 18:02, Paul Jakma wrote: > On Mon, 3 Nov 2003, Stan Bubrouski wrote: > > > more insecure /tmp usage, even if by only the broken usages (i.e. > > leaving the files behind). Any thoughts? > > Leaving the files behind does not automatically indicate the app > created/used tmp files insecurely. > Yes I'm well aware there are files and directories which by tradition and convenience exist in /tmp > what are the apps, and what is the insecure behavior in them? > This is not the appropriate forum to discuss unannounced bugs, however take for example a program that blindly creates a file in /tmp with a predictable or even static name and follows symlinks allowing files to be overwritten. With tmpwatch on, this bad behavior is masked because the files it might leave behind are deleted and may go for several releases before being caught, if ever. Like I said, I think this is definitely something to consider, because we can get a more secure system as a result. Take for example this: http://www.securityfocus.com/archive/1/343038/2003-10-31/2003-11-06/0 -sb -------------- 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 florin at andrei.myip.org Tue Nov 4 00:31:02 2003 From: florin at andrei.myip.org (Florin Andrei) Date: 03 Nov 2003 16:31:02 -0800 Subject: AMD 64 - What can I do to help? In-Reply-To: <20031103154055.A25665@devserv.devel.redhat.com> References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> <20031103154055.A25665@devserv.devel.redhat.com> Message-ID: <1067905862.2727.32.camel@rivendell.home.local> On Mon, 2003-11-03 at 12:40, Michael K. Johnson wrote: > There's a community effort to put together Fedora Core 1 for AMD64 > and Red Hat is participating. I'd say that since images should be > available for testing soon, testing them on your hardware and reporting > bugs, especially bugs that don't show up on x86, would be something > very important. Any issues that one might expect from things like ALSA or NVidia drivers? I'd like to switch to AMD64 and help with QA and maybe development as well, but i depend on the drivers mentioned above. -- Florin Andrei http://florin.myip.org/ From bos at serpentine.com Tue Nov 4 00:38:39 2003 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon, 03 Nov 2003 16:38:39 -0800 Subject: AMD 64 - What can I do to help? In-Reply-To: <1067905862.2727.32.camel@rivendell.home.local> References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> <20031103154055.A25665@devserv.devel.redhat.com> <1067905862.2727.32.camel@rivendell.home.local> Message-ID: <1067906319.2477.8.camel@serpentine.internal.keyresearch.com> On Mon, 2003-11-03 at 16:31, Florin Andrei wrote: > Any issues that one might expect from things like ALSA or NVidia > drivers? NVIDIA hasn't published any native 64-bit drivers yet. I'd be surprised if ALSA was fully 64-bit clean, but I don't use sound on my AMD64 systems. > I'd like to switch to AMD64 and help with QA and maybe development as > well, but i depend on the drivers mentioned above. I'd say it's a bit too early to expect whiz-bang 3D performance on 64-bit AMD64 desktop machines. On the other hand, I'd say that the platform is solid for servers, albeit with lots of packaging annoyances if you're running mixed 32-bit and 64-bit userland. References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> <20031103154055.A25665@devserv.devel.redhat.com> <1067905862.2727.32.camel@rivendell.home.local> <1067906319.2477.8.camel@serpentine.internal.keyresearch.com> Message-ID: <1067906621.2727.34.camel@rivendell.home.local> On Mon, 2003-11-03 at 16:38, Bryan O'Sullivan wrote: > On Mon, 2003-11-03 at 16:31, Florin Andrei wrote: > > > Any issues that one might expect from things like ALSA or NVidia > > drivers? > > NVIDIA hasn't published any native 64-bit drivers yet. Hmmm... So then what are the Linux AMD64 drivers on their website? -- Florin Andrei http://florin.myip.org/ From davej at redhat.com Tue Nov 4 01:19:11 2003 From: davej at redhat.com (Dave Jones) Date: Tue, 4 Nov 2003 01:19:11 +0000 Subject: AMD 64 support In-Reply-To: References: <20031103140349.B1468@lnxi.com> Message-ID: <20031104011911.GA6186@redhat.com> On Mon, Nov 03, 2003 at 04:12:57PM -0500, Rik van Riel wrote: > We just need some volunteers to pull things together > and put the AMD64 patches from Taroon into Fedora Core > (which is more work than it sounds, because the Taroon > kernel is close to RHL9, while Fedora is closer to the > upstream 2.4 kernel). I spent a day or two last week doing this (and various other fixes). What I have so far is a very 'rough and ready' port, but its mostly functional at least. For the brave who want to try this.. 1) Grab the x86_64 boot disk from x86_64 rawhide dir 2) Boot, and do a network install This gets you a 64bit install based on the 2.4.20 kernel that shipped with gingin64. 3) Now the fun bit. http://people.redhat.com/davej/amd64/ contains the above mentioned 'rough cut' of the amd64 kernel. There's a bunch of known problems right now, like unresolved symbols and the like, which I'll fix up over the next few days. One word of warning, this has had very little testing/QA. Do *not* trust these kernels with data you don't have backups of. Happy hacking.. Dave From 64bit_fedora at comcast.net Tue Nov 4 02:02:18 2003 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Mon, 3 Nov 2003 20:02:18 -0600 (CST) Subject: AMD 64 - What can I do to help? In-Reply-To: <1067906319.2477.8.camel@serpentine.internal.keyresearch.com> Message-ID: On Mon, 3 Nov 2003, Bryan O'Sullivan wrote: > > NVIDIA hasn't published any native 64-bit drivers yet. > Actually, NVidia published 64bit drivers with the Opteron release months ago. They updated those drives with the Athlon 64 release. But AGP is still an issue so far... That should change soon. Justin M. Forbes From mharris at redhat.com Tue Nov 4 02:36:44 2003 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 3 Nov 2003 21:36:44 -0500 (EST) Subject: AMD 64 - What can I do to help? In-Reply-To: <1067906319.2477.8.camel@serpentine.internal.keyresearch.com> References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> <20031103154055.A25665@devserv.devel.redhat.com> <1067905862.2727.32.camel@rivendell.home.local> <1067906319.2477.8.camel@serpentine.internal.keyresearch.com> Message-ID: On Mon, 3 Nov 2003, Bryan O'Sullivan wrote: >> Any issues that one might expect from things like ALSA or NVidia >> drivers? > >NVIDIA hasn't published any native 64-bit drivers yet. Oh? http://www.nvidia.com/object//linux_display_amd64_1.0-4499 http://www.nvidia.com/object/linux_display_ia64_1.0-4050 What are those then? ;o) >I'd be surprised if ALSA was fully 64-bit clean, but I don't use sound >on my AMD64 systems. I'd assume that people with 64bit computers are also using/testing ALSA, and that it's probably not 64bit neglected, although I can't say from personal experience as all my 64bit systems use 2.4.x >> I'd like to switch to AMD64 and help with QA and maybe development as >> well, but i depend on the drivers mentioned above. > >I'd say it's a bit too early to expect whiz-bang 3D performance >on 64-bit AMD64 desktop machines. For proprietary drivers I'd expect them to be reasonable, but one would really have to do specific benchmarks. For OSS drivers, it's more of a matter of having working MTRR support that doesn't suck (mostly XFree86 wonkiness for the time being), and the AGP rate being set properly by the BIOS and configurable in CMOS. >On the other hand, I'd say that the platform is solid for >servers, albeit with lots of packaging annoyances if you're >running mixed 32-bit and 64-bit userland. File bug reports. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From riel at redhat.com Tue Nov 4 02:42:00 2003 From: riel at redhat.com (Rik van Riel) Date: Mon, 3 Nov 2003 21:42:00 -0500 (EST) Subject: AMD 64 support In-Reply-To: <3FA6C6F8.1040909@wanadoo.es> Message-ID: On Mon, 3 Nov 2003, Xose Vazquez Perez wrote: > Rik van Riel wrote: > > > (which is more work than it sounds, because the Taroon > > kernel is close to RHL9, while Fedora is closer to the > > Sorry, but RHL9 and Taroon kernel are *very far* cousins. > 2.4.21-4.EL is wonderful, 2.4.20-20.9 is not too good. True, they're rather far removed from each other by now ;) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From danielnastase at hotmail.com Tue Nov 4 02:44:59 2003 From: danielnastase at hotmail.com (Daniel Nastase) Date: Tue, 04 Nov 2003 02:44:59 +0000 Subject: System task scheduler - for configuring cron and at Message-ID: Hello, What exactly is required from these Configuration Tools ? I see that there already is a gui frontend for cron: kcron. I did not check for 'at' yet. Does it necessarily need to be an PyGtk ? or what's the reason ? Thanks, Daniel _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From xose at wanadoo.es Tue Nov 4 02:51:19 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Tue, 04 Nov 2003 03:51:19 +0100 Subject: AMD 64 support References: Message-ID: <3FA71427.5080000@wanadoo.es> Rik van Riel wrote: > On Mon, 3 Nov 2003, Xose Vazquez Perez wrote: >>Sorry, but RHL9 and Taroon kernel are *very far* cousins. >>2.4.21-4.EL is wonderful, 2.4.20-20.9 is not too good. > True, they're rather far removed from each other by now ;) I hope that you will send fixes/minor_features to Tosatti. 2.4.23 is getting better :-) -- HTML mails are going to trash automagically From anthony at safferconsulting.com Tue Nov 4 08:40:55 2003 From: anthony at safferconsulting.com (Anthony Saffer) Date: Tue, 4 Nov 2003 00:40:55 -0800 Subject: New Member Intro Message-ID: <002d01c3a2af$5dc25820$15f4ac41@k4h8f5> Hello Everyone, Just joined the list and wanted to say hello. I'm a 30 year old software developer out of Oklahoma who's excited about working on the Fedora project. Hope to meet everyone soon and looking forward to getting down to work! Anthony Saffer ======================================= SCS Consulting Services Professional Software and Website Development Affordable Webhosting also Available Visit: http://www.safferconsulting.com ======================================= From anthony at safferconsulting.com Tue Nov 4 08:47:25 2003 From: anthony at safferconsulting.com (Anthony Saffer) Date: Tue, 4 Nov 2003 00:47:25 -0800 Subject: Question about development languages Message-ID: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> Hello Everyone, I was browsing the Fedora website and noticed that the configuration tools are said to be all Python based with a few PyGTK ones. I don't know Python at all but am very familiar with Perl and PerlTk. Do the tools HAVE to be written in Python or are other languages acceptable? Thanks, Anthony ======================================= SCS Consulting Services Professional Software and Website Development Affordable Webhosting also Available Visit: http://www.safferconsulting.com ======================================= From salimma1 at yahoo.co.uk Tue Nov 4 08:00:40 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Tue, 04 Nov 2003 15:00:40 +0700 Subject: AMD 64 - What can I do to help? In-Reply-To: <20031103154055.A25665@devserv.devel.redhat.com> References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> <20031103154055.A25665@devserv.devel.redhat.com> Message-ID: <1067932839.8184.70.camel@bushido.localdomain> On Tue, 2003-11-04 at 03:40, Michael K. Johnson wrote: > Also, once it is available, helping QA packages for AMD64 in the > fedora.su QA queue would be useful. ~~ Freudian slip? I'm sure you mean fedora.us :) Regards, Michel From pros-n-cons at bak.rr.com Tue Nov 4 08:55:32 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Tue, 4 Nov 2003 00:55:32 -0800 Subject: Question about development languages In-Reply-To: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> Message-ID: <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> On Tue, 04 Nov 2003 00:47:25 -0800 Anthony Saffer wrote: > Hello Everyone, > > I was browsing the Fedora website and noticed that the configuration tools > are said to be all Python based with a few PyGTK ones. I don't know Python > at all but am very familiar with Perl and PerlTk. Do the tools HAVE to be > written in Python or are other languages acceptable? I am in the same boat as you. I know perl and wanted to help with this also but when I asked the impression I got is they would like the consistancy. So TK libs, gtk2-perl, etc isn't a dependancy during installation. I tend to agree now. I guess we have to wait for the python guys to add those tools. > > Thanks, > Anthony Vincent -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From shekhar.tiwatne at ensim.com Tue Nov 4 09:18:42 2003 From: shekhar.tiwatne at ensim.com (Shekhar) Date: 04 Nov 2003 14:48:42 +0530 Subject: mod_frontpage packaging In-Reply-To: <20031103212005.27713.21081.Mailman@listman.back-rdu.redhat.com> References: <20031103212005.27713.21081.Mailman@listman.back-rdu.redhat.com> Message-ID: <1067937522.28372.14.camel@stiwatne.india.ensim.com> Comment inline. > > We use mod_frontpage for package apache for our RH servers. It is > > already been included in Mandrake. I wonder can we [fedora] include this > > as part for distro. If it can be included I would put this request > > alongwith the package download URLs on fedora [.us?] site. > > New version of this module can be used as a DSO. > > A couple of thoughts... > > o Is "Frontpage" a trademark? Link to Frontpage trademark: http://tess2.uspto.gov/bin/gate.exe?f=3Ddoc&state=3Dp46ru3.3.3 Somebody really need to check but afaik frontpage extensions are redistributable. > o A google search on mod_frontpage shows several reimplementations > and lots of security issues as the main hits... The main issue with frontpage was there was a need to recompile / patch apache to support frontpage. But now MIcrosoft has released frontpage2002sr1.1 which does not have this issue. It can be used as a DSO now. I belive that the old security issues are now absolute. > > The first might be an issue for fedora.us (we want to be careful about > > legality); the second is more an issue of taste and might keep it out > > of Fedora Core even if it went into extras, from a concern for security > > standpoint. It ok even its in extras. > Beyond this, is there even a need for it? I guess there is. 1. Madrake includes it. 2. Most if not all web hosting service providers support frontpage. 3. Lot of web developers actually use frontpage to author site while the sites actually r on apache server. Personally I dont like it much though I guess above reasons r sufficient. From buildsys at porkchop.devel.redhat.com Tue Nov 4 11:50:51 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Tue, 4 Nov 2003 06:50:51 -0500 Subject: rawhide report: 20031104 changes Message-ID: <200311041150.hA4Bopr04385@porkchop.devel.redhat.com> Updated Packages: desktop-backgrounds-2.0-18 -------------------------- * Sun Nov 02 2003 Elliot Lee 2.0-18 - redhat-backgrounds-6 gnome-pilot-2.0.10-4 -------------------- * Sun Nov 02 2003 Jeremy Katz 2.0.10-4 - updated Treo600 patch openoffice.org-1.1.0-6 ---------------------- * Mon Nov 03 2003 Dan Williams 1.1.0-6 - Tweak default fonts some more (#108812) * Fri Oct 31 2003 Dan Williams 1.1.0-5 - Update default fonts, change Central/Eastern Europe to Nimbus from Luxi - Remove fonts not shipped with the OS from the Font menu * Tue Oct 28 2003 Dan Williams 1.1.0-4 - Make OpenOffice.org more prelink-friendly, ie. when prelinked it ought to start up faster (Jakub Jelinek) - Bypass soffice script, handle the necessary things already in ooffice script (Jakub Jelinek) - Make getstyle-gnome and msgbox-gnome binaries prelinkable (Jakub Jelinek) - Speed up the build by not packing all binaries and libraries 18 times (and also require way less diskspace for the build) (Jakub Jelinek) - Fix .desktop file stuff - Fix slightly broken 1.0.2 upgrade process - Enable parallel building for > 1 processor machines * Fri Oct 17 2003 Dan Williams 1.1.0-3 - Adjust UI font for different languages - Remove oosetup - Allow for RH 9 building (not quite working yet) - Fix .desktop files location in menus - Add libart_lgpl to Requirements, remove Startup Notification for RH9 - Massively clean up ooffice launcher script, upgrades cleaner - Remove Mozilla zipfiles from OOo sources to reduce bloat - Use system BerekelyDB rather than builtin one (requires a berkeleydb built _without_ -nostdlib, ie >= 4.1.25-11 or most v 4.0) - Remove "registration" dialog on startup - Patch in font antialias size rather than set on launch - Add regcomp tool to final package - Don't build ICU libs as DT_TEXTREL - Require GCC 3.2.2 now, rather than 3.3 - Switch on symbols and make debuginfo RPMs work * Tue Oct 07 2003 Jeremy Katz 1.1.0-2 - add obsoletes to subpackages * Fri Oct 03 2003 Dan Williams 1.1.0-1 - Initial Release of 1.1.0 rpms rpmdb-fedora-1-0.20031104 ------------------------- From johnsonm at redhat.com Tue Nov 4 12:41:54 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 4 Nov 2003 07:41:54 -0500 Subject: AMD 64 support In-Reply-To: <20031103140349.B1468@lnxi.com>; from msnitzer@lnxi.com on Mon, Nov 03, 2003 at 02:03:49PM -0700 References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> <20031103140349.B1468@lnxi.com> Message-ID: <20031104074154.A12202@devserv.devel.redhat.com> On Mon, Nov 03, 2003 at 02:03:49PM -0700, Mike Snitzer wrote: > RedHat employees have said they openly encourage people to port Fedora to > other architectures. So the fedora community can take Fedora where they > want it to go; but RedHat likely won't act as the catalyst for things like > an x86_64 port. All understandable, its just frustrating in that they've > obviously done the required work; and they are perfectly content with > having the Fedora community duplicate that effort of formalizing 64bit > library and 32bit library coexistance and so on. For all I know RedHat > will weigh in and advise on such decisions. What duplication? The biarch work needs no duplication. We're not holding anything back; we just haven't cut iso images yet. > So that said, has there been any big picture planning for how x86_64 > support will be added to Fedora Core? A list of which tasks need to be > accomplished, who the stakeholders that will be contributing are, etc. Testing, testing, testing, and more testing. I expect that ISO images will be available either from Justin or Red Hat soon. When they are, test them. > We may even want a new fedora-amd64-devel at fedora.redhat.com mailing list > for the cause. Actually it might be nice if a fedora--devel > mailing list were created for each architecture the Fedora community deems > worthy. I'd rather keep it all here on one list where everyone sees what is going on. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From johnsonm at redhat.com Tue Nov 4 12:43:29 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 4 Nov 2003 07:43:29 -0500 Subject: mod_frontpage packaging In-Reply-To: <1067894131.2582.40.camel@wvanl14.resnet.neu.edu>; from stan@ccs.neu.edu on Mon, Nov 03, 2003 at 04:15:31PM -0500 References: <20031101170009.7554.92510.Mailman@listman.back-rdu.redhat.com> <1067878855.27000.89.camel@stiwatne.india.ensim.com> <20031103160111.B25665@devserv.devel.redhat.com> <1067894131.2582.40.camel@wvanl14.resnet.neu.edu> Message-ID: <20031104074329.B12202@devserv.devel.redhat.com> On Mon, Nov 03, 2003 at 04:15:31PM -0500, Stan Bubrouski wrote: > Beyond this, is there even a need for it? When I queried Mark Cox about this, he pointed out that the authoring tools that use mod_frontpage can now also use DAV, and suggested that just using DAV is by far the right answer here. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From johnsonm at redhat.com Tue Nov 4 12:57:01 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 4 Nov 2003 07:57:01 -0500 Subject: Question about development languages In-Reply-To: <20031104005532.1ec9434a.pros-n-cons@bak.rr.com>; from pros-n-cons@bak.rr.com on Tue, Nov 04, 2003 at 12:55:32AM -0800 References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> Message-ID: <20031104075700.C12202@devserv.devel.redhat.com> On Tue, Nov 04, 2003 at 12:55:32AM -0800, Vincent wrote: > Anthony Saffer wrote: > > I was browsing the Fedora website and noticed that the configuration tools > > are said to be all Python based with a few PyGTK ones. I don't know Python > > at all but am very familiar with Perl and PerlTk. Do the tools HAVE to be > > written in Python or are other languages acceptable? > > I am in the same boat as you. I know perl and wanted to help with this also > but when I asked the impression I got is they would like the consistancy. So > TK libs, gtk2-perl, etc isn't a dependancy during installation. I tend to agree > now. I guess we have to wait for the python guys to add those tools. Hmm, it's my opinion that anyone able to learn Perl would find Python trivial, but I guess that's just an opinion. My experience, though, is that I was pretty normal in being able to write maintainable Python code the first day I started learning it -- I've heard the same from lots of other people. The real challenge here is probably not moving from Perl to Python, but rather moving from Tk to GTK. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From esr at thyrsus.com Tue Nov 4 13:02:17 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 4 Nov 2003 08:02:17 -0500 Subject: Question about development languages In-Reply-To: <20031104075700.C12202@devserv.devel.redhat.com> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> Message-ID: <20031104130217.GA22753@thyrsus.com> Michael K. Johnson : > Hmm, it's my opinion that anyone able to learn Perl would find Python > trivial, but I guess that's just an opinion. My experience, though, > is that I was pretty normal in being able to write maintainable Python > code the first day I started learning it -- I've heard the same from > lots of other people. > > The real challenge here is probably not moving from Perl to Python, > but rather moving from Tk to GTK. I've had experience with this kind of migration. Agreed on both counts. -- Eric S. Raymond From behdad at cs.toronto.edu Tue Nov 4 13:23:31 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 4 Nov 2003 08:23:31 -0500 Subject: Question about development languages In-Reply-To: <20031104130217.GA22753@thyrsus.com> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> Message-ID: On Tue, 4 Nov 2003, Eric S. Raymond wrote: > Michael K. Johnson : > > Hmm, it's my opinion that anyone able to learn Perl would find Python > > trivial, but I guess that's just an opinion. My experience, though, > > is that I was pretty normal in being able to write maintainable Python > > code the first day I started learning it -- I've heard the same from > > lots of other people. > > > > The real challenge here is probably not moving from Perl to Python, > > but rather moving from Tk to GTK. > > I've had experience with this kind of migration. Agreed on both counts. One thing I found about Python is that it's quite easy to write Python code on the first day, and it's the best choice for GUI apps. But it's by no means a good replacement for sophisticated shell scripts. (correct me if I'm wrong). From esr at thyrsus.com Tue Nov 4 13:34:09 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 4 Nov 2003 08:34:09 -0500 Subject: Question about development languages In-Reply-To: References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> Message-ID: <20031104133409.GA22913@thyrsus.com> Behdad Esfahbod : > One thing I found about Python is that it's quite easy to write > Python code on the first day, and it's the best choice for GUI > apps. But it's by no means a good replacement for sophisticated > shell scripts. (correct me if I'm wrong). I'm an expert shell programmer. But since I started using Python, I no longer use shell for anything with control structure in it. One liners, yes, but anything more complex seems to me to be more natural as a Python program. Nothing new about this; Perl fans say the same thing about Perl. -- Eric S. Raymond From behdad at cs.toronto.edu Tue Nov 4 13:46:37 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 4 Nov 2003 08:46:37 -0500 Subject: Question about development languages In-Reply-To: <20031104133409.GA22913@thyrsus.com> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> <20031104133409.GA22913@thyrsus.com> Message-ID: On Tue, 4 Nov 2003, Eric S. Raymond wrote: > Behdad Esfahbod : > > One thing I found about Python is that it's quite easy to write > > Python code on the first day, and it's the best choice for GUI > > apps. But it's by no means a good replacement for sophisticated > > shell scripts. (correct me if I'm wrong). > > I'm an expert shell programmer. Needless to say ;) > But since I started using Python, I no > longer use shell for anything with control structure in it. One liners, > yes, but anything more complex seems to me to be more natural as a > Python program. Nothing new about this; Perl fans say the same thing > about Perl. Here's my scenario: Am writing something called crs, which uses cvs and find extensively. I'm writing in Python, but found it really hard to run cvs and find from there, handling the outputs, ... all the time. I couldn't find any PyCVS module, if you are going to suggest that. So do you suggest writing something like /etc/rc.d/rc.sysinit in Python? behdad From peter.backlund at home.se Tue Nov 4 14:07:02 2003 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 04 Nov 2003 15:07:02 +0100 Subject: OOo missing build req? In-Reply-To: <200311041150.hA4Bopr04385@porkchop.devel.redhat.com> References: <200311041150.hA4Bopr04385@porkchop.devel.redhat.com> Message-ID: <3FA7B286.7000700@home.se> Hi. Tried building OOo 1.1.0-4 (newest version on my mirror) on Shrike, which initially failed due to missing mozilla-nspr-devel. Perhaps that should be added to BuildRequires: (I didn't see anything about this in the post -4 changelog) /Peter From dcbw at redhat.com Tue Nov 4 14:12:49 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 04 Nov 2003 09:12:49 -0500 Subject: OOo missing build req? In-Reply-To: <3FA7B286.7000700@home.se> References: <200311041150.hA4Bopr04385@porkchop.devel.redhat.com> <3FA7B286.7000700@home.se> Message-ID: <1067955169.4866.1.camel@dhcp64-188.boston.redhat.com> Eh, you're right. Will add it. Are you throwing the build_shrike switch in the specfile too (its not related to the requires problem)? Did you upgrade your libart_lgpl version? Dan On Tue, 2003-11-04 at 09:07, Peter Backlund wrote: > Hi. > > Tried building OOo 1.1.0-4 (newest version on my mirror) on Shrike, > which initially failed due to missing mozilla-nspr-devel. > > Perhaps that should be added to BuildRequires: > > (I didn't see anything about this in the post -4 changelog) > > /Peter > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From P at draigBrady.com Tue Nov 4 14:12:30 2003 From: P at draigBrady.com (P at draigBrady.com) Date: Tue, 04 Nov 2003 14:12:30 +0000 Subject: Question about development languages In-Reply-To: References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> <20031104133409.GA22913@thyrsus.com> Message-ID: <3FA7B3CE.2030207@draigBrady.com> Behdad Esfahbod wrote: > On Tue, 4 Nov 2003, Eric S. Raymond wrote: > >>Behdad Esfahbod : >> >>>One thing I found about Python is that it's quite easy to write >>>Python code on the first day, and it's the best choice for GUI >>>apps. But it's by no means a good replacement for sophisticated >>>shell scripts. (correct me if I'm wrong). >> >>I'm an expert shell programmer. > > > Needless to say ;) > >>But since I started using Python, I no >>longer use shell for anything with control structure in it. One liners, >>yes, but anything more complex seems to me to be more natural as a >>Python program. Nothing new about this; Perl fans say the same thing >>about Perl. > > Here's my scenario: Am writing something called crs, which uses > cvs and find extensively. I'm writing in Python, but found it > really hard to run cvs and find from there, handling the outputs, > ... all the time. I couldn't find any PyCVS module, if you are > going to suggest that. I've done essentially this in fslint: http://www.pixelbeat.org/fslint/ P?draig. From esr at thyrsus.com Tue Nov 4 14:56:12 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 4 Nov 2003 09:56:12 -0500 Subject: Question about development languages In-Reply-To: References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> <20031104133409.GA22913@thyrsus.com> Message-ID: <20031104145612.GA23302@thyrsus.com> Behdad Esfahbod : > So do you suggest writing something like /etc/rc.d/rc.sysinit in > Python? Hmmm...that might be one of tbe few places I *wouldn't* do it. There's a design-level question there about reducing boot-time dependencies that doesn'y apply to normal userland scripts. -- Eric S. Raymond From notting at redhat.com Tue Nov 4 15:03:28 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Nov 2003 10:03:28 -0500 Subject: Question about development languages In-Reply-To: ; from behdad@cs.toronto.edu on Tue, Nov 04, 2003 at 08:46:37AM -0500 References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> <20031104133409.GA22913@thyrsus.com> Message-ID: <20031104100328.C30221@devserv.devel.redhat.com> Behdad Esfahbod (behdad at cs.toronto.edu) said: > So do you suggest writing something like /etc/rc.d/rc.sysinit in > Python? Not really; this would stand a decent chance of making the bootup slower, to the best of my knowledge. Bill From elanthis at awesomeplay.com Tue Nov 4 15:15:16 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 04 Nov 2003 10:15:16 -0500 Subject: Question about development languages In-Reply-To: <20031104075700.C12202@devserv.devel.redhat.com> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> Message-ID: <1067958915.2129.4.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2003-11-04 at 07:57, Michael K. Johnson wrote: > On Tue, Nov 04, 2003 at 12:55:32AM -0800, Vincent wrote: > > Anthony Saffer wrote: > > > I was browsing the Fedora website and noticed that the configuration tools > > > are said to be all Python based with a few PyGTK ones. I don't know Python > > > at all but am very familiar with Perl and PerlTk. Do the tools HAVE to be > > > written in Python or are other languages acceptable? > > > > I am in the same boat as you. I know perl and wanted to help with this also > > but when I asked the impression I got is they would like the consistancy. So > > TK libs, gtk2-perl, etc isn't a dependancy during installation. I tend to agree > > now. I guess we have to wait for the python guys to add those tools. > > Hmm, it's my opinion that anyone able to learn Perl would find Python > trivial, but I guess that's just an opinion. My experience, though, > is that I was pretty normal in being able to write maintainable Python > code the first day I started learning it -- I've heard the same from > lots of other people. Agreed. I wrote a fully functional networked GUI app in a couple hours w/ Python and PyGTK the other week, and I've never made a GUI before, and haven't used Python in *years*. Picking up Python and GTK+ is as simple as it can possibly get. > > The real challenge here is probably not moving from Perl to Python, > but rather moving from Tk to GTK. > > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From peter.backlund at home.se Tue Nov 4 15:41:11 2003 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 04 Nov 2003 16:41:11 +0100 Subject: OOo missing build req? In-Reply-To: <1067955169.4866.1.camel@dhcp64-188.boston.redhat.com> References: <200311041150.hA4Bopr04385@porkchop.devel.redhat.com> <3FA7B286.7000700@home.se> <1067955169.4866.1.camel@dhcp64-188.boston.redhat.com> Message-ID: <3FA7C897.10602@home.se> > Are you throwing the build_shrike > switch in the specfile too (its not related to the requires problem)? > Did you upgrade your libart_lgpl version? Yes on both, rebuilt the rawhide libart_lgpl. This was caught quite early, however the build failed later on due to some complicated error that I don't remember now...but it says in the specfile that RH9 building doesn't quite work yet, so I wasn't really suprised :-) I could post the error if you aren't aware of any build errors on RH9 though. /Peter From peter.backlund at home.se Tue Nov 4 15:46:18 2003 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 04 Nov 2003 16:46:18 +0100 Subject: OOo missing build req? In-Reply-To: <3FA7C897.10602@home.se> References: <200311041150.hA4Bopr04385@porkchop.devel.redhat.com> <3FA7B286.7000700@home.se> <1067955169.4866.1.camel@dhcp64-188.boston.redhat.com> <3FA7C897.10602@home.se> Message-ID: <3FA7C9CA.7020306@home.se> Uh, I feel the need to clarify myself here: > Yes on both, rebuilt the rawhide libart_lgpl. This was caught quite > early, The missing mozilla-nspr-devel error. > however the build failed later on due to some complicated error > that I don't remember now... This is another error, an hour or so into the build. > but it says in the specfile that RH9 > building doesn't quite work yet, so I wasn't really suprised :-) > > I could post the error if you aren't aware of any build errors on RH9 > though. > > /Peter > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From dcbw at redhat.com Tue Nov 4 15:44:08 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 04 Nov 2003 10:44:08 -0500 Subject: OOo missing build req? In-Reply-To: <3FA7C897.10602@home.se> References: <200311041150.hA4Bopr04385@porkchop.devel.redhat.com> <3FA7B286.7000700@home.se> <1067955169.4866.1.camel@dhcp64-188.boston.redhat.com> <3FA7C897.10602@home.se> Message-ID: <1067960648.4866.16.camel@dhcp64-188.boston.redhat.com> Peter, The main issues right now with RH9 are libart_lgpl (which I'll fix today to allow whatever shipped with RH9 and not a newer version) and Mozilla. Since the package uses the installed system mozilla, and since RH9 ships with Moz 1.2 (i think), there are API changes between mozilla versions that have to be accounted for in the patches. I simply have not gotten around to making a new patch for RH9 systems that takes Mozilla 1.2 into account. Its not hard at all and I know what needs to be done, I just haven't gotten there yet. Dan On Tue, 2003-11-04 at 10:41, Peter Backlund wrote: > > Are you throwing the build_shrike > > switch in the specfile too (its not related to the requires problem)? > > Did you upgrade your libart_lgpl version? > > Yes on both, rebuilt the rawhide libart_lgpl. This was caught quite > early, however the build failed later on due to some complicated error > that I don't remember now...but it says in the specfile that RH9 > building doesn't quite work yet, so I wasn't really suprised :-) > > I could post the error if you aren't aware of any build errors on RH9 > though. > > /Peter > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From daly at rio.sci.ccny.cuny.edu Tue Nov 4 14:41:36 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Tue, 4 Nov 2003 09:41:36 -0500 Subject: AMD 64 support In-Reply-To: (message from Rik van Riel on Mon, 3 Nov 2003 16:12:57 -0500 (EST)) References: Message-ID: <200311041441.JAA10927@springbok.sci.ccny.cuny.edu> Is there an open AMD64 machine on the web? I can get at Itaniums using HP's Testdrive setup but they don't have an AMD64 online. I have 3 apps that need to be ported. Tim Daly axiom at tenkan.org daly at idsi.net From x.nicolovici at rsd.com Tue Nov 4 16:45:33 2003 From: x.nicolovici at rsd.com (NICOLOVICI Xavier) Date: Tue, 4 Nov 2003 17:45:33 +0100 Subject: Development offer Message-ID: <3A22BF344F2759448777928381C7284DF12D05@geneve01.hq.rsd.ch> Hi there, I've just been through the Fedora web site, after reading the RedHat announcement about stoping support on RedHat Linux. I've found that the Fedora project was missing some desktop tools, and especially a system task scheduler. I had a try of Python/PyGTK a few monthes ago and wanted to get a bit deeper with this environment. I found usefull to start learning by contributing to something that will benfit to the community. On top of that, I'm a Linux user since now 10 years, and except translating some GNOME guides into french, I haven't contributed so much. So, my question is, does someone even start writing any spec/code on a system task scheduler desktop tool for the Fedora project. If any, and if my assistance is welcome, then please get in touch with me. If not, then I may start working on my own side on some kind of specifications. Bye, Xavier Nicolovici This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or a transmission error has misdirected this e-mail, please notify the author by replying to the e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. We take reasonable precautions to ensure our e-mails are virus free. However, we cannot accept responsibility for any virus transmitted by us and recommend that you subject any incoming e-mail to your own virus checking procedures. From elanthis at awesomeplay.com Tue Nov 4 16:51:58 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 04 Nov 2003 11:51:58 -0500 Subject: AMD 64 support In-Reply-To: <200311041441.JAA10927@springbok.sci.ccny.cuny.edu> References: <200311041441.JAA10927@springbok.sci.ccny.cuny.edu> Message-ID: <1067964718.2640.5.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2003-11-04 at 09:41, Tim Daly wrote: > Is there an open AMD64 machine on the web? I can get at Itaniums > using HP's Testdrive setup but they don't have an AMD64 online. > I have 3 apps that need to be ported. SourceForge's compile farm has one, I believe, for projects hosted at SourceForge. The compile farm is excellent for porting work, I don't know what I'd do without it. (Well, yes I do - I'd have a lot of software will small, silly portability buglets. ~,^ ) > > Tim Daly > axiom at tenkan.org > daly at idsi.net > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From bfox at redhat.com Tue Nov 4 16:56:44 2003 From: bfox at redhat.com (Brent Fox) Date: Tue, 04 Nov 2003 11:56:44 -0500 Subject: Question about development languages In-Reply-To: <1067958915.2129.4.camel@support02.civic.twp.ypsilanti.mi.us> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <1067958915.2129.4.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1067965003.22828.12.camel@bfox.devel.redhat.com> On Tue, 2003-11-04 at 10:15, Sean Middleditch wrote: > Agreed. I wrote a fully functional networked GUI app in a couple hours > w/ Python and PyGTK the other week, and I've never made a GUI before, > and haven't used Python in *years*. Picking up Python and GTK+ is as > simple as it can possibly get. For more complicated GUIs, Glade can help you build the interfaces. For simpler UIs, I do them by hand. But for programs like redhat-config-kickstart which have tons of widgets, Glade really saves a lot of time. Creating all that widget code by hand would have been tedious and would have really increased the line count. I feel that Python has a great deal of untapped potential. Wrapping a decent IDE around Python and using something like Glade for the UI builder would give us an open source equivalent to Visual Basic. It would provide a rapid application development environment for Windows developers looking to migrate to Linux. Maybe Eclipse has something for Python; I'll have to check. Cheers, Brent From elanthis at awesomeplay.com Tue Nov 4 17:01:55 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 04 Nov 2003 12:01:55 -0500 Subject: Question about development languages In-Reply-To: <1067965003.22828.12.camel@bfox.devel.redhat.com> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <1067958915.2129.4.camel@support02.civic.twp.ypsilanti.mi.us> <1067965003.22828.12.camel@bfox.devel.redhat.com> Message-ID: <1067965315.2640.8.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2003-11-04 at 11:56, Brent Fox wrote: > On Tue, 2003-11-04 at 10:15, Sean Middleditch wrote: > > > Agreed. I wrote a fully functional networked GUI app in a couple hours > > w/ Python and PyGTK the other week, and I've never made a GUI before, > > and haven't used Python in *years*. Picking up Python and GTK+ is as > > simple as it can possibly get. > > For more complicated GUIs, Glade can help you build the interfaces. For > simpler UIs, I do them by hand. But for programs like > redhat-config-kickstart which have tons of widgets, Glade really saves a > lot of time. Creating all that widget code by hand would have been > tedious and would have really increased the line count. Definitely. I wouldn't have managed that "couple hours" feat without Glade. Altho, I probably could've done it a lot quicker still if Glade had a UI that didn't suck. ~,^ > > I feel that Python has a great deal of untapped potential. Wrapping a > decent IDE around Python and using something like Glade for the UI > builder would give us an open source equivalent to Visual Basic. It > would provide a rapid application development environment for Windows > developers looking to migrate to Linux. There are several decent IDEs for Python already, no? Perhaps building off of one of those would be a good idea. > > Maybe Eclipse has something for Python; I'll have to check. > > > Cheers, > Brent > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From dsr at best-off.org Tue Nov 4 17:17:24 2003 From: dsr at best-off.org (Daniel S. Reichenbach) Date: Tue, 04 Nov 2003 18:17:24 +0100 Subject: Question about development languages In-Reply-To: <1067965003.22828.12.camel@bfox.devel.redhat.com> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <1067958915.2129.4.camel@support02.civic.twp.ypsilanti.mi.us> <1067965003.22828.12.camel@bfox.devel.redhat.com> Message-ID: <3FA7DF24.1030203@best-off.org> Hi... Brent Fox wrote: > Maybe Eclipse has something for Python; I'll have to check. Eclipse definitly has something for python. You might want to try TruStudio. It's a Plugin for Eclipse featuring both Python and PHP. It's Open Source and has a OSI compliant license. [1] http://www.xored.com/products.php > Cheers, > Brent daniel -- best off info at best-off.org One company. One profession. http://www.best-off.org/ Marie-Calm-Str. 25 Phone +49 561 920 37 48 34131 Kassel Fax +49 561 920 37 49 Germany Mobile +49 178 474 20 63 From anthony at safferconsulting.com Tue Nov 4 19:20:06 2003 From: anthony at safferconsulting.com (Anthony Saffer) Date: Tue, 4 Nov 2003 11:20:06 -0800 Subject: Development Offer References: <20031104170009.10266.55002.Mailman@listman.back-rdu.redhat.com> Message-ID: <00e901c3a308$ab7f0500$49f4ac41@k4h8f5> > So, my question is, does someone even start writing any spec/code on a > system task scheduler desktop tool for the Fedora project. If any, and if my > assistance is welcome, then please get in touch with me. If not, then I may > start working on my own side on some kind of specifications. Hi Xavier, I've recently started work on a GUI interface to cron and at in Perl. But from reading around, it doesn't look like my project will ever make it into the release (due to it not being Python source). I think there's a lot of room for a good scheduler out there. Good luck! Anthony From rdieter at math.unl.edu Tue Nov 4 17:46:09 2003 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 04 Nov 2003 11:46:09 -0600 Subject: OOo missing build req? In-Reply-To: <20031104170009.10266.76691.Mailman@listman.back-rdu.redhat.com> References: <20031104170009.10266.76691.Mailman@listman.back-rdu.redhat.com> Message-ID: <3FA7E5E1.5090601@math.unl.edu> Peter Backlund wrote: > > Tried building OOo 1.1.0-4 (newest version on my mirror) on Shrike, > which initially failed due to missing mozilla-nspr-devel. > > Perhaps that should be added to BuildRequires: I would argue that it's a bug in mozilla-devel in that it ought to have Requires: mozilla-nspr-devel -- Rex From mchilders at bentonville.k12.ar.us Tue Nov 4 17:43:45 2003 From: mchilders at bentonville.k12.ar.us (Childers, Matthew) Date: Tue, 4 Nov 2003 11:43:45 -0600 Subject: Development offer Message-ID: <00500B63031BE4429D4F6532841D3681F7F66C@loki.bentonville.k12.ar.us> > Hi there, > > I've just been through the Fedora web site, after reading the RedHat > announcement about stoping support on RedHat Linux. > > I've found that the Fedora project was missing some desktop tools, and > especially a system task scheduler. I had a try of Python/PyGTK a few > monthes ago and wanted to get a bit deeper with this environment. I found > usefull to start learning by contributing to something that will benfit to > the community. On top of that, I'm a Linux user since now 10 years, and > except translating some GNOME guides into french, I haven't contributed so > much. > > So, my question is, does someone even start writing any spec/code on a > system task scheduler desktop tool for the Fedora project. If any, and if > my > assistance is welcome, then please get in touch with me. If not, then I > may > start working on my own side on some kind of specifications. > > Bye, > > Xavier Nicolovici I too am a long time user of RedHat and have never really found a place to contribute, but would love to help out on the Fedora Project. I have developed apps in C and Gtk before (although most of my development knowledge is in VB and ASP on the Windows side), but I have used Python/PyGTK a little bit and don't think it would be that major of a learning curve. Like Xavier, I am willing to help out on any projects if any have started, or Xavier, I would be willing to work with you on a task scheduler. Again, I don't want to be a burden to anyone, and don't mind doing dirty work, just let me know what you need and I would be more than willing to help, as long as I have free time at that moment. Would love to get my feet wet in the development process, so let me know if you need anything. Thanks, Matt From florin at andrei.myip.org Tue Nov 4 17:47:25 2003 From: florin at andrei.myip.org (Florin Andrei) Date: 04 Nov 2003 09:47:25 -0800 Subject: AMD 64 - What can I do to help? In-Reply-To: <1067905862.2727.32.camel@rivendell.home.local> References: <001d01c3a233$f93c0d40$0100a8c0@shubunkin> <20031103154055.A25665@devserv.devel.redhat.com> <1067905862.2727.32.camel@rivendell.home.local> Message-ID: <1067968044.2642.6.camel@rivendell.home.local> On Mon, 2003-11-03 at 16:31, Florin Andrei wrote: > > Any issues that one might expect from things like ALSA or NVidia > drivers? Ok, according to Takashi Iwai, there are no issues with ALSA on AMD64, except for the occasional broken app that needs to be fixed. http://sourceforge.net/mailarchive/forum.php?thread_id=3401842&forum_id=1751 ALSA overall works, NVidia seems to work... -- Florin Andrei http://florin.myip.org/ From wcooley at nakedape.cc Tue Nov 4 18:01:34 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Tue, 04 Nov 2003 10:01:34 -0800 Subject: Question about development languages In-Reply-To: <1067965003.22828.12.camel@bfox.devel.redhat.com> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <1067958915.2129.4.camel@support02.civic.twp.ypsilanti.mi.us> <1067965003.22828.12.camel@bfox.devel.redhat.com> Message-ID: <1067968894.5248.89.camel@denk.nakedape.priv> On Tue, 2003-11-04 at 08:56, Brent Fox wrote: > I feel that Python has a great deal of untapped potential. Wrapping a > decent IDE around Python and using something like Glade for the UI > builder would give us an open source equivalent to Visual Basic. Except the language wouldn't suck :) Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Naked Ape Consulting http://nakedape.cc * -------------- 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 tony at tgds.net Tue Nov 4 18:04:41 2003 From: tony at tgds.net (tony) Date: Tue, 04 Nov 2003 19:04:41 +0100 Subject: A presentation Message-ID: <1067969081.5029.38.camel@localhost.localdomain> Hello, I'm new - and old fashioned... I remember the days when, if one joined a list, it was good etiquette to present ones self. I still do that. Today's news and various mail from RHN sent me a signal that it was time to give back a little more. I seem to be one of the few reading /. that actually understand why the changes underway are happening. And why they are good. Good for Linux. Good for Redhat. And good for users such as myself. I have been using Redhat Linux since 1997. I have a habit of installing it on strange hardware: the first time was on a Mac PowerBook running a w at rez beta copy of VirtualPC. I learnt more about Linux in those three weeks than I have since. I learnt so much about Redhat Linux that I have only flirted with other distros. I ran it on some classic iron for a time. Then I graduated to a Sony C1XD Picturebook. I still use that on the road. My main machine is now a hush mini-ITX Epia-M machine. I hope to sell these machines with a Linux desktop installed (DVD playback is my current battle). I don't know where I can help. But I'm here, and willing to do so. Cheers Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From briandee at mail.weber.edu Tue Nov 4 19:03:08 2003 From: briandee at mail.weber.edu (Brian Dee) Date: Tue, 04 Nov 2003 12:03:08 -0700 Subject: Question about development languages In-Reply-To: <1067965003.22828.12.camel@bfox.devel.redhat.com> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <1067958915.2129.4.camel@support02.civic.twp.ypsilanti.mi.us> <1067965003.22828.12.camel@bfox.devel.redhat.com> Message-ID: <1067972520.23916.22.camel@Anubis> I've used Python and PyGTK to build some personal little widgets and stuff, just to learn more about the language(s). But, I've never used Glade to interface with Python. Anyone know of a good resource to learn that? I haven't been able to find any Glade/Python tutorials out there with google. I read through some of the source for redhat-configure-packages, but I have a hard time learning by reading other people's code, I'm better with some kind of a reference. I'd also like to get involved with them more in this project. I read about a cron/at scheduler idea going around. Is that still out there? Let me know!! I'd love to "get my feet wet"!!! : ) On Tue, 2003-11-04 at 09:56, Brent Fox wrote: > On Tue, 2003-11-04 at 10:15, Sean Middleditch wrote: > > > Agreed. I wrote a fully functional networked GUI app in a couple hours > > w/ Python and PyGTK the other week, and I've never made a GUI before, > > and haven't used Python in *years*. Picking up Python and GTK+ is as > > simple as it can possibly get. > > For more complicated GUIs, Glade can help you build the interfaces. For > simpler UIs, I do them by hand. But for programs like > redhat-config-kickstart which have tons of widgets, Glade really saves a > lot of time. Creating all that widget code by hand would have been > tedious and would have really increased the line count. > > I feel that Python has a great deal of untapped potential. Wrapping a > decent IDE around Python and using something like Glade for the UI > builder would give us an open source equivalent to Visual Basic. It > would provide a rapid application development environment for Windows > developers looking to migrate to Linux. > > Maybe Eclipse has something for Python; I'll have to check. > > > Cheers, > Brent > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kworthington at linuxmail.org Tue Nov 4 19:07:50 2003 From: kworthington at linuxmail.org (Kevin Worthington) Date: Tue, 04 Nov 2003 14:07:50 -0500 Subject: A presentation Message-ID: <20031104190750.21090.qmail@linuxmail.org> > My main machine is now a hush mini-ITX Epia-M machine. I hope to sell > these machines with a Linux desktop installed (DVD playback is my > current battle). To get DVD playback, go to http://freshrpms.net Matthias has all the necessary codecs and packages there to watch DVDs. HTH, Kev --- Kevin Worthington - Faithful Red Hat Linux user since April 1998 Registered Linux User #218689 - http://counter.li.org -- ______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze From elanthis at awesomeplay.com Tue Nov 4 19:18:07 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 04 Nov 2003 14:18:07 -0500 Subject: Question about development languages In-Reply-To: <1067972520.23916.22.camel@Anubis> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <1067958915.2129.4.camel@support02.civic.twp.ypsilanti.mi.us> <1067965003.22828.12.camel@bfox.devel.redhat.com> <1067972520.23916.22.camel@Anubis> Message-ID: <1067973487.2640.17.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2003-11-04 at 14:03, Brian Dee wrote: > I've used Python and PyGTK to build some personal little widgets and > stuff, just to learn more about the language(s). But, I've never used > Glade to interface with Python. Anyone know of a good resource to > learn that? I haven't been able to find any Glade/Python tutorials out > there with google. I read through some of the source for > redhat-configure-packages, but I have a hard time learning by reading > other people's code, I'm better with some kind of a reference. I'd > also like to get involved with them more in this project. I read about > a cron/at scheduler idea going around. Is that still out there? Let me > know!! I'd love to "get my feet wet"!!! : ) It's dead simple, really. This is probably the wrong list to discuss it on, tho. Really, all you need to do is something like widgets = gtk.glade.XML('myproject.glade') And then you can look up any widget in the system using the ID you provided in glade, using something like my_button = widgets.get_widget('my_button') The my_button var would then be a reference to the actual GTK widget that you can manipulate just like normal. That's really all there is to using Glade w/ Python, if you are already familiar w/ PyGTK. > > On Tue, 2003-11-04 at 09:56, Brent Fox wrote: > > On Tue, 2003-11-04 at 10:15, Sean Middleditch wrote: > > > > > Agreed. I wrote a fully functional networked GUI app in a couple hours > > > w/ Python and PyGTK the other week, and I've never made a GUI before, > > > and haven't used Python in *years*. Picking up Python and GTK+ is as > > > simple as it can possibly get. > > > > For more complicated GUIs, Glade can help you build the interfaces. For > > simpler UIs, I do them by hand. But for programs like > > redhat-config-kickstart which have tons of widgets, Glade really saves a > > lot of time. Creating all that widget code by hand would have been > > tedious and would have really increased the line count. > > > > I feel that Python has a great deal of untapped potential. Wrapping a > > decent IDE around Python and using something like Glade for the UI > > builder would give us an open source equivalent to Visual Basic. It > > would provide a rapid application development environment for Windows > > developers looking to migrate to Linux. > > > > Maybe Eclipse has something for Python; I'll have to check. > > > > > > Cheers, > > Brent > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From anthony at safferconsulting.com Tue Nov 4 21:18:02 2003 From: anthony at safferconsulting.com (Anthony Saffer) Date: Tue, 4 Nov 2003 13:18:02 -0800 Subject: Software Installation Question Message-ID: <016301c3a319$227f8c00$49f4ac41@k4h8f5> Hello Again Everyone, I've decided to go ahead and write a cron/at GUI scheduler in Perl/Tk. While I know that it might not making into the distribution, I still could offer it as an alternative to the one that does make it in. Since I've never developed software for Linux before (aside from a few C programs that I controlled where things went) I'm not sure how to handle installation. Let's say someone downloads my program (presumably contained in one Perl file) do THEY decide where to place it or is this something I need to provide an installer script for? Thanks! Anthony Saffer ======================================= SCS Consulting Services Professional Software and Website Development Affordable Webhosting also Available Visit: http://www.safferconsulting.com ======================================= From elanthis at awesomeplay.com Tue Nov 4 19:31:05 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 04 Nov 2003 14:31:05 -0500 Subject: Software Installation Question In-Reply-To: <016301c3a319$227f8c00$49f4ac41@k4h8f5> References: <016301c3a319$227f8c00$49f4ac41@k4h8f5> Message-ID: <1067974265.2640.19.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2003-11-04 at 16:18, Anthony Saffer wrote: > Hello Again Everyone, > > I've decided to go ahead and write a cron/at GUI scheduler in Perl/Tk. While > I know that it might not making into the distribution, I still could offer > it as an alternative to the one that does make it in. Since I've never > developed software for Linux before (aside from a few C programs that I > controlled where things went) I'm not sure how to handle installation. Let's > say someone downloads my program (presumably contained in one Perl file) do > THEY decide where to place it or is this something I need to provide an > installer script for? You make an RPM. You'd also want to make a .desktop file to install, so users can find the app in the menus, and not have to hunt around in a terminal to launch it. (if they wanted to hunt around in terminals, they wouldn't be using GUIs now, would they? ;-) > > Thanks! > Anthony Saffer > > ======================================= > SCS Consulting Services > Professional Software and Website Development > Affordable Webhosting also Available > Visit: http://www.safferconsulting.com > ======================================= > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From bfox at redhat.com Tue Nov 4 19:29:09 2003 From: bfox at redhat.com (Brent Fox) Date: Tue, 04 Nov 2003 14:29:09 -0500 Subject: Question about development languages In-Reply-To: <1067972520.23916.22.camel@Anubis> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <1067958915.2129.4.camel@support02.civic.twp.ypsilanti.mi.us> <1067965003.22828.12.camel@bfox.devel.redhat.com> <1067972520.23916.22.camel@Anubis> Message-ID: <1067974149.22828.81.camel@bfox.devel.redhat.com> On Tue, 2003-11-04 at 14:03, Brian Dee wrote: > I've used Python and PyGTK to build some personal little widgets and > stuff, just to learn more about the language(s). But, I've never used > Glade to interface with Python. Anyone know of a good resource to > learn that? I haven't been able to find any Glade/Python tutorials out > there with google. I read through some of the source for > redhat-configure-packages, but I have a hard time learning by reading > other people's code, I'm better with some kind of a reference. I'd > also like to get involved with them more in this project. I read about > a cron/at scheduler idea going around. Is that still out there? Let me > know!! I'd love to "get my feet wet"!!! : ) For a drop-dead simple example of a pygtk program, look at ftp://people.redhat.com/bfox/sample-glade-program.tar. Uncompress the tar file and then cd into the template/ directory. Then run './template.py' to execute the program. template.glade is the XML file that glade creates. In order to change this UI, open this file with Glade. mainWindow.py contains the Python code. The "xml.get_widget()" calls show how to retrieve the GTK widgets from the XML file so that you can then reference them from inside your Python code. Cheers, Brent From moe at blagblagblag.org Tue Nov 4 20:48:21 2003 From: moe at blagblagblag.org (moe) Date: Tue, 4 Nov 2003 13:48:21 -0700 Subject: Setting Default Theme Message-ID: <200311041348.21284.moe@blagblagblag.org> I'm working up the mailing list food chain for an answer to this as I haven't been able to figure it out... What file contains the default system theme? I mean, when you add a new user, they get that theme automatically instead of Bluecurve. I've changed a number of files, but they don't do the trick: /etc/gtk-2.0/gtkrc /etc/skel/.gtkrc /etc/gconf/schemas/desktop_gnome_interface.schemas /etc/gconf/schemas/metacity.schemas /usr/share/themes/Default/gtk/gtkrc I have heard a couple of suggestions on ways to try to get around it (e.g. drop some other files in /etc/skel), but I want to do it the redhat/fedora way. Somehow, somewhere ya'll set the theme--where does it hide? :) Anyone? Thanks, -Jeff From hp at redhat.com Tue Nov 4 20:56:31 2003 From: hp at redhat.com (Havoc Pennington) Date: Tue, 04 Nov 2003 15:56:31 -0500 Subject: Question about development languages In-Reply-To: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> Message-ID: <1067979391.4179.70.camel@localhost.localdomain> On Tue, 2003-11-04 at 03:47, Anthony Saffer wrote: > I was browsing the Fedora website and noticed that the configuration tools > are said to be all Python based with a few PyGTK ones. I don't know Python > at all but am very familiar with Perl and PerlTk. Do the tools HAVE to be > written in Python or are other languages acceptable? Tk is unacceptable, it has to be a modern toolkit. Perl is maybe acceptable (others may disagree) but my concern would be more with Perl/GTK bindings, I'm not sure what their status is. The pygtk bindings do require a fair bit of "babysitting" to keep in a good state. Havoc From johnsonm at redhat.com Tue Nov 4 21:14:35 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 4 Nov 2003 16:14:35 -0500 Subject: Question about development languages In-Reply-To: <1067979391.4179.70.camel@localhost.localdomain>; from hp@redhat.com on Tue, Nov 04, 2003 at 03:56:31PM -0500 References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <1067979391.4179.70.camel@localhost.localdomain> Message-ID: <20031104161435.A17581@devserv.devel.redhat.com> On Tue, Nov 04, 2003 at 03:56:31PM -0500, Havoc Pennington wrote: > Tk is unacceptable[...] Let me fill in the missing piece: for config tools in Fedora Core. Fedora Extras and Alternatives have different requirements. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From carwyn at carwyn.com Tue Nov 4 21:38:44 2003 From: carwyn at carwyn.com (Carwyn Edwards) Date: Tue, 04 Nov 2003 21:38:44 +0000 Subject: A presentation In-Reply-To: <20031104190750.21090.qmail@linuxmail.org> References: <20031104190750.21090.qmail@linuxmail.org> Message-ID: <3FA81C64.20004@carwyn.com> Kevin Worthington wrote: >>My main machine is now a hush mini-ITX Epia-M machine. I hope to sell >>these machines with a Linux desktop installed (DVD playback is my >>current battle). >> >> >To get DVD playback, go to http://freshrpms.net >Matthias has all the necessary codecs and packages there to watch DVDs. > > http://forums.viaarena.com/ is the place to look in the OS Arena -> Linux Arena area Actaully, skimming them just now : http://www3.sympatico.ca/howlettfamily/epia/epia.html .. seems like the best place to start. Carwyn From johnsonm at redhat.com Tue Nov 4 21:59:52 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 4 Nov 2003 16:59:52 -0500 Subject: RH recommends using Windows? plus a Question! In-Reply-To: ; from nsilva-list@aoi.atari-source.com on Tue, Nov 04, 2003 at 02:32:45PM -0500 References: <3FA7F935.4050705@atl.lmco.com> Message-ID: <20031104165952.B30342@devserv.devel.redhat.com> On Tue, Nov 04, 2003 at 02:32:45PM -0500, Noah Silva [Mailing list] wrote: > But, like mandrake's, it is woefully lacking. One thing I want to see happen is a self-service hardware compatibility service that makes it easy for users to provide information on the compatibility they are seeing with their hardware on Fedora, and for which the information is well-enough organized that you can actually have good searches for that information. My basic concept is that there's a lot of information on the system that you can get at with tools like lspci and dmidecode. Parse that into units of hardware and present the user a GUI that lets them make some easy assignments for how well things work (default is "don't know" in order to avoid garbage) with definitions for the levels, and places for comments for each piece of hardware. Then this data is uploaded (signed with the user's gpg key?) in a structured, parseable format (xml?) to a centralized database that is both downloadable and web-searchable. Any volunteers? :-) (I'm cc'ing the devel list because I've noticed several people looking for projects lately -- here's a candidate. If you are interested, start the discussion, but I suggest keeping it on fedora-devel-list since fedora-test-list is high-enough traffic as it is...) michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From jfm512 at free.fr Tue Nov 4 22:18:01 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 04 Nov 2003 23:18:01 +0100 Subject: Question about development languages In-Reply-To: References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> Message-ID: <1067984281.1146.13.camel@agnes.fremen.dune> Humm, ever tried to read a shell script exceeding a few dozens of lines? Nearly by definition, shell languages are oriented far more toward interactive use than for even moderately sophisticated programming tasks (and still more inadequate if the script is not "Use and throw" but is supposed to be maintained). On Tue, 2003-11-04 at 14:23, Behdad Esfahbod wrote: > On Tue, 4 Nov 2003, Eric S. Raymond wrote: > > > Michael K. Johnson : > > > Hmm, it's my opinion that anyone able to learn Perl would find Python > > > trivial, but I guess that's just an opinion. My experience, though, > > > is that I was pretty normal in being able to write maintainable Python > > > code the first day I started learning it -- I've heard the same from > > > lots of other people. > > > > > > The real challenge here is probably not moving from Perl to Python, > > > but rather moving from Tk to GTK. > > > > I've had experience with this kind of migration. Agreed on both counts. > > One thing I found about Python is that it's quite easy to write > Python code on the first day, and it's the best choice for GUI > apps. But it's by no means a good replacement for sophisticated > shell scripts. (correct me if I'm wrong). > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jean Francois Martinez From jspaleta at princeton.edu Tue Nov 4 22:30:32 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 04 Nov 2003 17:30:32 -0500 Subject: RH recommends using Windows? plus a Question! Message-ID: <1067985032.15706.93.camel@spatula> Michael K. Johnson wrote: > My basic concept is that there's a lot of information on the system > that you can get at with tools like lspci and dmidecode. Parse that > into units of hardware and present the user a GUI that lets them > make some easy assignments for how well things work (default is > "don't know" in order to avoid garbage) with definitions for the > levels, and places for comments for each piece of hardware. Then > this data is uploaded (signed with the user's gpg key?) in a > structured, parseable format (xml?) to a centralized database that > is both downloadable and web-searchable. Hmm well lets see...what other things have a model like this...freedb. Maybe there are lessons to be learned from freedb. Some hard issues though for me... Even if you do have people sign their specs with gpg...how do you really know who's key's to trust. And how do you deal with conflicting reports. I'd imagine certain popular off the shelf groups of hardware will have a lot of reports...a lot of conflicting reports (depending on several factors of the user's particular experience level). can't really limit this sort of thing to a few trusted individuals..yer going to need a wide range of people with a wide range of hardware for this to be useful. And, how do you make sure the hardware database takes into account specific hardware conflicts...not just broken hardware...but specific issues with specific combinations of hardware. Seems to me this sort of thing almost ends up being a specifically tasked rework of bugzilla in a way....but with a mature way to cross reference conflicting hardware reports that crop up. So that people can do queries on a grouping of hardware so they can see if there are specific incompatibilities when certain hardware is used together. So maybe video card A works with motherboard 1 seamlessly...but not with motherboard 2...having a way to query not just a piece of hardware and see all known comments for it...but a way to query specific groupings of hardware to narrow down relevant reports. -jef"this monster is going to need a bit of care and feeding...maybe even some sort of /. like moderation scheme to keep hardware comments maintained"spaleta -------------- 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 johnsonm at redhat.com Tue Nov 4 23:20:30 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 4 Nov 2003 18:20:30 -0500 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1067985032.15706.93.camel@spatula>; from jspaleta@princeton.edu on Tue, Nov 04, 2003 at 05:30:32PM -0500 References: <1067985032.15706.93.camel@spatula> Message-ID: <20031104182030.A25825@devserv.devel.redhat.com> On Tue, Nov 04, 2003 at 05:30:32PM -0500, Jef Spaleta wrote: > Even if you do have people sign their specs with gpg...how do you really know > who's key's to trust. Oh, that was just a throwaway idea, I'm not sure if it makes sense. Maybe could be optional as a kind of +1 on the provenance that people can use if they want to. > And how do you deal with conflicting reports. Probably like reviews of products/books/etc. Like at Amazon, a book gets, say, 3.5 stars with 10. So you read the comments and correlate the clue level of the comment with the number of stars provided by the reviewer. The more reporters, the more you can trust the report. > I'd imagine > certain popular off the shelf groups of hardware will have a lot of > reports...a lot of conflicting reports (depending on several factors of > the user's particular experience level). can't really limit this sort of > thing to a few trusted individuals..yer going to need a wide range of > people with a wide range of hardware for this to be useful. Absolutely! That's why it's got to be EASY to get good information or there's not much point in doing it. I'd run it myself if it took less than 10 minutes, and I know I'd never get around to it if it took 20. > And, how do you make sure the hardware database takes into account > specific hardware conflicts...not just broken hardware...but specific > issues with specific combinations of hardware. The entire report has to be available whenever part of it is being presented. Say you are searching for video card foo. It has average rating bar. You want to look into this more, so you click on "read all reports" Reports that look interesting, you click on "see hardware" and you have the entire hardware database for the machine (we probably shouldn't include things like tag ids from dmidecode :-) and you can see what the context is. Some main things (say motherboard version, running kernel version, that type of thing) can be displayed in short form with the review. Then, if you really want to get fancy, you add the ability to add comments to individual reports. You happen to know that the reason the video card foo didn't work on that system is that there's a conflict with bios version J.UNK on that particular motherboard. So you post a annotation to that effect. If you want to get really fancy, you do an advogato-like voting structure so that consistently clueful reporters have their ratings weighted higher in producing the averages. > -jef"this monster is going to need a bit of care and feeding...maybe > even some sort of /. like moderation scheme to keep hardware comments > maintained"spaleta Absolutely, though I'd think that advogato or a combination of /. and advogato voting systems for different parts (/. for individual reports, advogato for reporters?) would make sense. Anyway, it's clearly a lot of work, and I don't want to minimize that. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From julo at altern.org Tue Nov 4 23:35:18 2003 From: julo at altern.org (Julien Olivier) Date: Tue, 04 Nov 2003 23:35:18 +0000 Subject: Question about development languages In-Reply-To: <1067979391.4179.70.camel@localhost.localdomain> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <1067979391.4179.70.camel@localhost.localdomain> Message-ID: <1067988918.3470.4.camel@localhost.localdomain> On Tue, 2003-11-04 at 20:56, Havoc Pennington wrote: > On Tue, 2003-11-04 at 03:47, Anthony Saffer wrote: > > I was browsing the Fedora website and noticed that the configuration tools > > are said to be all Python based with a few PyGTK ones. I don't know Python > > at all but am very familiar with Perl and PerlTk. Do the tools HAVE to be > > written in Python or are other languages acceptable? > > Tk is unacceptable, it has to be a modern toolkit. Perl is maybe > acceptable (others may disagree) but my concern would be more with > Perl/GTK bindings, I'm not sure what their status is. The pygtk bindings > do require a fair bit of "babysitting" to keep in a good state. > What about bash/zenity ? I have never tried to do anything with this combination though. > Havoc > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Julien Olivier From julo at altern.org Tue Nov 4 23:52:19 2003 From: julo at altern.org (Julien Olivier) Date: Tue, 04 Nov 2003 23:52:19 +0000 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <20031104165952.B30342@devserv.devel.redhat.com> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> Message-ID: <1067989938.3470.17.camel@localhost.localdomain> On Tue, 2003-11-04 at 21:59, Michael K. Johnson wrote: > On Tue, Nov 04, 2003 at 02:32:45PM -0500, Noah Silva [Mailing list] wrote: > > But, like mandrake's, it is woefully lacking. > > One thing I want to see happen is a self-service hardware compatibility > service that makes it easy for users to provide information on the > compatibility they are seeing with their hardware on Fedora, and for > which the information is well-enough organized that you can actually > have good searches for that information. > > My basic concept is that there's a lot of information on the system > that you can get at with tools like lspci and dmidecode. Parse that > into units of hardware and present the user a GUI that lets them > make some easy assignments for how well things work (default is > "don't know" in order to avoid garbage) with definitions for the > levels, and places for comments for each piece of hardware. Then > this data is uploaded (signed with the user's gpg key?) in a > structured, parseable format (xml?) to a centralized database that > is both downloadable and web-searchable. > > Any volunteers? :-) > I could be interested but I'm just wondering: why not use a web form to fetch those information ? Isn't it easier to create a simple form in PHP on redhat's website than create a GUI app ? Users will need an internet connection to validate their form anyway, so I don't see the point to have a desktop app. But maybe I'm missing something... > (I'm cc'ing the devel list because I've noticed several people looking > for projects lately -- here's a candidate. If you are interested, > start the discussion, but I suggest keeping it on fedora-devel-list > since fedora-test-list is high-enough traffic as it is...) > > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Julien Olivier From otaylor at redhat.com Wed Nov 5 00:03:37 2003 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 04 Nov 2003 19:03:37 -0500 Subject: Setting Default Theme In-Reply-To: <200311041348.21284.moe@blagblagblag.org> References: <200311041348.21284.moe@blagblagblag.org> Message-ID: <1067990617.11271.1033.camel@poincare.devel.redhat.com> On Tue, 2003-11-04 at 15:48, moe wrote: > I'm working up the mailing list food chain for an answer to this as I haven't > been able to figure it out... > > What file contains the default system theme? I mean, when you add a new user, > they get that theme automatically instead of Bluecurve. > > I've changed a number of files, but they don't do the trick: > /etc/gtk-2.0/gtkrc > /etc/skel/.gtkrc > /etc/gconf/schemas/desktop_gnome_interface.schemas > /etc/gconf/schemas/metacity.schemas > /usr/share/themes/Default/gtk/gtkrc > > I have heard a couple of suggestions on ways to try to get around it (e.g. > drop some other files in /etc/skel), but I want to do it the redhat/fedora > way. Somehow, somewhere ya'll set the theme--where does it hide? :) http://mail.gnome.org/mailman/listinfo/gnome-redhat-list/ would be the right venue for this. You need to set the three GConf keys (use gconftool-2 with the appropriate settings, don't edit files by hand .. see the gnome-sysadmin guide) /desktop/gnome/interface/gtk_theme /desktop/gnome/interface/icon_theme /apps/metacity/general/theme Regards, Owen From johnsonm at redhat.com Wed Nov 5 00:04:59 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 4 Nov 2003 19:04:59 -0500 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1067989938.3470.17.camel@localhost.localdomain>; from julo@altern.org on Tue, Nov 04, 2003 at 11:52:19PM +0000 References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> Message-ID: <20031104190459.A15665@devserv.devel.redhat.com> On Tue, Nov 04, 2003 at 11:52:19PM +0000, Julien Olivier wrote: > I could be interested but I'm just wondering: why not use a web form to > fetch those information ? Isn't it easier to create a simple form in PHP > on redhat's website than create a GUI app ? Users will need an internet > connection to validate their form anyway, so I don't see the point to > have a desktop app. But maybe I'm missing something... Your idea is "run this text application to create a file which you then POST to a web site and it then provides you with web forms to fill in" -- do I understand right? My reasons for a GUI application: o Seems easier for the novice user to select one "report my hardware" icon from a menu than run a text program, then go through several web pages to upload it and fill out forms about it. This is really three points: Easier to find, fewer steps to completion, and perhaps it might be possible to make the interface a bit smarter. o Could conceivably do queries based on user input (this is vague) and users could intentionally limit the hardware they report (like if they don't want to publish to the whole world that they have a $50,000 computer sitting in their basement or they have hardware under NDA that they are required not to talk about and really don't ever want that information going out of their network. But that doesn't mean it's the only way this could work, I'm just sharing my vision... michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From jspaleta at princeton.edu Wed Nov 5 00:05:38 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 04 Nov 2003 19:05:38 -0500 Subject: RH recommends using Windows? plus a Question! Message-ID: <1067990738.15706.126.camel@spatula> Michael K. Johnson wrote: > Say you are searching for video card foo. It has average rating bar. > You want to look into this more, so you click on "read all reports" > Reports that look interesting, you click on "see hardware" and you > have the entire hardware database for the machine (we probably > shouldn't include things like tag ids from dmidecode :-) and you > can see what the context is. Some main things (say motherboard > version, running kernel version, that type of thing) can be displayed > in short form with the review. Well i was thinking take it a step further down the fancy metric...and allow people to specify a few core components in one query and have crossed referenced reports pop up in a most/least relevant listing. I'd imagine there will be a metric crapload of reports for certain video cards. Being able to narrow down by picking your mobo and maybe even your monitor could help sort the initial list of reports you are going to pull up, just by bringing any relevant mobo/card issues up to the top. > Then, if you really want to get fancy, you add the ability to add > comments to individual reports. You happen to know that the reason > the video card foo didn't work on that system is that there's a > conflict with bios version J.UNK on that particular motherboard. > So you post a annotation to that effect. Hmm..is it wise to make it point and click easy to list brokenness in a hardware database that is completely seperate from bugzilla? I'd really hate to lose useful bugreports to comments in the hardware database and make developers have to troll the hardware reviews as well to find out if a piece of hardware has a problem. A review based hardware database makes some sense as an end-user tool for people choosing hardware to use, but i don't know if it makes sense as a tool for developers to keep track of specific hardware issues...and i'd hate to see review comments become the prefered end-user way to report problems...but have bugzilla be the preferred developer way to track problems. > If you want to get really fancy, you do an advogato-like voting > structure so that consistently clueful reporters have their > ratings weighted higher in producing the averages. Well i vote for mocking up the forum side of this with a pre-existing forum codebase if at all possible. A specially crafted advogato reporter client to script the hardware reports to submit would be simple for someone to bootstrap together i would imagine. But would a stock advogato forum provide enough initial usefulness as a target forum platform to play with? Is linux-usb.org device database a useful example of this sort of thing minus the advogato ranking system? http://www.qbik.ch/usb/devices/ -jef"just looking for a good pre-existing starting point"spaleta -------------- 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 spamfrommailing at freax.org Wed Nov 5 00:15:37 2003 From: spamfrommailing at freax.org (Philip Van Hoof) Date: Wed, 05 Nov 2003 01:15:37 +0100 Subject: A dhcpd.conf GUI Message-ID: <1067991336.2154.121.camel@pluisje> Hi there, Three days ago I was reading the fedora webpages, two days ago I started giving some lessions to two of my friends in Gtk-Sharp and C#. Because while I was reading the fedora webpages I noticed that fedora is looking for a dhcpd.conf GUI, it gave me the idea to implement this using Gtk- Sharp and use it for educating those two friends of mine. So I asked my "students" to create a GUI and created the parser myself. The first lession was Gtk-Sharp using Glade-Sharp and also glade-2. The second lession was Exception handing, recursive function calls, Regular Expressions, etc etc. So, again, I figured that a "dhcpd.conf"-file parser in C# would be a great way to explain such stuff :). But they would probably not yet succeed in getting stuff working yet. So I made it as a sample for them, so they can study it. Of course is stuff pretty much unfinished but we have decided to go ahead and finish the complete application at some point ;). Something like: Just for Fun, and because that way those two friends have a pretty good way of learning how to write a Gtk-Sharp application: They learn by writing a real one from scratch. I understand that fedora is probably not yet shipping with Mono nor Gtk- Sharp. So it's possible that such a GUI cannot be used (yet). Nevertheless I want to share it with you guys. That way you can decide what you want to do with it. The die-hard python gods will probably want to port it to python, the die-hard C gods will probably want to port it to plain C and the perl monks will probably want to create 600 versions of this application which will all use another method of solving the problem. Probably will 599 versions use perl regular expressions and 1 version will most likely be never understandable by anybody else than Larry Wall and the original coder of it. And I say to them: go ahead :). ps. It's also very possible that just nothing will happen at all. Also good. Yet, we (because, me too) are learning while programming this application. So don't kill us for trying to write it. In case you dislike it, we are not doing it for _you_ anyway. The Class1.cs is a Console application that will actually parse a dhcpd. conf file into a few classes (build up in a recursive tree-way). It also prints some values... for testing. It's not yet integrated with a Gtk- Sharp GUI (and my students/two friends are still working on the Gtk- Sharp/Glade-Sharp GUI code). The attached .glade file is highly unfinished and just a tryout, actually. It (should) look a lot like the redhat-config-samba tool. Please do let me know what you think of it. Do fix crab and bugs if thats what you want to do. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org work: Philip dot VanHoof at cronos dot be http://www.freax.be, http://www.freax.eu.org -------------- next part -------------- using System; using System.IO; using System.Text.RegularExpressions; using System.Collections; namespace ConfParser { public class CommonConfig { public ArrayList Allow = new ArrayList(); public ArrayList Deny = new ArrayList(); public Hashtable Options = new Hashtable(); public ArrayList SubnetConfigs = new ArrayList(); public ArrayList HostConfigs = new ArrayList(); public ArrayList GroupConfigs = new ArrayList(); public ArrayList SharedNetworkConfigs = new ArrayList(); public string DefaultLeaseTime; public string MaxLeaseTime; public string Hardware; public string FileName; public string ServerName; public string NextServer; public string FixedAddress; public string DynamicBootpLeaseCutoff; public string DynamicBootpLeaseLength; public string GetLeaseHostnames; public string UseHostDeclNames; public string Authoritative; public string UseLeaseAddrForDefaultRoute; public string AlwaysReplyRfc1048; public string ServerIdentifier; private Regex GetLeaseHostnamesRegex = new Regex(@"get-lease-hostnames\s(.*);$"); private Regex UseHostDeclNamesRegex = new Regex(@"use-host-decl-names\s(.*);$"); private Regex AuthoritativeRegex = new Regex(@"([not\s|])authoritative;$"); private Regex UseLeaseAddrForDefaultRouteRegex = new Regex(@"use-lease-addr-for-default-route\s(.*);$"); private Regex AlwaysReplyRfc1048Regex = new Regex(@"always-reply-rfc1048\s(.*);$"); private Regex ServerIdentifierRegex = new Regex(@"server-identifier\s(.*);$"); private Regex NextServerRegex = new Regex(@"next-server\s(.*);$"); private Regex FixedAddressRegex = new Regex(@"fixed-address address\s(.*);$"); private Regex DynamicBootpLeaseCutoffRegex = new Regex(@"dynamic-bootp-lease-cutoff\s(.*);$"); private Regex DynamicBootpLeaseLengthRegex = new Regex(@"dynamic-bootp-lease-length\s(.*);$"); private Regex HardwareRegex = new Regex(@"hardware\s(.*);$"); private Regex FileNameRegex = new Regex("filename\\s\"(.*)\";$"); private Regex ServerNameRegex = new Regex("server-name\\s\"(.*)\";$"); private Regex DefaultLeaseTimeRegex = new Regex(@"default-lease-time\s(.*);$"); private Regex MaxLeaseTimeRegex = new Regex(@"max-lease-time\s(.*);$"); private Regex OptionRegex = new Regex("option\\s(.*)\\s(\"?)(.*)(\"?);$"); private Regex AllowRegex = new Regex(@"allow\s(.*);$"); private Regex DenyRegex = new Regex(@"deny\s(.*);$"); private bool ParseGetLeaseHostnames (string line) { return ParseParameter (line, ref GetLeaseHostnames, GetLeaseHostnamesRegex); } private bool ParseUseHostDeclNames (string line) { return ParseParameter (line, ref UseHostDeclNames, UseHostDeclNamesRegex); } private bool ParseAuthoritative (string line) { return ParseParameter (line, ref Authoritative, AuthoritativeRegex); } private bool ParseUseLeaseAddrForDefaultRoute (string line) { return ParseParameter (line, ref UseLeaseAddrForDefaultRoute, UseLeaseAddrForDefaultRouteRegex); } private bool ParseAlwaysReplyRfc1048 (string line) { return ParseParameter (line, ref AlwaysReplyRfc1048, AlwaysReplyRfc1048Regex); } private bool ParseServerIdentifier (string line) { return ParseParameter (line, ref ServerIdentifier, ServerIdentifierRegex); } private bool ParseNextServer (string line) { return ParseParameter (line, ref NextServer, NextServerRegex); } private bool ParseFixedAddress (string line) { return ParseParameter (line, ref FixedAddress, FixedAddressRegex); } private bool ParseDynamicBootpLeaseCutoff (string line) { return ParseParameter (line, ref DynamicBootpLeaseCutoff, DynamicBootpLeaseCutoffRegex); } private bool ParseDynamicBootpLeaseLength (string line) { return ParseParameter (line, ref DynamicBootpLeaseLength, DynamicBootpLeaseLengthRegex); } private bool ParseHardware (string line) { return ParseParameter (line, ref Hardware, HardwareRegex); } private bool ParseFileName (string line) { return ParseParameter (line, ref FileName, FileNameRegex); } private bool ParseServerName (string line) { return ParseParameter (line, ref ServerName, ServerNameRegex); } private bool ParseMaxLeaseTime (string line) { return ParseParameter (line, ref MaxLeaseTime, MaxLeaseTimeRegex); } private bool ParseDefaultLeaseTime (string line) { return ParseParameter (line, ref DefaultLeaseTime, DefaultLeaseTimeRegex); } private bool ParseParameter (string line, ref string result, Regex regex) { Match m = regex.Match(line); if (m.Success) { m.NextMatch(); result = m.Groups[1].Value; return true; } return false; } private bool ParseOption (string line) { Match m = OptionRegex.Match(line); if (m.Success) { m.NextMatch(); if (!this.Options.Contains (m.Groups[1].Value)) this.Options.Add (m.Groups[1].Value, m.Groups[3].Value); return true; } return false; } private bool ParseAllow (string line) { Match m = AllowRegex.Match (line); if (m.Success) { m.NextMatch(); this.Allow.Add (m.Groups[0].Value); return true; } return false; } private bool ParseDeny (string line) { Match m = DenyRegex.Match (line); if (m.Success) { m.NextMatch(); this.Deny.Add (m.Groups[0].Value); return true; } return false; } public void ParseAnyConfigAndReturn (StreamReader sr, string line) { try { SubnetConfig subnetconfig = SubnetConfig.Parse (sr, line); this.SubnetConfigs.Add (subnetconfig); return; } catch (NotSubnetConfigException) {} try { HostConfig hostconfig = HostConfig.Parse (sr, line); this.HostConfigs.Add (hostconfig); return; } catch (NotHostConfigException) {} try { GroupConfig groupconfig = GroupConfig.Parse (sr, line); this.GroupConfigs.Add (groupconfig); return; } catch (NotGroupConfigException) {} try { SharedNetwork sconfig = SharedNetwork.Parse(sr, line); this.SharedNetworkConfigs.Add (sconfig); return; } catch (NotSharedNetworkConfigException) {} } public void ParseAnySingleLineAndReturn (string line) { if (this.ParseDefaultLeaseTime (line)) return; if (this.ParseMaxLeaseTime (line)) return; if (this.ParseHardware (line)) return; if (this.ParseFileName (line)) return; if (this.ParseServerName (line)) return; if (this.ParseNextServer (line)) return; if (this.ParseFixedAddress (line)) return; if (this.ParseDynamicBootpLeaseCutoff (line)) return; if (this.ParseDynamicBootpLeaseLength (line)) return; if (this.ParseGetLeaseHostnames (line)) return; if (this.ParseUseHostDeclNames (line)) return; if (this.ParseAuthoritative (line)) return; if (this.ParseUseLeaseAddrForDefaultRoute (line)) return; if (this.ParseAlwaysReplyRfc1048 (line)) return; if (this.ParseServerIdentifier (line)) return; if (this.ParseOption (line)) return; if (this.ParseAllow (line)) return; if (this.ParseDeny (line)) return; } public virtual void ParseBody (StreamReader sr) { bool KeepGoing = true; string line; if ((line = sr.ReadLine ()) == null) throw new FormatException ("Unexpected end of file"); int begin=line.IndexOf ('{'), end=-1; if (begin != -1) line = line.Substring (begin+1, line.Length); while (KeepGoing) { end = line.IndexOf ('}'); if (end != -1) { if (end == 0) line = ""; else line = line.Substring (0, end-1); KeepGoing = false; } this.ParseAnySingleLineAndReturn (line); this.ParseAnyConfigAndReturn (sr, line); if (end == -1) { if ((line = sr.ReadLine ()) == null) throw new FormatException ("Unexpected end of file"); } } } #region doc // allow unknown-clients; // deny unknown-clients; // allow bootp; // deny bootp; // allow booting; // deny booting; // [parameters] // default-lease-time time; // max-lease-time time; // hardware hardware-type hardware-address; // filename "filename"; // server-name "name"; // next-server server-name; // fixed-address address [, address ... ]; // dynamic-bootp-lease-cutoff date; // dynamic-bootp-lease-length length; // get-lease-hostnames flag; // use-host-decl-names flag; // authoritative; // [not ]authoritative; // use-lease-addr-for-default-route flag; // always-reply-rfc1048 flag; // server-identifier hostname; #endregion #region doc // [options] // option all-subnets-local flag; // option arp-cache-timeout uint32; // option bootfile-name text; // option boot-size uint16; // option broadcast-address ip-address; // option cookie-servers ip-address [, ip-address... ]; // option default-ip-ttl uint8; // option default-tcp-ttl uint8; // option dhcp-client-identifier string; // option dhcp-lease-time uint32; // option dhcp-max-message-size uint16; // option dhcp-message text; // option dhcp-message-type uint8; // option dhcp-parameter-request-list uint16; // option dhcp-option-overload uint8; // option dhcp-rebinding-time uint32; // option dhcp-renewal-time uint32; // option dhcp-requested-address ip-address; // option dhcp-server-identifier ip-address; // option domain-name text; // option domain-name-servers ip-address [, ip-address... ]; // option extensions-path text; // option finger-server ip-address [, ip-address... ]; // option font-servers ip-address [, ip-address... ]; // option host-name string; // option ieee802-3-encapsulation flag; // option ien116-name-servers ip-address [, ip-address... ]; // option impress-servers ip-address [, ip-address... ]; // option interface-mtu uint16; // option ip-forwarding flag; // option irc-server ip-address [, ip-address... ]; // option log-servers ip-address [, ip-address... ]; // option lpr-servers ip-address [, ip-address... ]; // option mask-supplier flag; // option max-dgram-reassembly uint16; // option merit-dump text; // option mobile-ip-home-agent ip-address [, ip-address... ]; // option nds-context string; // option nds-servers ip-address [, ip-address... ]; // option nds-tree-name string; // option netbios-dd-server ip-address [, ip-address... ]; // option netbios-name-servers ip-address [, ip-address...]; // option netbios-node-type uint8; // Possible node types are: // 1 B-node: Broadcast - no WINS // 2 P-node: Peer - WINS only. // 4 M-node: Mixed - broadcast, then WINS // 8 H-node: Hybrid - WINS, then broadcast // option netbios-scope string; // option nis-domain text; // option nis-servers ip-address [, ip-address... ]; // option nisplus-domain text; // option nisplus-servers ip-address [, ip-address... ]; // option nntp-server ip-address [, ip-address... ]; // option non-local-source-routing flag; // option ntp-servers ip-address [, ip-address... ]; // option nwip-domain string; // option nwip-suboptions string; // option path-mtu-aging-timeout uint32; // option path-mtu-plateau-table uint16 [, uint16... ]; // option perform-mask-discovery flag; // option policy-filter ip-address ip-address [, ip-address ip-address...]; // option pop-server ip-address [, ip-address... ]; // option resource-location-servers ip-address [, ip-address...]; // option root-path text; // option router-discovery flag; // option router-solicitation-address ip-address; // option routers ip-address [, ip-address... ]; // option slp-directory-agent boolean ip-address [, ip-address... ]; // option slp-service-scope boolean text; // option smtp-server ip-address [, ip-address... ]; // option static-routes ip-address ip-address [, ip-address ip-address...]; // option streettalk-directory-assistance-server ip-address [, ip-address...]; // option streettalk-server ip-address [, ip-address... ]; // option subnet-mask ip-address; // option subnet-selection string; // option swap-server ip-address; // option tcp-keepalive-garbage flag; // option tcp-keepalive-interval uint32; // option tftp-server-name text; // option time-offset int32; // option time-servers ip-address [, ip-address... ]; // option trailer-encapsulation flag; // option uap-servers text; // option user-class string; // option vendor-class-identifier string; // option vendor-encapsulated-options string; // option www-server ip-address [, ip-address... ]; // option x-display-manager ip-address [, ip-address... ]; // option agent.circuit-id string; // option agent.remote-id string; // option fqdn.no-client-update flag; // option fqdn.server-update flag; // option fqdn.encoded flag; // option fqdn.rcode1 flag; // option fqdn.rcode1 flag; // option fqdn.fqdn text; // option nwip.nsq-broadcast flag; // option nwip.preferred-dss ip-address [, ip-address... ]; // option nwip.nearest-nwip-server ip-address [, ip-address...]; // option nwip.autoretries uint8; // option nwip.autoretry-secs uint8; // option nwip.nwip-1-1 uint8; // option nwip.primary-dss ip-address; // custom options // option new-name code new-code = definition ; // examples // option use-zephyr code 180 = boolean; // option use-zephyr on; // // option sql-connection-max code 192 = unsigned integer 16; // option sql-connection-max 1536; // option sql-server-address code 193 = ip-address; // option sql-server-address sql.example.com; // option sql-default-connection-name code 194 = text; // option sql-default-connection-name "PRODZA"; // // option sql-identification-token code 195 = string; // option sql-identification-token 17:23:19:a6:42:ea:99:7c:22; // option space local; // option local.demo code 1 = text; // option local-encapsulation code 197 = encapsulate local; // option local.demo "demo"; // option kerberos-servers code 200 = array of ip-address; // option kerberos-servers 10.20.10.1, 10.20.11.1; // option contrived-001 code 201 = { boolean, integer 32, text }; // option contrived-001 on 1772 "contrivance"; // option new-static-routes code 201 = array of { ip-address, ip-address, ip-address, integer 8 }; // // option static-routes // 10.0.0.0 255.255.255.0 net-0-rtr.example.com 1, // 10.0.1.0 255.255.255.0 net-1-rtr.example.com 1, // 10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3; // // option vendor-encapsulated-options // 2:4:AC:11:41:1: // 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31: // 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63; // // option space SUNW; // option SUNW.server-address code 2 = ip-address; // option SUNW.server-name code 3 = text; // option SUNW.root-path code 4 = text; // class "vendor-classes" // { // match option vendor-class-identifier; // } // // option SUNW.server-address 172.17.65.1; // option SUNW.server-name "sundhcp-server17-1"; // // subclass "vendor-classes" "SUNW.Ultra-5_10" // { // vendor-option-space SUNW; // option SUNW.root-path "/export/root/sparc"; // } // // subclass "vendor-classes" "SUNW.i86pc" // { // vendor-option-space SUNW; // option SUNW.root-path "/export/root/i86pc"; // } // // } #endregion } public class GlobalConfig : CommonConfig { public static GlobalConfig Parse (string filename) { using (StreamReader sr = new StreamReader(filename)) { return Parse (sr); } } public static GlobalConfig Parse (StreamReader sr) { bool KeepGoing = true; GlobalConfig gconfig = new GlobalConfig (); while (KeepGoing) { string line; try { if ((line = sr.ReadLine ()) == null) throw new EndOfStreamException (); gconfig.ParseAnySingleLineAndReturn (line); gconfig.ParseAnyConfigAndReturn (sr, line); } catch (EndOfStreamException) { KeepGoing = false; } } return gconfig; } } // [declarations] public class NotGroupConfigException : Exception {} public class GroupConfig : CommonConfig { public GroupConfig () { } public override void ParseBody (StreamReader sr) { base.ParseBody (sr); } // group // { // [ parameters ] // [ declarations ] // } public static GroupConfig Parse (StreamReader sr, string line) { if (line == null) throw new EndOfStreamException (); Regex r = new Regex(@"group[$|.*]"); Match m = r.Match(line); if (m.Success) { m.NextMatch(); GroupConfig gconfig = new GroupConfig (); gconfig.ParseBody (sr); return gconfig; } throw new NotGroupConfigException (); } } public class NotSharedNetworkConfigException : Exception {} public class SharedNetwork : CommonConfig { public string Name; public SharedNetwork (string Name) { this.Name = Name; } public override void ParseBody (StreamReader sr) { base.ParseBody (sr); } // shared-network name // { // [ parameters ] // [ declarations ] // } public static SharedNetwork Parse (StreamReader sr, string line) { if (line == null) throw new EndOfStreamException (); Regex r = new Regex(@"shared-network\s(.*)[$|.*]"); Match m = r.Match(line); if (m.Success) { m.NextMatch(); SharedNetwork sconfig = new SharedNetwork (m.Groups[1].Value); sconfig.ParseBody (sr); return sconfig; } throw new NotSharedNetworkConfigException (); } } public class NotHostConfigException : Exception {} public class HostConfig : CommonConfig { public string Name; public HostConfig (string Name) { this.Name = Name; } public override void ParseBody (StreamReader sr) { base.ParseBody (sr); } // host hostname // { // [ parameters ] // [ declarations ] // } public static HostConfig Parse (StreamReader sr, string line) { if (line == null) throw new EndOfStreamException (); Regex r = new Regex(@"host\s(.*)[$|.*]"); Match m = r.Match(line); if (m.Success) { m.NextMatch(); HostConfig hostconfig = new HostConfig (m.Groups[1].Value); hostconfig.ParseBody (sr); return hostconfig; } throw new NotHostConfigException (); } } public class NotSubnetConfigException : Exception {} public class SubnetConfig : CommonConfig { public string Number; public string Netmask; public SubnetConfig (string Number, string Netmask) { this.Number = Number; this.Netmask = Netmask; } public override void ParseBody (StreamReader sr) { base.ParseBody (sr); } // subnet subnet-number netmask netmask // { // [ parameters ] // [ declarations ] // } public static SubnetConfig Parse (StreamReader sr, string line) { if (line == null) throw new EndOfStreamException (); Regex r = new Regex(@"subnet\s(.*)\snetmask\s(.*)[$|.*]"); Match m = r.Match(line); if (m.Success) { m.NextMatch(); SubnetConfig subnetconfig = new SubnetConfig (m.Groups[1].Value, m.Groups[2].Value); subnetconfig.ParseBody (sr); return subnetconfig; } throw new NotSubnetConfigException (); } } /// /// Summary description for Class1. /// class Class1 { [STAThread] static void Main(string[] args) { GlobalConfig config = GlobalConfig.Parse (@"D:\Temp\dhcpd.conf"); if (config.SubnetConfigs.Count > 0) { SubnetConfig c = (SubnetConfig)config.SubnetConfigs[0]; Console.WriteLine (c.Number); Console.WriteLine (c.Netmask); IDictionaryEnumerator myenum = c.Options.GetEnumerator(); while (myenum.MoveNext()) { Console.WriteLine ("{0}={1}", myenum.Key, myenum.Value); } Console.ReadLine(); } } } } -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-config-dhcpd.glade Type: application/x-glade Size: 12509 bytes Desc: not available URL: From xose at wanadoo.es Wed Nov 5 00:59:19 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 05 Nov 2003 01:59:19 +0100 Subject: RH recommends using Windows? plus a Question! References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> Message-ID: <3FA84B67.7080605@wanadoo.es> Michael K. Johnson wrote: > One thing I want to see happen is a self-service hardware compatibility > service that makes it easy for users to provide information on the > compatibility they are seeing with their hardware on Fedora, and for > which the information is well-enough organized that you can actually > have good searches for that information. There is two sources of good information: linux-kernel and Xfree86. Nearly all devices carry a PCI_ID information inside. Linux kernel and Xfree86 usually collect it to load the correct device driver. This is a big project, and is better to split it in chunks, basic PCI HW(SCSI, VIDEO, NET...) first and latter more(USB....): 1- HW detection by Anaconda and kuzdzu pcitable from hwdata package is the best place to begin. I have done some work and I am waiting for Martin Mares from http://pciids.sf.net to send updates to hwdata maintainers. 2 - Documentation about HW supported. Greg KH said me in linux-kernel nl that devices supported by kernel are "already listed in the MODULE_DEVICE_TABLE and can be parsed later by userspace tools quite easily." Xfree86 :-? Volunteers? where are python wizards :-) ? I hope to see some documentation as FreeBSD has: http://www.freebsd.org/releases/5.1R/hardware-i386.html -- HTML mails are going to trash automagically From johnsonm at redhat.com Wed Nov 5 01:05:41 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 4 Nov 2003 20:05:41 -0500 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1067990738.15706.126.camel@spatula>; from jspaleta@princeton.edu on Tue, Nov 04, 2003 at 07:05:38PM -0500 References: <1067990738.15706.126.camel@spatula> Message-ID: <20031104200541.A3076@devserv.devel.redhat.com> On Tue, Nov 04, 2003 at 07:05:38PM -0500, Jef Spaleta wrote: > I'd imagine there will be a metric crapload of reports for certain video > cards. Being able to narrow down by picking your mobo and maybe even > your monitor could help sort the initial list of reports you are going > to pull up, just by bringing any relevant mobo/card issues up to the > top. Sure, I was just trying to keep the example simple. :-) > Hmm..is it wise to make it point and click easy to list brokenness in a > hardware database that is completely seperate from bugzilla? I'd really > hate to lose useful bugreports to comments in the hardware database and > make developers have to troll the hardware reviews as well to find out > if a piece of hardware has a problem. A review based hardware database > makes some sense as an end-user tool for people choosing hardware to > use, but i don't know if it makes sense as a tool for developers to keep > track of specific hardware issues...and i'd hate to see review comments > become the prefered end-user way to report problems...but have bugzilla > be the preferred developer way to track problems. Well, it would be nice to have someplace to point people when the answer is RESOLVED->NOTABUG (hardware not supported) You'd definitely want to have the ability to file a bug report in bugzilla and say "my hardware report is at URL foo" for easy access. bugzilla really isn't set up for this kind of information AFAIK... (Now Dave will chime in and tell me that bugzilla can butter my bread for me, of course.) > Well i vote for mocking up the forum side of this with a pre-existing > forum codebase if at all possible. A specially crafted advogato reporter > client to script the hardware reports to submit would be simple for > someone to bootstrap together i would imagine. But would a stock > advogato forum provide enough initial usefulness as a target forum > platform to play with? Is linux-usb.org device database a useful example > of this sort of thing minus the advogato ranking system? > > http://www.qbik.ch/usb/devices/ Mmmm, I'm thinking a lot more structured information and cross-linking. I'm not sure how useful it is without that. I think you really want a database behind it in order to do interesting queries, especially the kinds of queries you have proposed. :-) michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From danielnastase at hotmail.com Wed Nov 5 02:09:30 2003 From: danielnastase at hotmail.com (Daniel) Date: Tue, 04 Nov 2003 21:09:30 -0500 (EST) Subject: Development Offer In-Reply-To: <00e901c3a308$ab7f0500$49f4ac41@k4h8f5> Message-ID: On Tue, 4 Nov 2003, Anthony Saffer wrote: > > So, my question is, does someone even start writing any spec/code on a > > system task scheduler desktop tool for the Fedora project. If any, and if > my > > assistance is welcome, then please get in touch with me. If not, then I > may > > start working on my own side on some kind of specifications. > > Hi Xavier, > > I've recently started work on a GUI interface to cron and at in Perl. But > from reading around, it doesn't look like my project will ever make it into > the release (due to it not being Python source). I think there's a lot of > room for a good scheduler out there. Good luck! So one of the requirements for developing for Fedora (in the case of config tools) is that it needs to be coded in Python + GTK ? Like I said previously there is a 'kcron' application that already implements a gui frontend for cron. I guess it's not suitable for Fedora, then... I was thinking on taking up on the 'cron' task myself. As it seems to be a simple project and I'm kind of new to developing for Linux. The project is simple enough to be handled by a single person. So I guess I'll try my hand on something else... Daniel > > Anthony > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- From warren at togami.com Wed Nov 5 02:38:55 2003 From: warren at togami.com (Warren Togami) Date: Tue, 04 Nov 2003 16:38:55 -1000 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1067990738.15706.126.camel@spatula> References: <1067990738.15706.126.camel@spatula> Message-ID: <1067999934.11320.79.camel@laptop> On Tue, 2003-11-04 at 14:05, Jef Spaleta wrote: > Hmm..is it wise to make it point and click easy to list brokenness in a > hardware database that is completely seperate from bugzilla? I'd really > hate to lose useful bugreports to comments in the hardware database and > make developers have to troll the hardware reviews as well to find out > if a piece of hardware has a problem. A review based hardware database > makes some sense as an end-user tool for people choosing hardware to > use, but i don't know if it makes sense as a tool for developers to keep > track of specific hardware issues...and i'd hate to see review comments > become the prefered end-user way to report problems...but have bugzilla > be the preferred developer way to track problems. When Michael, the kernel guy, proposes a GUI solution, it must be for good reason. =) End-users NEED a simple way to submit hardware information where they don't need to learn about tools like lspci, dmesg, dmidecode, etc. It saves us time by having a large pool of submitted data, allowing us to see trends and avoid asking for information. Furthermore, fewer poorly written Bugzilla entries from end-users would waste our time. As long as the topic contains "Windows" this seems like a good time to mention what I saw in recent Windows betas that I thought was a really good idea. When Windows was unable to find a built-in driver for an unknown piece of hardware, it searched a database on the Internet. While this mechanism was useless in the AMD64 Windows beta that I tried since ZERO DRIVERS were available, I really see the potential for us to harness this same idea. In addition to simply submitting data, our system should be able to pull up links to more information about the specific hardware that we are using. Very often workarounds exist for problems, and it would save us even more time if users learned about them automatically. Warren From m.fioretti at inwind.it Wed Nov 5 03:37:53 2003 From: m.fioretti at inwind.it (M. Fioretti) Date: Wed, 5 Nov 2003 04:37:53 +0100 Subject: Question about development languages In-Reply-To: <1067979391.4179.70.camel@localhost.localdomain> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <1067979391.4179.70.camel@localhost.localdomain> Message-ID: <20031105033753.GA933@inwind.it> On Tue, Nov 04, 2003 15:56:31 at 03:56:31PM -0500, Havoc Pennington (hp at redhat.com) wrote: > On Tue, 2003-11-04 at 03:47, Anthony Saffer wrote: > > I was browsing the Fedora website and noticed that the configuration tools > > are said to be all Python based with a few PyGTK ones. I don't know Python > > at all but am very familiar with Perl and PerlTk. Do the tools HAVE to be > > written in Python or are other languages acceptable? > > Tk is unacceptable, it has to be a modern toolkit. May I ask why? Is it for some functional reason or because it looks better in screenshots it sounds better when one says it I'd understand even in tose cases, I'm just curious. Ciao, Marco Fioretti -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ Travel is fatal to prejudice, bigotry, and narrow-mindedness, and many of our people need it sorely on these accounts. Broad, wholesome, charitable views of man and things cannot be acquired by vegetating in one little corner of the earth all one's lifetime. Mark Twain From katzj at redhat.com Wed Nov 5 04:48:57 2003 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Nov 2003 23:48:57 -0500 Subject: Question about development languages In-Reply-To: <20031105033753.GA933@inwind.it> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <1067979391.4179.70.camel@localhost.localdomain> <20031105033753.GA933@inwind.it> Message-ID: <1068007736.1570.42.camel@edoras.local.net> On Tue, 2003-11-04 at 22:37, M. Fioretti wrote: > On Tue, Nov 04, 2003 15:56:31 at 03:56:31PM -0500, Havoc Pennington (hp at redhat.com) wrote: > > On Tue, 2003-11-04 at 03:47, Anthony Saffer wrote: > > > I was browsing the Fedora website and noticed that the configuration tools > > > are said to be all Python based with a few PyGTK ones. I don't know Python > > > at all but am very familiar with Perl and PerlTk. Do the tools HAVE to be > > > written in Python or are other languages acceptable? > > > > Tk is unacceptable, it has to be a modern toolkit. > > May I ask why? > > Is it for some functional reason or because > > it looks better in screenshots > it sounds better when one says it > > I'd understand even in tose cases, I'm just curious. Short list of reasons to start with 1) Internationalization 2) Accessibility 3) Fitting in with the general look and feel of the rest of the desktop Cheers, Jeremy From m.fioretti at inwind.it Wed Nov 5 05:17:48 2003 From: m.fioretti at inwind.it (M. Fioretti) Date: Wed, 5 Nov 2003 06:17:48 +0100 Subject: Question about development languages In-Reply-To: <1068007736.1570.42.camel@edoras.local.net> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <1067979391.4179.70.camel@localhost.localdomain> <20031105033753.GA933@inwind.it> <1068007736.1570.42.camel@edoras.local.net> Message-ID: <20031105051748.GL933@inwind.it> On Tue, Nov 04, 2003 23:48:57 at 11:48:57PM -0500, Jeremy Katz (katzj at redhat.com) wrote: > > > Tk is unacceptable, it has to be a modern toolkit. > > > > May I ask why? [snip] > > Short list of reasons to start with > 1) Internationalization > 2) Accessibility Agreed, these are excellent reasons. Thanks Marco Fioretti -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ "To turn $100 into $110 is work. To turn $100 million into $110 million is inevitable" -- Edgar Bronfman From tony at tgds.net Wed Nov 5 06:32:15 2003 From: tony at tgds.net (tony) Date: Wed, 05 Nov 2003 07:32:15 +0100 Subject: A presentation In-Reply-To: <3FA81C64.20004@carwyn.com> References: <20031104190750.21090.qmail@linuxmail.org> <3FA81C64.20004@carwyn.com> Message-ID: <1068013935.5029.43.camel@localhost.localdomain> Le mar 04/11/2003 ? 22:38, Carwyn Edwards a ?crit : > >>My main machine is now a hush mini-ITX Epia-M machine. I hope to sell > >>these machines with a Linux desktop installed (DVD playback is my > >>current battle). > >> > >> > >To get DVD playback, go to http://freshrpms.net > >Matthias has all the necessary codecs and packages there to watch DVDs. > > > > > http://forums.viaarena.com/ is the place to look in the > > OS Arena -> Linux Arena area > > Actaully, skimming them just now : > http://www3.sympatico.ca/howlettfamily/epia/epia.html > > .. seems like the best place to start. The Redhat 9 RPM there were debugged by myself... They "work" but the HW mpeg2 stuff is very buggy and the modified version of Xine must be run as root. When I said "DVD playback is my current battle" I meant that it was what I am working on right now. My next step will be to get the RPMs to build on Fedora. Cheers Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From maxka at myrealbox.com Wed Nov 5 07:13:07 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Tue, 04 Nov 2003 23:13:07 -0800 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <20031104165952.B30342@devserv.devel.redhat.com> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> Message-ID: <1068016387.6414.42.camel@max.localdomain> All right. We had a bit of discussion on this in #fedora-devel. Here's a quick summary of what the project seems to need. (1) A database that holds hardware information (2) A GUI tool to submit that information (3) A web interface to use that information Requirements and Functionality ------------------------------ Primary Purpose of the System: To allow users to know if their hardware works with Fedora/Red Hat Linux. Secondary Purpose: To allow users to resolve hardware issues with Red Hat Linux products. How this is accomplished: By creating a database of hardware and how well it works. Specific Implementation: Creating the database from end-user data, which has the added advantage of giving people the opportunity to participate in the Fedora project. Value of the Product: If well-designed, the product will allow both Fedora and Enterprise customers to have confidence that their hardware works with our software. This leads to the following requirements: * The system needs to hold hardware information in a logical fashion. (Meaning, the more specific fields that we can get about the hardware outside of a "comments" field, the better.) * The system needs to be easily cross-indexable. * The system needs to be as easy as possible for the end-user to use. * It must be likely that the average end-user will submit their information. * The submission must take no longer than 10 minutes, though under 5 minutes would be ideal. * The system must be flexible enough to adapt to new types of hardware that we cannot predict. * The end-user of the web product must be able to determine the quality of the data that they are presented with. * The end-users privacy must be protected to the exact degree they desire. What to use ----------- When it comes to (1), we'll want a real database solution, probably based on PostgreSQL. Ideally, I'd like to see if there's some high-level solution already in existence that can be modified according to our parameters. We could build from the database up, but the incredible amount of effort that this project requires could be considerably lessened by some higher-level tool. Any suggestions in this area? For (2), we'll probably have to roll our own. Does _anything_ like this already exist in the open-source world? For (3), it's clear that there are components of various systems that will do various parts of what we need. For example, if we want to rank comments, Advogato has been suggested, for the reason of algorithmic quality and code quality. Slashdot is an alternative, however that seemed to be not as well-liked initially. Are there any less well-known Open Source projects that would suit these needs better than Advogato? As far as the actual browsing of the hardware, are there any projects that would give us a leg up here? Now, it would be possible to use a sort of modified Bugzilla to do what we want. The problem seems to be that Bugzilla is a system much more complex than our hardware database is going to be. The volume of our hardware database is going to be pretty high, and a Bugzilla with a high level of submission requires a lot of maintenance, volunteer and otherwise (witness bugzilla.mozilla.org). In general, it seems that Bugzilla is out, from consensus. Feel free to argue -- we're at the "throwing ideas around" stage. Languages --------- GUI: PyGTK. It's clearly the Red Hat standard for GUI projects. Backend: SQL and Python. Some C if required for interfacing with Open Source Projects we use. Web Interface: PHP or Python. Once again, this might also depend somewhat on the other projects we integrate. Other Implementation Notes -------------------------- We have a lot of tools that can get data for us: lspci, dmidecode, dmesg What I _don't_ really think would be fun would be parsing the text output of those programs. MKJ thought it would be ideal if dmidecode could give us XML. Anybody know if there's a tool that already does this, or something we could start with? hwbrowser seems to make sense of that data somehow -- is there a way to get data out of it? Who's the maintainer of hwbrowser? It would be a good idea to have people submit data and have a "No Problems Reported" status. The program would probably be a small applet that exists in the tray until run. After that, it should disappear forever. The alternative is an icon on the user's desktop saying "submit your hardware information" or something like that. Priorities ---------- (1) A backend which accepts data. (2) A method of populating the backend. (3) A method of browsing the submitted data. (4) A method of using the submitted data to resolve problems. (5) Connecting the submitted data to driver downloads. (A great idea from Warren.) Cost ---- * One computer to act as the DB server, etc. * One computer to run development versions. * Bandwidth -- I'm not sure on this one, how much do you think it would take? Okay, this is just a rapid sketch! More suggestions!! If I can get a space somewhere, I can maintain this document as a web page. I'm sure I left a lot of stuff out. It's a big project. :-) Also, who wants to actually work on this, and on what part? -Max K-A From behdad at cs.toronto.edu Wed Nov 5 07:16:28 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Wed, 5 Nov 2003 02:16:28 -0500 Subject: A presentation In-Reply-To: <1068013935.5029.43.camel@localhost.localdomain> References: <20031104190750.21090.qmail@linuxmail.org> <3FA81C64.20004@carwyn.com> <1068013935.5029.43.camel@localhost.localdomain> Message-ID: On Wed, 5 Nov 2003, tony wrote: > Le mar 04/11/2003 ? 22:38, Carwyn Edwards a ?crit : > > > >>My main machine is now a hush mini-ITX Epia-M machine. I hope to sell > > >>these machines with a Linux desktop installed (DVD playback is my > > >>current battle). > > >> > > >> > > >To get DVD playback, go to http://freshrpms.net > > >Matthias has all the necessary codecs and packages there to watch DVDs. > > > > > > > > http://forums.viaarena.com/ is the place to look in the > > > > OS Arena -> Linux Arena area > > > > Actaully, skimming them just now : > > http://www3.sympatico.ca/howlettfamily/epia/epia.html > > > > .. seems like the best place to start. > > The Redhat 9 RPM there were debugged by myself... They "work" but the HW > mpeg2 stuff is very buggy and the modified version of Xine must be run > as root. > > When I said "DVD playback is my current battle" I meant that it was what > I am working on right now. My next step will be to get the RPMs to build > on Fedora. Perhaps I'm missing something, but AFAIK both mplayer and xine from rpm.livna.org work perfectly. (using myself) > Cheers > > Tony Grant > behdad From warren at togami.com Wed Nov 5 07:37:56 2003 From: warren at togami.com (Warren Togami) Date: Tue, 04 Nov 2003 21:37:56 -1000 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068016387.6414.42.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> Message-ID: <1068017876.13574.23.camel@laptop> On Tue, 2003-11-04 at 21:13, Maxwell Kanat-Alexander wrote: > > Languages > --------- > > GUI: PyGTK. It's clearly the Red Hat standard for GUI projects. > > Backend: SQL and Python. Some C if required for interfacing with Open > Source Projects we use. > > Web Interface: PHP or Python. Once again, this might also depend > somewhat on the other projects we integrate. > This is also a clear case for XMLRPC-like communication between client and server. > Other Implementation Notes > -------------------------- > > We have a lot of tools that can get data for us: > > lspci, dmidecode, dmesg > > What I _don't_ really think would be fun would be parsing the text > output of those programs. MKJ thought it would be ideal if dmidecode > could give us XML. Anybody know if there's a tool that already does > this, or something we could start with? hwbrowser seems to make sense of > that data somehow -- is there a way to get data out of it? Who's the > maintainer of hwbrowser? lspci and some other data can be communicated easily parsed from the numeric form: [root at laptop root]# lspci -n 00:00.0 Class 0600: 1106:0305 (rev 03) 00:01.0 Class 0604: 1106:8305 00:07.0 Class 0601: 1106:0686 (rev 40) 00:07.1 Class 0101: 1106:0571 (rev 06) 00:07.2 Class 0c03: 1106:3038 (rev 1a) 00:07.3 Class 0c03: 1106:3038 (rev 1a) 00:07.4 Class 0601: 1106:3057 (rev 40) 00:07.5 Class 0401: 1106:3058 (rev 50) 00:07.6 Class 0780: 1106:3068 (rev 30) 00:0a.0 Class 0607: 104c:ac51 00:0a.1 Class 0607: 104c:ac51 00:0e.0 Class 0c00: 104c:8020 00:10.0 Class 0200: 10ec:8139 (rev 10) 01:00.0 Class 0300: 1002:4c4d (rev 64) Ultimately all of this and other data should be converted into XML and communicated over the Internet. The pygtk applications on the client side displays human readable information based upon a lookup table from this data. That particular part isn't the challenge. > > It would be a good idea to have people submit data and have a "No > Problems Reported" status. > > The program would probably be a small applet that exists in the tray > until run. After that, it should disappear forever. The alternative is > an icon on the user's desktop saying "submit your hardware information" > or something like that. I hope this applet would not be within the default Gnome/KDE profile, because then it would pop up on the user desktop of all users at least once. This is not ideal for massive multi-user systems like LTSP. I believe this may be ideal for firstboot, and also choosable from the System menu. Perhaps there are better ideas... Warren From maxka at myrealbox.com Wed Nov 5 08:07:25 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 00:07:25 -0800 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068017876.13574.23.camel@laptop> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068017876.13574.23.camel@laptop> Message-ID: <1068019644.6414.50.camel@max.localdomain> On Tue, 2003-11-04 at 23:37, Warren Togami wrote: > This is also a clear case for XMLRPC-like communication between client > and server. That makes sense. > Ultimately all of this and other data should be converted into XML and > communicated over the Internet. The pygtk applications on the client > side displays human readable information based upon a lookup table from > this data. Agreed. Is there a pre-existing source of data that we could use for that lookup table? > I hope this applet would not be within the default Gnome/KDE profile, > because then it would pop up on the user desktop of all users at least > once. This is not ideal for massive multi-user systems like LTSP. I would think that it would only come up once, system-wide. > I believe this may be ideal for firstboot, and also choosable from the > System menu. Perhaps there are better ideas... We discussed having it on firstboot. Here's the pros and cons: Pro: Doesn't clutter up user space after firstboot. Pro: Easy to draw users' attention Con: I heard a "nobody likes firstboot already" that may or may not be true. Con: It's hard to determine whether or not hardware works on the first boot. The only real problem is the last one. I think it would be great to get the data on firstboot, and then we could have a lot of "No Problems Reported" on a lot of hardware. What are our options then for getting further data about what hardware works and what doesn't? Here's the info we can get at firstboot: (1) What hardware the user has. (2) Do we have drivers for it? (3) Some simple diagnostics, maybe. Perhaps we can just leave it up to more advanced users to report when they have hardware problems, and leave it to the more basic users to just search the advanced users' reports. That is, we'd have a "Submit Hardware Information" in the System Tools. -M From Nicolas.Mailhot at laPoste.net Wed Nov 5 09:06:34 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 05 Nov 2003 10:06:34 +0100 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068016387.6414.42.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> Message-ID: <1068023194.8102.20.camel@ulysse.olympe.o2t> Le mer 05/11/2003 ? 08:13, Maxwell Kanat-Alexander a ?crit : > Other Implementation Notes > -------------------------- > > We have a lot of tools that can get data for us: > > lspci, dmidecode, dmesg lsusb, some sort of lspcsi/lsata and the acpi guys will want /proc/acpi/dst (and some of those can crash a system sometimes) usb is very important - you can get half your devices hooked on it nowadays. I'm deeply sceptical about any gui implementation from scratch - a form-based tool at first to test what exact information is needed seems more logical (but I'm not the one writing the code:) The db could be hosted at a vendor-neutral location like osdl, and a system "card" accessible via a simple url so it can be referenced in the various bugzillas out there. (you aren't talking about replacing bugzilla are you ?) There may also probably be ways to have per-component views to allow linking to external info (vendor description pages, bios downloads, linuxprinting db entry, linux driver homepage, newsgroup, etc) Anyway this is a wonderful idea, and it should be shared will all the other linux project that need hardware dbs. 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 eendebak at math.uu.nl Wed Nov 5 09:58:42 2003 From: eendebak at math.uu.nl (Pieter Eendebak) Date: Wed, 5 Nov 2003 10:58:42 +0100 Subject: fedora DVD Message-ID: <200311051058.42903.eendebak@math.uu.nl> Hi all! Would it be possible to create an iso image containing the complete fedora distribution that can be burned onto a DVD disc? I am not familiar with the structure of fedora packages and installation discs but my guess is that I would not be that difficult. For me at least it would be very convenient and I think in the near future this option will be desired by more people. thanks, Pieter Eendebak From alan at redhat.com Wed Nov 5 10:02:25 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 5 Nov 2003 05:02:25 -0500 (EST) Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a In-Reply-To: <1068023194.8102.20.camel@ulysse.olympe.o2t> from "Nicolas Mailhot" at Tach 05, 2003 10:06:34 Message-ID: <200311051002.hA5A2Pm14194@devserv.devel.redhat.com> > > lspci, dmidecode, dmesg > > lsusb, some sort of lspcsi/lsata and the acpi guys will want > /proc/acpi/dst (and some of those can crash a system sometimes) /proc/pnpbios is another one if PnP BIOS is in use and can also have some similar problems. Also cardinfo for pcmcica devices From maxka at myrealbox.com Wed Nov 5 10:16:53 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 02:16:53 -0800 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068023194.8102.20.camel@ulysse.olympe.o2t> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068023194.8102.20.camel@ulysse.olympe.o2t> Message-ID: <1068027413.3612.4.camel@max.localdomain> On Wed, 2003-11-05 at 01:06, Nicolas Mailhot wrote: > I'm deeply sceptical about any gui implementation from scratch - a > form-based tool at first to test what exact information is needed seems > more logical (but I'm not the one writing the code:) What sort of tool were you thinking of? > The db could be hosted at a vendor-neutral location like osdl I was thinking that it would be nice to have an all-Linux Hardware Compatibility Database. The engineering problems would be immense, of course, starting with the simple logical problems of how to do it at all. It might be better to design a single system that would be easily portable by other vendors. > , and a > system "card" accessible via a simple url so it can be referenced in the > various bugzillas out there. That's a good idea. > (you aren't talking about replacing > bugzilla are you ?) Absolutely not. :-) > There may also probably be ways to have per-component views to allow > linking to external info (vendor description pages, bios downloads, > linuxprinting db entry, linux driver homepage, newsgroup, etc) That is certainly a necessity, I'd think. I wonder how we'd get that information -- automate it somehow, or get it from users, or have volunteers populate it, or...? > Anyway this is a wonderful idea, and it should be shared will all the > other linux project that need hardware dbs. I think it would be a great step forward for Linux in general, and certainly a great asset to Fedora. :-) -M From P at draigBrady.com Wed Nov 5 10:17:17 2003 From: P at draigBrady.com (P at draigBrady.com) Date: Wed, 05 Nov 2003 10:17:17 +0000 Subject: fedora DVD In-Reply-To: <200311051058.42903.eendebak@math.uu.nl> References: <200311051058.42903.eendebak@math.uu.nl> Message-ID: <3FA8CE2D.5020108@draigBrady.com> Pieter Eendebak wrote: > Hi all! > > Would it be possible to create an iso image containing the complete fedora > distribution that can be burned onto a DVD disc? 1st hit when searching for dvd in archives http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00736.html P?draig. From julo at altern.org Wed Nov 5 10:23:59 2003 From: julo at altern.org (Julien Olivier) Date: Wed, 05 Nov 2003 10:23:59 +0000 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <20031104190459.A15665@devserv.devel.redhat.com> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> Message-ID: <1068027839.3471.11.camel@localhost.localdomain> On Wed, 2003-11-05 at 00:04, Michael K. Johnson wrote: > On Tue, Nov 04, 2003 at 11:52:19PM +0000, Julien Olivier wrote: > > I could be interested but I'm just wondering: why not use a web form to > > fetch those information ? Isn't it easier to create a simple form in PHP > > on redhat's website than create a GUI app ? Users will need an internet > > connection to validate their form anyway, so I don't see the point to > > have a desktop app. But maybe I'm missing something... > > Your idea is "run this text application to create a file which you > then POST to a web site and it then provides you with web forms to > fill in" -- do I understand right? > Hmm... not at all :) My idea is: -The user clicks on a link (for example http://hardwarde.redhat.com) -He then fills a web form asking him which hardware he has and how it works (in an "assistant/wizard/druid" form, like in bugzilla). -He validates > My reasons for a GUI application: > > o Seems easier for the novice user to select one "report my hardware" > icon from a menu than run a text program, then go through several > web pages to upload it and fill out forms about it. This is really > three points: Easier to find, fewer steps to completion, and > perhaps it might be possible to make the interface a bit smarter. > Well, my idea was to click on "report my hardware" and be sent to the right webpage through Mozilla or Epiphany. So I guess it's as simple as using a GUI application. > o Could conceivably do queries based on user input (this is vague) > and users could intentionally limit the hardware they report > (like if they don't want to publish to the whole world that they > have a $50,000 computer sitting in their basement or they have > hardware under NDA that they are required not to talk about and > really don't ever want that information going out of their network. > > But that doesn't mean it's the only way this could work, I'm just sharing > my vision... > > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Julien Olivier From Nicolas.Mailhot at laPoste.net Wed Nov 5 10:29:07 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 05 Nov 2003 11:29:07 +0100 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068027413.3612.4.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068023194.8102.20.camel@ulysse.olympe.o2t> <1068027413.3612.4.camel@max.localdomain> Message-ID: <1068028146.9794.6.camel@ulysse.olympe.o2t> Le mer 05/11/2003 ? 11:16, Maxwell Kanat-Alexander a ?crit : > On Wed, 2003-11-05 at 01:06, Nicolas Mailhot wrote: > > I'm deeply sceptical about any gui implementation from scratch - a > > form-based tool at first to test what exact information is needed seems > > more logical (but I'm not the one writing the code:) > > What sort of tool were you thinking of? Stupid form with attachements like in bugzilla. After a few months once everyone has agreed on the exact attachement list/url list then it'll be time to write the gui client (keeping the form interface since that's the one you'll need to perform searches and this way people can report even if the gui tool is not installed on their distro). > > There may also probably be ways to have per-component views to allow > > linking to external info (vendor description pages, bios downloads, > > linuxprinting db entry, linux driver homepage, newsgroup, etc) > > That is certainly a necessity, I'd think. I wonder how we'd get that > information -- automate it somehow, or get it from users, or have > volunteers populate it, or...? 1. Ask it from users each time they add a component without full info (ie bug users till someone completed all the fields for a particular hardware id) and/or 2. Send a mail to interested groups each time a component is entered (ie send to linuxprinting.org when people add a new printer, to ati when people add a new ati card, etc) Btw there should probably be a gateway to hotplug/dbus people somewhere. 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 julo at altern.org Wed Nov 5 10:30:00 2003 From: julo at altern.org (Julien Olivier) Date: Wed, 05 Nov 2003 10:30:00 +0000 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <20031104190459.A15665@devserv.devel.redhat.com> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> Message-ID: <1068028200.3471.18.camel@localhost.localdomain> Aaargh, forget my proposition... it is stupid because it needs the user to _know_ what hardware he has and fill everything himself. I understand that a GUI application would have the advantage to be able to "auto-detect" the hardware and do most of the work for the user. That said, it could still be done the following way: - When you click on "report my hardware", a cookie is generated containing all the information required automatically. - The website is opened, reads the cookie and pre-fills the form - The user can modify the defaults choices and validates The drawback: - if your navigator is configured to refuse cookies, you're screwed... -- Julien Olivier From julo at altern.org Wed Nov 5 10:36:08 2003 From: julo at altern.org (Julien Olivier) Date: Wed, 05 Nov 2003 10:36:08 +0000 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068028146.9794.6.camel@ulysse.olympe.o2t> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068023194.8102.20.camel@ulysse.olympe.o2t> <1068027413.3612.4.camel@max.localdomain> <1068028146.9794.6.camel@ulysse.olympe.o2t> Message-ID: <1068028568.3471.21.camel@localhost.localdomain> On Wed, 2003-11-05 at 10:29, Nicolas Mailhot wrote: > Le mer 05/11/2003 ? 11:16, Maxwell Kanat-Alexander a ?crit : > > On Wed, 2003-11-05 at 01:06, Nicolas Mailhot wrote: > > > I'm deeply sceptical about any gui implementation from scratch - a > > > form-based tool at first to test what exact information is needed seems > > > more logical (but I'm not the one writing the code:) > > > > What sort of tool were you thinking of? > > Stupid form with attachements like in bugzilla. > After a few months once everyone has agreed on the exact attachement > list/url list then it'll be time to write the gui client (keeping the > form interface since that's the one you'll need to perform searches and > this way people can report even if the gui tool is not installed on > their distro). > Another advantage of having a form ala bugzilla is that if your modem doesn't work on Linux, if you have a Windows (or any other OS) partition you still can boot to it and report your hardware failure. That said, you could as well do it through bugzilla too. -- Julien Olivier From stuart at terminus.co.uk Wed Nov 5 10:57:37 2003 From: stuart at terminus.co.uk (Stuart Children) Date: Wed, 05 Nov 2003 10:57:37 +0000 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068019644.6414.50.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068017876.13574.23.camel@laptop> <1068019644.6414.50.camel@max.localdomain> Message-ID: <3FA8D7A1.7040307@terminus.co.uk> Hi all Maxwell Kanat-Alexander wrote: >>I believe this may be ideal for firstboot, and also choosable from the >>System menu. Perhaps there are better ideas... > > > We discussed having it on firstboot. Here's the pros and cons: > > Pro: Doesn't clutter up user space after firstboot. > Pro: Easy to draw users' attention > > Con: I heard a "nobody likes firstboot already" that may or may not be > true. > Con: It's hard to determine whether or not hardware works on the first > boot. Just a thought: how about linking to [a page about] it from file:///usr/share/doc/HTML/index.html? That way it is presented to the user when they fire up a web browser for the first time. Everyone should see it. Yet it's simple to get rid of - most people I expect change their homepage anyway. Even if they don't there's no real added annoyance because the application itself hasn't been loaded up. The only issues I can see here are: 1) It's easy for people to ignore. 2) People have to read about it and then execute the program themselves rather than it just popping up itself. 3) People who don't install/use a web browser won't see it at all. 1) and 2) could be argued as benefits though! :) However, to address the above: 1) Redesign index.html so it looks more interesting. Put clear headings like "Need help?", "Developers", "Updates", etc. 2) Can be lessened by telling people where to look in the system menu to launch the program. 3) This is only an issue if it such people are amoungst those you're trying to target. I would suspect not. The same could apply to other applications. Cheers -- Stuart From tony at tgds.net Wed Nov 5 11:23:33 2003 From: tony at tgds.net (tony) Date: Wed, 05 Nov 2003 12:23:33 +0100 Subject: A presentation In-Reply-To: References: <20031104190750.21090.qmail@linuxmail.org> <3FA81C64.20004@carwyn.com> <1068013935.5029.43.camel@localhost.localdomain> Message-ID: <1068031413.5029.60.camel@localhost.localdomain> Le mer 05/11/2003 ? 08:16, Behdad Esfahbod a ?crit : > > > >>My main machine is now a hush mini-ITX Epia-M machine. > Perhaps I'm missing something, but AFAIK both mplayer and xine > from rpm.livna.org work perfectly. (using myself) With hardware mpeg2 acceleration? on a M10000? mplayer uses > 90% CPU and sound drops off very quickly (memory leak) xine plays video but not sound and without hardware acceleration uses > 60% CPU Via version of xine (VeXP) uses 35% CPU. But it is a buggy as (your word goes here). ogle plays sound and not video to complete the list. The support for Epia M is on its way (I think a certain Alan Cox may be working on it) but for now the Via stuff has best performance. Cheers Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From david at fubar.dk Wed Nov 5 11:47:17 2003 From: david at fubar.dk (David Zeuthen) Date: Wed, 05 Nov 2003 12:47:17 +0100 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068016387.6414.42.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> Message-ID: <1068032835.7163.10.camel@laptop.fubar.dk> On Wed, 2003-11-05 at 08:13, Maxwell Kanat-Alexander wrote: > Other Implementation Notes > -------------------------- > > We have a lot of tools that can get data for us: > > lspci, dmidecode, dmesg > > What I _don't_ really think would be fun would be parsing the text > output of those programs. MKJ thought it would be ideal if dmidecode > could give us XML. Anybody know if there's a tool that already does > this, or something we could start with? hwbrowser seems to make sense of > that data somehow -- is there a way to get data out of it? Who's the > maintainer of hwbrowser? > May I propose to use the freedesktop.org HAL I'm working on? This project is supposed to be a database of all hardware on the system, see http://freedesktop.org/~hal/spec-0.2-pre/hal-spec.html The HAL will have both hardware details as well as other properties that may be merged per-device or per-user. For instance this is a HAL device describing my sound card device_id = '/org/freedesktop/Hal/devices/pci.00:08.0' Bus = 'pci' (string) GotDeviceInfo = false (bool) State = NEED_DEVICE_INFO (int) pci.className = 'Multimedia audio controller' (string) pci.programmingInterface = 0 (0x0) (int) pci.subClass = 1 (0x1) (int) pci.class = 4 (0x4) (int) pci.revision = 16 (0x10) (int) pci.subsysDeviceName = '009e' (string) pci.subsysDeviceId = 158 (0x9e) (int) pci.subsysVendorName = 'Dell Computer Corporation' (string) pci.subsysVendorId = 4136 (0x1028) (int) pci.deviceName = 'ES1978 Maestro 2E' (string) pci.vendorName = 'ESS Technology' (string) pci.deviceId = 6520 (0x1978) (int) pci.vendorId = 4701 (0x125d) (int) pci.function = 0 (0x0) (int) pci.slot = 8 (0x8) (int) pci.busNumber = 0 (0x0) (int) The idea is that Device Info Files can provide more properties. Now, it would be extremely cool if the hardware database could actually provide device info files.. Now, HAL is not finished and there are big changes from the 0.1 version, but I expect to finish version 0.2 late this or early next month. This version will support USB and PCI devices but it will be very easy to add new kinds of types such as IEEE1394. HAL will depend only on D-BUS and expat. Thanks, David From mharris at redhat.com Wed Nov 5 11:48:27 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 5 Nov 2003 06:48:27 -0500 (EST) Subject: AMD 64 support In-Reply-To: <20031103140349.B1468@lnxi.com> References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> <20031103140349.B1468@lnxi.com> Message-ID: On Mon, 3 Nov 2003, Mike Snitzer wrote: >> I wouldnt say that... people are working on an AMD64 fedora currently. > >Sure, I'd imagine (based on previous mails you've sent) you are >one of those people. But the fact remains that RedHat Inc. has >full-blown support for a native x86_64 install in RHELv3; yet >they haven't said a word about offering that technology to >Fedora. This is quite likely by design as they want to see the >financial fruits of all their effort before giving it away to >the community they are fostering. Quite to the contrary. When asked, we always respond, just as I am right this second. Our website also I believe contains comments about possibilities of other ports. Red Hat Linux has not had non-x86 ports for a long time now. The last non-x86 port was Red Hat Linux 7.2 for Alpha and IA64. Back in those days, ports to other architectures were done after the main x86 port was done, and were done under contract to a given hardware vendor or various vendors. Red Hat has never to my knowledge produced the operating system for non-x86 processors except under contract with a vendor who produces systems for the given processor. While x86 is the mainstay, non-x86 processors have traditionally just not been a viable profitable platform to develop the OS for without partnerships and contracts to do the work in order to make it worthwhile. Red Hat Linux 9 development was the beginning of our quest to build our OS simultaneously on all architectures we had contracts to produce *some* product for. As such, starting then, and ever since then, we have compiled all of our software on the following processor platforms: x86 AMD64 ia64 ppc ppc64 s390 s390x x86 is our flagship architecture due to it's obvious large commodity status, so that is always done. All other architectures are produced under contract with particular vendors. We compile all of our software on all 7 architectures religiously now in order to make things at least compile always wether a given product we're doing will actually ship on that architecture or ever be supported. This is because it is somewhat easier to just keep everything building across the board always, than it is to come back and roll a special port for a given architecture down the road. It also helps to keep the software of higher quality all around because of the 7 architectures, we have 32bit little endian (x86), 64bit little endian (ia64, AMD64), 32bit big endian(ppc,s390), 64bit big endian(ppc64, s390x) completely covered, maximizing portability between different endianness, as well as architecture specific problems. This also helps to find compiler and other toolchain problems much easier. A given problem might only trigger on a particular architecture, but might actually be a problem on all architectures. The more architectural coverage that is seen by the code, the cleaner and more portable the entire distribution becomes. However, making sure all rpm packages compile on all 7 architectures is only one part of producing a Linux distribution. Certain packages require architecture specific work, and that might require a lot of developer attention in order to fix problems that arise and are architecture specific. Also, special features we develop on x86, would need to be ported to the other architectures in question also, such as NPTL, exec-shield, and other things. This requires massive kernel engineering time commitment, glibc engineering time, gcc, XFree86, and other hardware and toolchain related development. It isn't a small task, and it doesn't come for free. Our goal for Fedora Core was to produce an x86 distribution, similar in nature to previous Red Hat Linux distribution releases. Aside from that specific goal, another goal was to continue with our goal to always build on all architectures, so that the distribution is always as clean as possible. However there never was a plan to officially release the distribution for other archtectures than x86. That doesn't in any way mean that Red Hat does not want to see non-x86 distribution ports happen. It means that non-x86 ports were not official Fedora Core 1 project goal targets, and that aside from making sure all packages build cleanly on all architectures, there hasn't really been any architecture specific work done, except more or less on a voluntary basis by particular developers interested in investigating a problem on a given non-target arch, or problems that occured in RHEL testing and got fixed in RHEL, and thus also in Fedora Core. >RedHat employees have said they openly encourage people to port >Fedora to other architectures. Absolutely. And many of us here _at_ Red Hat are some of the people who will be doing that work ourselves as volunteers. I for example am interested in making Fedora Core a reality on AMD64 and Alpha processors. There are a large number of other engineers here willing to volunteer to make that happen also. >So the fedora community can take Fedora where they want it to >go; but RedHat likely won't act as the catalyst for things like >an x86_64 port. Well you're very wrong there I'm afraid. Very. Non-x86 ports are going to be definitely volunteer driven. That doesn't mean they'll have to be done outside Red Hat at all. It does mean that when we put in our 8 hours of time at work here, we wont be spending much if any of that time on non-x86 ports of Fedora. However we don't put in 8 hour days at Red Hat now do we. ;o) We need to have some time ourselves to volunteer to do some of the things that need to be done. The most major thing for each architecture without question, is the kernel. The kernel needs work done for every architecture, and that is a LOT of hard work that needs experienced knowledgeable kernel guru hands on it. Right now Dave Jones I hear is hacking on the AMD64 kernel for Fedora Core 1. I don't know if any other kernel folk are working with Dave on that or if he's doing it himself. Either way, it is a lot of work, and it's volunteer work. Remember that. glibc/gcc et al. I am told are more or less pretty solid, and most of the rest of the distribution probably is also. Keep in mind though, that since non-x86 was not ever an official target of Fedora Core, while we are interested in doing other ports, and we want the community to get involved, throughout the whole development cycle, even though all 7 architectures got built, there have not been any test releases or betas of any of it. The only major architectural testing that happened is for RHEL 3. So in this case, it is RHEL 3 that has improved greatly the quality of non-x86 architecture support for Fedora Core, instead of the other way around. /me sticks his tongue out There are differences of course between what's in RHEL 3, and what's in Fedora Core, and so there very well is likely to be unknown bugs in Fedora Core on non-x86. First we need kernels for each non-x86 architecture, then we need the installer ported if necessary to work properly. It's not clear yet what other work is needed to be done. >All understandable, its just frustrating in that they've >obviously done the required work; and they are perfectly content >with having the Fedora community duplicate that effort of Considering all of the work that we have done, I'm rather offended by your short sighted and rather thankless remarks to be honest. ;o) We've set out to do a great amount of goodwill here, and not because we had to. Because we WANT to, not just as a company, but because making the distribution more open and being a community project is supposed to be a _fun_ thing too. We also do it because we ourselves not only work on this stuff daily for a living, but we volunteer to work on it way beyond our 8 hours a day - because we love doing it. We are employees, but the majority of us are also volunteers, and we'll be contributing a lot of our own personal spare time to this project as well, and that includes non-x86 architectures. >formalizing 64bit library and 32bit library coexistance and so >on. For all I know RedHat will weigh in and advise on such >decisions. Wrong. Rawhide has the latest of everything. We're not holding back or hiding *ANYTHING*. Fedora Core and rawhide contain the absolute latest support for anything and everything we have to offer. As I said above, there is some per architecture kernel work, installer work, possibly other surprises and gotchas we absolutely have no idea about yet, but it is not stuff just sitting idle with no effort happening. But the effort that IS occuring internally is volunteer driven. To attack us for this is to insult each and every engineer here who goes out of their way far beyond the call of duty to contribute something so that people such as yourself can have bits to play with. >So that said, has there been any big picture planning for how >x86_64 support will be added to Fedora Core? A list of which >tasks need to be accomplished, who the stakeholders that will be >contributing are, etc. We've been severely worked to the bone for the last n months trying to finalize Red Hat Enterprise Linux 3, trying to finish off Fedora Core, and other high priority critical tasks. We haven't really had a lot of spare volunteer time to throw around really as it was tied up either doing work chasing the clock for our products, or tied up in other volunteer efforts. I personally do not know of any list of what needs to be done for each architecture. I stated roughly some of the items above. There are some known AMD64 issues with XFree86 I'd like to work on, but that's dependant on spare time. People can scan bugzilla reports for open "all" "i386/i686/athlon" and "x86_64" bug reports to get an idea what bugs are open for AMD64. Feel free to report new ones too. It'd be a great idea to have a wiki on fedora.redhat.com with proper ACLs, which allowed Red Hat engineers and Fedora project community volunteers to place this kind of information. >We may even want a new fedora-amd64-devel at fedora.redhat.com >mailing list for the cause. Actually it might be nice if a >fedora--devel mailing list were created for each >architecture the Fedora community deems worthy. Personally I'm on about 130 mailing lists. I really don't need another one. People are too quick to create new mailing lists nowadays unnecessarily. All 3 existing fedora lists are for the most part identical off topic clones of each other, and a new list would probably just add a 4th clone list. fedora-devel-list is the best place to have these discussions and hit everyone in one spot. If the volume of per arch discussion really grows to the size that it warrants another mailing list then that is something to consider, but doing it prematurely is just personally an annoyance at least to me. Others may feel differently of course. In closing, I'd like to kindly request that you please don't be so critical about us. I think it is unfair to make these type of judgements without the full factual information out there, and without knowing just how much volunteerism goes into the distribution by Red Hat engineers already. We opened the distribution development via Fedora Core, so that we could work more closely with the community, and so much more could be accomplished both for the good of the community, and the good of Red Hat as well. The open source concept applied to an entire Linux distribution as a whole. We may or may not be crazy for doing so, but then people thought Bob Young was crazy 10+ years ago for starting a company based on open source technology too. Boy were all those people wrong 10 years ago weren't they? ;o) So we've opened things up, but that doesn't mean we can just push buttons and make people's requests happen instantly. It takes time to plan things, to develop them, etc. We also need to plan, design, and develop whatever infrastructure we need in order to make community involvement easier, perhaps that can even be done directly in collaboration with people like yourself. We need to put the infrastructure in place for people to build packages, to test things, and various other suggestions people have made or which we've come up with. This wont happen overnight, and neither will an AMD64 port of Fedora, nor an Alpha port - both of which I'm interested in. The best thing people who truely want to be a part of this community can do, is to become involved in a positive minded and open manner, with due patience. Ask us questions, and we'll generally answer them. Feel free to make suggestions too. Join the IRC #fedora-devel channel, and communicate on the fedora-devel mailing list. Please try to refrain from negativity and insulting discussion though - that doesn't help anything and doesn't improve the project, or the atmosphere. Keep an open mind also, and to get involved wherever you feel comfortable doing so. If someone wants to make a list of what needs to be done for AMD64, PPC or Alpha, by all means, someone start keeping track, and we can probably put it up on a web page or something. Actually what would be perfect, would be a public bug tracker bug, which links to actual bug reports that are issues needing work. That way we've got individual problems reported and/or RFEs, as well as a tracker. Count me in on AMD64 and Alpha, and many other mad hatters here too. Dunno who all is interested in PPC, but there are some internal folk. Perhaps we should have a web page listing interested volunteers per architecture too? Damn, a wiki would be nice, and I actually hate wikis. ;o) Anyhow, hopefully I've squelched some conspiracy theories, Slashdot FUD, and other bogosities now, and we can all work together on producing real 64bit Fedora Core stuff, and get rid of this x86 junk. ;oP -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Wed Nov 5 11:51:37 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 5 Nov 2003 06:51:37 -0500 (EST) Subject: AMD 64 support In-Reply-To: <200311041441.JAA10927@springbok.sci.ccny.cuny.edu> References: <200311041441.JAA10927@springbok.sci.ccny.cuny.edu> Message-ID: On Tue, 4 Nov 2003, Tim Daly wrote: >Is there an open AMD64 machine on the web? I can get at Itaniums >using HP's Testdrive setup but they don't have an AMD64 online. >I have 3 apps that need to be ported. We don't currently have any publically useable machines with shell accounts. It'd be nice to be able to offer that in the future however, but I dunno if/how/when that'd happen. Part of the infrastructure we need to discuss/plan/design/implement/etc. I think Sourceforge has AMD64 hardware available to shell account users, and perhaps even AMD does themselves. AMD64 is going to be so widespread within the next 3-6 months IMHO that it shouldn't be hard to find a shell by then anyway. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Wed Nov 5 11:58:29 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 5 Nov 2003 06:58:29 -0500 (EST) Subject: AMD 64 support In-Reply-To: <20031103212419.GA22201@ti19.telemetry-investments.com> References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> <20031103140349.B1468@lnxi.com> <20031103212419.GA22201@ti19.telemetry-investments.com> Message-ID: On Mon, 3 Nov 2003, Bill Rugolsky Jr. wrote: >> RedHat employees have said they openly encourage people to port Fedora to >> other architectures. So the fedora community can take Fedora where they >> want it to go; but RedHat likely won't act as the catalyst for things like >> an x86_64 port. All understandable, its just frustrating in that they've >> obviously done the required work; and they are perfectly content with >> having the Fedora community duplicate that effort of formalizing 64bit >> library and 32bit library coexistance and so on. For all I know RedHat >> will weigh in and advise on such decisions. > >There is no great hidden magic here. There are x86_64 package >builds in Rawhide, and the RHEL base is available as SRPMS. >Sure, a lot of work went into getting multi-arch to function >properly in RHEL, and the fruits of that are already available >to you. To really contribute, one will have to read and >understand first, and the code is there for you to peruse. >Perhaps someone has thrown together a whitepaper on multi-arch >support. Or you can start by looking at the changelogs, >patches, and spec files for things like gcc, binutils, gdb, >glibc, rpm, etc. There really isn't a lot one needs to know/care about to support AMD64. Make sure rpm spec files, Makefiles and other build scripts do not hard code /lib, /usr/lib et al. as directories to look for libraries in, nor for directories to install libraries into. On AMD64 all 64bit libraries are in /lib64, /usr/lib64 etc. This is done by using %{_libdir} instead of /usr/lib in the rpm specfile, and /%{lib} instead of /lib. Similar constructs for other library locations. Some packages need patching to do this, others just need spec file tweaks. It's usually very simple work for each package that takes 5-30 minutes depending on package complexity. As long as the code is 64bit clean, there isn't a lot of other concerns to have. Just search the web for generic 64bit portability notes/papers/HOWTO docs, etc. For multiarch issues, that is what %{_libdir} is for as mentioned above. Never hard code library paths ever. ;o) After building an rpm, do an "rpm -qlp *.rpm" on all of the binary rpms it produced, making sure no files were installed into /usr/lib, /lib, /whatever/lib, etc.. and if so, fix it. ;o) If an app crashes on 64bit but not 32, run it in gdb, and well... um... well, fix it. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Wed Nov 5 12:00:39 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 5 Nov 2003 07:00:39 -0500 (EST) Subject: Disabling /tmp watch in RawHide In-Reply-To: <1067890175.2582.33.camel@wvanl14.resnet.neu.edu> References: <1067890175.2582.33.camel@wvanl14.resnet.neu.edu> Message-ID: On Mon, 3 Nov 2003, Stan Bubrouski wrote: >Over the last four years I have found and reported several >vulnerabilities in various apps that have use /tmp insecurely. A >great many of them were discovered by merely looking in /tmp >once a week or so at some of the files left behind. > >By default you guys have tmpwatch turned on, and I think that in >RawHide and test builds this should be disabled so these kinds of >security bugs can be found easier before releases. Yes I know /tmp >can get messy with legitimate files (though most of the files left in >/tmp SHOULD NOT be there), however I think the benefits of disabling by >default on testing environments will get a great many more eyes spotting >general bugs with some program /tmp usage. > >For instance I installed Fedora Core Test 3 release last weekend. I >turned off tmpwatch, and voila, without even trying I found 4 insecure >file uses between 3 packages. I did nothing to find these except ls >through my /tmp and then track down the offenders. I guess this is >probably something that will be debated, or shot down immediately, but >still I'm throwing it out there. Without tmpwatch people WILL notice >more insecure /tmp usage, even if by only the broken usages (i.e. >leaving the files behind). Any thoughts? This is IMHO an absolutely fantastic idea. I'm forwarding it internally in case any shmuckheads aren't reading this list. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From buildsys at porkchop.devel.redhat.com Wed Nov 5 12:09:47 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Wed, 5 Nov 2003 07:09:47 -0500 Subject: rawhide report: 20031105 changes Message-ID: <200311051209.hA5C9ln28981@porkchop.devel.redhat.com> Removed package openoffice.org Removed package fedora-release Removed package lm_sensors Removed package apmd Removed package memtest86 Removed package kon2 Removed package festival Removed package lilo Removed package pstack Removed package mkbootdisk Removed package redhat-lsb Removed package hwcrypto Removed package memprof Removed package kernel-pcmcia-cs Removed package emacspeak Removed package awesfx Updated Packages: rpmdb-fedora-1-0.20031105 ------------------------- From mharris at redhat.com Wed Nov 5 12:20:15 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 5 Nov 2003 07:20:15 -0500 (EST) Subject: Question about development languages In-Reply-To: <20031104075700.C12202@devserv.devel.redhat.com> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> Message-ID: On Tue, 4 Nov 2003, Michael K. Johnson wrote: >> > I was browsing the Fedora website and noticed that the configuration tools >> > are said to be all Python based with a few PyGTK ones. I don't know Python >> > at all but am very familiar with Perl and PerlTk. Do the tools HAVE to be >> > written in Python or are other languages acceptable? >> >> I am in the same boat as you. I know perl and wanted to help with this also >> but when I asked the impression I got is they would like the consistancy. So >> TK libs, gtk2-perl, etc isn't a dependancy during installation. I tend to agree >> now. I guess we have to wait for the python guys to add those tools. > >Hmm, it's my opinion that anyone able to learn Perl would find Python >trivial, but I guess that's just an opinion. My experience, though, >is that I was pretty normal in being able to write maintainable Python >code the first day I started learning it -- I've heard the same from >lots of other people. > >The real challenge here is probably not moving from Perl to Python, >but rather moving from Tk to GTK. Takes a perl programmer about 2-3 days to grasp most aspects of python, with some python.org sifting, it is pretty easy. Within a week or two, most normal things are learned easily without needing a book or other docs other than the web IMHO. Eric Raymond's comments about python vs. perl convinced me to learn python. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Wed Nov 5 12:23:38 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 5 Nov 2003 07:23:38 -0500 (EST) Subject: Question about development languages In-Reply-To: <1067984281.1146.13.camel@agnes.fremen.dune> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> <1067984281.1146.13.camel@agnes.fremen.dune> Message-ID: On Tue, 4 Nov 2003, Jean Francois Martinez wrote: >Humm, ever tried to read a shell script exceeding a few dozens >of lines? Nearly by definition, shell languages are oriented far >more toward interactive use than for even moderately >sophisticated programming tasks (and still more inadequate if >the script is not "Use and throw" but is supposed to be >maintained). That's kindof funny actually... I write shell scripts almost exclusively for automation and other small short tasks that are non-interactive. Any task that would have any interactivity at all, I naturally reach for python, C, or perl roughly in that order. I almost never ever write interactive shell scripts, as the syntax is quite obscure compared to python or C. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Wed Nov 5 12:30:36 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 5 Nov 2003 07:30:36 -0500 (EST) Subject: Question about development languages In-Reply-To: <20031104130217.GA22753@thyrsus.com> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> Message-ID: On Tue, 4 Nov 2003, Eric S. Raymond wrote: >Michael K. Johnson : >> Hmm, it's my opinion that anyone able to learn Perl would find Python >> trivial, but I guess that's just an opinion. My experience, though, >> is that I was pretty normal in being able to write maintainable Python >> code the first day I started learning it -- I've heard the same from >> lots of other people. >> >> The real challenge here is probably not moving from Perl to Python, >> but rather moving from Tk to GTK. > >I've had experience with this kind of migration. Agreed on both counts. Speak of the devil. ;o) Didn't notice you were in this thread prior to my last response. ;o) Actually, it was both your comments found linked off python.org and also Yoda's knowledge linked off python.org that convinced me. The "understand it in 6 months" part in particular. It made me realize how many times I had written a perl script of a few pages in length, then tried to modify it a few weeks or months later. It was worse than trying to understand uncommented assembler quite often, and it was never what I'd call spaghetti perl. Perl is just cryptic by nature, whereas python is hard-to-be-cryptic by nature. After reading your comments of finally reading the python book and giving it a shot, then realizing all the benefits, and more or less switching to python from perl overnight, I decided it had to be worth spending at least 3-4 days poking around with python to find out for myself. I don't know any developer who has used perl, then used python for 4-5 days who prefers perl still. I do still like perl for quickie one liners, and <= 20-30 line sed'ish scripting though. regex heavy stuff that is short tends to be cryptic in any language and perl's just a simpler syntax for short cryptic junk. Beyond that though, I now reach for python. TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From rezso at rdsor.ro Wed Nov 5 12:35:35 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Wed, 5 Nov 2003 14:35:35 +0200 Subject: rawhide report: 20031105 changes [What ? no more OOo ?] In-Reply-To: <200311051209.hA5C9ln28981@porkchop.devel.redhat.com> References: <200311051209.hA5C9ln28981@porkchop.devel.redhat.com> Message-ID: <200311051435.35319.rezso@rdsor.ro> On Wednesday 05 November 2003 14:09, Build System wrote: > Removed package openoffice.org ?!? no more openoffice.org or what ? > > Removed package fedora-release And thats one why ? > > Removed package lm_sensors > > Removed package apmd > > Removed package memtest86 > > Removed package kon2 > > Removed package festival > > Removed package lilo > > Removed package pstack > > Removed package mkbootdisk > > Removed package redhat-lsb > > Removed package hwcrypto > > Removed package memprof > > Removed package kernel-pcmcia-cs > > Removed package emacspeak > > Removed package awesfx > > Updated Packages: > > rpmdb-fedora-1-0.20031105 > ------------------------- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From pauln at truemesh.com Wed Nov 5 12:52:56 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 5 Nov 2003 12:52:56 +0000 Subject: Bug Day Episode IV - A New Hope Message-ID: <20031105125250.GC31078@shitake.truemesh.com> Yet again Wednesday has arrived, it's time to head over to your friendly cantina at #fedora-bugs and do some triaging. Same drill as usual - sticking with theme of blockers only 66 left there. If people are good we can choose a new and exciting theme for next week :) http://www.fedora.us/wiki/FedoraTriage For those who want even more details - the original Bug Day post can be found here - http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00681.html Paul From behdad at cs.toronto.edu Wed Nov 5 13:01:45 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Wed, 5 Nov 2003 08:01:45 -0500 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068028146.9794.6.camel@ulysse.olympe.o2t> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068023194.8102.20.camel@ulysse.olympe.o2t> <1068027413.3612.4.camel@max.localdomain> <1068028146.9794.6.camel@ulysse.olympe.o2t> Message-ID: On Wed, 5 Nov 2003, Nicolas Mailhot wrote: > Btw there should probably be a gateway to hotplug/dbus people somewhere. And perhaps hal in the future. > Cheers, From behdad at cs.toronto.edu Wed Nov 5 13:08:08 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Wed, 5 Nov 2003 08:08:08 -0500 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1068028200.3471.18.camel@localhost.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068028200.3471.18.camel@localhost.localdomain> Message-ID: On Wed, 5 Nov 2003, Julien Olivier wrote: > Aaargh, forget my proposition... it is stupid because it needs the user > to _know_ what hardware he has and fill everything himself. I understand > that a GUI application would have the advantage to be able to > "auto-detect" the hardware and do most of the work for the user. > > That said, it could still be done the following way: > > - When you click on "report my hardware", a cookie is generated > containing all the information required automatically. > - The website is opened, reads the cookie and pre-fills the form > - The user can modify the defaults choices and validates > > The drawback: > > - if your navigator is configured to refuse cookies, you're screwed... This is a non-issue. What about this: App (no GUI) collects needed info, POSTs that to the website, acquires a session-id, launches browser with the session-id. BTW, offering the service at the right time is quite important. Say, when the hotplug/kudzu/... fails to configure a device, should offer the user to report that. behdad From tdiehl at rogueind.com Wed Nov 5 13:11:35 2003 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 5 Nov 2003 08:11:35 -0500 (EST) Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1067999934.11320.79.camel@laptop> Message-ID: On Tue, 4 Nov 2003, Warren Togami wrote: > As long as the topic contains "Windows" this seems like a good time to > mention what I saw in recent Windows betas that I thought was a really > good idea. When Windows was unable to find a built-in driver for an > unknown piece of hardware, it searched a database on the Internet. > While this mechanism was useless in the AMD64 Windows beta that I tried > since ZERO DRIVERS were available, I really see the potential for us to > harness this same idea. AFAIK it has been in windoze since W2K. I have used it many times. You just need the NIC drivers installed and working and the rest is pretty much automagic. > In addition to simply submitting data, our system should be able to pull > up links to more information about the specific hardware that we are > using. Very often workarounds exist for problems, and it would save us > even more time if users learned about them automatically. +1 -- ......Tom Registered Linux User #14522 http://counter.li.org tdiehl at rogueind.com My current SpamTrap -------> mtd123 at rogueind.com From julo at altern.org Wed Nov 5 13:37:43 2003 From: julo at altern.org (Julien Olivier) Date: Wed, 05 Nov 2003 13:37:43 +0000 Subject: RH recommends using Windows? plus a Question! In-Reply-To: References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068028200.3471.18.camel@localhost.localdomain> Message-ID: <1068039463.3973.8.camel@localhost.localdomain> On Wed, 2003-11-05 at 13:08, Behdad Esfahbod wrote: > On Wed, 5 Nov 2003, Julien Olivier wrote: > > > Aaargh, forget my proposition... it is stupid because it needs the user > > to _know_ what hardware he has and fill everything himself. I understand > > that a GUI application would have the advantage to be able to > > "auto-detect" the hardware and do most of the work for the user. > > > > That said, it could still be done the following way: > > > > - When you click on "report my hardware", a cookie is generated > > containing all the information required automatically. > > - The website is opened, reads the cookie and pre-fills the form > > - The user can modify the defaults choices and validates > > > > The drawback: > > > > - if your navigator is configured to refuse cookies, you're screwed... > > This is a non-issue. What about this: App (no GUI) collects > needed info, POSTs that to the website, acquires a session-id, > launches browser with the session-id. Technically, it's a good idea but I can already hear comments about how Fedora spies its users by sending reports of their users' hardware without any human intervention... More over, it could well be that you don't want your hardware information (all or partially) to be sent to Fedora (for any reason). But maybe a solution could be to allow users to configure which kind of information can/cannot be sent to Fedora. For example, it could be configured at install time or in the firstboot tool. > BTW, offering the service > at the right time is quite important. Say, when the > hotplug/kudzu/... fails to configure a device, should offer the > user to report that. > Of course, that would be very smart and useful. > behdad > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Julien Olivier From m.hander at el-me.de Wed Nov 5 13:51:45 2003 From: m.hander at el-me.de (Hander Martin) Date: Wed, 5 Nov 2003 14:51:45 +0100 Subject: universal bootloader and embedded linux are not working properly Message-ID: <367ED8C46538D7119DAC000A0D1067444B5E67@elmegmbh.elmedmn.com> Hello, I'm setting up a new board and I use the universal bootloader and embedded linux for this. I can boot the board with this programs, but there exists a problem with the ethernet connection. When I boot the universal bootloader, then start the embedded linux and then call ifconfig with some parameters I don't get an ethernet connection. In the output of the starting linux I get a mac adress like this: 00:00:00:00:00:00. When I boot the universal bootloader and enter dhcp then I receive an ethernet adress from my dhcp server. Then I start embedded linux and make an ifconfig call for assigning an ip adress to my board then I get an ethernet connection. In the output of the starting linux I get a valid mac adress. I know, that this problem can also be a problem of the universal bootloader, but I want to be sure about who is responsible for this malfunction. if somebody knows a way to go around this problem and knows how to automatically receive an ethernet connection I would be very thankful. If somebody knows how to solve this problem or knows where the bug is I would also be very thankful. Thanks Martin Hander M.Hander at el-me.de From alan at redhat.com Wed Nov 5 13:53:52 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 5 Nov 2003 08:53:52 -0500 (EST) Subject: Disabling /tmp watch in RawHide In-Reply-To: from "Mike A. Harris" at Tach 05, 2003 07:00:39 Message-ID: <200311051353.hA5Drqi16426@devserv.devel.redhat.com> > >more insecure /tmp usage, even if by only the broken usages (i.e. > >leaving the files behind). Any thoughts? > > This is IMHO an absolutely fantastic idea. I'm forwarding it > internally in case any shmuckheads aren't reading this list. ;o) Even more fun is to hack your login tools (I guess pam_ somewhere to do it properly) to create a seperate /tmp for each login tree of processes now that Linux supports namespaces From Nicolas.Mailhot at laPoste.net Wed Nov 5 13:55:48 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 05 Nov 2003 14:55:48 +0100 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1068039463.3973.8.camel@localhost.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068028200.3471.18.camel@localhost.localdomain> <1068039463.3973.8.camel@localhost.localdomain> Message-ID: <1068040547.11359.6.camel@ulysse.olympe.o2t> Le mer 05/11/2003 ? 14:37, Julien Olivier a ?crit : > On Wed, 2003-11-05 at 13:08, Behdad Esfahbod wrote: > > On Wed, 5 Nov 2003, Julien Olivier wrote: > > BTW, offering the service > > at the right time is quite important. Say, when the > > hotplug/kudzu/... fails to configure a device, should offer the > > user to report that. > > > > Of course, that would be very smart and useful. Gosh, yet another reason to kill kudzu/firstboot on sight. Let's not annoy users with this ok ? Enough people will submit this info willingly if the tool is well made you don't need to force-feed it to users. Last I've seen the pci db maintains itself well enough without any of this crap. Put big notices on bugzilla startup pages, default index.html, etc if you want but do not resort to any M$-like "were do we want you to go today" automated junkware. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From davej at redhat.com Wed Nov 5 14:02:49 2003 From: davej at redhat.com (Dave Jones) Date: Wed, 5 Nov 2003 14:02:49 +0000 Subject: AMD 64 support In-Reply-To: References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> <20031103140349.B1468@lnxi.com> Message-ID: <20031105140249.GC5392@redhat.com> On Wed, Nov 05, 2003 at 06:48:27AM -0500, Mike A. Harris wrote: > We need to have some time ourselves to volunteer to do some of > the things that need to be done. The most major thing for each > architecture without question, is the kernel. The kernel needs > work done for every architecture, and that is a LOT of hard work > that needs experienced knowledgeable kernel guru hands on it. > Right now Dave Jones I hear is hacking on the > AMD64 kernel for Fedora Core 1. I don't know if any other kernel > folk are working with Dave on that or if he's doing it himself. RHEL AMD64 guru Jim Paradis has lent a hand, and most of the nptl fixes in the current Fedora kernel are based on the work he did for RHEL. Thanks Jim 8-) > Wrong. Rawhide has the latest of everything. We're not holding > back or hiding *ANYTHING*. Fedora Core and rawhide contain the > absolute latest support for anything and everything we have to > offer. Except when the packages are really experimental, when they end up on our people pages instead. (http://people.redhat.com/davej/amd64 for example) > This wont happen overnight, and neither will an AMD64 port of > Fedora, nor an Alpha port - both of which I'm interested in. Indeed. Whilst amd64 kernel is proceeding, it's a spare time project, which has to compete with other spare time projects which all compete for 'spare' time. Yesterday I spent the day chasing RAID problems so no work at all got done on amd64 for eg. It'll all happen, it just takes time. Dave From jeremyp at pobox.com Wed Nov 5 14:10:32 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: Wed, 05 Nov 2003 09:10:32 -0500 Subject: AMD 64 support In-Reply-To: References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> <20031103140349.B1468@lnxi.com> Message-ID: <1068041432.24282.13.camel@jeremy.dtcc.cc.nc.us> On Wed, 2003-11-05 at 06:48, Mike A. Harris wrote: > On Mon, 3 Nov 2003, Mike Snitzer wrote: > >We may even want a new fedora-amd64-devel at fedora.redhat.com > >mailing list for the cause. Actually it might be nice if a > >fedora--devel mailing list were created for each > >architecture the Fedora community deems worthy. > > Personally I'm on about 130 mailing lists. I really don't need > another one. People are too quick to create new mailing lists > nowadays unnecessarily. All 3 existing fedora lists are for the > most part identical off topic clones of each other, and a new > list would probably just add a 4th clone list. fedora-devel-list > is the best place to have these discussions and hit everyone in > one spot. If the volume of per arch discussion really grows to > the size that it warrants another mailing list then that is > something to consider, but doing it prematurely is just > personally an annoyance at least to me. Others may feel > differently of course. FWIW, there already is a list for AMD64 discussion, though it seems to get only a limited amount of traffic. http://www.redhat.com/mailman/listinfo/amd64-list This was created for the "GinGin64" technology preview, which was a sort of "alpha" prior to the Taroon beta for RHEL 3, but it could be used for generic RHL/Fedora discussion for AMD64. --Jeremy -- /---------------------------------------------------------------------\ | Jeremy Portzer jeremyp at pobox.com trilug.org/~jeremy | | GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 | \---------------------------------------------------------------------/ -------------- 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 julo at altern.org Wed Nov 5 14:12:02 2003 From: julo at altern.org (Julien Olivier) Date: Wed, 05 Nov 2003 14:12:02 +0000 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1068040547.11359.6.camel@ulysse.olympe.o2t> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068028200.3471.18.camel@localhost.localdomain> <1068039463.3973.8.camel@localhost.localdomain> <1068040547.11359.6.camel@ulysse.olympe.o2t> Message-ID: <1068041521.17617.3.camel@localhost.localdomain> > Gosh, yet another reason to kill kudzu/firstboot on sight. > Let's not annoy users with this ok ? > > Enough people will submit this info willingly if the tool is well made > you don't need to force-feed it to users. Last I've seen the pci db > maintains itself well enough without any of this crap. > > Put big notices on bugzilla startup pages, default index.html, etc if > you want but do not resort to any M$-like "were do we want you to go > today" automated junkware. > I'm not sure I understand how this is junkware... I mean that if I install a new piece of hardware I've just bought and get an error message stating that this hardware isn't supported/doesn't work with my Linux distribution, I would be glad to know that I can easily report this to my distribution vendor so that I can soon enjoy my new hardware (and I really mean it :)). But maybe I'm the only one in this case ? > Regards, -- Julien Olivier From pete.s.bradbury at btinternet.com Wed Nov 5 14:29:42 2003 From: pete.s.bradbury at btinternet.com (Pete Bradbury) Date: Wed, 5 Nov 2003 14:29:42 -0000 Subject: AMD 64 support - non techie perpective References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> <20031103140349.B1468@lnxi.com> Message-ID: <001e01c3a3a9$412b8ec0$0100a8c0@shubunkin> As I unwittingly opened the (other thread 'AMD 6 support') can of worms, then can I make this request. I'm no Linux guru - I just like what it (RH) has to offer. I was introduced to and purchased my first and only copy of RH 6.1, upgrading for free until now the 9.0. One great cooperative system which must 'cost' RH quite a number of dollars to support. I like the familiar RH installer and the 'standard' whereabouts of things, and am apprehensive of having to relearn if things are to be changed under fedora. Now however I'm feeling a bit deserted on two counts 1 RH changes to Fedora (for me that is) - what happens to update notifications - does that stay the same? 2 Just as this was announced I 'enhanced' my home system to run the AMD 64 - now what should I run on it? The new fedora (I tried it doesn't) or try a RH9.0 (which I haven't) instal? RH has produced great products - THANKS - , but as a non guru techie, type, a simpler fedora interface on the web site to non techie RH users, might cause less panic, and greater ressurance. Hand holding has always been a heartwarming component of the linux community and only once or twice has RTFM been addressed to me. >From what I've read so far on this thread I think I need to be patient and just hang on, correct? Do nothing? Don't use my AMD 64 for linux? I wait for a crash of thunder ... From sopwith at redhat.com Wed Nov 5 14:31:03 2003 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 5 Nov 2003 09:31:03 -0500 (EST) Subject: fedora DVD In-Reply-To: <200311051058.42903.eendebak@math.uu.nl> Message-ID: On Wed, 5 Nov 2003, Pieter Eendebak wrote: > Would it be possible to create an iso image containing the complete fedora > distribution that can be burned onto a DVD disc? It should be there for FC1. But no guarantees, -- Elliot "I lead a very full life. I belong to a handful of chat rooms." - Blofeld From dcbw at redhat.com Wed Nov 5 14:43:48 2003 From: dcbw at redhat.com (Dan Williams) Date: Wed, 05 Nov 2003 09:43:48 -0500 Subject: rawhide report: 20031105 changes [What ? no more OOo ?] In-Reply-To: <200311051435.35319.rezso@rdsor.ro> References: <200311051209.hA5C9ln28981@porkchop.devel.redhat.com> <200311051435.35319.rezso@rdsor.ro> Message-ID: <1068043428.8679.0.camel@dhcp64-188.boston.redhat.com> News to me. I tend to think its an error... Dan On Wed, 2003-11-05 at 07:35, Balint Cristian wrote: > On Wednesday 05 November 2003 14:09, Build System wrote: > > Removed package openoffice.org > > ?!? no more openoffice.org or what ? From darryl at snakegully.nu Wed Nov 5 14:53:20 2003 From: darryl at snakegully.nu (Darryl Luff) Date: Thu, 06 Nov 2003 01:53:20 +1100 Subject: Self-Introduction: Darryl Luff Message-ID: <3FA90EE0.3020200@snakegully.nu> Full Name: Darryl Luff Country, City: Australia, Canberra Profession: IT Security/Consulting Goals in Fedora: My aim is that packages for every program I use regularly are in Fedora. I would be happy to do QA once I am really familiar with the process. Historical Qualifications: I have worked on many small software projects since I started programming around 1984, but nothing huge. I've contributed ad-hoc patches to open source software and documentation as I've found bugs, and maintain the 'gtksql' and 'snakegully' projects on Sourceforge. I have used Redhat Linux continuously since version 3.0.3 and been involved with the online community with BBS's, then Fidonet, and now the internet. I started programming in assembler then went (briefly) to C then 'upgraded' to Pascal and Java. For the past few years I have unfortunately had to use C, although I still don't like it. I also use Perl a lot. You shouldnt really trust me any more than you trust anyone else, but I do appreciate the need for procedures and documentation and why they are important in any project, especially those with large groups of developers. Good luck all! [darryll at dad darryll]$ gpg --fingerprint 1B8FDF72 pub 1024D/1B8FDF72 2003-04-26 Darryl Luff Key fingerprint = AD43 1958 D755 8943 8CDD 3C79 1360 C6CF 1B8F DF72 sub 1024g/A2D1C621 2003-04-26 [expires: 2005-04-25] From rezso at rdsor.ro Wed Nov 5 14:54:01 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Wed, 5 Nov 2003 16:54:01 +0200 Subject: rawhide report: 20031105 changes [What ? no more OOo ?] In-Reply-To: <1068043428.8679.0.camel@dhcp64-188.boston.redhat.com> References: <200311051209.hA5C9ln28981@porkchop.devel.redhat.com> <200311051435.35319.rezso@rdsor.ro> <1068043428.8679.0.camel@dhcp64-188.boston.redhat.com> Message-ID: <200311051654.01501.rezso@rdsor.ro> On Wednesday 05 November 2003 16:43, Dan Williams wrote: > News to me. I tend to think its an error... Oh sory, i looked and just the "duplicated" version of Ooo was removed .... There was duplicates of packages in SRPMS ... Sorry for bugging but only than seen the rawhide ... > > Dan > > On Wed, 2003-11-05 at 07:35, Balint Cristian wrote: > > On Wednesday 05 November 2003 14:09, Build System wrote: > > > Removed package openoffice.org > > > > ?!? no more openoffice.org or what ? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From Nicolas.Mailhot at laPoste.net Wed Nov 5 14:55:51 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 05 Nov 2003 15:55:51 +0100 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1068041521.17617.3.camel@localhost.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068028200.3471.18.camel@localhost.localdomain> <1068039463.3973.8.camel@localhost.localdomain> <1068040547.11359.6.camel@ulysse.olympe.o2t> <1068041521.17617.3.camel@localhost.localdomain> Message-ID: <1068044150.11931.8.camel@ulysse.olympe.o2t> Le mer 05/11/2003 ? 15:12, Julien Olivier a ?crit : > I'm not sure I understand how this is junkware... I mean that if I > install a new piece of hardware I've just bought and get an error > message stating that this hardware isn't supported/doesn't work with my > Linux distribution, I would be glad to know that I can easily report > this to my distribution vendor so that I can soon enjoy my new hardware > (and I really mean it :)). But maybe I'm the only one in this case ? What I meant is kudzu will fail, and re-fail at each boot, sometimes you have parks of hardware that will each fail in the same way, and I don't ever want to see "do you really, really, really not want to report" popups on 20 boxes at every boot. Put a reference in the release notes, put in in the default index.html, put it on bugzilla startup page, but do not put ever think to put it in startup scripts. It's bad enough every single RH server I've seen have startup/shutdown failures because someone assumed you have to have a sound card in each and every system, without someone adding "helpful" hints yo report hardware problems then. Let the user choose how and when he wants to report. Do not try to "help" it make the decision. 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 sean at compu-aid.net Wed Nov 5 15:31:03 2003 From: sean at compu-aid.net (Sean Millichamp) Date: 05 Nov 2003 10:31:03 -0500 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068016387.6414.42.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> Message-ID: <1068046262.7278.7.camel@pc01.wks.enertronllc.com> On Wed, 2003-11-05 at 02:13, Maxwell Kanat-Alexander wrote: > > Primary Purpose of the System: To allow users to know if their hardware > works with Fedora/Red Hat Linux. When cataloging hardware things like PCI ids and chipsets obviously need to be tracked because ultimately that is what Linux tends to care about and that seems to be what most of the discussion is around. However, from a user's standpoint they are much more likely to be looking at brand names and models. I think it is very important that if there is no way to conclusively determine a brandname/model from the hardware systematically then there should be a spot for the user to enter the brand and model as the product is sold and marketed. I can do all the legwork finding a motherboard, looking up what northbridge and southbridge it has on it and then searching the web for any reports of problems with Linux but the average user isn't likely to ever get more detailed then saying "I have a motherboard made by XXXX, it's model number is YYYY, and the revision is ZZZ". Actually, even getting the revision might be too much for most. This sort of brand/model information will help people select Linux compatible components before they ever purchase anything without having to become experts on all the chipsets that go into it. Sean From julo at altern.org Wed Nov 5 15:38:24 2003 From: julo at altern.org (Julien Olivier) Date: Wed, 05 Nov 2003 15:38:24 +0000 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1068044150.11931.8.camel@ulysse.olympe.o2t> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068028200.3471.18.camel@localhost.localdomain> <1068039463.3973.8.camel@localhost.localdomain> <1068040547.11359.6.camel@ulysse.olympe.o2t> <1068041521.17617.3.camel@localhost.localdomain> <1068044150.11931.8.camel@ulysse.olympe.o2t> Message-ID: <1068046704.29481.2.camel@localhost.localdomain> On Wed, 2003-11-05 at 14:55, Nicolas Mailhot wrote: > Le mer 05/11/2003 ? 15:12, Julien Olivier a ?crit : > > > I'm not sure I understand how this is junkware... I mean that if I > > install a new piece of hardware I've just bought and get an error > > message stating that this hardware isn't supported/doesn't work with my > > Linux distribution, I would be glad to know that I can easily report > > this to my distribution vendor so that I can soon enjoy my new hardware > > (and I really mean it :)). But maybe I'm the only one in this case ? > > What I meant is kudzu will fail, and re-fail at each boot, sometimes you > have parks of hardware that will each fail in the same way, and I don't > ever want to see "do you really, really, really not want to report" > popups on 20 boxes at every boot. > OK, there I fully agree with you. If it has to happen, it should happen only once. > Put a reference in the release notes, put in in the default index.html, > put it on bugzilla startup page, but do not put ever think to put it in > startup scripts. > > It's bad enough every single RH server I've seen have startup/shutdown > failures because someone assumed you have to have a sound card in each > and every system, without someone adding "helpful" hints yo report > hardware problems then. Let the user choose how and when he wants to > report. Do not try to "help" it make the decision. > I too agree that kudzu should be deactivated by default on servers. But we aren't talking of servers here, are we ? > Cheers, -- Julien Olivier From Nicolas.Mailhot at laPoste.net Wed Nov 5 15:51:48 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 05 Nov 2003 16:51:48 +0100 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068046262.7278.7.camel@pc01.wks.enertronllc.com> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068046262.7278.7.camel@pc01.wks.enertronllc.com> Message-ID: <1068047508.12258.3.camel@ulysse.olympe.o2t> Le mer 05/11/2003 ? 16:31, Sean Millichamp a ?crit : > On Wed, 2003-11-05 at 02:13, Maxwell Kanat-Alexander wrote: > > > > Primary Purpose of the System: To allow users to know if their hardware > > works with Fedora/Red Hat Linux. > > When cataloging hardware things like PCI ids and chipsets obviously need > to be tracked because ultimately that is what Linux tends to care about > and that seems to be what most of the discussion is around. > > However, from a user's standpoint they are much more likely to be > looking at brand names and models. I think it is very important that if > there is no way to conclusively determine a brandname/model from the > hardware systematically then there should be a spot for the user to > enter the brand and model as the product is sold and marketed. Ie use the pci db and feed it too. Manufacturer is usually not too difficult to guess (with pci and usb devices). Model is not (even under other OSes). Of course, you always have the problem of "branded" mass-market hardware, when the id returned is the OEM one and the shiny logo on the box something else. 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 Wed Nov 5 16:00:58 2003 From: davej at redhat.com (Dave Jones) Date: Wed, 5 Nov 2003 16:00:58 +0000 Subject: AMD 64 support - non techie perpective In-Reply-To: <001e01c3a3a9$412b8ec0$0100a8c0@shubunkin> References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> <20031103140349.B1468@lnxi.com> <001e01c3a3a9$412b8ec0$0100a8c0@shubunkin> Message-ID: <20031105160058.GD5392@redhat.com> On Wed, Nov 05, 2003 at 02:29:42PM -0000, Pete Bradbury wrote: > 2 Just as this was announced I 'enhanced' my home system to run the AMD 64 - > now what should I run on it? The new fedora (I tried it doesn't) I don't recall seeing this in bugzilla. Dave From razvan.vilt at linux360.ro Wed Nov 5 16:19:34 2003 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Wed, 05 Nov 2003 18:19:34 +0200 Subject: fedora DVD In-Reply-To: <3FA8CE2D.5020108@draigBrady.com> References: <200311051058.42903.eendebak@math.uu.nl> <3FA8CE2D.5020108@draigBrady.com> Message-ID: <1068049173.20707.50.camel@home-04019.b.astral.ro> On Wed, 2003-11-05 at 12:17, P at draigBrady.com wrote: > Pieter Eendebak wrote: > > Hi all! > > > > Would it be possible to create an iso image containing the complete fedora > > distribution that can be burned onto a DVD disc? > > 1st hit when searching for dvd in archives > http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00736.html > > P?draig. > Although I don't really enjoy quoting myself... I'll make an exception... By this way you can generate an iso from a distribution tree, because right now only that one is up-to date. You can mirror ftp://ftp.redhat.com/pub/redhat/linux/rawhide/i386... From: Razvan Corneliu C.R. "d3vi1" VILT Reply-To: fedora-test-list at redhat.com To: fedora-test-list at redhat.com Subject: Re: Updated ISO images? Date: Tue, 04 Nov 2003 01:01:21 +0200 (...) I can see that every-one wants iso's... Well if you have a DVD-R I can give you the command to generate an ISO from the distribution tree: cd /$distribution_tree #e.g. cd /opt/mirrors/ftp.redhat.com/pub/redhat/linux/rawhide/i386 mkisofs -A Fedora\ Core\ 1/i386 -V Fedora\ Core\ 1/i386 -J -R -v -T -o fedora-core.RC1-i386-DVD.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table . /usr/lib/anaconda-runtime/implantisomd5 fedora-core.RC1-i386-DVD.iso You can use this command to generate a ~2.2GB iso which is excellent for VMWare or DVD-R's... Ntz...Ntz...Ntz... so impatient... should warn you though that there are absolutely no differences from an updated Severn Test3... Your choice... -- fedora-test-list mailing list fedora-test-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From behdad at cs.toronto.edu Wed Nov 5 16:27:48 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Wed, 5 Nov 2003 11:27:48 -0500 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1068040547.11359.6.camel@ulysse.olympe.o2t> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068028200.3471.18.camel@localhost.localdomain> <1068039463.3973.8.camel@localhost.localdomain> <1068040547.11359.6.camel@ulysse.olympe.o2t> Message-ID: On Wed, 5 Nov 2003, Nicolas Mailhot wrote: > Le mer 05/11/2003 ? 14:37, Julien Olivier a ?crit : > > On Wed, 2003-11-05 at 13:08, Behdad Esfahbod wrote: > > > On Wed, 5 Nov 2003, Julien Olivier wrote: > > > > BTW, offering the service > > > at the right time is quite important. Say, when the > > > hotplug/kudzu/... fails to configure a device, should offer the > > > user to report that. > > > > > > > Of course, that would be very smart and useful. > > Gosh, yet another reason to kill kudzu/firstboot on sight. > Let's not annoy users with this ok ? > > Enough people will submit this info willingly if the tool is well made > you don't need to force-feed it to users. Last I've seen the pci db > maintains itself well enough without any of this crap. > > Put big notices on bugzilla startup pages, default index.html, etc if > you want but do not resort to any M$-like "were do we want you to go > today" automated junkware. There should be a page saying "I couldn't configure yours" (perhaps with a single Ok button). Just put at the other corner, an small button reading "Report ..."... > Regards, From notting at redhat.com Wed Nov 5 16:27:45 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 5 Nov 2003 11:27:45 -0500 Subject: rawhide report: 20031105 changes [What ? no more OOo ?] In-Reply-To: <200311051435.35319.rezso@rdsor.ro>; from rezso@rdsor.ro on Wed, Nov 05, 2003 at 02:35:35PM +0200 References: <200311051209.hA5C9ln28981@porkchop.devel.redhat.com> <200311051435.35319.rezso@rdsor.ro> Message-ID: <20031105112745.A1687@devserv.devel.redhat.com> Balint Cristian (rezso at rdsor.ro) said: > On Wednesday 05 November 2003 14:09, Build System wrote: > > Removed package openoffice.org > > ?!? no more openoffice.org or what ? > > > > > Removed package fedora-release > > And thats one why ? > > > > > Removed package lm_sensors > > > > Removed package apmd > > > > Removed package memtest86 > > > > Removed package kon2 > > > > Removed package festival > > > > Removed package lilo > > > > Removed package pstack > > > > Removed package mkbootdisk > > > > Removed package redhat-lsb > > > > Removed package hwcrypto > > > > Removed package memprof > > > > Removed package kernel-pcmcia-cs > > > > Removed package emacspeak > > > > Removed package awesfx There was an internal compose error and the i386 tree fell out, so all the x86-specific packages fell out. Thanks to the wonders of rsync's max_delete option, this wasn't actually pushed to the live site. Bill From m.a.young at durham.ac.uk Wed Nov 5 16:32:10 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Wed, 5 Nov 2003 16:32:10 +0000 (GMT) Subject: rawhide report: 20031105 changes [What ? no more OOo ?] In-Reply-To: <200311051435.35319.rezso@rdsor.ro> References: <200311051209.hA5C9ln28981@porkchop.devel.redhat.com> <200311051435.35319.rezso@rdsor.ro> Message-ID: On Wed, 5 Nov 2003, Balint Cristian wrote: > On Wednesday 05 November 2003 14:09, Build System wrote: > > Removed package openoffice.org > > ?!? no more openoffice.org or what ? > > > > > Removed package fedora-release > > And thats one why ? > ... This could just be rawhide moving into a post fedora core 1 unstable state. I think in the past it has quite often been several packages short of a distribution. Michael Young From stevelist at silverorange.com Wed Nov 5 16:45:30 2003 From: stevelist at silverorange.com (Steven Garrity) Date: Wed, 05 Nov 2003 12:45:30 -0400 Subject: Redesign of Bugzilla.Redhat.com Message-ID: <3FA9292A.8030409@silverorange.com> Just a quick note to acknowledge the fine redesign of the Redhat's Bugzilla (http://bugzilla.redhat.com/). The updated design makes nice use of CSS for simple and elegant tabs, and also uses Bitstream Vera Sans as the default font. I suspect this as Garrett's doing (http://www.linuxart.com/), but that's just a guess. My regards to the designer, whoever it may have been. Steven Garrity From Nicolas.Mailhot at laPoste.net Wed Nov 5 16:58:20 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 05 Nov 2003 17:58:20 +0100 Subject: RH recommends using Windows? plus a Question! In-Reply-To: References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068028200.3471.18.camel@localhost.localdomain> <1068039463.3973.8.camel@localhost.localdomain> <1068040547.11359.6.camel@ulysse.olympe.o2t> Message-ID: <1068051499.12457.26.camel@ulysse.olympe.o2t> Le mer 05/11/2003 ? 17:27, Behdad Esfahbod a ?crit : > On Wed, 5 Nov 2003, Nicolas Mailhot wrote: > > > Le mer 05/11/2003 14:37, Julien Olivier a crit : > > > On Wed, 2003-11-05 at 13:08, Behdad Esfahbod wrote: > > > > On Wed, 5 Nov 2003, Julien Olivier wrote: > > > > > > BTW, offering the service > > > > at the right time is quite important. Say, when the > > > > hotplug/kudzu/... fails to configure a device, should offer the > > > > user to report that. > > > > > > > > > > Of course, that would be very smart and useful. > > > > Gosh, yet another reason to kill kudzu/firstboot on sight. > > Let's not annoy users with this ok ? > > > > Enough people will submit this info willingly if the tool is well made > > you don't need to force-feed it to users. Last I've seen the pci db > > maintains itself well enough without any of this crap. > > > > Put big notices on bugzilla startup pages, default index.html, etc if > > you want but do not resort to any M$-like "were do we want you to go > > today" automated junkware. > > There should be a page saying "I couldn't configure yours" > (perhaps with a single Ok button). Just put at the other corner, > an small button reading "Report ..."... That's an ok too much. Just do 20 installs on a row or a big integration run with every single app considering "it's just another screen" and you'll start noticing such things. There are no free interactive screens. That's one of the lessons the HiG people learned. -- 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 garrett at redhat.com Wed Nov 5 17:03:53 2003 From: garrett at redhat.com (Garrett LeSage) Date: Wed, 05 Nov 2003 12:03:53 -0500 Subject: Redesign of Bugzilla.Redhat.com In-Reply-To: <3FA9292A.8030409@silverorange.com> References: <3FA9292A.8030409@silverorange.com> Message-ID: <3FA92D79.6030105@redhat.com> Steven Garrity wrote: > Just a quick note to acknowledge the fine redesign of the Redhat's > Bugzilla (http://bugzilla.redhat.com/). > > The updated design makes nice use of CSS for simple and elegant tabs, > and also uses Bitstream Vera Sans as the default font. > > I suspect this as Garrett's doing (http://www.linuxart.com/), but > that's just a guess. My regards to the designer, whoever it may have > been. Steven, Actually I did the Fedora website and Dave Lawrence redid Bugzilla based on the CSS from Fedora. He did ask me a few questions throughout the process, but he did all the work. He did a _great_ job on the site. I still need to update the Bugzilla logo though. (: Garrett From seyman at wanadoo.fr Wed Nov 5 17:07:06 2003 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Wed, 5 Nov 2003 18:07:06 +0100 Subject: Redesign of Bugzilla.Redhat.com In-Reply-To: <3FA9292A.8030409@silverorange.com> References: <3FA9292A.8030409@silverorange.com> Message-ID: <20031105170706.GA9874@orient.maison> On Wed, Nov 05, 2003 at 12:45:30PM -0400, Steven Garrity wrote: > > I suspect this as Garrett's doing (http://www.linuxart.com/), but that's > just a guess. My regards to the designer, whoever it may have been. AOL! Very clear (and much needed, IMHO) design. Emmanuel From msnitzer at lnxi.com Wed Nov 5 17:31:30 2003 From: msnitzer at lnxi.com (Mike Snitzer) Date: Wed, 5 Nov 2003 10:31:30 -0700 Subject: AMD 64 support In-Reply-To: ; from mharris@redhat.com on Wed, Nov 05, 2003 at 06:48:27AM -0500 References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> <20031103140349.B1468@lnxi.com> Message-ID: <20031105103130.E9868@lnxi.com> Mike, First let me thank you for your detailed, heartfelt insight. I was obviously way off base with my comments; and as such made assumptions that offended you and others. However, you did lay it on pretty thick ;) I do appreciate all that RedHat and its' hardworking employees has done. As is evidenced by a recent flame-war (in defense of RedHat) I started on the beowulf.org mailing-list. I suggested people improve Fedora Core as opposed to re-engineering/re-building RHEL3 to serve as the base distro for various HPC clustering Linux distros. http://www.beowulf.org/pipermail/beowulf/2003-November/008459.html http://www.beowulf.org/pipermail/beowulf/2003-November/008472.html How was I supposed to know if RedHat was or wasn't paying their engineers to work on non-x86 architecture support during normal business hours? >From the _outside_ looking in it appeared as though RedHat Inc was purposely pigeonholing Fedora to be x86-only; which led to my erroneous speculation. Sorry for any grief I may have caused you, I *do* really appreciate all the effort; I can't stress that enough. I too _really_ want to contribute amd64 help to Fedora; but my current project at work is all consuming.. hopefully I'll be able to find some time. Regards, Mike > If someone wants to make a list of what needs to be done for > AMD64, PPC or Alpha, by all means, someone start keeping track, > and we can probably put it up on a web page or something. > Actually what would be perfect, would be a public bug tracker > bug, which links to actual bug reports that are issues needing > work. That way we've got individual problems reported and/or > RFEs, as well as a tracker. > > Count me in on AMD64 and Alpha, and many other mad hatters here > too. Dunno who all is interested in PPC, but there are some > internal folk. Perhaps we should have a web page listing > interested volunteers per architecture too? Damn, a wiki would > be nice, and I actually hate wikis. ;o) Sounds good to me. > Anyhow, hopefully I've squelched some conspiracy theories, > Slashdot FUD, and other bogosities now, and we can all work > together on producing real 64bit Fedora Core stuff, and get rid > of this x86 junk. ;oP You have, thanks! From mharris at redhat.com Wed Nov 5 17:37:28 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 5 Nov 2003 12:37:28 -0500 (EST) Subject: rawhide report: 20031105 changes [What ? no more OOo ?] In-Reply-To: <200311051435.35319.rezso@rdsor.ro> References: <200311051209.hA5C9ln28981@porkchop.devel.redhat.com> <200311051435.35319.rezso@rdsor.ro> Message-ID: On Wed, 5 Nov 2003, Balint Cristian wrote: >Date: Wed, 5 Nov 2003 14:35:35 +0200 >From: Balint Cristian >To: fedora-devel-list at redhat.com >Content-Type: text/plain; > charset="utf-8" >List-Id: For developers, developers, developers >Subject: Re: rawhide report: 20031105 changes [What ? no more OOo ?] > >On Wednesday 05 November 2003 14:09, Build System wrote: >> Removed package openoffice.org > >?!? no more openoffice.org or what ? Bwahahahaaha! When I saw that message, I almost sent out a "troll" email myself to say something similar, then I figured some people wouldn't get the humour so I refrained. In hindsight, it was funnier waiting for someone else to do it. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Wed Nov 5 17:41:38 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 5 Nov 2003 12:41:38 -0500 (EST) Subject: AMD 64 support In-Reply-To: <1068041432.24282.13.camel@jeremy.dtcc.cc.nc.us> References: <000c01c3a247$677e3d10$0100a8c0@shubunkin> <20031103140349.B1468@lnxi.com> <1068041432.24282.13.camel@jeremy.dtcc.cc.nc.us> Message-ID: On Wed, 5 Nov 2003, Jeremy Portzer wrote: >> >We may even want a new fedora-amd64-devel at fedora.redhat.com >> >mailing list for the cause. Actually it might be nice if a >> >fedora--devel mailing list were created for each >> >architecture the Fedora community deems worthy. >> >> Personally I'm on about 130 mailing lists. I really don't need >> another one. People are too quick to create new mailing lists >> nowadays unnecessarily. All 3 existing fedora lists are for the >> most part identical off topic clones of each other, and a new >> list would probably just add a 4th clone list. fedora-devel-list >> is the best place to have these discussions and hit everyone in >> one spot. If the volume of per arch discussion really grows to >> the size that it warrants another mailing list then that is >> something to consider, but doing it prematurely is just >> personally an annoyance at least to me. Others may feel >> differently of course. > >FWIW, there already is a list for AMD64 discussion, though it seems to >get only a limited amount of traffic. > >http://www.redhat.com/mailman/listinfo/amd64-list > >This was created for the "GinGin64" technology preview, which was a sort >of "alpha" prior to the Taroon beta for RHEL 3, but it could be used for >generic RHL/Fedora discussion for AMD64. amd64-list is a generic architecture list for the generalized discussion of AMD64 stuff, particularly pertaining to Red Hat products. It's similar in nature to ia64-list (does anyone even post there anymore *grin*) and axp-list for Alpha for example. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From sopwith at redhat.com Wed Nov 5 17:53:14 2003 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 5 Nov 2003 12:53:14 -0500 (EST) Subject: Self-Introduction: Logan Rathbone In-Reply-To: <20031030052745.E260A7267@sitemail.everyone.net> Message-ID: On Wed, 29 Oct 2003, Logan Rathbone wrote: > I hope dearly that I will be permitted to contribute to this wonderful > project, Hello Logan, It's good to read your introduction and know of your interest. I hope that you're finding ways to contribute and getting a handle on the project. Please let me know if there are any questions I can answer or any way I can help make contributing easier. Cheers, -- Elliot From jspaleta at princeton.edu Wed Nov 5 18:53:50 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 05 Nov 2003 13:53:50 -0500 Subject: Triage and You: An experiment in publicly unfunded tracking bugs Message-ID: <1068058430.17378.12.camel@spatula> Good Morning! Picking up on the mustfix and shouldfix tracking bugs for cambridge. I've create a public tracking bug for 'easyfix' bugreports that I hope developers will find is a useful tool to get at low priority trivial bugs they can work on in those oh-so-very-rare moments of free time. The basic idea here is, instead of developers having to troll through the bugzilla bugs they own looking for trivial bugs to fix or community supplied patches that can be tested and applied. They can hopefully use a query to this easyfix tracker and skip the time consuming step of finding the easyfix bugs themselves. If you have 10 minutes for working on low-priority stuff...I want to make it so you spend as little of that 10 minutes as possible searching for easy fixes or submitted patches. I'd appreciate feedback as to whether or not this is going to be a helpful tool for you to be more efficient at digging up some those pesky low-priority bugs. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109188 -jef"all this..and i've only had one cup of coffee today"spaleta -------------- 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 pjones at redhat.com Wed Nov 5 18:55:36 2003 From: pjones at redhat.com (Peter Jones) Date: Wed, 5 Nov 2003 13:55:36 -0500 (EST) Subject: AMD 64 support In-Reply-To: Message-ID: On Wed, 5 Nov 2003, Mike A. Harris wrote: > Red Hat has never to my knowledge produced the operating system for > non-x86 processors except under contract with a vendor who produces > systems for the given processor. This is just plain wrong; we did Alpha and SPARC both for quite some time without being paid to do them. > While x86 is the mainstay, non-x86 processors have traditionally just > not been a viable profitable platform to develop the OS for without > partnerships and contracts to do the work in order to make it > worthwhile. That's probably pretty accurate. -- Peter I was born not knowing and have had only a little time to change that here and there. -- Feynman From jkeating at j2solutions.net Wed Nov 5 19:19:30 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 5 Nov 2003 11:19:30 -0800 Subject: FC has been released. Message-ID: <200311051119.31068.jkeating@j2solutions.net> In case anybody has missed it: http://download.fedora.redhat.com/pub/fedora/linux/core/1/i386/iso/ torrent at http://torrent.dulug.duke.edu -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 maxka at myrealbox.com Wed Nov 5 20:32:01 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 12:32:01 -0800 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068032835.7163.10.camel@laptop.fubar.dk> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068032835.7163.10.camel@laptop.fubar.dk> Message-ID: <1068064320.3427.1.camel@max.localdomain> On Wed, 2003-11-05 at 03:47, David Zeuthen wrote: > May I propose to use the freedesktop.org HAL I'm working on? This > project is supposed to be a database of all hardware on the system, see > > http://freedesktop.org/~hal/spec-0.2-pre/hal-spec.html This sounds like just what I was looking for. Is this data going to be held centrally by freedesktop.org, or is it going to be in a distributed tool? -M From maxka at myrealbox.com Wed Nov 5 20:36:26 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 12:36:26 -0800 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <3FA8D7A1.7040307@terminus.co.uk> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068017876.13574.23.camel@laptop> <1068019644.6414.50.camel@max.localdomain> <3FA8D7A1.7040307@terminus.co.uk> Message-ID: <1068064586.3427.4.camel@max.localdomain> On Wed, 2003-11-05 at 02:57, Stuart Children wrote: > Just a thought: how about linking to [a page about] it from > file:///usr/share/doc/HTML/index.html? This seems like a possible option. Perhaps we collect the initial information about the hardware on firstboot, and then we explain in index.html how to report further difficulty, and that it's a Great Way to Contribute! -M From maxka at myrealbox.com Wed Nov 5 20:41:42 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 12:41:42 -0800 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068028146.9794.6.camel@ulysse.olympe.o2t> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068023194.8102.20.camel@ulysse.olympe.o2t> <1068027413.3612.4.camel@max.localdomain> <1068028146.9794.6.camel@ulysse.olympe.o2t> Message-ID: <1068064901.3427.10.camel@max.localdomain> On Wed, 2003-11-05 at 02:29, Nicolas Mailhot wrote: > this way people can report even if the gui tool is not installed on > their distro). This is an important ability -- that if people have another O/S they can boot up and report problems with, they ought to be able to do it _somehow_. (Not saying that the method they use will be the one everybody uses, but they ought to have a method.) > 1. Ask it from users each time they add a component without full info > (ie bug users till someone completed all the fields for a particular > hardware id) I think that this might work, particularly if we hold a lot of information in a Vendor table so that certain things only have to be worked out once. I'll bet that certain vendors have a way that we could even process the device info and automagically create a link to the driver. I can think of a table structure and program logic right now that could make this optional and easy. > 2. Send a mail to interested groups each time a component is entered (ie > send to linuxprinting.org when people add a new printer, to ati when > people add a new ati card, etc) We ought to allow people to subscribe! Let them know that they can get information. Also, this way they can tell their users "Our hardware works with Red Hat Linux" and be kept up to date on what hardware that's true for. > Btw there should probably be a gateway to hotplug/dbus people somewhere. Oh? Why them specifically? -M From maxka at myrealbox.com Wed Nov 5 20:47:46 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 12:47:46 -0800 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068046262.7278.7.camel@pc01.wks.enertronllc.com> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068046262.7278.7.camel@pc01.wks.enertronllc.com> Message-ID: <1068065266.3427.16.camel@max.localdomain> On Wed, 2003-11-05 at 07:31, Sean Millichamp wrote: > However, from a user's standpoint they are much more likely to be > looking at brand names and models. I think it is very important that if > there is no way to conclusively determine a brandname/model from the > hardware systematically then there should be a spot for the user to > enter the brand and model as the product is sold and marketed. Now this is an interesting point, here. Ideally, we'd be able to determine what we'd need from dmidecode and lspci. However, take the example of my M-Audio Delta 44 (a soundcard with notorious ALSA OSS-emulation problems). lspci reports it as an ICE Ensemble 1712 [Envy24] which is correct if you want the chipset. However, the level of support for different Envy24 cards is actually different. So here's what we do: Allow users to enter the specific name of their hardware. When they do this, they are presented with a drop-down box containing the other entries that users have put in for this PCI id, and an "Other" to put in their own. It's an optional entry. This keeps the data integrity fairly high while allowing us to collect the relevant information. -M From david at fubar.dk Wed Nov 5 20:52:12 2003 From: david at fubar.dk (David Zeuthen) Date: Wed, 05 Nov 2003 21:52:12 +0100 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068064320.3427.1.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068032835.7163.10.camel@laptop.fubar.dk> <1068064320.3427.1.camel@max.localdomain> Message-ID: <1068065532.32434.17.camel@laptop.fubar.dk> On Wed, 2003-11-05 at 21:32, Maxwell Kanat-Alexander wrote: > On Wed, 2003-11-05 at 03:47, David Zeuthen wrote: > > May I propose to use the freedesktop.org HAL I'm working on? This > > project is supposed to be a database of all hardware on the system, see > > > > http://freedesktop.org/~hal/spec-0.2-pre/hal-spec.html > > This sounds like just what I was looking for. Is this data going to be > held centrally by freedesktop.org, or is it going to be in a distributed > tool? > Oh that's a really good question. HAL is a quite new initiative so right now the focus have only been on what is stored on the desktop system and how desktop applications access it. There's been quite a lot of discussion on the xdg-list about the device information file format (I call them .fdi files - for Free Device Information) and the conclusion was that these files will be XML and resemble the Progeny discover file format with few changes. The conclusion was also that for every device a .fdi file is nice to have since it's difficult to know what capabilities a device got. Now, it would be really cool to have deployable software for driving this database that you are suggesting along with a web service or HTTP interface that desktop applications can access so people can download the .fdi files and/or required OS packages with driver software etc. Deployment-wise freedesktop.org could possibly host a database, the Fedora project could host one and maybe, someday, hardware vendors and/or OEM's could host one. Thanks, David From maxka at myrealbox.com Wed Nov 5 20:51:02 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 12:51:02 -0800 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1068046704.29481.2.camel@localhost.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068028200.3471.18.camel@localhost.localdomain> <1068039463.3973.8.camel@localhost.localdomain> <1068040547.11359.6.camel@ulysse.olympe.o2t> <1068041521.17617.3.camel@localhost.localdomain> <1068044150.11931.8.camel@ulysse.olympe.o2t> <1068046704.29481.2.camel@localhost.localdomain> Message-ID: <1068065462.3427.19.camel@max.localdomain> Due to privacy concerns, kudzu interacting with the Hardware Database seems unlikely at this time, though we ought to consider it in the future if we can get a survey that says that many users would be interested in that sort of functionality. Of course, if we did implement it, we'd do it in the least annoying way possible. :-) -M From maxka at myrealbox.com Wed Nov 5 21:06:00 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 13:06:00 -0800 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068065532.32434.17.camel@laptop.fubar.dk> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068032835.7163.10.camel@laptop.fubar.dk> <1068064320.3427.1.camel@max.localdomain> <1068065532.32434.17.camel@laptop.fubar.dk> Message-ID: <1068066360.3427.28.camel@max.localdomain> On Wed, 2003-11-05 at 12:52, David Zeuthen wrote: > There's been quite a lot of discussion on the xdg-list about the device > information file format (I call them .fdi files - for Free Device > Information) and the conclusion was that these files will be XML and > resemble the Progeny discover file format with few changes. All right. Sounds a lot like what we were thinking of, as well. Perhaps our tool could generate these files. Or, instead, perhaps the server could generate them from the database, which would be good since we could keep more up-to-date on file-format changes and it would be easy (at 3 AM, I'd hope) to refresh your entire freedesktop.org DB. > Deployment-wise freedesktop.org could possibly host a database, the > Fedora project could host one and maybe, someday, hardware vendors > and/or OEM's could host one. Sure. Maybe Fedora could host the central information database itself, and freedesktop.org could hold the fdi database. The fdi database would hold the automated access for the HAL, and the Fedora database would host the user-searching-for-hardware-info side. And, of course, if hardware vendors wanted to pitch in somehow as well, nobody would object! :-) It definitely sounds like we could work together on a lot of things! -M From mharris at redhat.com Wed Nov 5 21:14:47 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 5 Nov 2003 16:14:47 -0500 (EST) Subject: AMD 64 support In-Reply-To: References: Message-ID: On Wed, 5 Nov 2003, Peter Jones wrote: >> Red Hat has never to my knowledge produced the operating system for >> non-x86 processors except under contract with a vendor who produces >> systems for the given processor. > >This is just plain wrong; we did Alpha and SPARC both for quite some time >without being paid to do them. It's not wrong in the specific wording that I used, in particular the "to my knowledge" part. I started at Red Hat just after Red Hat Linux 7.0 was released, and every architecture port we've done the entire time that I've been here was contractual, unless I have missed something. Prior to that I have no knowledge of what ports were funded or not, however Sparc was dropped due to lack of commercial interest if that means anything, and so was Alpha after 7.2. I put "to my knowledge" intentionally, so as not to exclude the possibility that there was something done outside of my knowledge prior to my assimilation into The Hat. ;o) >> While x86 is the mainstay, non-x86 processors have traditionally just >> not been a viable profitable platform to develop the OS for without >> partnerships and contracts to do the work in order to make it >> worthwhile. > >That's probably pretty accurate. Until now... Lets change all that. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From kreg at virtual1.net Wed Nov 5 21:20:06 2003 From: kreg at virtual1.net (Kreg Steppe) Date: Wed, 05 Nov 2003 16:20:06 -0500 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1068039463.3973.8.camel@localhost.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068028200.3471.18.camel@localhost.localdomain> <1068039463.3973.8.camel@localhost.localdomain> Message-ID: <3FA96986.3000207@virtual1.net> I would definatly opt-in for something like this. I would also suggest that if there was a problem installing something, and you opt-in have it check the DB for any notes to a solution and display them instead of just reporting it. Julien Olivier wrote: >On Wed, 2003-11-05 at 13:08, Behdad Esfahbod wrote: > > >>On Wed, 5 Nov 2003, Julien Olivier wrote: >> >> >> >>>Aaargh, forget my proposition... it is stupid because it needs the user >>>to _know_ what hardware he has and fill everything himself. I understand >>>that a GUI application would have the advantage to be able to >>>"auto-detect" the hardware and do most of the work for the user. >>> >>>That said, it could still be done the following way: >>> >>> - When you click on "report my hardware", a cookie is generated >>>containing all the information required automatically. >>> - The website is opened, reads the cookie and pre-fills the form >>> - The user can modify the defaults choices and validates >>> >>>The drawback: >>> >>> - if your navigator is configured to refuse cookies, you're screwed... >>> >>> >>This is a non-issue. What about this: App (no GUI) collects >>needed info, POSTs that to the website, acquires a session-id, >>launches browser with the session-id. >> >> > >Technically, it's a good idea but I can already hear comments about how >Fedora spies its users by sending reports of their users' hardware >without any human intervention... More over, it could well be that you >don't want your hardware information (all or partially) to be sent to >Fedora (for any reason). But maybe a solution could be to allow users to >configure which kind of information can/cannot be sent to Fedora. For >example, it could be configured at install time or in the firstboot >tool. > > > >>BTW, offering the service >>at the right time is quite important. Say, when the >>hotplug/kudzu/... fails to configure a device, should offer the >>user to report that. >> >> >> > >Of course, that would be very smart and useful. > > > >>behdad >> >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> From laurent at guerby.net Wed Nov 5 22:03:56 2003 From: laurent at guerby.net (Laurent GUERBY) Date: Wed, 05 Nov 2003 23:03:56 +0100 Subject: Hardware Database In-Reply-To: <1068016387.6414.42.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> Message-ID: <1068069646.8125.100.camel@localhost.localdomain> I've been thinking about something like that in the past few weeks. I believe the project to collect and exploit hardware information could be separated in three parts: 1. Software to collect the hardware data using various tools and producing a harware data file. 2. Storage servers to collect user submitted hardware data files. 3. Software or web service to exploit the data files in storage servers and their mirrors. The simplest possible thing I can think of that would work under this scheme: 1. The file format could be just a compressed text file recalling the software version used, command issued without any filtering: bash$ simple_lhw_collector.sh | gzip > my_lhw_data.gz bash$ zcat my_lhw_data.gz %lhwdata:version:simple_lhw_collector.sh version 0.0.0-pre-alpha0-ok-you-re-warned %lhwdata:usertime:20031105T2223Z %lhwdata:userinfo Anonymous (default of course) %lhwdata:command:cat /proc/version Linux version 2.4.20-20.9 (bhcompile at stripples.devel.redhat.com) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Mon Aug 18 11:45:58 EDT 2003 %lhwdata:command:lspci 00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corp. 82815 815 Chipset AGP Bridge (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corp. 82801BAM ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801BAM IDE U100 (rev 02) 00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 Go] (rev b2) 02:03.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI Audio Accelerator (rev 10) 02:06.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01) 02:0f.0 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller 02:0f.1 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller 02:0f.2 FireWire (IEEE 1394): Texas Instruments PCI4451 IEEE-1394 Controller 07:00.0 USB Controller: NEC Corporation USB (rev 41) 07:00.1 USB Controller: NEC Corporation USB (rev 41) 07:00.2 USB Controller: NEC Corporation USB 2.0 (rev 02) %lwdata:command:... ... %lwdata:end bash$ This should allow us to survive future linux changes in userland tools and to allow people developping more serious harware data file formats or databases to get all the data they need. My estimate is that such a file should be less than 20k compressed. User information should be opt-in of course, with the user telling if she wants to be contacted when new drivers or whatever are available so she can give a hand testing. Developpers are free to write whatever lhw file generator they like (TUI, GUI, Qt, GTK+, PHP, ...), lhw collectors for the enterprise running as a sophisticated distributed system ot collect data on your company harware (ok a bit too much :). 2. The storage servers could be anything such as anonymous ftp upload, web site with upload form, XML services, could be accessed from the data collecting software,... To allow easy collecting and mirroring, a standard flat file and directory could be used by all storage systems and their mirrors, for example the official "fedora" collecting site could be structured as follows: http://www.fedora.us/lhw/200311/20031105/fedora-lhw-000042.gz http://www.fedora.us/lhw/200311/20031105/fedora-lhw-000043.gz So it's easy to mirror and aggregate since it's write once, never move, rename or change (the date is obviously the server date at the time of submission, and the number a serial id for the day). A collecting site could just mirror all files with any technology (ftp mirror, rsync). Big bandwidth mirrors could just offer monthly tar so anyone has an easy access to all the user data. When a user submits something to a storage server, she should get the URL to the collected file, that would do as an id. 3. The fun part is the service part. May be google would index compressed text files (may be served by a transparently uncompressing web server), otherwise anyone is free to develop any software or web site: - we've done our best to collect in a simple way all possible harware data without commiting to a particular database format. In particular we can improve the data collector to follow future Linux developments without changing the existing data. - we made it easy to assemble, mirror and process the hardware data. Everyone as a fair access to it, from the small kernel developper looking for a driver to develop and debug, to the major Linux companies. What do people think about the general idea? May be Red Hat could contribute some data to a first version (probably legal issues, I'm not a lawyer)? I've no idea on the number of systems we should expect, as I said we should be able to host 50 000 systems per gigabyte, and there's no need to have a central server to begin with, so people can contribute their repository URL to the fedora wiki. Laurent From alan at redhat.com Wed Nov 5 22:06:39 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 5 Nov 2003 17:06:39 -0500 (EST) Subject: Hardware Database In-Reply-To: <1068069646.8125.100.camel@localhost.localdomain> from "Laurent GUERBY" at Tach 05, 2003 11:03:56 Message-ID: <200311052206.hA5M6e321045@devserv.devel.redhat.com> One thing in favour of a generic format however (eg XML) is that someone could write a windows version. That way you can also collect stats on stuff that doesnt work.. From laurent at guerby.net Wed Nov 5 22:16:04 2003 From: laurent at guerby.net (Laurent GUERBY) Date: Wed, 05 Nov 2003 23:16:04 +0100 Subject: Hardware Database In-Reply-To: <200311052206.hA5M6e321045@devserv.devel.redhat.com> References: <200311052206.hA5M6e321045@devserv.devel.redhat.com> Message-ID: <1068070563.8125.108.camel@localhost.localdomain> On Wed, 2003-11-05 at 23:06, Alan Cox wrote: > One thing in favour of a generic format however (eg XML) is that > someone could write a windows version. That way you can also > collect stats on stuff that doesnt work.. There's nothing that prevent a window based tool to generate a flat text file in the line of the format I proposed (you just have to be imaginative for :command: sections :). A specialized boot disk or ISO could also do the job and write the file on a vfat fs (USB key?) if any is available, then you could use your favorite Windows & Internet Explorer version to upload the resulting file. The ultimate advantage over XML is that you could post it to lkml or any linux list when you have a problem without getting flames about HTML mails not allowed :) :). Laurent From alan at redhat.com Wed Nov 5 22:16:29 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 5 Nov 2003 17:16:29 -0500 (EST) Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a In-Reply-To: <1068065532.32434.17.camel@laptop.fubar.dk> from "David Zeuthen" at Tach 05, 2003 09:52:12 Message-ID: <200311052216.hA5MGTB26081@devserv.devel.redhat.com> > Oh that's a really good question. HAL is a quite new initiative so right > now the focus have only been on what is stored on the desktop system and > how desktop applications access it. Dumb question - should "provide an XML description for the database" be something each HAL module is defined to do ? From tim at mmto.org Wed Nov 5 22:39:27 2003 From: tim at mmto.org (T. E. Pickering) Date: Wed, 5 Nov 2003 15:39:27 -0700 Subject: Question about development languages In-Reply-To: ; from mharris@redhat.com on Wed, Nov 05, 2003 at 07:30:36AM -0500 References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> Message-ID: <20031105153927.A17129@mmto.org> out of curiosity, how many people out there are using ruby at all? i was a perl hacker for many years and tried to switch to python, but even after a couple months python seemed like a slog compared what i was used to. then one day i picked up a ruby book on a lark and immediately saw the Light. its syntax, especially for regexps, is similar enough to perl to be friendly to old perl mongers, but its support for OO (in fact it's purely OO) and threading is a lot cleaner and easier to use than python's. i still go back to perl, though, when i need to munge data because the PDL module provides plotting and numerical support that's superior to anything yet available for the other scripting languages. we've been using ruby pretty heavily at our observatory for various network tasks and for building guis using the gtk2 bindings at http://ruby-gnome2.sourceforge.jp/. we find it a lot easier to use ruby threading to build dynamic GUIs than perl/python plus gtk's idle/timeout add mechanism. they seem to have done a good job melding ruby's threading with gtk's so it's been quite stable for us when handled carefully. it results in more responsive guis, too. i've been building rpms for ruby-gnome2 for our own use and can clean them up for contribution to fedora if there's demand.. tim -- +--------------------------------------------------------------------+ | T. E. Pickering, Ph.D. | MMT Observatory | | Assoc. Staff Scientist | 933 N. Cherry Ave. | | tim at mmto.org | Tucson, AZ 85721 | | tpickering at tmomail.com (SMS) | (520) 626-3755 | +--------------------------------------------------------------------+ Uncle Ed's Rule of Thumb: Never use your thumb for a rule. You'll either hit it with a hammer or get a splinter in it. From david at fubar.dk Wed Nov 5 22:41:12 2003 From: david at fubar.dk (David Zeuthen) Date: Wed, 05 Nov 2003 23:41:12 +0100 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068066360.3427.28.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068032835.7163.10.camel@laptop.fubar.dk> <1068064320.3427.1.camel@max.localdomain> <1068065532.32434.17.camel@laptop.fubar.dk> <1068066360.3427.28.camel@max.localdomain> Message-ID: <1068072068.32434.33.camel@laptop.fubar.dk> On Wed, 2003-11-05 at 22:06, Maxwell Kanat-Alexander wrote: > On Wed, 2003-11-05 at 12:52, David Zeuthen wrote: > > There's been quite a lot of discussion on the xdg-list about the device > > information file format (I call them .fdi files - for Free Device > > Information) and the conclusion was that these files will be XML and > > resemble the Progeny discover file format with few changes. > > All right. Sounds a lot like what we were thinking of, as well. > > Perhaps our tool could generate these files. > > Or, instead, perhaps the server could generate them from the database, > which would be good since we could keep more up-to-date on file-format > changes and it would be easy (at 3 AM, I'd hope) to refresh your entire > freedesktop.org DB. > Yeah - of course in the ideal situation the device vendor ships the .fdi file on standard media and/or submits it to your database. However, the community will initially have to create these files. Now, .fdi files should also be signed so there must be some way of moderating what comes from your database; maybe some karma/voting system for contributing users would fit the bill here? > > Deployment-wise freedesktop.org could possibly host a database, the > > Fedora project could host one and maybe, someday, hardware vendors > > and/or OEM's could host one. > > Sure. Maybe Fedora could host the central information database itself, > and freedesktop.org could hold the fdi database. The fdi database would > hold the automated access for the HAL, and the Fedora database would > host the user-searching-for-hardware-info side. > > And, of course, if hardware vendors wanted to pitch in somehow as well, > nobody would object! :-) > > > It definitely sounds like we could work together on a lot of things! Definately! I will however concentrate on getting hal 0.2 finished so it works with PCI and USB devices and storage. When that is done I'll look into packaging it for FC1 and see how it fits in. Automated retrival of .fdi files from a database such as yours and signing stuff is something that will come after that Btw, I intend that each device object in HAL to export a lot of device specific information (right now only USB is documented, but I got PCI working as well); perhaps it would be good already now to agree on naming conventions (e.g. I call it usb.bDeviceClass) for specific hardware properties? Thanks, David From david at fubar.dk Wed Nov 5 22:48:14 2003 From: david at fubar.dk (David Zeuthen) Date: Wed, 05 Nov 2003 23:48:14 +0100 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a In-Reply-To: <200311052216.hA5MGTB26081@devserv.devel.redhat.com> References: <200311052216.hA5MGTB26081@devserv.devel.redhat.com> Message-ID: <1068072493.32434.41.camel@laptop.fubar.dk> On Wed, 2003-11-05 at 23:16, Alan Cox wrote: > > Oh that's a really good question. HAL is a quite new initiative so right > > now the focus have only been on what is stored on the desktop system and > > how desktop applications access it. > > Dumb question - should "provide an XML description for the database" > be something each HAL module is defined to do ? > Yes. For every bus-type there are/will be thorough requirements on well-defined hardware specific properties that will always be available for every device on that bus-type. And yeah, generating the XML is easy as python got D-BUS bindings, so it's really as simple as import dbus bus = dbus.Bus(dbus.Bus.TYPE_SYSTEM) hal_service = bus.get_service("org.freedesktop.Hal") hal_manager = hal_service.get_object("/org/freedesktop/Hal/Manager", "org.freedesktop.Hal.Manager") device_names = hal_manager.GetAllDevices() for name in device_names: device = hal_service.get_object(name, "org.freedesktop.Hal.Device") properties = device.GetAllProperties() and then selecting what subset to dump to XML. The spec currently only mentions USB but I also got PCI working.. Thanks, David From pmatilai at welho.com Wed Nov 5 22:53:55 2003 From: pmatilai at welho.com (Panu Matilainen) Date: 06 Nov 2003 00:53:55 +0200 Subject: Question about development languages In-Reply-To: <20031105153927.A17129@mmto.org> References: <003d01c3a2b0$470d3ea0$15f4ac41@k4h8f5> <20031104005532.1ec9434a.pros-n-cons@bak.rr.com> <20031104075700.C12202@devserv.devel.redhat.com> <20031104130217.GA22753@thyrsus.com> <20031105153927.A17129@mmto.org> Message-ID: <1068072835.31964.20.camel@chip.ath.cx> On Thu, 2003-11-06 at 00:39, T. E. Pickering wrote: > out of curiosity, how many people out there are using ruby at all? i > was a perl hacker for many years and tried to switch to python, but > even after a couple months python seemed like a slog compared what i > was used to. then one day i picked up a ruby book on a lark and > immediately saw the Light. its syntax, especially for regexps, is Heh. I've got a "perl head" collague trying to learn python (not really willingly) and he's having somewhat hard time trying to grasp a language where everything isn't based on regexps :) Never had any fondness beyond "have to do it" in regexps myself, python was a nice, safe harbor from that particular hell for me. Oh and yes, this is off-topic in the sense I've never tried ruby, after python the {&%?}#%$1'ness of the overall look of the language drove me away, fast. - Panu - From maxka at myrealbox.com Wed Nov 5 23:27:49 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 15:27:49 -0800 Subject: Hardware Database In-Reply-To: <1068070563.8125.108.camel@localhost.localdomain> References: <200311052206.hA5M6e321045@devserv.devel.redhat.com> <1068070563.8125.108.camel@localhost.localdomain> Message-ID: <1068074868.3427.30.camel@max.localdomain> On Wed, 2003-11-05 at 14:16, Laurent GUERBY wrote: > The ultimate advantage over XML is that you could post > it to lkml or any linux list when you have a problem without getting > flames about HTML mails not allowed :) :). This would be handled by the idea of a "System Card" -- a URL that uniquely identifies a certain system in the database. You could include the link anywhere. -M From maxka at myrealbox.com Thu Nov 6 00:39:26 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 16:39:26 -0800 Subject: Hardware Database In-Reply-To: <200311052206.hA5M6e321045@devserv.devel.redhat.com> References: <200311052206.hA5M6e321045@devserv.devel.redhat.com> Message-ID: <1068079166.3427.37.camel@max.localdomain> On Wed, 2003-11-05 at 14:06, Alan Cox wrote: > One thing in favour of a generic format however (eg XML) is that > someone could write a windows version. That way you can also > collect stats on stuff that doesnt work.. Another thing in favor of it is that it's flexible. We're not in a hurry to make the system, so why not make it as flexible as possible? Of course, this is still the "throw ideas around" stage. Whatever we decide here is best will probably be the initial roadmap of the project, though even that's subject to change over time. -M From maxka at myrealbox.com Thu Nov 6 01:13:59 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 05 Nov 2003 17:13:59 -0800 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068016387.6414.42.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> Message-ID: <1068081239.3427.42.camel@max.localdomain> I'm working on the updated spec/summary with all of the new suggestions added in. It should be up as HTML tomorrow night, most likely, or possibly tomorrow during the day. I'm not entirely sure what web space I'll use for it. If anybody would like to volunteer some web space, I'd be most gratified. It would be up today, but I've got a date. :-) -M From salimma1 at yahoo.co.uk Thu Nov 6 04:08:06 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Thu, 06 Nov 2003 11:08:06 +0700 Subject: Firewire regression on shipped FC 1 kernel Message-ID: <1068091686.7682.29.camel@bushido.localdomain> Hi, As reported in bug # 108916: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108916 I use a Firewire external HDD enclosure that works fine with -1.2105.nptl but not with -1.2115.nptl (which unfortunately ships with the final product). Suspecting the removal of the orlov patch or ACPI changes to be the culprit, as these are the only items in the Changelog between the two releases. FWIW, I tested the kernel under a FC 0.94 install upgraded to 0.95. Regards, Michel From mharris at redhat.com Thu Nov 6 06:38:58 2003 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 6 Nov 2003 01:38:58 -0500 (EST) Subject: Hardware Database In-Reply-To: <200311052206.hA5M6e321045@devserv.devel.redhat.com> References: <200311052206.hA5M6e321045@devserv.devel.redhat.com> Message-ID: On Wed, 5 Nov 2003, Alan Cox wrote: >One thing in favour of a generic format however (eg XML) is that >someone could write a windows version. That way you can also >collect stats on stuff that doesnt work.. There's a rather humourous double entendre in that sentence depending on how you read/interpret it. ;o) Was that intentional? ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From skvidal at phy.duke.edu Thu Nov 6 15:42:10 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Nov 2003 10:42:10 -0500 Subject: FC2 release dates Message-ID: <1068133330.1455.11.camel@opus> Hi, I think we should get an estimate on FC2 beta/freeze/release dates ironed out right now. If we're looking at 4-6 months how about: Betas around Valentine's Day and St Patrick's Day: Freeze for the second week of April Maybe try for a release on Tax Day? How does that sound. Very holiday-centric. -sv From cmadams at hiwaay.net Thu Nov 6 16:04:31 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 6 Nov 2003 10:04:31 -0600 Subject: FC2 release dates In-Reply-To: <1068133330.1455.11.camel@opus> References: <1068133330.1455.11.camel@opus> Message-ID: <20031106160431.GG1548864@hiwaay.net> Once upon a time, seth vidal said: > I think we should get an estimate on FC2 beta/freeze/release dates > ironed out right now. Hmm, I think an idea of what the goal of FC2 will be should come first. An obvious one: switch to kernel 2.6? The goals will somewhat drive the dates. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From notting at redhat.com Thu Nov 6 14:19:18 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 6 Nov 2003 09:19:18 -0500 Subject: Announcing Fedora Core 1 Message-ID: <20031106091918.A26390@devserv.devel.redhat.com> RALEIGH, N.C., Nov 6, 2003 (BUSINESS WIRE) -- Red Hat, Inc. (NASDAQ: RHAT), the world's premier open source software provider, today announced the availability of Fedora(TM)Core 1, the first software release of the Fedora Project. The Fedora Project is a Red Hat-sponsored and community-supported open source project that promotes rapid development of innovative open source software through a collaborative, community effort. Fedora Core 1 provides a complete Linux platform built exclusively from open source software. Available at no cost, the release serves the needs of community developers, testers, and other technology enthusiasts who wish to participate in and accelerate the technology development process. As a community forum for advanced development, the Fedora Project provides early visibility to the latest open source technology and serves as a proving ground for technology that may eventually make its way into Red Hat's fully-supported commercial solutions such as Red Hat Enterprise Linux. Red Hat contributes development resources, editorial direction and management to the Fedora Project. Following this release, Red Hat and the community's efforts will turn to the development of Fedora Core 2, which will focus on the next wave of leading edge technology including the integration of the Linux 2.6 kernel. Developers and testers alike are welcome to visit fedora.redhat.com and get directly involved with building the future of Linux. Fedora Core 1 can be downloaded from http://fedora.redhat.com/, and from the following mirrors: * North America * USA East * ftp://ftp.linux.ncsu.edu/pub/fedora/linux/core/ * http://ftp.dulug.duke.edu/pub/fedora/linux/core/ * ftp://ftp.dulug.duke.edu/pub/fedora/linux/core/ * ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/core/ * http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/ * ftp://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/ * rsync://distro.ibiblio.org/fedora-linux-core/ * ftp://ftp.cse.buffalo.edu/pub/fedora/linux/core/ * http://mirror.eas.muohio.edu/fedora/linux/core/ * ftp://mirror.eas.muohio.edu/pub/fedora/linux/core/ * USA West * ftp://limesetone.uoregon.edu/fedora/ * ftp://linux.stanford.edu/pub/mirrors/fedora/linux/core/ * Canada * ftp://less.cogeco.net/pub/fedora/linux/core/ * ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/ * Europe * Austria * http://gd.tuwien.ac.at/opsys/linux/fedora/core/ * ftp://gd.tuwien.ac.at/opsys/linux/fedora/core/ * Czech Republic * ftp://sunsite.mff.cuni.cz/pub/fedora/ * ftp://ultra.linux.cz/pub/fedora/ * rsync://sunsite.mff.cuni.cz/fedora/fedora/ * ftp://ftp.fi.muni.cz/pub/linux/fedora/linux/core/ * ftp://ftp6.linux.cz/pub/linux/fedora/linux/core/ * rsync://ftp.fi.muni.cz/pub/linux/fedora/linux/core/ * France * http://ftp.crihan.fr/mirrors/fedora.redhat.com/fedora/linux/core/ * ftp//ftp.crihan.fr/mirrors/fedora.redhat.com/fedora/linux/core/ * rsync://ftp.crihan.fr::fedora-linux-core/ * Germany * http://wftp.tu-chemnitz.de/pub/linux/fedora-core/ * ftp://ftp.tu-chemnitz.de/pub/linux/fedora-core/ * ftp://ftp.uni-bayreuth.de/pub/linux/fedora/linux/core/ * rsync://rsync.uni-bayreuth.de/fedora-linux-core/ * ftp://ftp.stw-bonn.de/pub/mirror/fedora/linux/core/ * Ireland * http://ftp.heanet.ie/pub/fedora/linux/core/ * ftp://ftp.heanet.ie/pub/fedora/linux/core/ * rsync://ftp.heanet.ie/pub/fedora/linux/core/ * Netherlands * ftp://ftp.quicknet.nl/pub/Linux/download.fedora.redhat.com/ * ftp://alviss.et.tudelft.nl/pub/fedora/core/ * Norway * ftp://ftp.uninett.no/pub/linux/Fedora/core/ * Poland * ftp://tux.cprm.net/pub/ftp.redhat.com/fedora/linux/core/ * ftp://ftp.wsisiz.edu.pl/mirror/download.fedora.redhat.com/ * United Kingdom * http://zeniiia.linux.org.uk/pub/distributions/fedora/linux/core/ * ftp://zeniiia.linux.org.uk/pub/distributions/fedora/linux/core/ * rsync://zeniiia.linux.org.uk/fedora-linux-core/ * Pacific * Australia * ftp://ftp.netcraft.com.au/pub/fedora/linux/core/ From dfarning at sbcglobal.net Thu Nov 6 16:08:16 2003 From: dfarning at sbcglobal.net (David Farning) Date: Thu, 06 Nov 2003 10:08:16 -0600 Subject: location of up2date cvs Message-ID: <1068134895.6649.109.camel@localhost.localdomain> I was looking for the location of the cvs tree for up2 date. I tried export CVSROOT=:pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS cvs -z3 login cvs -z3 co up2 date and just got a bunch of *.po stuff. Has the fedora development stuff moved? Thanks Dave farning From dan_young at parkrose.k12.or.us Thu Nov 6 16:15:02 2003 From: dan_young at parkrose.k12.or.us (Dan Young) Date: Thu, 06 Nov 2003 08:15:02 -0800 Subject: FC2 release dates In-Reply-To: <20031106160431.GG1548864@hiwaay.net> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> Message-ID: <1068135302.19610.3.camel@dan.parkrose.k12.or.us> On Thu, 2003-11-06 at 08:04, Chris Adams wrote: > Once upon a time, seth vidal said: > > I think we should get an estimate on FC2 beta/freeze/release dates > > ironed out right now. > > Hmm, I think an idea of what the goal of FC2 will be should come first. > An obvious one: switch to kernel 2.6? The goals will somewhat drive the > dates. See http://fedora.redhat.com/participate/schedule/ 2.6 is mentioned for FC2, but ought not keep it from shipping if it isn't ready in time. Part of the philosophy for Fedora is regular time-based releases. See the roadmap, about middle of the page: http://fedora.redhat.com/participate/roadmap/ -Dan Young -Parkrose School District From skvidal at phy.duke.edu Thu Nov 6 16:18:22 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Nov 2003 11:18:22 -0500 Subject: FC2 release dates In-Reply-To: <20031106160431.GG1548864@hiwaay.net> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> Message-ID: <1068135502.1453.17.camel@opus> On Thu, 2003-11-06 at 11:04, Chris Adams wrote: > Once upon a time, seth vidal said: > > I think we should get an estimate on FC2 beta/freeze/release dates > > ironed out right now. > > Hmm, I think an idea of what the goal of FC2 will be should come first. > An obvious one: switch to kernel 2.6? The goals will somewhat drive the > dates. Well it looks like gnome 2.6 will be in late betas in feb/march http://www.gnome.org/start/2.5/ Might be a good idea to see where that will be and how badly it break compat with 2.4/2.2. So it's looking very 2.6-y kde 3.2 should be in stable for about 3 months by the beta - so that would be good. What's mozilla's roadmap look like? Any other major programs that should be kept in mind? -sv From pauln at truemesh.com Thu Nov 6 16:36:21 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Thu, 6 Nov 2003 16:36:21 +0000 Subject: location of up2date cvs In-Reply-To: <1068134895.6649.109.camel@localhost.localdomain> References: <1068134895.6649.109.camel@localhost.localdomain> Message-ID: <20031106163620.GV31078@shitake.truemesh.com> On Thu, Nov 06, 2003 at 10:08:16AM -0600, David Farning wrote: > I was looking for the location of the cvs tree for up2 date. I tried > > export CVSROOT=:pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS > cvs -z3 login > cvs -z3 co up2 date > > and just got a bunch of *.po stuff. > > Has the fedora development stuff moved? No i18n has been on elvis/rhlinux.redhat.com for a while I don't believe up2date has ever been exposed. Best bet track rawhide src.rpms for now. Paul From jspaleta at princeton.edu Thu Nov 6 16:25:32 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 06 Nov 2003 11:25:32 -0500 Subject: FC2 release dates Message-ID: <1068135931.18754.8.camel@spatula> Chris Adams wrote: > Hmm, I think an idea of what the goal of FC2 will be should come first. > An obvious one: switch to kernel 2.6? The goals will somewhat drive the > dates. You development people always look at things in such a myopic way, like its the content that actually matters as compared to the perception. Yer totally missing the obvious PR opportunities here. What better way to say i love you...than with a valentines fedora beta. Kiss me I'm Irish AND i run Fedora beta2. And the big PR winner. A release just before the USA tax-day...would mean you could get LUGs to burn cds and hand them out to the people standing in line at the big post-offices trying to get their taxes in under the wire. Can't you see the obvious PR spin involving the concept of unfair taxation and fedora linux as a generously offered solution to that emotional and economic heartache. Successful volunteer movements typically have an eye out for useful PR opportunities. Maybe its not a driving force...but its a mitigating one....and something to think about. -jef"the 5% nation of Casio tones"spaleta -------------- 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 julo at altern.org Thu Nov 6 17:16:47 2003 From: julo at altern.org (Julien Olivier) Date: Thu, 06 Nov 2003 17:16:47 +0000 Subject: FC2 release dates In-Reply-To: <1068135502.1453.17.camel@opus> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <1068135502.1453.17.camel@opus> Message-ID: <1068139006.3241.36.camel@localhost.localdomain> > Well it looks like gnome 2.6 will be in late betas in feb/march > http://www.gnome.org/start/2.5/ > > Might be a good idea to see where that will be and how badly it break > compat with 2.4/2.2. > > So it's looking very 2.6-y > > kde 3.2 should be in stable for about 3 months by the beta - so that > would be good. > > What's mozilla's roadmap look like? > > Any other major programs that should be kept in mind? What about OpenOffice ? Any chance to have a Ximian-ised OpenOffice in Fedora Core 2 ? > -sv > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Julien Olivier From kaboom at gatech.edu Thu Nov 6 17:18:32 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 6 Nov 2003 12:18:32 -0500 (EST) Subject: FC2 release dates In-Reply-To: <1068135502.1453.17.camel@opus> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <1068135502.1453.17.camel@opus> Message-ID: On Thu, 6 Nov 2003, seth vidal wrote: > Any other major programs that should be kept in mind? I'd like to see OpenGroupWare merged, and maybe Clam AV to go with spamassassin. Having an easy to setup, integrated spam / virus / groupware solution would popularize Fedora in a lot of ways. Harald @ RH has RPMs for OpenGroupWare, and I've got a mostly working RPM for clam w/ Postfix. I suppose I can break down, install sendmail, and make it work with either.... This might be more something for the Extras branch, but I at least think it's significant enough to go in Core.... later, chris From kaboom at gatech.edu Thu Nov 6 17:29:21 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 6 Nov 2003 12:29:21 -0500 (EST) Subject: FC2 release dates In-Reply-To: <1068135931.18754.8.camel@spatula> References: <1068135931.18754.8.camel@spatula> Message-ID: On Thu, 6 Nov 2003, Jef Spaleta wrote: > Successful volunteer movements typically have an eye out for useful PR > opportunities. Maybe its not a driving force...but its a mitigating > one....and something to think about. I think if marketing were a driving concern for this project, a more marketable name for releases than "Fedora Core" would have been chosen. I have a classful of students here who just watched me install it. Comments, in order, on watching it boot for the first time: 0. Graphical bootup was universally liked 1. Click-through licensing in firstboot was either amusing or annoying, depending on the student 2. Universal confusion as to why it said Fedora Core all over the place. Even after I explained the Core / Extras / Legacy / etc. business, still disliking. > -jef"the 5% nation of Casio tones"spaleta You should've gone for "the 5% nation of harmful free radicals" instead ;-) later, chris From pmatilai at welho.com Thu Nov 6 17:46:53 2003 From: pmatilai at welho.com (Panu Matilainen) Date: 06 Nov 2003 19:46:53 +0200 Subject: location of up2date cvs In-Reply-To: <20031106163620.GV31078@shitake.truemesh.com> References: <1068134895.6649.109.camel@localhost.localdomain> <20031106163620.GV31078@shitake.truemesh.com> Message-ID: <1068140813.15769.2.camel@chip.ath.cx> On Thu, 2003-11-06 at 18:36, Paul Nasrat wrote: > On Thu, Nov 06, 2003 at 10:08:16AM -0600, David Farning wrote: > > I was looking for the location of the cvs tree for up2 date. I tried > > > > export CVSROOT=:pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS > > cvs -z3 login > > cvs -z3 co up2 date > > > > and just got a bunch of *.po stuff. > > > > Has the fedora development stuff moved? > > No i18n has been on elvis/rhlinux.redhat.com for a while I don't believe > up2date has ever been exposed. rhlinux.redhat.com did have various things (initscripts, kudzu, rhgb...) even if they weren't advertised anywhere and I *think* up2date was one of those. Could be wrong though. - Panu - From skvidal at phy.duke.edu Thu Nov 6 17:58:49 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Nov 2003 12:58:49 -0500 Subject: FC2 release dates In-Reply-To: <1068139006.3241.36.camel@localhost.localdomain> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <1068135502.1453.17.camel@opus> <1068139006.3241.36.camel@localhost.localdomain> Message-ID: <1068141529.1455.25.camel@opus> > What about OpenOffice ? Any chance to have a Ximian-ised OpenOffice in > Fedora Core 2 ? I think Dan Williams is currently Captain OpenOffice at RH - might be worth getting his input. -sv From skvidal at phy.duke.edu Thu Nov 6 18:01:41 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Nov 2003 13:01:41 -0500 Subject: FC2 release dates In-Reply-To: References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <1068135502.1453.17.camel@opus> Message-ID: <1068141701.1453.29.camel@opus> On Thu, 2003-11-06 at 12:18, Chris Ricker wrote: > On Thu, 6 Nov 2003, seth vidal wrote: > > > Any other major programs that should be kept in mind? > > I'd like to see OpenGroupWare merged, and maybe Clam AV to go with > spamassassin. Having an easy to setup, integrated spam / virus / groupware > solution would popularize Fedora in a lot of ways. > > Harald @ RH has RPMs for OpenGroupWare, and I've got a mostly working RPM > for clam w/ Postfix. I suppose I can break down, install sendmail, and make > it work with either.... > > This might be more something for the Extras branch, but I at least think > it's significant enough to go in Core.... > I'd like to reiterate jef spaleta's point and the point of fedora's release cycle. TIME BASED. The point is to get something out there and people using it so it can be tested. So april 14th (the day before US tax day) is just about 6 months out. It means being able to get gnome in under the wire and should provide a good opportunity for a more baked 2.6 kernel. I think everything else should be targeted at stable fedora extras. -sv From jspaleta at princeton.edu Thu Nov 6 18:01:55 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 06 Nov 2003 13:01:55 -0500 Subject: FC2 release dates Message-ID: <1068141715.18754.24.camel@spatula> Chris Ricker wrote: > I think if marketing were a driving concern for this project, a more > marketable name for releases than "Fedora Core" would have been chosen. I > have a classful of students here who just watched me install it. Comments, > in order, on watching it boot for the first time: Now, I could probably argue that there is quite a lot of room in this process to implement 'a lessons learned' phase where we sit back and constructively try to navel gaze about how certain decisions were good or bad or worth reconsidering. But I'm not going to argue for anything like that till at least FC3. And I'm not going to even try to imply that 'Core' is bad till we see 'Extras / Alternatives' media out in the wild to complicate things. I'd rather not fight battles over decisions already made just yet...when there are so many important decisions yet to make. I'm going to concentrate on making sure the remaining decisions are as multi-facted, win-win, opportunity advantageous as possible. -jef"someone didn't catch my song quote reference..oh well"spaleta -------------- 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 dfarning at sbcglobal.net Thu Nov 6 18:15:01 2003 From: dfarning at sbcglobal.net (David Farning) Date: Thu, 06 Nov 2003 12:15:01 -0600 Subject: location of up2date cvs In-Reply-To: <1068140813.15769.2.camel@chip.ath.cx> References: <1068134895.6649.109.camel@localhost.localdomain> <20031106163620.GV31078@shitake.truemesh.com> <1068140813.15769.2.camel@chip.ath.cx> Message-ID: <1068142501.6649.143.camel@localhost.localdomain> On Thu, 2003-11-06 at 11:46, Panu Matilainen wrote: > On Thu, 2003-11-06 at 18:36, Paul Nasrat wrote: > > On Thu, Nov 06, 2003 at 10:08:16AM -0600, David Farning wrote: > > > I was looking for the location of the cvs tree for up2 date. I tried > > > > > > export CVSROOT=:pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS > > > cvs -z3 login > > > cvs -z3 co up2 date > > > > > > and just got a bunch of *.po stuff. > > > > > > Has the fedora development stuff moved? > > > > No i18n has been on elvis/rhlinux.redhat.com for a while I don't believe > > up2date has ever been exposed. > > rhlinux.redhat.com did have various things (initscripts, kudzu, rhgb...) > even if they weren't advertised anywhere and I *think* up2date was one > of those. Could be wrong though. > > - Panu - The reason I ask is that i am working on a gui front end for a package management system. I wanted to know the current devel state of up2date. My initial work is porting sysnaptic to python/pygtk. How does the development community feel about writing some of the wigets in C++ and then wrapping them? I am looking at doing this for reasons of efficiency. The package and dependency caches will be based closely on yum (if not directly using yum code extended for interactive use) On the back side I'm looking a the existing up2date code to allow different types of repos to be read and down loaded. The basic set of event will be. 1. Create pkgStatus list to include all known packages and their statue ie name, epoch, version, location ,installStatue 2. Via gui interaction a transaction set is developed ie package install, update, or remove 3. Do a dry run transaction set test -- paranoid 4. Do transaction set Thanks Dave Farning From skvidal at phy.duke.edu Thu Nov 6 18:25:50 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Nov 2003 13:25:50 -0500 Subject: location of up2date cvs In-Reply-To: <1068142501.6649.143.camel@localhost.localdomain> References: <1068134895.6649.109.camel@localhost.localdomain> <20031106163620.GV31078@shitake.truemesh.com> <1068140813.15769.2.camel@chip.ath.cx> <1068142501.6649.143.camel@localhost.localdomain> Message-ID: <1068143150.1455.33.camel@opus> > The reason I ask is that i am working on a gui front end for a package > management system. I wanted to know the current devel state of up2date. > > My initial work is porting sysnaptic to python/pygtk. How does the > development community feel about writing some of the wigets in C++ and > then wrapping them? I am looking at doing this for reasons of > efficiency. > > The package and dependency caches will be based closely on yum (if not > directly using yum code extended for interactive use) > > On the back side I'm looking a the existing up2date code to allow > different types of repos to be read and down loaded. David, This sounds like a great idea. A couple of ideas for you. 1. work on learning the redhat-config-packages infrastructure or at least understanding it. 2. make tweaks to the ui and talk to katzj and bfox about them 3. be prepared for apt repos and yum repos to be the same thing, hopefully, in the future. -sv From skvidal at phy.duke.edu Thu Nov 6 18:44:34 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Nov 2003 13:44:34 -0500 Subject: FC2 release dates In-Reply-To: <1068135931.18754.8.camel@spatula> References: <1068135931.18754.8.camel@spatula> Message-ID: <1068144274.1919.49.camel@opus> > What better way to say i love you...than with a valentines fedora beta. > Kiss me I'm Irish AND i run Fedora beta2. This is obviously such a wonderful tag line for a beta announcement it is painful. +1 > And the big PR winner. A release just before the USA tax-day...would > mean you could get LUGs to burn cds and hand them out to the people > standing in line at the big post-offices trying to get their taxes in > under the wire. Can't you see the obvious PR spin involving the concept > of unfair taxation and fedora linux as a generously offered solution to > that emotional and economic heartache. Gotta make sure gnucash is working though. ;) > Successful volunteer movements typically have an eye out for useful PR > opportunities. Maybe its not a driving force...but its a mitigating > one....and something to think about. Take another +1 for Gryffindor Mr Spaleta. -sv From twaugh at redhat.com Thu Nov 6 18:52:31 2003 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 6 Nov 2003 18:52:31 +0000 Subject: Much faster grep Message-ID: <20031106185231.GU1963@redhat.com> A quite invasive, experimental patch has been applied to this grep package: http://cyberelk.net/tim/data/tmp/grep-2.5.1-19.i386.rpm (SRPM in the same place) It gives quite significant speed improvements for multibyte (UTF-8) handling, but needs lots of real world testing to make sure there are no regressions. It will appear in rawhide in due course. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dfarning at sbcglobal.net Thu Nov 6 18:53:40 2003 From: dfarning at sbcglobal.net (David Farning) Date: Thu, 06 Nov 2003 12:53:40 -0600 Subject: location of up2date cvs In-Reply-To: <1068143150.1455.33.camel@opus> References: <1068134895.6649.109.camel@localhost.localdomain> <20031106163620.GV31078@shitake.truemesh.com> <1068140813.15769.2.camel@chip.ath.cx> <1068142501.6649.143.camel@localhost.localdomain> <1068143150.1455.33.camel@opus> Message-ID: <1068144820.6649.164.camel@localhost.localdomain> On Thu, 2003-11-06 at 12:25, seth vidal wrote: > > The reason I ask is that i am working on a gui front end for a package > > management system. I wanted to know the current devel state of up2date. > > > > My initial work is porting sysnaptic to python/pygtk. How does the > > development community feel about writing some of the wigets in C++ and > > then wrapping them? I am looking at doing this for reasons of > > efficiency. > > > > The package and dependency caches will be based closely on yum (if not > > directly using yum code extended for interactive use) > > > > On the back side I'm looking a the existing up2date code to allow > > different types of repos to be read and down loaded. > > > David, > This sounds like a great idea. A couple of ideas for you. > > 1. work on learning the redhat-config-packages infrastructure or at > least understanding it. I'm currently working on that. It seems that one of the main reasons cited for why linux is not ready for the desktop is the lack of a cohesive gui config system. The creation of fedora will hopefull help the user community develop a unified gui config system that is available GNU/Linux wide. > 2. make tweaks to the ui and talk to katzj and bfox about them > > 3. be prepared for apt repos and yum repos to be the same thing, > hopefully, in the future. That is my feeling/hope. The use of nevral is much more elegant that the apt cache. I've been looking into how to put together some sort of kludge to convert the apt pkgcache into a nevral. > -sv > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From skvidal at phy.duke.edu Thu Nov 6 18:56:51 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Nov 2003 13:56:51 -0500 Subject: location of up2date cvs In-Reply-To: <1068144820.6649.164.camel@localhost.localdomain> References: <1068134895.6649.109.camel@localhost.localdomain> <20031106163620.GV31078@shitake.truemesh.com> <1068140813.15769.2.camel@chip.ath.cx> <1068142501.6649.143.camel@localhost.localdomain> <1068143150.1455.33.camel@opus> <1068144820.6649.164.camel@localhost.localdomain> Message-ID: <1068145010.1919.53.camel@opus> > > 3. be prepared for apt repos and yum repos to be the same thing, > > hopefully, in the future. > That is my feeling/hope. The use of nevral is much more elegant that > the apt cache. I've been looking into how to put together some sort of > kludge to convert the apt pkgcache into a nevral. Don't do that right now. We're already working on a new format that I hope will match your goals in both directions. give us some more time, though. -sv From notting at redhat.com Thu Nov 6 19:05:02 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 6 Nov 2003 14:05:02 -0500 Subject: FC2 release dates In-Reply-To: <1068144274.1919.49.camel@opus>; from skvidal@phy.duke.edu on Thu, Nov 06, 2003 at 01:44:34PM -0500 References: <1068135931.18754.8.camel@spatula> <1068144274.1919.49.camel@opus> Message-ID: <20031106140502.E28226@devserv.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > Gotta make sure gnucash is working though. ;) Uh-oh, then we have to wait for gnome2 gnucash. Bill From dfarning at sbcglobal.net Thu Nov 6 19:08:15 2003 From: dfarning at sbcglobal.net (David Farning) Date: Thu, 06 Nov 2003 13:08:15 -0600 Subject: location of up2date cvs In-Reply-To: <1068145010.1919.53.camel@opus> References: <1068134895.6649.109.camel@localhost.localdomain> <20031106163620.GV31078@shitake.truemesh.com> <1068140813.15769.2.camel@chip.ath.cx> <1068142501.6649.143.camel@localhost.localdomain> <1068143150.1455.33.camel@opus> <1068144820.6649.164.camel@localhost.localdomain> <1068145010.1919.53.camel@opus> Message-ID: <1068145695.6649.179.camel@localhost.localdomain> > Don't do that right now. We're already working on a new format that I > hope will match your goals in both directions. > > give us some more time, though. > Should I expect the current nevral design to last? > -sv > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From jspaleta at princeton.edu Thu Nov 6 19:22:06 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 06 Nov 2003 14:22:06 -0500 Subject: FC2 release Message-ID: <1068146526.18754.36.camel@spatula> seth vidal wrote: > Gotta make sure gnucash is working though. ;) crap...I hate you...you've totally made it impossible for me to get work done today. I have a mounting FC2 todo list in my head now because of you. It's worse than when i had rico suave stuck in my head for a week. One thing i REALLY want to see as early as possible is to get the people with accessibility concerns talking ASAP about a priority list of concerns they want to see addressed in the next distro. Being blindsided late in the last beta about lilo vs grub accessibility was totally uncool. And I'm not saying the next release is going to a magical silver bullet to solve accessibility problems...its a hard problem..and its one very prone for communication disconnects, even though technical/development people recognize it is important. I think a roadmap to on "focused" accessibility cleanup longterm is something worth working on. Just trying to have every package maintainer try to deal with accessibility issues as they come up..is going to suck for everyone. But if there were some priorities so people who understand accessibility issues could start somewhere and work with a few developers at a time...and march through the distro so that 3 or 4 releases from now not only is accessibility a lot cleaner but there will be a real human development process in place to keep accessibility from being something each maintainer has to try to remember to deal with. I want to see an accessibility focus/support group to be there in the community to help developers deal with issues. And i want that focus/support group to have a long term vision and a master plan to get from here to there. -jef"i also want my own jet pack"spaleta -------------- 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 Thu Nov 6 19:24:04 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Nov 2003 14:24:04 -0500 Subject: location of up2date cvs In-Reply-To: <1068145695.6649.179.camel@localhost.localdomain> References: <1068134895.6649.109.camel@localhost.localdomain> <20031106163620.GV31078@shitake.truemesh.com> <1068140813.15769.2.camel@chip.ath.cx> <1068142501.6649.143.camel@localhost.localdomain> <1068143150.1455.33.camel@opus> <1068144820.6649.164.camel@localhost.localdomain> <1068145010.1919.53.camel@opus> <1068145695.6649.179.camel@localhost.localdomain> Message-ID: <1068146644.1455.60.camel@opus> On Thu, 2003-11-06 at 14:08, David Farning wrote: > > Don't do that right now. We're already working on a new format that I > > hope will match your goals in both directions. > > > > give us some more time, though. > > > Should I expect the current nevral design to last? sortof. You'll be able to get to things via a the nevral data but the metadata is changing. Like I said - sit tight, let me get some other bits ironed out and cleared through the other people involved. It's VERY important to me that the other pkg mgmt people are onboard and happy with what is being proposed. Thanks -sv From stan at ccs.neu.edu Thu Nov 6 19:43:19 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Thu, 06 Nov 2003 14:43:19 -0500 Subject: location of up2date cvs In-Reply-To: <1068142501.6649.143.camel@localhost.localdomain> References: <1068134895.6649.109.camel@localhost.localdomain> <20031106163620.GV31078@shitake.truemesh.com> <1068140813.15769.2.camel@chip.ath.cx> <1068142501.6649.143.camel@localhost.localdomain> Message-ID: <1068147798.5979.3.camel@wvanl14.resnet.neu.edu> Well as far as up2date goes I'm none to pleased with it to be honest. It seems to frequently lock-up due to errors in underlying python libraries when it recieves something unexpected fro mthe server. I've found myself only running up2date from a shell so I can see the output and know when it is locked up. Honestly I wish it were written in different language, but that just me I guess, I don't know python (perl fan about all other scripting lang.) so I can't fix bugs on my own which erks me cause now I gotta learn python ;-) -sb On Thu, 2003-11-06 at 13:15, David Farning wrote: > The reason I ask is that i am working on a gui front end for a package > management system. I wanted to know the current devel state of up2date. > > My initial work is porting sysnaptic to python/pygtk. How does the > development community feel about writing some of the wigets in C++ and > then wrapping them? I am looking at doing this for reasons of > efficiency. > > The package and dependency caches will be based closely on yum (if not > directly using yum code extended for interactive use) > > On the back side I'm looking a the existing up2date code to allow > different types of repos to be read and down loaded. > > The basic set of event will be. > > 1. Create pkgStatus list to include all known packages and their statue > ie name, epoch, version, location ,installStatue > > 2. Via gui interaction a transaction set is developed ie package > install, update, or remove > > 3. Do a dry run transaction set test -- paranoid > > 4. Do transaction set > > Thanks > Dave Farning > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- 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 hugo at devin.com.br Thu Nov 6 19:52:25 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Thu, 06 Nov 2003 16:52:25 -0300 Subject: FC2 release dates In-Reply-To: <20031106160431.GG1548864@hiwaay.net> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> Message-ID: <3FAAA679.8090206@devin.com.br> Chris Adams wrote: > > Hmm, I think an idea of what the goal of FC2 will be should come first. > An obvious one: switch to kernel 2.6? The goals will somewhat drive the > dates. I think a good choice is to provide native ACL support for the file system. many people I know want this feature a lot to control their files on server, specially when used by large groups of people. I don't know if the implementation is stable enough, but I think when kernel 2.6 arrives, it'll be a good "ride" to implement native ACL support in the file system. I mean native = easy access and documented procedure on how to work with ACL on files and such :) []'s Hugo From gemi at bluewin.ch Thu Nov 6 20:07:49 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Thu, 06 Nov 2003 21:07:49 +0100 Subject: My experience with upgrading from RH9 to FC1 Message-ID: <1068149267.5640.12.camel@scriabin.tannenrauch.ch> Hi, I just upgraded from RedHat9 to Fedora Core 1. The upgrade itself was easy. However I didn't meet the package selection in the installer... Did I simply miss the option? These are the issues I encountered: 1. I had to install the following drivers: a) proprietary NVIDIA b) bcm4400 for the network card c) alsa At first it didn't work at all, then I noticed that I must use gcc32 to compile, this wasn't very clear from the release notes. I had a problem with compiling the alsa driver (schedule_work), but google groups was my friend. BTW before trying to fix alsa, I tried sndconfig, which detected the onboard soundcard before my SB Live!. I would have preferred to choose the order the soundcards are configured. 2. At first starting, the GNOME desktop was in a mess. I moved .gnome2 out of the way. I previously always used sawfish, but that didn't work at all. The background was gray overlaying the Nautilus icons. So I installed metacity. However I prefer sawfish, because it allows better control of window placement. I have two screens configured with Xinerama. The first screen is 1600x1200, the second 1280x01024. With Gnome 2.2 and Sawfish, I could place a panel at the bottom of the second screen. This I can no longer do. I can place a panel at the top and at the right, but not at the bottom. (BTW I miss the rounded edges of the menu panel :-( Well that's all for now. Otherwise FC1 is fine. Thanks -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From xose at wanadoo.es Thu Nov 6 20:18:15 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Thu, 06 Nov 2003 21:18:15 +0100 Subject: My experience with upgrading from RH9 to FC1 References: <1068149267.5640.12.camel@scriabin.tannenrauch.ch> Message-ID: <3FAAAC87.7060308@wanadoo.es> Gerard Milmeister wrote: > 1. I had to install the following drivers: > a) proprietary NVIDIA > b) bcm4400 for the network card ^^^^^^^ forget that and use _tg3_ driver. -- HTML mails are going to trash automagically From fs111 at web.de Thu Nov 6 20:23:53 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Thu, 06 Nov 2003 21:23:53 +0100 Subject: FC2 release dates In-Reply-To: <3FAAA679.8090206@devin.com.br> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <3FAAA679.8090206@devin.com.br> Message-ID: <1068150233.16262.11.camel@localhost> Am Don, den 06.11.2003 schrieb Hugo Cisneiros um 20:52: > I think a good choice is to provide native ACL support for the file > system. many people I know want this feature a lot to control their > files on server, specially when used by large groups of people. > > I don't know if the implementation is stable enough, but I think when > kernel 2.6 arrives, it'll be a good "ride" to implement native ACL > support in the file system. > > I mean native = easy access and documented procedure on how to work with > ACL on files and such :) Full ACK! ACL is something really important, because it is impossible to "emulate" ACL with normal user/group permission. IMO this should be one of the first points on the TODO-list. Andr? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From xose at wanadoo.es Thu Nov 6 20:23:36 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Thu, 06 Nov 2003 21:23:36 +0100 Subject: My experience with upgrading from RH9 to FC1 References: <1068149267.5640.12.camel@scriabin.tannenrauch.ch> <3FAAAC87.7060308@wanadoo.es> Message-ID: <3FAAADC8.9050806@wanadoo.es> Xose Vazquez Perez wrote: > Gerard Milmeister wrote: > > >>1. I had to install the following drivers: >> a) proprietary NVIDIA >> b) bcm4400 for the network card > > ^^^^^^^ > > forget that and use _tg3_ driver. it's _b44_ driver, tg3 is for others bcm NICs. Sorry. -- HTML mails are going to trash automagically From gemi at bluewin.ch Thu Nov 6 20:35:39 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Thu, 06 Nov 2003 21:35:39 +0100 Subject: My experience with upgrading from RH9 to FC1 In-Reply-To: <3FAAADC8.9050806@wanadoo.es> References: <1068149267.5640.12.camel@scriabin.tannenrauch.ch> <3FAAAC87.7060308@wanadoo.es> <3FAAADC8.9050806@wanadoo.es> Message-ID: <1068150938.5640.17.camel@scriabin.tannenrauch.ch> On Thu, 2003-11-06 at 21:23, Xose Vazquez Perez wrote: > Xose Vazquez Perez wrote: > > Gerard Milmeister wrote: > > > > > >>1. I had to install the following drivers: > >> a) proprietary NVIDIA > >> b) bcm4400 for the network card > > > > ^^^^^^^ > > > > forget that and use _tg3_ driver. > > it's _b44_ driver, tg3 is for others bcm NICs. Sorry. Thanks, that works. -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From brugolsky at telemetry-investments.com Thu Nov 6 21:01:39 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 6 Nov 2003 16:01:39 -0500 Subject: Much faster grep In-Reply-To: <20031106185231.GU1963@redhat.com> References: <20031106185231.GU1963@redhat.com> Message-ID: <20031106210139.GA20249@ti19.telemetry-investments.com> On Thu, Nov 06, 2003 at 06:52:31PM +0000, Tim Waugh wrote: > It gives quite significant speed improvements for multibyte (UTF-8) > handling, but needs lots of real world testing to make sure there are > no regressions. Thank you, thank you, thank you! The notion that a UTF-8 performance regression of several hundred times in core text utils is not a showstopper boggles my mind. [I'm still mulling which is the greater headache with FC1: UTF-8 or C locale.] Regards, Bill Rugolsky From barryn at pobox.com Thu Nov 6 21:07:57 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 6 Nov 2003 13:07:57 -0800 Subject: location of up2date cvs In-Reply-To: <1068147798.5979.3.camel@wvanl14.resnet.neu.edu> References: <1068134895.6649.109.camel@localhost.localdomain> <20031106163620.GV31078@shitake.truemesh.com> <1068140813.15769.2.camel@chip.ath.cx> <1068142501.6649.143.camel@localhost.localdomain> <1068147798.5979.3.camel@wvanl14.resnet.neu.edu> Message-ID: <20031106210757.GC29089@ip68-4-255-84.oc.oc.cox.net> On Thu, Nov 06, 2003 at 02:43:19PM -0500, Stan Bubrouski wrote: > It seems to frequently lock-up due to errors in underlying python > libraries when it recieves something unexpected fro mthe server. I've > found myself only running up2date from a shell so I can see the output > and know when it is locked up. Me Too(tm) I filed this right after the Red Hat 9 release (unfortunately I didn't do much testing of the betas between Red Hat 8.0 and 9), as bug 88349. IIRC, Red Hat 8.0's up2date did *not* have this problem -- tracebacks appeared in their own dialog boxes. (It could be some other component that changed and caused this problem, for all I know.) -Barry K. Nathan From jrb at redhat.com Thu Nov 6 22:06:21 2003 From: jrb at redhat.com (Jonathan Blandford) Date: 06 Nov 2003 17:06:21 -0500 Subject: Much faster grep In-Reply-To: <20031106185231.GU1963@redhat.com> References: <20031106185231.GU1963@redhat.com> Message-ID: Tim Waugh writes: > A quite invasive, experimental patch has been applied to this grep > package: > > http://cyberelk.net/tim/data/tmp/grep-2.5.1-19.i386.rpm > > (SRPM in the same place) > > It gives quite significant speed improvements for multibyte (UTF-8) > handling, but needs lots of real world testing to make sure there are > no regressions. > > It will appear in rawhide in due course. And I was just complaining about this this morning. This made an operation go from 15 seconds to nearly instantaneous (with the same output). It's definitely an improvement. -Jonathan From czar at czarc.net Thu Nov 6 22:30:34 2003 From: czar at czarc.net (Gene C.) Date: Thu, 6 Nov 2003 17:30:34 -0500 Subject: Fwd: Updated Fedora Core test release: Severn Message-ID: <200311061730.34684.czar@czarc.net> Received: from listman.back-rdu.redhat.com (listman.back-rdu.redhat.com [10.10.2.136]) by hormel.redhat.com (Postfix) with ESMTP id 309FF135C7B; Thu, 6 Nov 2003 10:17:55 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by listman.back-rdu.redhat.com (8.11.6/8.11.6) with ESMTP id h9DIKdO06667 for ; Mon, 13 Oct 2003 14:20:39 -0400 I wondered about this announcement. Until I noticed the date I thought either FC2 had started or FC1 had gone "back" to testing. -- Gene -------------- next part -------------- An embedded message was scrubbed... From: Bill Nottingham Subject: Updated Fedora Core test release: Severn Date: Mon, 13 Oct 2003 14:25:02 -0400 Size: 5448 URL: From michaelfivis at verizon.net Thu Nov 6 22:48:10 2003 From: michaelfivis at verizon.net (Michael S. Fivis) Date: Thu, 06 Nov 2003 17:48:10 -0500 Subject: regarding: Anyone else interested in graphics? Message-ID: <3FAACFAA.60104@verizon.net> Are there other people on this list deeply interested in doing 2D graphical work for fedora? (wallpapers, handling, icons, etc)? michaelfivis at verizon.net Should start a forum or our own list of some sort. From bfox at redhat.com Thu Nov 6 22:47:08 2003 From: bfox at redhat.com (Brent Fox) Date: Thu, 06 Nov 2003 17:47:08 -0500 Subject: Fwd: Updated Fedora Core test release: Severn In-Reply-To: <200311061730.34684.czar@czarc.net> References: <200311061730.34684.czar@czarc.net> Message-ID: <1068158828.26480.97.camel@bfox.devel.redhat.com> On Thu, 2003-11-06 at 17:30, Gene C. wrote: > Received: from listman.back-rdu.redhat.com (listman.back-rdu.redhat.com > [10.10.2.136]) > by hormel.redhat.com (Postfix) with ESMTP > id 309FF135C7B; Thu, 6 Nov 2003 10:17:55 -0500 (EST) > Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com > [172.16.52.254]) > by listman.back-rdu.redhat.com (8.11.6/8.11.6) with ESMTP id > h9DIKdO06667 > for ; Mon, 13 Oct 2003 > 14:20:39 -0400 > > I wondered about this announcement. Until I noticed the date I thought either > FC2 had started or FC1 had gone "back" to testing. It was my fault. I hadn't cleared out the admin queue for a while and accidentally approved the wrong message. Sorry about that. Cheers, Brent From twaugh at redhat.com Thu Nov 6 23:20:45 2003 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 6 Nov 2003 23:20:45 +0000 Subject: Much faster grep In-Reply-To: <20031106210139.GA20249@ti19.telemetry-investments.com> References: <20031106185231.GU1963@redhat.com> <20031106210139.GA20249@ti19.telemetry-investments.com> Message-ID: <20031106232045.GX1963@redhat.com> On Thu, Nov 06, 2003 at 04:01:39PM -0500, Bill Rugolsky Jr. wrote: > Thank you, thank you, thank you! The notion that a UTF-8 performance > regression of several hundred times in core text utils is not > a showstopper boggles my mind. It's just that it needs a lot of testing because it's so invasive. We already had a false start with this patch because of the bugs that kept popping up. Once we can be sure that it doesn't have regressions it's something that should get officially updated IMHO. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Thu Nov 6 23:24:55 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Nov 2003 18:24:55 -0500 Subject: FC2 release In-Reply-To: <1068146526.18754.36.camel@spatula> References: <1068146526.18754.36.camel@spatula> Message-ID: <1068161095.3442.30.camel@opus> On Thu, 2003-11-06 at 14:22, Jef Spaleta wrote: > seth vidal wrote: > > Gotta make sure gnucash is working though. ;) > > crap...I hate you...you've totally made it impossible for me to get work > done today. I have a mounting FC2 todo list in my head now because of > you. It's worse than when i had rico suave stuck in my head for a week. > I could hum a few bars of 'ring of fire' if that would help at all ;) > One thing i REALLY want to see as early as possible is to get the people > with accessibility concerns talking ASAP about a priority list of > concerns they want to see addressed in the next distro. Being blindsided > late in the last beta about lilo vs grub accessibility was totally > uncool. Do we have a tracker bug open for a11y issues that are open in bugzilla? If not - one would be handy. > I want to see an accessibility focus/support group to be there in the > community to help developers deal with issues. And i want that > focus/support group to have a long term vision and a master plan to get > from here to there. I think the a11y people who hammered on gnome might even be welcome. -sv ps: I'm still gonna harp on: beta1 - valentine's day beta2 - st patrick's day freeze - april fool's day (so suitable) release - US tax day-eve or if 3 betas are better: beta1 - Hot and Spicy Food International Day and National Nothing Day (jan 16) beta2 - valentine's day - feb 14 beta3 - st patrick's day - Mar 17 freeze - april fool's day - apr 1 release - US tax day-eve - apr 14 From stevelist at silverorange.com Thu Nov 6 23:29:15 2003 From: stevelist at silverorange.com (Steven Garrity) Date: Thu, 06 Nov 2003 19:29:15 -0400 Subject: regarding: Anyone else interested in graphics? In-Reply-To: <3FAACFAA.60104@verizon.net> References: <3FAACFAA.60104@verizon.net> Message-ID: <3FAAD94B.9090309@silverorange.com> Michael S. Fivis wrote: > Are there other people on this list deeply interested in doing 2D > graphical work for fedora? (wallpapers, handling, icons, etc)? > michaelfivis at verizon.net Should start a forum or our own list of some > sort. I am interested in helping out in these areas. I am a designer for a web development firm but have an interested in UI, window, and icon design. I also have some talented help from some co-workers in these areas. Do you have any particular work in mind? Steven Garrity From dfarning at sbcglobal.net Thu Nov 6 23:46:27 2003 From: dfarning at sbcglobal.net (David Farning) Date: Thu, 06 Nov 2003 17:46:27 -0600 Subject: regarding: Anyone else interested in graphics? In-Reply-To: <3FAAD94B.9090309@silverorange.com> References: <3FAACFAA.60104@verizon.net> <3FAAD94B.9090309@silverorange.com> Message-ID: <1068162387.6649.254.camel@localhost.localdomain> On Thu, 2003-11-06 at 17:29, Steven Garrity wrote: > Michael S. Fivis wrote: > > > Are there other people on this list deeply interested in doing 2D > > graphical work for fedora? (wallpapers, handling, icons, etc)? > > michaelfivis at verizon.net Should start a forum or our own list of > some > sort. > > I am interested in helping out in these areas. I am a designer for a web > development firm but have an interested in UI, window, and icon design. > I also have some talented help from some co-workers in these areas. > > Do you have any particular work in mind? > > Steven Garrity I would have to give a +1 to a consistent look and feel across the config suit. Granted it is not glamorous, but it would be nice! Dave Farning From katzj at redhat.com Fri Nov 7 00:03:48 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Nov 2003 19:03:48 -0500 Subject: FC2 release dates In-Reply-To: <1068139006.3241.36.camel@localhost.localdomain> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <1068135502.1453.17.camel@opus> <1068139006.3241.36.camel@localhost.localdomain> Message-ID: <1068163428.12498.16.camel@mirkwood.devel.redhat.com> On Thu, 2003-11-06 at 12:16, Julien Olivier wrote: > What about OpenOffice ? Any chance to have a Ximian-ised OpenOffice in > Fedora Core 2 ? Dan Williams is working closely with Michael Meeks from Ximian to get the things which make sense integrated into the Fedora packages. Cheers, Jeremy From katzj at redhat.com Fri Nov 7 00:13:25 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Nov 2003 19:13:25 -0500 Subject: FC2 release dates In-Reply-To: <1068133330.1455.11.camel@opus> References: <1068133330.1455.11.camel@opus> Message-ID: <1068164005.12985.11.camel@mirkwood.devel.redhat.com> On Thu, 2003-11-06 at 10:42, seth vidal wrote: > I think we should get an estimate on FC2 beta/freeze/release dates > ironed out right now. I tend to agree, although they're test releases, not betas :-) > If we're looking at 4-6 months how about: > > Betas around Valentine's Day and St Patrick's Day: > Freeze for the second week of April > Maybe try for a release on Tax Day? > How does that sound. I would personally prefer to get 2.6 out sooner rather than later. To throw out something as an alternative plan for a faster release, something like the following for availability of milestones could work. It's definitely a more aggressive suggestion :) Test1 - January 13 Test2 - February 3 Test3/RC - March 1 GA - March 22 Then, extrapolate back roughly a week earlier for freeze dates. I'd love to actually get earlier, but that would require either less test releases (which strikes me as a bad idea for 2.6), less time between them (same) or getting test 1 out before Christmas (likely to be really really hard to pull off) Anyway, my $0.02 on the matter Jeremy From chuckw at quantumlinux.com Fri Nov 7 00:18:58 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Thu, 6 Nov 2003 16:18:58 -0800 (PST) Subject: Fedora, Ximian, SuSE (Was: Re: FC2 release dates) In-Reply-To: <1068163428.12498.16.camel@mirkwood.devel.redhat.com> Message-ID: > > What about OpenOffice ? Any chance to have a Ximian-ised OpenOffice in > > Fedora Core 2 ? > > Dan Williams is working closely with Michael Meeks from Ximian to get > the things which make sense integrated into the Fedora packages. Just as an anecdote, I'd be curious to see how much of Ximian gets into Fedora now that Novell has made it clear that their acquisition of SuSE puts them in direct competition with RedHat. Oh yeah, and consider this my vote for including a full load of Ximian in FC ;) -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com A: Because we read from top to bottom, left to right. Q: Why should i start my reply below the quoted text? From skvidal at phy.duke.edu Fri Nov 7 00:19:52 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 06 Nov 2003 19:19:52 -0500 Subject: FC2 release dates In-Reply-To: <1068164005.12985.11.camel@mirkwood.devel.redhat.com> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> Message-ID: <1068164392.10735.6.camel@binkley> > I tend to agree, although they're test releases, not betas :-) what's the distinction in nomenclature? > I would personally prefer to get 2.6 out sooner rather than later. To > throw out something as an alternative plan for a faster release, > something like the following for availability of milestones could work. > It's definitely a more aggressive suggestion :) > > Test1 - January 13 > Test2 - February 3 > Test3/RC - March 1 > GA - March 22 > I liked the month between test releases better than 2 weeks. If only b/c the installer(as you well know) will be less tested if there is less time to sync test isos to do full reinstalls. And for a lot of people it still takes about a day or 2 to get 3 isos. And I think the installer+2.6+lvm/evms/etc will be more than enough pain to iron out. > Then, extrapolate back roughly a week earlier for freeze dates. I'd > love to actually get earlier, but that would require either less test > releases (which strikes me as a bad idea for 2.6), less time between > them (same) or getting test 1 out before Christmas (likely to be really > really hard to pull off) What's the motive to shorten up to end of March instead of Mid-April? You'll start get bugs rolling in from the test releases for 2.6. I don't think there will be any shortage. :) and the dates you mention don't have humorous holiday jokes involved - you've got to keep the important stuff in perspective! :) -sv From cra at WPI.EDU Fri Nov 7 00:30:53 2003 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 6 Nov 2003 19:30:53 -0500 Subject: My experience with upgrading from RH9 to FC1 In-Reply-To: <3FAAADC8.9050806@wanadoo.es>; from xose@wanadoo.es on Thu, Nov 06, 2003 at 09:23:36PM +0100 References: <1068149267.5640.12.camel@scriabin.tannenrauch.ch> <3FAAAC87.7060308@wanadoo.es> <3FAAADC8.9050806@wanadoo.es> Message-ID: <20031106193053.H16873@angus.ind.WPI.EDU> On Thu, Nov 06, 2003 at 09:23:36PM +0100, Xose Vazquez Perez wrote: > > forget that and use _tg3_ driver. > it's _b44_ driver, tg3 is for others bcm NICs. Sorry. But don't use tg3 for BCM 57xx cards. It drops packets under load, where bcm5700 driver does not. Can we get bcm5700.o (which is GPL) integrated? http://www.broadcom.com/support/downloaddrivers.php We've been happily using 7.0.0 on a couple Dell 2650's without problems, and Snort is much happier. -- Charles R. Anderson / http://angus.ind.wpi.edu/~cra/ PGP Key ID: 49BB5886 Fingerprint: EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 49BB 5886 From katzj at redhat.com Fri Nov 7 00:34:17 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Nov 2003 19:34:17 -0500 Subject: FC2 release dates In-Reply-To: <1068164392.10735.6.camel@binkley> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> Message-ID: <1068165254.12985.20.camel@mirkwood.devel.redhat.com> On Thu, 2003-11-06 at 19:19, seth vidal wrote: > > I tend to agree, although they're test releases, not betas :-) > > what's the distinction in nomenclature? It's on http://fedora.redhat.com/participate/terminology.html -- To distinguish Red Hat Enterprise Linux's formal beta program from the community-based testing of Fedora Core, we will use the term "test" release instead of "beta" release to refer to test releases. > > I would personally prefer to get 2.6 out sooner rather than later. To > > throw out something as an alternative plan for a faster release, > > something like the following for availability of milestones could work. > > It's definitely a more aggressive suggestion :) [snip] > I liked the month between test releases better than 2 weeks. If only b/c > the installer(as you well know) will be less tested if there is less > time to sync test isos to do full reinstalls. And for a lot of people it > still takes about a day or 2 to get 3 isos. That's four weeks between all but test3 and final which is a slightly shorter one. Hopefully, having rawhide continually installable will help get installer feedback sooner and allow people to test fixes much sooner. Also, being able to do graphical installs via FTP or HTTP should be a nice help here as well. > And I think the installer+2.6+lvm/evms/etc will be more than enough pain > to iron out. Oh, believe me... I have a pretty good idea of how much pain is involved :/ > > Then, extrapolate back roughly a week earlier for freeze dates. I'd > > love to actually get earlier, but that would require either less test > > releases (which strikes me as a bad idea for 2.6), less time between > > them (same) or getting test 1 out before Christmas (likely to be really > > really hard to pull off) > > What's the motive to shorten up to end of March instead of Mid-April? > You'll start get bugs rolling in from the test releases for 2.6. I don't > think there will be any shortage. :) Because people are already asking for 2.6 stuff now and test releases aren't the same as an actual release. That's basically the fastest timeline I can come up with that I think can be hit and still have something that's robust. Jeremy From pmmm at rnl.ist.utl.pt Fri Nov 7 00:34:25 2003 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Fri, 7 Nov 2003 00:34:25 +0000 Subject: i18n issues, was: FC2 release In-Reply-To: <1068146526.18754.36.camel@spatula> References: <1068146526.18754.36.camel@spatula> Message-ID: <200311070034.25123.pmmm@rnl.ist.utl.pt> Em Quinta 06 Novembro 2003 19:22, Jef Spaleta escreveu: > One thing i REALLY want to see as early as possible is to get the people > with accessibility concerns talking ASAP about a priority list of > concerns they want to see addressed in the next distro. Being blindsided > late in the last beta about lilo vs grub accessibility was totally > uncool. Another "acessibility" issue is internationalization; the current process isn't bad at all, but could be improved. I was unfortunately very busy during this beta period (only managed to follow the mailling lists and update portuguese translations), so I can't really complain, but I kept i18n stats at 100% at almost all tims, and certainly at the freeze point I'm sure that only the anaconda docs has a couple of untranlated, and still there are powerdown messages in english (in the middle of portuguese messages, so it's not a "too late for i18n issue") and, even worse, up2date/rhn_register is half translated/half in english. Clearly there's room for improvement. -- Pedro Morais - morais at kde.org - http://www.rnl.ist.utl.pt/~pmmm/ From pgampe at redhat.com Fri Nov 7 00:41:56 2003 From: pgampe at redhat.com (Paul Gampe) Date: Fri, 7 Nov 2003 10:41:56 +1000 Subject: i18n issues, was: FC2 release In-Reply-To: <200311070034.25123.pmmm@rnl.ist.utl.pt> References: <1068146526.18754.36.camel@spatula> <200311070034.25123.pmmm@rnl.ist.utl.pt> Message-ID: <200311071041.56654.pgampe@redhat.com> Red Hat's internal localization team still has a considerable backlog of work related to the Enterprise Linux 3 launch. We are hoping by mid-December to be able to get back on track with the Fedora releases. We are very excited by the strong support of community translators though, and hope to have the time soon to be able to better coordinate these efforts. Paul On Fri, 7 Nov 2003 10:34 am, Pedro Morais wrote: > > Another "acessibility" issue is internationalization; the current process > isn't bad at all, but could be improved. > I was unfortunately very busy during this beta period (only managed to > follow the mailling lists and update portuguese translations), so I can't > really complain, but I kept i18n stats at 100% at almost all tims, and > certainly at the freeze point I'm sure that only the anaconda docs has a > couple of untranlated, and still there are powerdown messages in english > (in the middle of portuguese messages, so it's not a "too late for i18n > issue") and, even worse, up2date/rhn_register is half translated/half in > english. > > Clearly there's room for improvement. From pmmm at rnl.ist.utl.pt Fri Nov 7 00:42:35 2003 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Fri, 7 Nov 2003 00:42:35 +0000 Subject: i18n issues, was: FC2 release In-Reply-To: <200311070034.25123.pmmm@rnl.ist.utl.pt> References: <1068146526.18754.36.camel@spatula> <200311070034.25123.pmmm@rnl.ist.utl.pt> Message-ID: <200311070042.35857.pmmm@rnl.ist.utl.pt> > Another "acessibility" issue is internationalization; the current process > isn't bad at all, but could be improved. > I was unfortunately very busy during this beta period (only managed to > follow the mailling lists and update portuguese translations), so I can't > really complain, but I kept i18n stats at 100% at almost all tims, and > certainly at the freeze point I'm sure that only the anaconda docs has a > couple of untranlated, and still there are powerdown messages in english > (in the middle of portuguese messages, so it's not a "too late for i18n > issue") and, even worse, up2date/rhn_register is half translated/half in > english. > > Clearly there's room for improvement. And, now that I read the rest of this thread :-) a tracking bug for i18n issues, similar to the proposed for a11y could be a step in that direction. (If it exists, i'm not aware of it) -- Pedro Morais - morais at kde.org - http://www.rnl.ist.utl.pt/~pmmm/ From xose at wanadoo.es Fri Nov 7 00:46:29 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Fri, 07 Nov 2003 01:46:29 +0100 Subject: My experience with upgrading from RH9 to FC1 References: <1068149267.5640.12.camel@scriabin.tannenrauch.ch> <3FAAAC87.7060308@wanadoo.es> <3FAAADC8.9050806@wanadoo.es> <20031106193053.H16873@angus.ind.WPI.EDU> Message-ID: <3FAAEB65.9000508@wanadoo.es> Charles R. Anderson wrote: > But don't use tg3 for BCM 57xx cards. It drops packets under load, > where bcm5700 driver does not. which is tg3 release ? tg3 bugs must go to netdev at oss.sgi.com > Can we get bcm5700.o (which is GPL) integrated? NOOOO, please. bcm5700 code is shit. Yes, it works but it's shit. -- HTML mails are going to trash automagically From katzj at redhat.com Fri Nov 7 00:49:09 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Nov 2003 19:49:09 -0500 Subject: i18n issues, was: FC2 release In-Reply-To: <200311070042.35857.pmmm@rnl.ist.utl.pt> References: <1068146526.18754.36.camel@spatula> <200311070034.25123.pmmm@rnl.ist.utl.pt> <200311070042.35857.pmmm@rnl.ist.utl.pt> Message-ID: <1068166149.12985.29.camel@mirkwood.devel.redhat.com> On Thu, 2003-11-06 at 19:42, Pedro Morais wrote: > And, now that I read the rest of this thread :-) a tracking bug for i18n > issues, similar to the proposed for a11y could be a step in that direction. > (If it exists, i'm not aware of it) Yes, this is definitely a good idea. I've created an i18n keyword, but right now keywords require bug editing access. If you want to create a tracker, though, then that can be used to populate the keyword from eventually. Cheers, Jeremy From alan at redhat.com Fri Nov 7 00:49:27 2003 From: alan at redhat.com (Alan Cox) Date: Thu, 6 Nov 2003 19:49:27 -0500 (EST) Subject: i18n issues, was: FC2 release In-Reply-To: <200311071041.56654.pgampe@redhat.com> from "Paul Gampe" at Tach 07, 2003 10:41:56 Message-ID: <200311070049.hA70nRt20880@devserv.devel.redhat.com> > related to the Enterprise Linux 3 launch. We are hoping by mid-December to > be able to get back on track with the Fedora releases. > > We are very excited by the strong support of community translators though, and > hope to have the time soon to be able to better coordinate these efforts. Does that mean that by mid December we can be thinking about getting the lost translations (for non install stuff) rolling out as or with errata, since Fedora doesn't have the errata restrictions RHEL does ? From skvidal at phy.duke.edu Fri Nov 7 00:47:52 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 06 Nov 2003 19:47:52 -0500 Subject: FC2 release dates In-Reply-To: <1068165254.12985.20.camel@mirkwood.devel.redhat.com> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> Message-ID: <1068166072.10735.16.camel@binkley> > That's four weeks between all but test3 and final which is a slightly > shorter one. Hopefully, having rawhide continually installable will > help get installer feedback sooner and allow people to test fixes much > sooner. Also, being able to do graphical installs via FTP or HTTP > should be a nice help here as well. umm continually installable rawhide. hehe. /me holds his breath. :) > Because people are already asking for 2.6 stuff now and test releases > aren't the same as an actual release. That's basically the fastest > timeline I can come up with that I think can be hit and still have > something that's robust. hmm Makes a crunch for gnome 2.6 then. Looks like it will just miss it on that schedule. Maybe I'll talk to luis and see if there are plans for a 2.4.X release to fix misc bugs. -sv From pmmm at rnl.ist.utl.pt Fri Nov 7 00:52:28 2003 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Fri, 7 Nov 2003 00:52:28 +0000 Subject: i18n issues, was: FC2 release In-Reply-To: <200311071041.56654.pgampe@redhat.com> References: <1068146526.18754.36.camel@spatula> <200311070034.25123.pmmm@rnl.ist.utl.pt> <200311071041.56654.pgampe@redhat.com> Message-ID: <200311070052.28589.pmmm@rnl.ist.utl.pt> Em Sexta 07 Novembro 2003 00:41, Paul Gampe escreveu: > Red Hat's internal localization team still has a considerable backlog of > work related to the Enterprise Linux 3 launch. We are hoping by > mid-December to be able to get back on track with the Fedora releases. > > We are very excited by the strong support of community translators though, > and hope to have the time soon to be able to better coordinate these > efforts. One first small step would be to somewhat generate a list of i18n update dates for each of the packages on a release. I understand that a package won't be regenerated just because I commited an update to a translation (in the betas, for the final release there should be a "Ok, day x all packages will be regenerated even if otherwise necessary just to include translation"). But at least I could when testing a beta look at CVS history and notice that at the day/hour of that last i18n fetch the package was 100% translated and any problem must be in the package. And I think this process is not as simple as "look at the build date of the RPM". Anyway Paul, I do think you are doing a good job overall. > > Paul > > On Fri, 7 Nov 2003 10:34 am, Pedro Morais wrote: > > Another "acessibility" issue is internationalization; the current process > > isn't bad at all, but could be improved. > > I was unfortunately very busy during this beta period (only managed to > > follow the mailling lists and update portuguese translations), so I can't > > really complain, but I kept i18n stats at 100% at almost all tims, and > > certainly at the freeze point I'm sure that only the anaconda docs has a > > couple of untranlated, and still there are powerdown messages in english > > (in the middle of portuguese messages, so it's not a "too late for i18n > > issue") and, even worse, up2date/rhn_register is half translated/half in > > english. > > > > Clearly there's room for improvement. -- Pedro Morais - morais at kde.org - http://www.rnl.ist.utl.pt/~pmmm/ From pmmm at rnl.ist.utl.pt Fri Nov 7 00:55:04 2003 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Fri, 7 Nov 2003 00:55:04 +0000 Subject: regarding: Anyone else interested in graphics? In-Reply-To: <1068162387.6649.254.camel@localhost.localdomain> References: <3FAACFAA.60104@verizon.net> <3FAAD94B.9090309@silverorange.com> <1068162387.6649.254.camel@localhost.localdomain> Message-ID: <200311070055.04798.pmmm@rnl.ist.utl.pt> Em Quinta 06 Novembro 2003 23:46, David Farning escreveu: > On Thu, 2003-11-06 at 17:29, Steven Garrity wrote: > > Michael S. Fivis wrote: > > > Are there other people on this list deeply interested in doing 2D > > > graphical work for fedora? (wallpapers, handling, icons, etc)? > > > michaelfivis at verizon.net Should start a forum or our own list of > > > > some > sort. > > > > I am interested in helping out in these areas. I am a designer for a web > > development firm but have an interested in UI, window, and icon design. > > I also have some talented help from some co-workers in these areas. > > > > Do you have any particular work in mind? > > > > Steven Garrity > > I would have to give a +1 to a consistent look and feel across the > config suit. Granted it is not glamorous, but it would be nice! A big +1. Also, maybe not graphics related, better gnome style guide adherance. > > Dave Farning > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Pedro Morais - morais at kde.org - http://www.rnl.ist.utl.pt/~pmmm/ From pmmm at rnl.ist.utl.pt Fri Nov 7 01:01:29 2003 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Fri, 7 Nov 2003 01:01:29 +0000 Subject: i18n issues, was: FC2 release In-Reply-To: <200311070049.hA70nRt20880@devserv.devel.redhat.com> References: <200311070049.hA70nRt20880@devserv.devel.redhat.com> Message-ID: <200311070101.29753.pmmm@rnl.ist.utl.pt> Em Sexta 07 Novembro 2003 00:49, Alan Cox escreveu: > > related to the Enterprise Linux 3 launch. We are hoping by mid-December > > to be able to get back on track with the Fedora releases. > > > > We are very excited by the strong support of community translators > > though, and hope to have the time soon to be able to better coordinate > > these efforts. > > Does that mean that by mid December we can be thinking about getting the > lost translations (for non install stuff) rolling out as or with errata, > since Fedora doesn't have the errata restrictions RHEL does ? That would be very good; each untranslated string is a serious acessibility issue -- at least here in Portugal in the special market I use Linux (industrial shop floor segment). Although I do understand that's it's probably a lot of work for Red Hat to do so, so maybe we better just think of ways to make sure there aren't any "lost translations" on FC2. -- Pedro Morais - morais at kde.org - http://www.rnl.ist.utl.pt/~pmmm/ From jensknutson at yahoo.com Fri Nov 7 01:05:42 2003 From: jensknutson at yahoo.com (Jens Knutson) Date: Thu, 06 Nov 2003 19:05:42 -0600 Subject: FC2 release dates In-Reply-To: <1068166072.10735.16.camel@binkley> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> Message-ID: <1068167142.4766.2.camel@localhost.localdomain> On Thu, 2003-11-06 at 18:47, seth vidal wrote: > > Because people are already asking for 2.6 stuff now and test releases > > aren't the same as an actual release. That's basically the fastest > > timeline I can come up with that I think can be hit and still have > > something that's robust. > > hmm Makes a crunch for gnome 2.6 then. Looks like it will just miss it > on that schedule. Maybe I'll talk to luis and see if there are plans for > a 2.4.X release to fix misc bugs. Indeed. Certainly, waiting 2-4 weeks on FC 2 to make sure GNOME 2.6 makes it in, too, would be worth it! - jck -- "To turn $100 into $110 is work. To turn $100 million into $110 million is inevitable" -- Edgar Bronfman From skvidal at phy.duke.edu Fri Nov 7 01:03:33 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 06 Nov 2003 20:03:33 -0500 Subject: FC2 release dates In-Reply-To: <1068166072.10735.16.camel@binkley> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> Message-ID: <1068167013.10735.19.camel@binkley> > hmm Makes a crunch for gnome 2.6 then. Looks like it will just miss it > on that schedule. Maybe I'll talk to luis and see if there are plans for > a 2.4.X release to fix misc bugs. This is one thing I think might want to be emphasized. I think gnome 2.6 is looking good for being 1. on time and 2. pretty solid - according to Luis. Maybe the novell-ximian thing brought Luis some more resources to beat on bugs, who knows. :) Worth asking: What group makes this final decision? -sv From pros-n-cons at bak.rr.com Fri Nov 7 01:20:48 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Thu, 6 Nov 2003 17:20:48 -0800 Subject: FC2 release dates In-Reply-To: <1068135502.1453.17.camel@opus> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <1068135502.1453.17.camel@opus> Message-ID: <20031106172048.0f31f3f6.pros-n-cons@bak.rr.com> On Thu, 06 Nov 2003 11:18:22 -0500 seth vidal wrote: > On Thu, 2003-11-06 at 11:04, Chris Adams wrote: > > Once upon a time, seth vidal said: > > > I think we should get an estimate on FC2 beta/freeze/release dates > > > ironed out right now. > > > > Hmm, I think an idea of what the goal of FC2 will be should come first. > > An obvious one: switch to kernel 2.6? The goals will somewhat drive the > > dates. > > Well it looks like gnome 2.6 will be in late betas in feb/march > http://www.gnome.org/start/2.5/ > > Might be a good idea to see where that will be and how badly it break > compat with 2.4/2.2. > > So it's looking very 2.6-y > > kde 3.2 should be in stable for about 3 months by the beta - so that > would be good. > > What's mozilla's roadmap look like? > > Any other major programs that should be kept in mind? > -sv I think April is perfect. the EOL of RedHat 9 will be there and if these ppl switch Fedora is where we'd want them to go right? kernel 2.6, Gnome 2.6, etc plus a long 6 month release gives kernel2.6 time to iron out some things, this should _not_ be a quick release. It is probably going to be a defining release for Fedora most ppl are waiting for a second release to see where its really going to stand in the market. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maxka at myrealbox.com Fri Nov 7 05:05:37 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Thu, 06 Nov 2003 21:05:37 -0800 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068072068.32434.33.camel@laptop.fubar.dk> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068032835.7163.10.camel@laptop.fubar.dk> <1068064320.3427.1.camel@max.localdomain> <1068065532.32434.17.camel@laptop.fubar.dk> <1068066360.3427.28.camel@max.localdomain> <1068072068.32434.33.camel@laptop.fubar.dk> Message-ID: <1068181537.3488.3.camel@max.localdomain> On Wed, 2003-11-05 at 14:41, David Zeuthen wrote: > Now, .fdi files should also be signed so there must be some way of > moderating what comes from your database; maybe some karma/voting system > for contributing users would fit the bill here? We've talked about this over here, as well. We were sort of tentatively planning on using Advogato somehow. Also, we could flag "high contention" devices and volunteer admins could look at them, in particularly intense cases. > Definately! I will however concentrate on getting hal 0.2 finished so it > works with PCI and USB devices and storage. When that is done I'll look > into packaging it for FC1 and see how it fits in. Automated retrival of > .fdi files from a database such as yours and signing stuff is something > that will come after that. All right. Should I join the xdg-list so that I can keep up-to-date on this situation? > Btw, I intend that each device object in HAL to export a lot of device > specific information (right now only USB is documented, but I got PCI > working as well); perhaps it would be good already now to agree on > naming conventions (e.g. I call it usb.bDeviceClass) for specific > hardware properties? Yes, it would be a really good idea to talk about naming conventions. :-) For me, the priority is on flexibility. There are going to be buses we can't imagine, and devices we can't imagine, and we want to be able to use them some day. :-) Any naming convention that translates easily into XML and makes sense without being too specific is good by me. I'm so thrilled to find that there's a project that's moving in even somewhat the same direction as us. :-) -M From tony at tgds.net Fri Nov 7 06:24:23 2003 From: tony at tgds.net (tony) Date: Fri, 07 Nov 2003 07:24:23 +0100 Subject: regarding: Anyone else interested in graphics? In-Reply-To: <3FAACFAA.60104@verizon.net> References: <3FAACFAA.60104@verizon.net> Message-ID: <1068186263.5029.122.camel@localhost.localdomain> Le jeu 06/11/2003 ? 23:48, Michael S. Fivis a ?crit : > Are there other people on this list deeply interested in doing 2D > graphical work for fedora? (wallpapers, handling, icons, etc)? > michaelfivis at verizon.net Should start a forum or our own list of some sort. I do a little of that. But I'm a better nitpicker "that's not straight", "this should be aligned with that" and "these colours don't work for the color blind" kind of stuff... Cheers Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From barryn at pobox.com Fri Nov 7 07:53:04 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 6 Nov 2003 23:53:04 -0800 Subject: Yum-able screen-4.0.1 test-only RPMS In-Reply-To: <1067608285.4912.141.camel@atlantis.boston.redhat.com> References: <1067608285.4912.141.camel@atlantis.boston.redhat.com> Message-ID: <20031107075304.GD29089@ip68-4-255-84.oc.oc.cox.net> On Fri, Oct 31, 2003 at 08:51:25AM -0500, Lon Hohberger wrote: > NOTE NOTE NOTE: If you test this package, you must also comment out the > "stty erase `tput kbs`" line from your shell's rcfile. Tcsh users, I am > told, do not need to do this. Ok, I've done this, Whenever I start a brand new screen session (this does not happen when attaching to a previous session), I get some kind of error message flashing by the title bar on my terminal window (with both xterm and gnome-terminal). It flashes by too quickly for me to comprehend the entire error message. Wait, let me try again from a Mac OS X "Jaguar" Terminal, and see if I can copy-and-paste... Got it! Here's the message: /etc/screenrc: bind: character, ^x, or (octal) \032 expected. This is in fact the new /etc/screenrc from your new package. I did 'rpm -e screen' and made sure there was no /etc/screenrc, before installing your new package, just to make sure. Other than this message, things seem fine so far! -Barry K. Nathan From Axel.Thimm at physik.fu-berlin.de Fri Nov 7 10:50:50 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Fri, 7 Nov 2003 11:50:50 +0100 Subject: Distags in rpm sort order (yes, versioning again ;) In-Reply-To: <20031103103548.GC16946@puariko.nirvana> References: <20031031065846.GC4184@puariko.nirvana> <20031103103548.GC16946@puariko.nirvana> Message-ID: <20031107105050.GC17587@puariko.nirvana> On Mon, Nov 03, 2003 at 11:35:48AM +0100, Axel Thimm wrote: > No comments from RH? Should every repository and its cat come up with > its own scheme creating more compatibility problems in the future? Well, this thread is becoming old and boring and is like beating a dead horse, so I am giving up ;) While I personally think that scheme A (e.g. using fedora like disttags for past RH releases) would solve the problems best, it only makes sense to me, if that would become a standard, and not only something atrpms follows. Since neither RH nor any other repo really commented on this (constructively that is ;), I guess it means repos will go wild with supporting multiple RH/FC releases. I for my part will use scheme B (numbering FC with something higher than rh9, e.g. rh9.1, similar to Rex Dieter's suggestion a while back). I wash my hands in innocence ;) > On Fri, Oct 31, 2003 at 07:58:46AM +0100, Axel Thimm wrote: > > Bringing up this topic again, since it was left unresolved. > > > > I won't go into details again, about *why* a disttag is needed and why > > it has to adhear to rpm internal sort algorithms. Please check the > > following threads in doubt (and discuss the reasons there please, help > > keeping this thread constructive this time ;): > > > > http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00272.html > > http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00551.html > > http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00263.html > > > > The bottom line is that distags are needed if one wants to create > > packages for the same upstream sources but built for different > > distributions. Disttags can then be embedded in the release tag to > > ensure proper upgradability. > > > > ==================== Disttag schemes: pick one! > > > > Here are the discussed schemes (some others exist with small > > variations, e.g. fc instead of fdr, or no fdr tag at all, the > > discussion is the same). Default versioning is (no cvs/beta, kernel > > modules and special cases, leave that for another thread): > > > > -- > > e.g. simply > > foo-1.2.3-4..johnsmith > > > > disttag can be: > > A B C > > Red Hat Linux 7.3 fdr0.7.3 rh7.3 rh7.3 > > Red Hat Linux 8.0 fdr0.8.0 rh8.0 rh8.0 > > Red Hat Linux 9 fdr0.9 rh9 rh9 > > Fedora Core 1 fdr1 rh9.1 1fdr > > Fedora Core 2 test1 fdr1.95 rh9.1.95 1.95fdr > > > > A) + consistent distid > > + future tagging will be self-explanatory > > + fits nicer into a general nameing scheme (e.g. not only RHL and > > FDR, but RHEL and non-RH could use, or allready do use the > > := idiom) > > - obfuscates RHL <= 9 rpm versioning > > - requires rebuilding of existing 3rd party repos for the sake of > > versioning. > > o requires a statement from redhat to allow calling RH 7.3 as FDR > > 0.7.3 for instance, e.g. the "old" RHL product is officially > > conamed Fedora 0.something > > > > B) + current practice for many repos offering rpms build form the same > > upstream sources for more than one distribution. > > + keeps current 3rd party repos from rebuilding all the old rpms > > just for reversioning (and users from redownloading the same rpms > > with a new name) > > - does not pertain the strict separation RHL <-> FDR, and may cause > > confusion. > > o A) is preferable, but B) may be a nice transition solution for > > existing installations. > > > > C) + visually pertains separation of rh and fdr releases > > - is a kludgy workaround using rpm semantics present only after > > RHL9, thus breaking upgrading from RH8.0 and less (note that rpm > > errata for fixing this rpm bug and others are still not > > officially available) > > - number prefixing breaks when the preceding expression is numeric > > separated with dots or underscores, e.g. > > > > foo-1.2.3-1.1_rh9 > foo-1.2.3-1_1fdr > > > > (the stems here are "foo-1.2.3-1.1" < "foo-1.2.3-1") > > Using decimal release tags needs to be separately considered, but > > the fact is that they are being used often. > > - reverses order of distid and distversion > > - Variant "1fdr" keeps order of distid and distversion, > > but breaks in all other ways above, as well as introducing an > > obfuscating decimal in the release tag. > > > > I hope RH agrees to using A) or a variant thereof. In any case it > > would be beneficial if an "official" solution could be blessed, so > > that 3rd party repos don't have to reinvent their own > > versioning. > > > > Certainly many repos will start offering their packages (officially) > > after FC1 is (officially) released, so there are only a few days left > > ... > > > > In order to not molest users with forced downloads for reversioning > > rpms for older RHL releases, I would suggest to use B) in a transition > > phase for large rpms that do not need updating other than the > > reversioning. After some time B) will have been phased out. > > > > C) is not really an option. It will break more than it is intended to > > salvage. > > > > Also it would be nice to have rawhide versioning, e.g. immediately > > after a release update fedora-release to the next test release > > version or something below to indicate rawhide builds. > > > > Thank you for your time. > > > -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From xose at wanadoo.es Fri Nov 7 12:48:57 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Fri, 07 Nov 2003 13:48:57 +0100 Subject: My experience with upgrading from RH9 to FC1 References: <1068149267.5640.12.camel@scriabin.tannenrauch.ch> <3FAAAC87.7060308@wanadoo.es> <3FAAADC8.9050806@wanadoo.es> <20031106193053.H16873@angus.ind.WPI.EDU> Message-ID: <3FAB94B9.6090106@wanadoo.es> Charles R. Anderson wrote: > But don't use tg3 for BCM 57xx cards. It drops packets under load, > where bcm5700 driver does not. which is tg3 release ? tg3 bugs must go to netdev at oss.sgi.com > Can we get bcm5700.o (which is GPL) integrated? NOOOO, please. bcm5700 code is shit. Yes, it works but it's shit. -- HTML mails are going to trash automagically From xfs at ramaswamy.net Fri Nov 7 13:27:31 2003 From: xfs at ramaswamy.net (Ajay Ramaswamy) Date: Fri, 7 Nov 2003 18:57:31 +0530 Subject: XFS filesystem support in Fedora In-Reply-To: <20031106210804.B034A1437074@burgers.bubbanfriends.org> References: <20031106210804.B034A1437074@burgers.bubbanfriends.org> Message-ID: <200311071857.31463.xfs@ramaswamy.net> On Friday 07 Nov 2003 2:38 am, Mike Burger wrote: > Are there any plans to include SGI's XFS filesystem support into Fedora's > kernels and/or installers? > > Such support would be incredibly appreciated. > > > -- > fedora-list mailing list > fedora-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-list These two patches add the necessary support to anaconda to enable XFS support, the only problem with this is that grub will hang at the end while installing the bootloader, a few of us on the linux-xfs mailing list are trying to find the answer to that problem too. As for the kernel & userspace utils oss.sgi.com is your friend. Eric Sandeen has just put out a kernel SRPM today. Now to find the reason grub hangs at the end. HTH Ajay -------------- next part -------------- A non-text attachment was scrubbed... Name: anaconda-xfs-label.patch Type: text/x-diff Size: 5030 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: anaconda-xfs.patch Type: text/x-diff Size: 4211 bytes Desc: not available URL: From xose at wanadoo.es Fri Nov 7 15:47:13 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Fri, 07 Nov 2003 16:47:13 +0100 Subject: Packages licenses Message-ID: <3FABBE81.7060207@wanadoo.es> hi, I have extracted the 'License' tag of all RH9 packages, sorry FC1 is not here yet. And I see a chaotic style, duplicates... A clearer policy and style should be used in Fedora. idea? Maybe, rpmbuild should check 'License' against a list of OSI compatible licenses, otherwise a -nocl (--noOSIcompatiblelicense) flag should be used to build it. --cut-- 3DFX GLIDE Source Code General Public License Apacheish Apache Software License Arphic Public License (GPL-like) Artistic BSD BSD/GPL BSDish BSD-like BSD-like and LGPL BSD-style Copyright ? 1999-2002 Red Hat, Inc. All rights reserved. Copyright ? 2002 Red Hat, Inc. All rights reserved. distributable Distributable Distributable (BSD-like) Distributable under Licenses eGenix.com Public License (Python) FDL Free freely distributable Freely distributable Freely Distributable Freely redistributable Freely Redistributable Free, no warranties. freeware Freeware GNU General Public License GNU GPL GNU GPL Version 2 GPL GPL2 GPL and Artistic GPL/BSD GPL/distributable GPL, LGPL GPL/LGPL GPL/LGPL/GFDL GPL/MIT GPL / new BSD License / other GPL (not Firmware) GPL or artistic GPL or Artistic GPL or BSD GPL (programs), relaxed LGPL (libraries), and public domain (docs) GPL/QPL GPL, URW holds copyright GPL/XFree86 IBM Public License LaTeX Project Public License (http://www.latex-project.org/lppl.txt) LGPL LGPL and GPL LGPL/GPL MIT MIT, freely distributable. MPL OMRON Corporation, OMRON Software Co., Ltd. Open Group Public License OpenLDAP OSI certified PSF - see LICENSE public domain Public domain Public Domain Redistributable Special (see Copyright Notice) The PHP License University of Washington Free-Fork License W3C IPR W3C (see: http://www.w3.org/Consortium/Legal/copyright-software.html) XFree86 X-like --this-is-the-end-- -- HTML mails are going to trash automagically From salimma1 at yahoo.co.uk Fri Nov 7 04:30:04 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Fri, 07 Nov 2003 11:30:04 +0700 Subject: FC2 release dates In-Reply-To: <1068139006.3241.36.camel@localhost.localdomain> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <1068135502.1453.17.camel@opus> <1068139006.3241.36.camel@localhost.localdomain> Message-ID: <1068179403.8454.26.camel@bushido.localdomain> On Fri, 2003-11-07 at 00:16, Julien Olivier wrote: > What about OpenOffice ? Any chance to have a Ximian-ised OpenOffice in > Fedora Core 2 ? > As long as the default file format is not .doc ! Regards, Michel From behdad at cs.toronto.edu Fri Nov 7 16:01:01 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Fri, 7 Nov 2003 11:01:01 -0500 Subject: rawhide-release? Message-ID: Hi, Where is rawhide-release gone? BTW, I've noticed that /usr/share/doc/fedora-release-1/9 is empty, while the other ones are not. behdad From twaugh at redhat.com Fri Nov 7 16:10:32 2003 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 7 Nov 2003 16:10:32 +0000 Subject: Packages licenses In-Reply-To: <3FABBE81.7060207@wanadoo.es> References: <3FABBE81.7060207@wanadoo.es> Message-ID: <20031107161032.GF1963@redhat.com> On Fri, Nov 07, 2003 at 04:47:13PM +0100, Xose Vazquez Perez wrote: > And I see a chaotic style, duplicates... A clearer policy and style should be used > in Fedora. The trouble is that a license can't always be described in a couple of words. Sometimes you really do need to read through COPYING to know what kind of license it is. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From barryn at pobox.com Fri Nov 7 09:38:02 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 7 Nov 2003 01:38:02 -0800 Subject: FC2 release dates In-Reply-To: <1068166072.10735.16.camel@binkley> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> Message-ID: <20031107093802.GE29089@ip68-4-255-84.oc.oc.cox.net> On Thu, Nov 06, 2003 at 07:47:52PM -0500, seth vidal wrote: > hmm Makes a crunch for gnome 2.6 then. Looks like it will just miss it > on that schedule. Maybe I'll talk to luis and see if there are plans for > a 2.4.X release to fix misc bugs. FWIW, I saw a mail on the Mandrake cooker list asking people to completely keep GNOME 2.6 stuff out of cooker. It sounds like Mandrake 10.0 may still ship with GNOME 2.4. Ok, I found the mail here: http://marc.theaimsgroup.com/?l=mandrake-cooker&m=106811594208408&w=2 (Personally, I don't care too much about how the FC2 schedule goes. FWIW I was mildly annoyed when FC1 was delayed for GNOME 2.4 -- I wanted to see a release with RPM 4.2.1 and ExecShield sooner -- but I think it turned out for the best in the end.) -Barry K. Nathan From sopwith at redhat.com Fri Nov 7 16:20:34 2003 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 7 Nov 2003 11:20:34 -0500 (EST) Subject: Packages licenses In-Reply-To: <3FABBE81.7060207@wanadoo.es> Message-ID: On Fri, 7 Nov 2003, Xose Vazquez Perez wrote: > I have extracted the 'License' tag of all RH9 packages, sorry FC1 is not > here yet. And I see a chaotic style, duplicates... A clearer policy and > style should be used in Fedora. > > idea? Maybe, rpmbuild should check 'License' against a list of OSI > compatible licenses, otherwise a -nocl (--noOSIcompatiblelicense) flag > should be used to build it. Having a flag like that is not likely, because some of the licenses may be fine but not formally OSI-approved, and because the system used to build the packages doesn't allow passing options such as -nocl. You're right that there are many duplicates that could use fixing. Once it is decided which license strings need to change, you can file patches in bugzilla for all the ones that obviously need changing (e.g. s/Freely distributable/Freely redistributable/i). -- Elliot From warren at togami.com Fri Nov 7 11:27:20 2003 From: warren at togami.com (Warren Togami) Date: Fri, 07 Nov 2003 01:27:20 -1000 Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: <1067622953.20763.164.camel@bobcat.mine.nu> References: <3FA229D3.4000104@togami.com> <3FA2722D.6090504@togami.com> <20031031180006.1b3cad50.ms-nospam-0306@arcor.de> <1067622953.20763.164.camel@bobcat.mine.nu> Message-ID: <1068204440.12684.29.camel@laptop> On Fri, 2003-10-31 at 07:55, Ville Skytt? wrote: > On Fri, 2003-10-31 at 19:00, Michael Schwendt wrote: > > On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote: > > > > > > Err... you are completely right about it not being necessary in the > > > post-release case. I am not sure why our fedora.us policy retained that > > > even though it was unnecessary for all these months. The way I > > > understand the older version of rpm broken rpmvercmp behavior, this > > > wouldn't be a problem with those versions too. > > > > * To be able to go back from 2.1.7a to a patched 2.1.7 in case the > > 2.1.7a post-release "fix" turns out to cause side-effects. > > > > * Consistency above all. > > > > * The road of least surprise (with regard to upstream versioning). > > > > * To help avoid that users think foo-1.0a would be an unstable alpha > > version, when in fact it is a post-release patch-level. > > Also, if foo-1.0a < foo-1.0b < foo-1.0a, as presented earlier in the > proposal (the "two-way upgrade problem") exists for prereleases, why > wouldn't it exist for postreleases? Actually, the two-way upgrade problem was fixed right before RH9. So rpm-4.2 in RH9, rpm-4.2.1, rpm-4.1.1, rpm-4.0.5 all behave properly in this case. This however does not matter, since it has been agreed upon on fedora-legacy list that ALL distributions supported by Fedora Legacy will force an upgrade of rpm as a requirement for users to begin using those repositories. This is in order to enforce consistency and avoid old bugs that were fixed ages ago. (A tremendous amount of verification testing will happen before each rpm is published for Legacy.) Warren From pauln at truemesh.com Fri Nov 7 16:30:23 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Fri, 7 Nov 2003 16:30:23 +0000 Subject: Packages licenses In-Reply-To: <3FABBE81.7060207@wanadoo.es> References: <3FABBE81.7060207@wanadoo.es> Message-ID: <20031107163022.GF31078@shitake.truemesh.com> On Fri, Nov 07, 2003 at 04:47:13PM +0100, Xose Vazquez Perez wrote: > Maybe, rpmbuild should check 'License' against a list of OSI > compatible licenses, There are rpmlint modules for License IIRC. Paul From Axel.Thimm at physik.fu-berlin.de Fri Nov 7 16:47:17 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Fri, 7 Nov 2003 17:47:17 +0100 Subject: fedora-legacy agrees to enforce rpm upgrades? (was: Warren's Package Naming Proposal - Revision 1) In-Reply-To: <1068204440.12684.29.camel@laptop> References: <3FA229D3.4000104@togami.com> <3FA2722D.6090504@togami.com> <20031031180006.1b3cad50.ms-nospam-0306@arcor.de> <1067622953.20763.164.camel@bobcat.mine.nu> <1068204440.12684.29.camel@laptop> Message-ID: <20031107164717.GD27327@puariko.nirvana> On Fri, Nov 07, 2003 at 01:27:20AM -1000, Warren Togami wrote: > This however does not matter, since it has been agreed upon on > fedora-legacy list that ALL distributions supported by Fedora Legacy > will force an upgrade of rpm as a requirement for users to begin using > those repositories. When was this agreed upon? While I personally support this scheme, I was under the impression that there were more people against enforcing rpm upgrades for minimally changes (e.g. fedora-legacy should only provide security related errata). Especially because RH itself did not issue errata for rpm despite the known problems. In fact, Warren, I believe we were the only two supporting rpm upgrades, so unless we are the only left subscribers of fedora-legacy, it is not yet an agreement of the whole list. ;) -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From xose at wanadoo.es Fri Nov 7 16:50:13 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Fri, 07 Nov 2003 17:50:13 +0100 Subject: Packages licenses References: Message-ID: <3FABCD45.5040803@wanadoo.es> Elliot Lee wrote: > Having a flag like that is not likely, because some of the licenses may be > fine but not formally OSI-approved, and because the system used to build > the packages doesn't allow passing options such as -nocl. > > You're right that there are many duplicates that could use fixing. Once it > is decided which license strings need to change, you can file patches in > bugzilla for all the ones that obviously need changing (e.g. s/Freely > distributable/Freely redistributable/i). the worse is that there are packages with *wrong* 'License' tag: ex. db4 querida:~ $ rpm -q --qf '%{name}\t%{license}\n' db4 db4 GPL /usr/share/doc/db4-4.0.14/LICENSE shows that it's BSD-alike _All package maintainers_ *should check* 'License' tag!! -- HTML mails are going to trash automagically From otaylor at redhat.com Fri Nov 7 17:16:58 2003 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 07 Nov 2003 12:16:58 -0500 Subject: Packages licenses In-Reply-To: <3FABCD45.5040803@wanadoo.es> References: <3FABCD45.5040803@wanadoo.es> Message-ID: <1068225417.13389.33.camel@poincare.devel.redhat.com> On Fri, 2003-11-07 at 11:50, Xose Vazquez Perez wrote: > Elliot Lee wrote: > > > Having a flag like that is not likely, because some of the licenses may be > > fine but not formally OSI-approved, and because the system used to build > > the packages doesn't allow passing options such as -nocl. > > > > You're right that there are many duplicates that could use fixing. Once it > > is decided which license strings need to change, you can file patches in > > bugzilla for all the ones that obviously need changing (e.g. s/Freely > > distributable/Freely redistributable/i). > > the worse is that there are packages with *wrong* 'License' tag: ex. db4 > > querida:~ $ rpm -q --qf '%{name}\t%{license}\n' db4 > db4 GPL > > /usr/share/doc/db4-4.0.14/LICENSE shows that it's BSD-alike > > _All package maintainers_ *should check* 'License' tag!! Read that carefully. It's very much not BSD-like. It's not the GPL either, however, though it could roughly be described as GPL-like in general intent. Regards, Owen From esr at snark.thyrsus.com Fri Nov 7 17:20:44 2003 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 12:20:44 -0500 Subject: RPM submission script Message-ID: <200311071720.hA7HKi1C015566@snark.thyrsus.com> The next point release of Bugzilla will include and support a script called bug-bugzilla, written by Christian Reis and myself, that allows posting of bugs without going through a Web interface. You supply an RFC822-like message on input instead. Some may recall my urging that submission of RPMs for Fedora needs to be scriptable. I followed through by working with the Bugzilla crew to build and document this tool. The bug-bugzilla script is the essential piece of infrastructure for scriptable RPM submissions to happen. It abstracts away the details of interacting with Bugzilla CGIs. I therefore propose the following: 1. A bug-bugzilla RPM should become part of Fedora core. 2. I will write a fedora-submit script, which will call bug-bugzilla. 3. fedora-submit should become part of the Fedora RPM tools RPM, with a dependency on bug-bugzilla. Later, if Fedora's submission channel for RPMs changes, fedora-submit can be changed to suit. The important thing, in my opinion, is to get a fedora-submit mechanism in place in order to encourage contributions from people like me who run lots of projects and need scriptable RPM submission to support that. -- Eric S. Raymond Good intentions will always be pleaded for every assumption of authority. It is hardly too strong to say that the Constitution was made to guard the people against the dangers of good intentions. There are men in all ages who mean to govern well, but they mean to govern. They promise to be good masters, but they mean to be masters. -- Daniel Webster From jkeating at j2solutions.net Fri Nov 7 16:59:51 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 08:59:51 -0800 Subject: fedora-legacy agrees to enforce rpm upgrades? (was: Warren's Package Naming Proposal - Revision 1) In-Reply-To: <20031107164717.GD27327@puariko.nirvana> References: <3FA229D3.4000104@togami.com> <1068204440.12684.29.camel@laptop> <20031107164717.GD27327@puariko.nirvana> Message-ID: <200311070859.55886.jkeating@j2solutions.net> On Friday 07 November 2003 08:47, Axel Thimm wrote: > While I personally support this scheme, I was under the impression > that there were more people against enforcing rpm upgrades for > minimally changes (e.g. fedora-legacy should only provide security > related errata). Especially because RH itself did not issue errata > for rpm despite the known problems. > > In fact, Warren, I believe we were the only two supporting rpm > upgrades, so unless we are the only left subscribers of > fedora-legacy, it is not yet an agreement of the whole list. ;) I personally agreed to it, until somebody showed me clear evidence that it could/would break something. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 jkeating at j2solutions.net Fri Nov 7 17:34:28 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 09:34:28 -0800 Subject: RPM submission script In-Reply-To: <200311071720.hA7HKi1C015566@snark.thyrsus.com> References: <200311071720.hA7HKi1C015566@snark.thyrsus.com> Message-ID: <200311070934.28398.jkeating@j2solutions.net> On Friday 07 November 2003 09:20, Eric S. Raymond wrote: > The next point release of Bugzilla will include and support a script > called bug-bugzilla, written by Christian Reis and myself, that > allows posting of bugs without going through a Web interface. You > supply an RFC822-like message on input instead. Eric, this seems very nice. My lack of knowledge in the RFC area though brings me to ask if you could provide a small example of a "RFC822-like" message? Another project I manage is pressuring me to move away from bugzilla so that our users/developers can submit bugs w/out using the web interface. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 skvidal at phy.duke.edu Fri Nov 7 17:42:17 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 07 Nov 2003 12:42:17 -0500 Subject: RPM submission script In-Reply-To: <200311070934.28398.jkeating@j2solutions.net> References: <200311071720.hA7HKi1C015566@snark.thyrsus.com> <200311070934.28398.jkeating@j2solutions.net> Message-ID: <1068226936.5055.148.camel@opus> On Fri, 2003-11-07 at 12:34, Jesse Keating wrote: > On Friday 07 November 2003 09:20, Eric S. Raymond wrote: > > The next point release of Bugzilla will include and support a script > > called bug-bugzilla, written by Christian Reis and myself, that > > allows posting of bugs without going through a Web interface. You > > supply an RFC822-like message on input instead. > > Eric, this seems very nice. My lack of knowledge in the RFC area though > brings me to ask if you could provide a small example of a > "RFC822-like" message? Another project I manage is pressuring me to > move away from bugzilla so that our users/developers can submit bugs > w/out using the web interface. rfc822 == email. -sv From skvidal at phy.duke.edu Fri Nov 7 17:44:37 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 07 Nov 2003 12:44:37 -0500 Subject: FC2 release dates In-Reply-To: <20031107093802.GE29089@ip68-4-255-84.oc.oc.cox.net> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> <20031107093802.GE29089@ip68-4-255-84.oc.oc.cox.net> Message-ID: <1068227077.5055.152.camel@opus> > FWIW, I saw a mail on the Mandrake cooker list asking people to > completely keep GNOME 2.6 stuff out of cooker. It sounds like Mandrake > 10.0 may still ship with GNOME 2.4. > > Ok, I found the mail here: > http://marc.theaimsgroup.com/?l=mandrake-cooker&m=106811594208408&w=2 > > (Personally, I don't care too much about how the FC2 schedule goes. FWIW I > was mildly annoyed when FC1 was delayed for GNOME 2.4 -- I wanted to see > a release with RPM 4.2.1 and ExecShield sooner -- but I think it turned > out for the best in the end.) Well I guess I'm thinking from two perspectives: 1. it will mean more testing for gnome, which is definitely good. 2. it could mean staying roughly in-sync with gnome which is not bad 3. if fc1 is gnome 2.4 and fc2 is gnome 2.4 then it's a good shot that fc3 is gnome 2.8 - which is a bigger jump than gnome 2.4->2.6. Also there is that whole 'things numbered 2.6' which is nice. -sv From jigorou3 at mail.goo.ne.jp Fri Nov 7 18:00:00 2003 From: jigorou3 at mail.goo.ne.jp (jigorou3 at mail.goo.ne.jp) Date: 8 Nov 2003 03:00:00 +0900 Subject: esound.spec has a description thats\' out-of-date Message-ID: <20031107180000.97063.qmail@mail.goo.ne.jp> Hello. In esound.spec, line 2, the description %define __os_install_post /usr/lib/rpm/redhat/brp-compress should be %define __os_install_post /usr/lib/rpm/brp-compress isn't it? Recent version of Red Hat Linux (and Fedora Core) doesn't have /usr/lib/rpm/redhat , and esound's build fails in default setting. So, I think it would be better for all to be fixed esound.spec in esound's next release... Thanks From lhh at redhat.com Fri Nov 7 17:55:57 2003 From: lhh at redhat.com (Lon Hohberger) Date: Fri, 07 Nov 2003 12:55:57 -0500 Subject: Yum-able screen-4.0.1 test-only RPMS In-Reply-To: <20031107075304.GD29089@ip68-4-255-84.oc.oc.cox.net> References: <1067608285.4912.141.camel@atlantis.boston.redhat.com> <20031107075304.GD29089@ip68-4-255-84.oc.oc.cox.net> Message-ID: <1068227757.26303.784.camel@atlantis.boston.redhat.com> On Fri, 2003-11-07 at 02:53, Barry K. Nathan wrote: > /etc/screenrc: bind: character, ^x, or (octal) \032 expected. Thanks for that tidbit - I'd previously been unable to capture that message, but it is a known bug (my coworkers have reported it too). It seems to be a bug in the default screen-4.0.1 screenrc file; I'll ask the developer. > Other than this message, things seem fine so far! Great! I'll work on the one above as well as try and cut down on the number of unnecessary patches we include. -- Lon -- Lon Hohberger Red Hat, Inc. --> http://www.redhat.com My Public Key --> http://people.redhat.com/lhh/pubkey.txt The views expressed in this electronic mail message are mine alone and do not necessarily reflect the views of Red Hat, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From esr at thyrsus.com Fri Nov 7 18:19:26 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 13:19:26 -0500 Subject: RPM submission script In-Reply-To: <1068226936.5055.148.camel@opus> References: <200311071720.hA7HKi1C015566@snark.thyrsus.com> <200311070934.28398.jkeating@j2solutions.net> <1068226936.5055.148.camel@opus> Message-ID: <20031107181926.GA15796@thyrsus.com> seth vidal : > > Eric, this seems very nice. My lack of knowledge in the RFC area though > > brings me to ask if you could provide a small example of a > > "RFC822-like" message? Another project I manage is pressuring me to > > move away from bugzilla so that our users/developers can submit bugs > > w/out using the web interface. > > rfc822 == email. Yeah, what he said. Headers are various metadata, the body is the description. Here's what the last version of my test load looked like: ------------------------------------------------------------------------ Product: TestProduct Component: TestComponent Version: other Priority: P2 Keywords: mock Status: FUBAR Severity: normal Summary: Eric's test bug for the submit script #20 This version tries to merge in data from options. ------------------------------------------------------------------------ Thing about this format is that it's trivial to generate using a shellscript. I expect fedora-submit to be no more than about 30 lines of code. Your other project could write its own submission wrapper -- the fact that (as you note) this is a more generally useful capability is what would justify adding bug-bugzilla to Fedora core. (You can find it in the contrib directory of Bugzilla CVS.) Who's the gatekeeper for these decisions, and who's in charge of packaging the Fedora RPM tools? This is a small, easy addition with big benefits; I think it should definitely go in FC2. -- Eric S. Raymond From sopwith at redhat.com Fri Nov 7 18:23:09 2003 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 7 Nov 2003 13:23:09 -0500 (EST) Subject: esound.spec has a description thats\' out-of-date In-Reply-To: <20031107180000.97063.qmail@mail.goo.ne.jp> Message-ID: On 8 Nov 2003 jigorou3 at mail.goo.ne.jp wrote: > Recent version of Red Hat Linux (and Fedora Core) doesn't have > /usr/lib/rpm/redhat > , and esound's build fails in default setting. Make sure to install the redhat-rpm-config package. It does sound like esound.spec needs fixing, though. Please file a bug! -- Elliot From matthias at rpmforge.net Fri Nov 7 18:32:29 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Fri, 7 Nov 2003 19:32:29 +0100 Subject: esound.spec has a description thats\' out-of-date In-Reply-To: <20031107180000.97063.qmail@mail.goo.ne.jp> References: <20031107180000.97063.qmail@mail.goo.ne.jp> Message-ID: <20031107193229.7d136bcf.matthias@rpmforge.net> jigorou3 at mail.goo.ne.jp wrote : > In esound.spec, line 2, the description > > %define __os_install_post /usr/lib/rpm/redhat/brp-compress > > should be > > %define __os_install_post /usr/lib/rpm/brp-compress > > isn't it? > > Recent version of Red Hat Linux (and Fedora Core) doesn't have > /usr/lib/rpm/redhat > , and esound's build fails in default setting. > > So, I think it would be better for all to be fixed esound.spec in > esound's next release... I think the "redhat" sub-directory and its files come from the "redhat-rpm-config" package, which is responsible for quite a few things regarding package builds. Now the real question would be : "Why define that brp-compress instead of leaving the default?"... to avoid stripping, maybe? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2115.nptl Load : 0.19 0.42 0.85 From johnsonm at redhat.com Fri Nov 7 18:34:25 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 7 Nov 2003 13:34:25 -0500 Subject: Hardware Database In-Reply-To: <1068016387.6414.42.camel@max.localdomain>; from maxka@myrealbox.com on Tue, Nov 04, 2003 at 11:13:07PM -0800 References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> Message-ID: <20031107133425.A13384@devserv.devel.redhat.com> On Tue, Nov 04, 2003 at 11:13:07PM -0800, Maxwell Kanat-Alexander wrote: > What I _don't_ really think would be fun would be parsing the text > output of those programs. MKJ thought it would be ideal if dmidecode > could give us XML. Anybody know if there's a tool that already does > this, or something we could start with? hwbrowser seems to make sense of > that data somehow -- is there a way to get data out of it? Who's the > maintainer of hwbrowser? I don't know if there's a version of dmidecode that prints xml, but I can't imagine that it would be remotely difficult to add, nor that it would make the source code less clean. http://www.nongnu.org/dmidecode/ Also note that there are a few other tools that come with dmidecode that might have useful information for this project. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From johnsonm at redhat.com Fri Nov 7 18:44:32 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 7 Nov 2003 13:44:32 -0500 Subject: RH recommends using Windows? plus a Question! In-Reply-To: <1068027839.3471.11.camel@localhost.localdomain>; from julo@altern.org on Wed, Nov 05, 2003 at 10:23:59AM +0000 References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1067989938.3470.17.camel@localhost.localdomain> <20031104190459.A15665@devserv.devel.redhat.com> <1068027839.3471.11.camel@localhost.localdomain> Message-ID: <20031107134432.B13384@devserv.devel.redhat.com> On Wed, Nov 05, 2003 at 10:23:59AM +0000, Julien Olivier wrote: > Hmm... not at all :) My idea is: > > -The user clicks on a link (for example http://hardwarde.redhat.com) > -He then fills a web form asking him which hardware he has and how it > works (in an "assistant/wizard/druid" form, like in bugzilla). > -He validates o Not sufficiently structured o Not sufficiently complete o Not sufficiently verified o Too much work for the user for widespread compliance o Such databases we already have, and they aren't in nearly enough widespread use to be helpful. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From ms-nospam-0306 at arcor.de Fri Nov 7 19:05:52 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 7 Nov 2003 20:05:52 +0100 Subject: esound.spec has a description thats\' out-of-date In-Reply-To: <20031107180000.97063.qmail@mail.goo.ne.jp> References: <20031107180000.97063.qmail@mail.goo.ne.jp> Message-ID: <20031107200552.284f2e24.ms-nospam-0306@arcor.de> On 8 Nov 2003 03:00:00 +0900, jigorou3 at mail.goo.ne.jp wrote: > In esound.spec, line 2, the description > > %define __os_install_post /usr/lib/rpm/redhat/brp-compress > > should be > > %define __os_install_post /usr/lib/rpm/brp-compress > > isn't it? > > Recent version of Red Hat Linux (and Fedora Core) doesn't have > /usr/lib/rpm/redhat > , and esound's build fails in default setting. Not true. $ rpm --redhatprovides /usr/lib/rpm/redhat/brp-compress redhat-rpm-config-8.0.28-1.1 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pgampe at redhat.com Fri Nov 7 05:33:46 2003 From: pgampe at redhat.com (Paul Gampe) Date: Fri, 7 Nov 2003 15:33:46 +1000 Subject: i18n issues, was: FC2 release In-Reply-To: <200311070049.hA70nRt20880@devserv.devel.redhat.com> References: <200311070049.hA70nRt20880@devserv.devel.redhat.com> Message-ID: <200311071533.46328.pgampe@redhat.com> On Fri, 7 Nov 2003 10:49 am, Alan Cox wrote: > Does that mean that by mid December we can be thinking about getting the > lost translations (for non install stuff) rolling out as or with errata, > since Fedora doesn't have the errata restrictions RHEL does ? I may not be interpreting the question correctly Alan sorry, so do you mean translations that have been committed for redhat-config-* but not picked up in the rpm for the application? I think Pedro's suggestion of specifying a date for package maintainers to update their package is a reasonable solution, but I too have concerns about the workload this would generate. Using cvs watch on the po/* files has been an effective way for me to track as translations get updated, so that is one way to know whether a rebuild is required. Paul From ajn at ite.gmu.edu Fri Nov 7 19:22:12 2003 From: ajn at ite.gmu.edu (Alastair Neil) Date: Fri, 07 Nov 2003 14:22:12 -0500 Subject: Intro, and userhelper question Message-ID: <1068232932.13028.1323.camel@island> Hello I am Alastair Neil, a lapsed physicist and currently unix admin for IT&E labs at George Mason University. I've been using linux since late '93, slackware and then redhat since 96 or so. An issue we have with some of our redhat systems is co-management where I retain root access but create an account with admin privileges. All easy enough to do with sudo. However, the desire for access to the gui tools, again relatively easy enough to change the authorised account for the tools in /etc/security/console.apps, the problem is that now I have to remember the ladmin account password to access the apps. I would rather be able to always be granted access with the root password. It seems there are two ways to approach this, allow userhelper to have a list of authorised users, possibly selected from a dropdown list in consolehelper or modify pam to check the root password if the user password does not match. I modified pam in RH8 to do this because I liked the ability to unlock screensavers with the root passwd ala HPUX, but I noted that xscreensaver in Ximian allows this and as far as I can see it is not a pam level change. Does anyone think these modifications are a good idea and if so what is the preference? Or perhaps in my ignorance I am reinventing the wheel? -- Dr. Alastair Neil Unix Systems Administrator IT&E Labs George Mason University (703) 993-3953 From Nicolas.Mailhot at laPoste.net Fri Nov 7 18:59:24 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 07 Nov 2003 19:59:24 +0100 Subject: fedora-legacy agrees to enforce rpm upgrades? (was: Warren's Package Naming Proposal - Revision 1) In-Reply-To: <200311070859.55886.jkeating@j2solutions.net> References: <3FA229D3.4000104@togami.com> <1068204440.12684.29.camel@laptop> <20031107164717.GD27327@puariko.nirvana> <200311070859.55886.jkeating@j2solutions.net> Message-ID: <1068231564.3252.1.camel@m70.net81-64-235.noos.fr> Le ven 07/11/2003 ? 17:59, Jesse Keating a ?crit : > On Friday 07 November 2003 08:47, Axel Thimm wrote: > > While I personally support this scheme, I was under the impression > > that there were more people against enforcing rpm upgrades for > > minimally changes (e.g. fedora-legacy should only provide security > > related errata). Especially because RH itself did not issue errata > > for rpm despite the known problems. > > > > In fact, Warren, I believe we were the only two supporting rpm > > upgrades, so unless we are the only left subscribers of > > fedora-legacy, it is not yet an agreement of the whole list. ;) > > I personally agreed to it, until somebody showed me clear evidence that > it could/would break something. I supported it too I wasn't the only one. Is this "me too thread" really useful ? Did anyone propose an alternative scheme that had any chance to work ? 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 mharris at redhat.com Fri Nov 7 20:04:25 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 7 Nov 2003 15:04:25 -0500 (EST) Subject: Packages licenses In-Reply-To: References: Message-ID: On Fri, 7 Nov 2003, Elliot Lee wrote: >> I have extracted the 'License' tag of all RH9 packages, sorry FC1 is not >> here yet. And I see a chaotic style, duplicates... A clearer policy and >> style should be used in Fedora. >> >> idea? Maybe, rpmbuild should check 'License' against a list of OSI >> compatible licenses, otherwise a -nocl (--noOSIcompatiblelicense) flag >> should be used to build it. > >Having a flag like that is not likely, because some of the licenses may be >fine but not formally OSI-approved, and because the system used to build >the packages doesn't allow passing options such as -nocl. > >You're right that there are many duplicates that could use fixing. Once it >is decided which license strings need to change, you can file patches in >bugzilla for all the ones that obviously need changing (e.g. s/Freely >distributable/Freely redistributable/i). I completely agree, however before people submit patches, or suggest changes, I think we really do need to make an official rubber stamped list of specific license names. The list should NOT be considered a complete list of all licenses, but rather, it should be considered the official way to word the licenses that are contained in the list. For example, the GPL license should be stated consistently as either "GPL" everywhere, or as "GNU GPL" or whatever is decided. 2 more would probably be "BSD" and "BSD with advertising clause", "MIT", etc... In other words for each license which is rather well known or at least common, we should standardize the names, and put them on an official list of proper spelling for those licenses up on the Fedora site. While this may be considered a very negligible and trivial thing to many people, and it more or less is really, if we want to clean something like this up, then it needs to be standardized and have an official stamp of approval put on it by being on the Fedora website, so that people can be pointed to it. That also avoids different people from doing it their own way just to be different, using the argument "there is no standard, who cares". -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Fri Nov 7 20:06:19 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 7 Nov 2003 15:06:19 -0500 (EST) Subject: fedora-legacy agrees to enforce rpm upgrades? (was: Warren's Package Naming Proposal - Revision 1) In-Reply-To: <20031107164717.GD27327@puariko.nirvana> References: <3FA229D3.4000104@togami.com> <3FA2722D.6090504@togami.com> <20031031180006.1b3cad50.ms-nospam-0306@arcor.de> <1067622953.20763.164.camel@bobcat.mine.nu> <1068204440.12684.29.camel@laptop> <20031107164717.GD27327@puariko.nirvana> Message-ID: On Fri, 7 Nov 2003, Axel Thimm wrote: >> This however does not matter, since it has been agreed upon on >> fedora-legacy list that ALL distributions supported by Fedora Legacy >> will force an upgrade of rpm as a requirement for users to begin using >> those repositories. > >When was this agreed upon? > >While I personally support this scheme, I was under the impression >that there were more people against enforcing rpm upgrades for >minimally changes (e.g. fedora-legacy should only provide security >related errata). Especially because RH itself did not issue errata for >rpm despite the known problems. > >In fact, Warren, I believe we were the only two supporting rpm >upgrades, so unless we are the only left subscribers of fedora-legacy, >it is not yet an agreement of the whole list. ;) Make it 3 then... I support Warren's suggestion. Perhaps others will speak up too if it is something up for democratic vote. If it's not up for democratic vote, hail Warren! -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Fri Nov 7 20:07:30 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 7 Nov 2003 15:07:30 -0500 (EST) Subject: Packages licenses In-Reply-To: <3FABCD45.5040803@wanadoo.es> References: <3FABCD45.5040803@wanadoo.es> Message-ID: On Fri, 7 Nov 2003, Xose Vazquez Perez wrote: >> Having a flag like that is not likely, because some of the licenses may be >> fine but not formally OSI-approved, and because the system used to build >> the packages doesn't allow passing options such as -nocl. >> >> You're right that there are many duplicates that could use fixing. Once it >> is decided which license strings need to change, you can file patches in >> bugzilla for all the ones that obviously need changing (e.g. s/Freely >> distributable/Freely redistributable/i). > >the worse is that there are packages with *wrong* 'License' tag: ex. db4 > >querida:~ $ rpm -q --qf '%{name}\t%{license}\n' db4 >db4 GPL > >/usr/share/doc/db4-4.0.14/LICENSE shows that it's BSD-alike > >_All package maintainers_ *should check* 'License' tag!! I agree completely, however mistakes happen, and it's something that can't be avoided. It's a bug just like any other bug, so file a bug report. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Fri Nov 7 20:12:18 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 7 Nov 2003 15:12:18 -0500 (EST) Subject: Packages licenses In-Reply-To: <1068225417.13389.33.camel@poincare.devel.redhat.com> References: <3FABCD45.5040803@wanadoo.es> <1068225417.13389.33.camel@poincare.devel.redhat.com> Message-ID: On Fri, 7 Nov 2003, Owen Taylor wrote: >> > You're right that there are many duplicates that could use fixing. Once it >> > is decided which license strings need to change, you can file patches in >> > bugzilla for all the ones that obviously need changing (e.g. s/Freely >> > distributable/Freely redistributable/i). >> >> the worse is that there are packages with *wrong* 'License' tag: ex. db4 >> >> querida:~ $ rpm -q --qf '%{name}\t%{license}\n' db4 >> db4 GPL >> >> /usr/share/doc/db4-4.0.14/LICENSE shows that it's BSD-alike >> >> _All package maintainers_ *should check* 'License' tag!! > >Read that carefully. It's very much not BSD-like. It's not the GPL >either, however, though it could roughly be described as GPL-like >in general intent. Personally I wouldn't call a license GPL-like in an official sense. It opens the door for people to be mislead that a license is GPL compatible when it might not be. If a license does not have a specific name given to it, then I make one up based on the package name. So for this case, if the LICENSE file doesn't say "foo LICENSE", I would say this package's license is: License: db4 license That tells people clearly this is a special license that is different from other licenses, and they need to read the license for themselves in order to know what the terms are. It makes it less likely people will make false legal assumptions and misuse the code against the author's wishes. Of course, the rpm license header is just a summary line, and isn't authoritative, so people should always check the author's own written license text, however I think the rpm license tag should convey the license type as close as possible in as few words as possible, or else give vague term like "db4 license" which inspires the reader to find the license inside the package and read it to determine what "db4 license" really means. HTH -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From alan at redhat.com Fri Nov 7 20:16:54 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Nov 2003 15:16:54 -0500 (EST) Subject: Hardware Database In-Reply-To: <20031107133425.A13384@devserv.devel.redhat.com> from "Michael K. Johnson" at Tach 07, 2003 01:34:25 Message-ID: <200311072016.hA7KGsN06541@devserv.devel.redhat.com> > I don't know if there's a version of dmidecode that prints xml, but I > can't imagine that it would be remotely difficult to add, nor that it > would make the source code less clean. The newest version does yes From alan at redhat.com Fri Nov 7 20:20:00 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Nov 2003 15:20:00 -0500 (EST) Subject: RPM submission script In-Reply-To: <20031107181926.GA15796@thyrsus.com> from "Eric S. Raymond" at Tach 07, 2003 01:19:26 Message-ID: <200311072020.hA7KK0g09484@devserv.devel.redhat.com> > > rfc822 == email. > > Yeah, what he said. Headers are various metadata, the body is the > description. Here's what the last version of my test load looked like: RFC822 is problematic because \n and ":" can occur as part of multibyte symbols so dumb tools make dumb errors. It works for email only because SMTP uses some brain damaged "so dont do that" rules. From tcallawa at redhat.com Fri Nov 7 20:33:49 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 07 Nov 2003 14:33:49 -0600 Subject: esound.spec has a description thats\' out-of-date In-Reply-To: References: Message-ID: <1068237229.3752.5.camel@localhost.localdomain> On Fri, 2003-11-07 at 12:23, Elliot Lee wrote: > On 8 Nov 2003 jigorou3 at mail.goo.ne.jp wrote: > > > Recent version of Red Hat Linux (and Fedora Core) doesn't have > > /usr/lib/rpm/redhat > > , and esound's build fails in default setting. > > Make sure to install the redhat-rpm-config package. > > It does sound like esound.spec needs fixing, though. Please file a bug! I filed this one back in October: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107781 Aurora tripped over this, because it doesn't have /usr/lib/rpm/redhat. ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora SPARC Linux Project Leader "The author's mathematical treatment of the conception of purpose is novel and highly ingenious, but heretical and, so far as the present social order is concerned, dangerous and potentially subversive. Not to be published." -- Aldous Huxley From johnsonm at redhat.com Fri Nov 7 20:38:44 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 7 Nov 2003 15:38:44 -0500 Subject: FC2 release dates In-Reply-To: <1068167013.10735.19.camel@binkley>; from skvidal@phy.duke.edu on Thu, Nov 06, 2003 at 08:03:33PM -0500 References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> <1068167013.10735.19.camel@binkley> Message-ID: <20031107153844.C13384@devserv.devel.redhat.com> On Thu, Nov 06, 2003 at 08:03:33PM -0500, seth vidal wrote: > Worth asking: What group makes this final decision? As technical leader, it's my job to fix the fact that our leadership page on the fedora.redhat.com site is still a draft. That's something I'll be working on next week (doesn't mean I'll finish next week, but it's going to be one of the few items at the top of my list, so I'll probably get behind on email and be high-latency on IRC) and then we will have the group that can make the call. Roughly, we'll have a committee who is responsible for listening to all the arguments and making a decision. It will have folks from Red Hat and others on it. Red Hat's needs and community needs will both be part of the decision-making process. I should mention here my concept of Fedora leadership. I don't believe that leadership by appointment works very well, at least in this context. My intention for Fedora leadership is that we'll be *recognizing* people who are already acting as the leaders in the community. Not necessarily the people who have the most to say all the time () but the ones who lead by action, and whose goals as expressed in their actions are aligned with our goals, the statement of which is available at http://fedora.redhat.com/about/objectives.html and which we expect to refine over time. I want to be clear that Red Hat will be bringing some clear objectives to the table for this discussion. I'll say right away that a 2.6 kernel as soon as possible has at least three reasons that we care about: o We have a LOT of end users urgently requesting it. o Linus has asked us to do a 2.6-kernel-default distribution absolutely ASAP, and his request carries significant weight. o Red Hat has an interest in doing a distribution with a 2.6 kernel from the standpoint of our work on our Enterprise products. HTH, michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From esr at thyrsus.com Fri Nov 7 20:39:37 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 15:39:37 -0500 Subject: RPM submission script In-Reply-To: <200311072020.hA7KK0g09484@devserv.devel.redhat.com> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> Message-ID: <20031107203937.GC16285@thyrsus.com> Alan Cox : > RFC822 is problematic because \n and ":" can occur as part of multibyte > symbols so dumb tools make dumb errors. It works for email only because > SMTP uses some brain damaged "so dont do that" rules. Not a problem. I'll just specify that the input is expected to be UTF-8 and screw all that multibyte crap. World's going that direction anyway. -- Eric S. Raymond From ville.skytta at iki.fi Fri Nov 7 21:17:13 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 07 Nov 2003 23:17:13 +0200 Subject: fedora-legacy agrees to enforce rpm upgrades? (was: Warren's Package Naming Proposal - Revision 1) In-Reply-To: <1068231564.3252.1.camel@m70.net81-64-235.noos.fr> References: <3FA229D3.4000104@togami.com> <1068204440.12684.29.camel@laptop> <20031107164717.GD27327@puariko.nirvana> <200311070859.55886.jkeating@j2solutions.net> <1068231564.3252.1.camel@m70.net81-64-235.noos.fr> Message-ID: <1068239833.14859.296.camel@bobcat.mine.nu> On Fri, 2003-11-07 at 20:59, Nicolas Mailhot wrote: > Le ven 07/11/2003 ? 17:59, Jesse Keating a ?crit : > > On Friday 07 November 2003 08:47, Axel Thimm wrote: > > > While I personally support this scheme, I was under the impression > > > that there were more people against enforcing rpm upgrades for > > > minimally changes (e.g. fedora-legacy should only provide security > > > related errata). Especially because RH itself did not issue errata > > > for rpm despite the known problems. > > > > > > In fact, Warren, I believe we were the only two supporting rpm > > > upgrades, so unless we are the only left subscribers of > > > fedora-legacy, it is not yet an agreement of the whole list. ;) > > > > I personally agreed to it, until somebody showed me clear evidence that > > it could/would break something. > > I supported it too I wasn't the only one. > Is this "me too thread" really useful ? Did anyone propose an > alternative scheme that had any chance to work ? More importantly (IMHO, YMMV): what does that imply, if anything, related to the naming guidelines? There was some support for moving/keeping non-numeric upstream post-release version parts in %{version} instead of moving them into %{release}, what is the consensus on that now? From jm at jmason.org Fri Nov 7 21:05:33 2003 From: jm at jmason.org (Justin Mason) Date: Fri, 07 Nov 2003 13:05:33 -0800 Subject: RPM submission script In-Reply-To: <20031107203937.GC16285@thyrsus.com> Message-ID: <20031107210539.05BD516FC3@jmason.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric S. Raymond writes: >Alan Cox : >> RFC822 is problematic because \n and ":" can occur as part of multibyte >> symbols so dumb tools make dumb errors. It works for email only because >> SMTP uses some brain damaged "so dont do that" rules. > >Not a problem. I'll just specify that the input is expected to be UTF-8 and >screw all that multibyte crap. World's going that direction anyway. er, UTF-8 *is* multibyte ;) However, using UTF-8 should be OK, alright, since UTF-8 multibyte sequences must contain bit 7 set in all chars, so "\n" and ":" will not show up as bytes. viz: http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8 notes 'no ASCII byte (0x00-0x7F) can appear as part of any other character.' - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Exmh CVS iD8DBQE/rAkdQTcbUG5Y7woRAvwmAKC1ELoZO3WPPcAUY7mxaNHsDpzcLACePd/I Zx6Ouq6469oRQUzk7XQD1gw= =5ncM -----END PGP SIGNATURE----- From lowen at pari.edu Fri Nov 7 21:07:44 2003 From: lowen at pari.edu (Lamar Owen) Date: Fri, 7 Nov 2003 16:07:44 -0500 Subject: fedora-legacy agrees to enforce rpm upgrades? (was: Warren's Package Naming Proposal - Revision 1) In-Reply-To: References: <3FA229D3.4000104@togami.com> <20031107164717.GD27327@puariko.nirvana> Message-ID: <200311071607.44249.lowen@pari.edu> On Friday 07 November 2003 03:06 pm, Mike A. Harris wrote: > Make it 3 then... I support Warren's suggestion. Perhaps others > will speak up too if it is something up for democratic vote. If > it's not up for democratic vote, hail Warren! 4. I mentioned the fact that Red Hat had already set the precedent back with some errata packages for RPM with RHL 6.2, 7, and others. By way of introduction, since everyone else is doing them, my qualifications, etc, are as follows... I have maintained the PostgreSQL RPMset since July of 1999, and had my RPM work includedby Red Hat as part of RHL 6.1. I have built various other RPMs for my use, and have provided a few for other projects over the years, including the BibleTime SWORD project KDE reader. I have actively used and developed on Red Hat Linux since version 4.1 in April 1997. I am one of the few enterprise users of the Aurora Linux distribution on a network of UltraSPARCs at PARI. I have operated an internet radio site (on Red Hat Linux and RealAudio) since May 1997. I have recovered from a root compromise. I currently maintain the AOLserver PostgreSQL driver. And I of course try to show the benefits of Linux and open source at every opportunity to every one. A couple of things about me that are rather unusual among open source people is that I am a duly ordained Baptist minister and am a professor at Anchor Baptist Bible College, teaching English amongst other courses. -- (Rev.) Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From skvidal at phy.duke.edu Fri Nov 7 21:19:42 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 07 Nov 2003 16:19:42 -0500 Subject: RPM submission script In-Reply-To: <20031107203937.GC16285@thyrsus.com> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> Message-ID: <1068239981.6576.0.camel@opus> On Fri, 2003-11-07 at 15:39, Eric S. Raymond wrote: > Alan Cox : > > RFC822 is problematic because \n and ":" can occur as part of multibyte > > symbols so dumb tools make dumb errors. It works for email only because > > SMTP uses some brain damaged "so dont do that" rules. > > Not a problem. I'll just specify that the input is expected to be UTF-8 and > screw all that multibyte crap. World's going that direction anyway. ugh - a lot of data in rpms is not utf-8 happy. Often in latin-1 or beyond that in the encoding. You might find that mandating UTF-8 is harder than you think. -sv From esr at thyrsus.com Fri Nov 7 21:27:14 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 16:27:14 -0500 Subject: RPM submission script In-Reply-To: <20031107210539.05BD516FC3@jmason.org> References: <20031107203937.GC16285@thyrsus.com> <20031107210539.05BD516FC3@jmason.org> Message-ID: <20031107212714.GA16837@thyrsus.com> Justin Mason : > er, UTF-8 *is* multibyte ;) Well, technically, yes...but not the way people usually mean it (16-bit chars like Java). > However, using UTF-8 should be OK, alright, since UTF-8 multibyte > sequences must contain bit 7 set in all chars, so "\n" and ":" will not > show up as bytes. viz: http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8 > notes 'no ASCII byte (0x00-0x7F) can appear as part of any other > character.' Exactly. -- Eric S. Raymond From warren at togami.com Fri Nov 7 20:20:28 2003 From: warren at togami.com (Warren Togami) Date: Fri, 07 Nov 2003 10:20:28 -1000 Subject: Warren's Package Naming Proposal - Revision 2 Message-ID: <1068236427.12684.60.camel@laptop> http://www.fedora.us/wiki/PackageNamingGuidelines The following is based upon current fedora.us package naming guidelines, edited and dramatically simplified because fedora.redhat.com no longer needs many of fedora.us special considerations. http://www.redhat.com/archives/fedora-devel-list/2003-October/msg01152.html This is Revision 1 from October 31st, 2003 The below proposal is ALMOST EXACTLY THE SAME as fedora.us current scheme except with the leading "0.fdr." removed from all %{release} tags and %{reptag} added to the end. I would assert that fedora.us package naming scheme has demonstrated to be a great success, thus it should continued in fedora.redhat.com. The below scheme is also in-line with the common practices used by most of Red Hat's existing packages. Dispersed within the below draft are "XXX" sections where discussions are still necessary. The revision history of section iii otherwise notes sections that have been changed since Revision 1. Section C-7 at the bottom is the most important part in this revision. **Fedora Package Naming Guidelines Warren's Proposal for fedora.redhat.com Revision 2 ================================ i. Introduction Goals for package naming guidelines ii. Terminology iii. Revision History A. Package Name B. Version C. Release Tag 1. Release Prefix 2. Vepoch 3. Non-Numeric Version to Release 4. Dist tag 5. Special: Kernel modules 6. Special: Plugin, theme etc packages 7. Special: Repository Tag i. Introduction =============== Goals for the Fedora Package Naming Guidelines * Easily understandable package naming policy * Indication of the original source version (end-user convenience) * Allow for a smooth upgrade path between multiple levels of testing branches and future distribution upgrades. This means E-V-R must never be exactly identical between distribution versions. * Minimize the chance of package conflicts for future Fedora distribution upgrades. ii. Terminology ============== name This is the "Name" field of RPM .spec files. version This is the "Version" field of RPM .spec files. release tag This is the "Release" field of RPM .spec files. dist tag This is a distribution tag indicating which RHL/FC distribution this package is intended for. This only occurs in cases where packages from different distributions are built from the same SRPM and patchlevel. vepoch This is our term for "version specific epoch", used in all packages as a simple means of ensuring upgrades by simple incrementing the leading number within the release tag. vepoch is otherwise known as "release number" or "patchlevel". Read C-2 for more information. XXX: For now I am keeping the term vepoch in this draft because a better alternative has not been proposed. I personally feel that "release number" most effectively communicates what this number is about, however "release number" is confusingly similar to "release tag" no? "release tag" == %{release} Please discuss this... we need only choose a name to replace vepoch. XXX E-V-R Abbreviation for epoch, version, and release. This is often referred to when talking about potential package upgrading problems. iii. Revision History ===================== 07 October 2003 Draft Revision 2 * C-7 minor number is now %{reptag} for marking repositories and 3rd party repositories. * Many XXX sections needing discussion before changes in Draft Revision 3. 31 October 2003 Draft Revision 1. * Initial post for fedora.redhat.com. A. Package Name =============== Package name should preferably match the upstream tarball or project name from which this software came. In some cases this naming choice is more complicated. If this package has been packaged by other distributions/packagers (Mandrake, SuSE, Conectiva, PLD, PLF, FreshRPMS, etc.) in the past, then we should try to match their name for consistency. In any case, try to use your best judgment, and other developers will help in the final decision. Ultimately it is up to QA to decide upon the proper %{name} before publication. B. Version ========== If the version is only numbers, then these numbers can be put into the "version" field of the RPM .spec unchanged. If the version contains non-numeric characters, this creates several problems for RPM version comparison and a broken upgrade path. Example: foobar-1.2.3beta1.tar.gz foobar-1.2.3.tar.gz While the "1.2.3" version is newer than the 1.2.3beta1 version, RPM version comparison thinks the former is newer. Example: foobar-1.0a foobar-1.0b The "1.0b" version is higher than "1.0a", but all versions of RPM prior to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever package is first in the comparison "wins", thus this becomes a two way upgrade problem. This a < b comparison works properly only in RH9 and higher. For simplicity, Fedora treats both pre-release and post-release non-numeric version cases the same, making the version purely numeric and moving the alphabetic part to the release tag. Take the numeric portion of the source version and make that the package version tag. Read C-3 for more details. XXX: Read section C-3 for the very important discussion necessary for removing the post-release requirement in non-numeric %{version} tags. XXXX C. Release Tag ============== The release tag of Fedora packages more complicated, so this is split into several parts. C-1. Release Prefix ------------------- No longer needed in fedora.redhat.com. C-2. Vepoch ----------- The leftmost leading number within the release tag is the "version specific epoch" or vepoch in Fedora. This number is incremented with every package update. The vepoch is otherwise known as the "release number" or "patchlevel". The key difference between the concept of "vepoch" and "patch level" is that everything to the right of the vepoch is PURELY INFORMATIONAL. The only time where it matters is to guarantee a different %{release} tag between two distribution versions. The vepoch is to be respected by Fedora Core/Extras/Alternatives/Legacy as canonical. Package updates in any repository should always check all other official repositories to be sure that the vepoch is always incremented and never matching an existing package. With most normal packages, vepoch is a single number starting at "1". Under the (C-3) non-numeric version case it is two numbers starting at "0.1" with the second number being the number to increment. Normal Package Example: foobar-1.2.3-1.src.rpm compiles to foobar-1.2.3-1.i386.rpm If this package is patched: foobar-1.2.3-2.i386.rpm foobar-1.2.3-3.i386.rpm XXX: Read section ii. near the top regarding the discussion necessary in renaming of vepoch within the naming guidelines. XXX C-3. Non-Numeric Version to Release ----------------------------------- As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric versioned packages can be problematic so they must be treated with care. These are cases where the upstream version has letters rather than simple numbers in their version. Often they have tags like alpha, beta, rc, or letters like a and b denoting that it is a version before or after the number. Read section B to understand why we cannot simply put these letters into the version tag. Release Tag for Pre-Release Packages: 0.%{X}.%{alphatag} Release Tag for Non-Numeric Post-Release Packages: %{X}.%{alphatag} Where %{X} is the vepoch increment, and %{alphatag} is the string that came from the version. Example (pre-release): mozilla-1.4a.tar.gz from upstream is lower than mozilla-1.4.tar.gz the later "final" version thus mozilla-1.4-0.1.a Fedora package name Example (pre-release): alsa-lib-0.9.2beta1.tar.gz becomes alsa-lib-0.9.2-0.1.beta1 Example (post-release): gkrellm-2.1.7.tar.gz gkrellm-2.1.7a.tar.gz Quick bugfix release after 2.1.7 gkrellm-2.1.7-1.a Upgrade Path Example (mozilla): mozilla-1.4-0.1.a Patched mozilla-1.4-0.2.a Patched again mozilla-1.4-0.3.a Move to 1.4b mozilla-1.4-0.4.b Patched mozilla-1.4-0.5.b Move to 1.4 "final" version Notice that this becomes a normal C-2 case mozilla-1.4-1 Patched mozilla-1.4-2 Upgrade Path Example (alsa-lib): alsa-lib-0.9.2-0.1.beta1 Patched alsa-lib-0.9.2-0.2.beta1 Move to beta2 alsa-lib-0.9.2-0.3.beta2 Move to beta3 and simultaneously patch alsa-lib-0.9.2-0.4.beta3 Patched again alsa-lib-0.9.2-0.5.beta3 Move to rc1 alsa-lib-0.9.2-0.6.rc1 Move to rc2 alsa-lib-0.9.2-0.7.rc2 Move to "final" alsa-lib-0.9.2-1 Patched alsa-lib-0.9.2-2 XXX: Please discuss this: We should change the post-release case to no longer be effected by the non-numeric %{version} rule since rpm-4.2 in RH9 and higher are not effected by this problem. Furthermore (and by accident) rpm python bindings since rpm-4.1 of RH8 have behaved in a proper fashion while rpm itself did not, and apt-get has always behaved "properly" when comparing numbers to letters, or letters to letters. In any case Fedora Legacy has already agreed that upgrading rpm to the latest version must be done as the first requirement for all users who will be using Fedora Legacy. For these reasons we probably *can* allow non-numeric characters into the version only in certain cases where it is ABSOLUTELY CERTAIN it will not lead to an epoch increment in the future. Mike Harris brought up the example of the "imap" package with its strange versioning. In some cases like that, we may need to grandfather some packages in. This point needs a LOT more analysis before being ratified, so please discuss this. Do not contribute to this part of the thread unless you truly know what you are talking about. No speculation please. XXX C-4. Dist tag ------------- In cases where the same SRPM and patchlevel is used between two or more distributions supported by Fedora, a dist tag is appended to the end of the release tag defined in C-2 and C-3. The dist tags with the following examples appear to be only cosmetic, however the a different E-V-R is needed between distributions to ensure dist upgrading works fully in all corner cases. Dist Tag for Normal Packages: %{X}.%{disttag} Where %{X} is the vepoch and %{disttag} is a distribution tag from this table: 0.7.3 Red Hat Linux 7.3 0.8 Red Hat Linux 8 0.9 Red Hat Linux 9 1 Fedora Core 1 1.93 Fedora Core 1.93 beta 1.94 Fedora Core 1.94 beta 2 Fedora Core 2 beta Example: foobar-1.2.3-1.0.7.3.i386.rpm foobar-1.2.3-1.0.8.i386.rpm foobar-1.2.3-1.0.9.i386.rpm foobar-1.2.3-1.1.94.i386.rpm foobar-1.2.3-1.2.i386.rpm Upgrade Path Example (FC1 only shown): foobar-1.2.3-1.1.i386.rpm foobar-1.2.3-2.1.i386.rpm foobar-1.2.3-3.1.i386.rpm Dist Tag for Pre-Release Packages: %{X}.%{alphatag}.%{disttag} Where %{X} is the vepoch, %{alphatag} is the pre-release tag described in C-3, %{disttag} is a distribution tag described above. Example: alsa-lib-0.9.2-0.1.beta1.0.8.i386.rpm alsa-lib for RH 8.0 alsa-lib-0.9.2-0.1.beta1.1.i386.rpm alsa-lib for FC1 Upgrade Path Example (RH 7.3 only shown): alsa-lib-0.9.2-0.1.beta1.0.7.3 alsa-lib-0.9.2-0.2.beta1.0.7.3 alsa-lib-0.9.2-0.3.beta2.0.7.3 alsa-lib-0.9.2-0.4.beta3.0.7.3 alsa-lib-0.9.2-0.5.beta3.0.7.3 alsa-lib-0.9.2-0.6.rc1.0.7.3 alsa-lib-0.9.2-0.7.rc2.0.7.3 alsa-lib-0.9.2-1.0.7.3 alsa-lib-0.9.2-2.0.7.3 XXX: I replaced all of the underscores with periods due to the "ugly" reactions from the last draft. Yeah, there isn't a lot of logic behind "ugly" and having a different delimiter might make it easier to read, but I would suggest sticking with the period for these reasons: 1) Everyone thinks the underscores were ugly. 2) disttag is always at the end, so there is no confusion. 3) except... when it is a 3rd party repository where the reptag is at the end. But that isn't so confusing. Discuss this if you want, but be prepared for more whining about "ugly!" XXX C-5. Special Case: Kernel modules --------------------------------- XXX: This section still needs much discussion. Later. XXX C-6. Plugin, theme etc packages ------------------------------- Packages that are plugins, themes or the like, ie. enhance other packages must be named -. If the resulting name differs significantly from upstream naming, a Provides: = %{epoch}:%{version}-%{release} must be added. For example: Upstream package name: modplug-xmms Fedora package name: xmms-modplug Provides: modplug-xmms = %{epoch}:%{version}-%{release} XXX: Should we actively discourage packages that *appear* to be plugin, add-on or theme packages but are actually completely independent? One example that has caught me off guard lately was Dag's mozilla-firebird package. While Dag published mozilla-firebird, fedora.us decided against a name change from MozillaFirebird to mozilla-firebird for these reasons: 1) No reason to change. 2) Mozilla branding strategy document said the name was changing "soon" anyway, (which still hasn't happened.) 3) mozilla-firebird is within the long implicitly understood and fedora.us codified standard of being a component or add-on to "mozilla", which is clearly wrong in this case. #2 and #3 were the strongest arguments in my opinion. I can't think of any other past examples off the top of my head, but I really want to avoid these kinds of instances in the future if possible. Please express your opinions. XXX C-7. Repository Tag ------------------- Repository tags are appended to the end of %{release} tags for any packages not within Fedora Core or Fedora Extras. FC and FE are excluded because Fedora Core should never contain the same %{name} package as Fedora Extras, and vice-versa. All external and 3rd party repositories NEED repository tags. Fedora Alternatives and Fedora Legacy are to use rep tags. Repository Tag for Normal Packages: %{X}.%{disttag}.%{reptag} Where %{X} is the vepoch and %{disttag} is a distribution tag defined in C-4, and reptag is an alphanumeric string standardized and unique for a repository. XXX: The below examples are using theoretical reptags. XXX Fedora Legacy: apache for RH7.3 apache-1.3.27-4.0.7.3.legacy Fedora Alternatives: Beowulf for FC2 kernel-2.6.2-3.2.beowulf beowulf-pxe-images-2.3-2.2.beowulf cluster-foo-libs-1.7-2.2.beowulf cluster-foo-tools-1.7-2.2.beowulf cluster-foo-devel-1.7-2.2.beowulf freshrpms: 3rd party packages for FC1 diradmin-1.5.1-2.1.fr AtRPMS: 3rd party packages for FC1 perl-HTML-Tree-3.18-4.1.at DAG: 3rd party packages for FC1 distcc-2.11.1-1.1.dag Livna: 3rd party packages for FC1 foogame-3.3-3.beta3.1.lvn fooutil-2.1-4.1.lvn fooapplet-1.0-9.rc4.1.lvn kde-redhat: 3rd party Uncrippled KDE packages for FC1 kdebase-3.1.4-7.1.kderedhat Note that it is the 3rd party or Alternatives choice of what %{X} number to use. If they use the same %{X} number as the canonical FC/FE packages they are superceding, then any future upgrade upstream is guaranteed to superceed the 3rd party or Alternatives package. This can be desired or not. XXX: The 3 points below need to be worked into the document above somewhere... too tired to do that at the moment... discuss for now. Caveats! 1) Fedora Core and Fedora Extras are to be considered canonical. All other repositories must respect the vepoch of the canonical repositories, however FC and FE may choose to ignore 3rd parties when incrementing the vepoch for a new package release. 1a) Since fedora.us will eventually become a major source of Fedora Extras, fedora.us is to be considered canonical. fedora.us will no longer exist as a project after the full merge with fedora.redhat.com. 2) In the kde-redhat example, since they are a 3rd party and not canonical, it is possible that a future FC or FE upgrade will supercede the kde-redhat package. For this reason it is important for kde-redhat developers to BE INVOLVED in FC development so they are not caught off guard. It is the 3rd party's responsibility to simultaneously release updates to the 3rd party repository in order to avoid breakage or losing features when the crippled packages overrides the kde-redhat package. 3) These guidelines of canonism may seem onerous, however this encourages all 3rd party developers to contribute their packages to FC and FE whenever possible in order to make the central authoritative body strong. I would assert that the alliances of 3rd party repositories that have tried to form in the recent past are not sustainable in the long term, for the same controversial reasons that fedora.us rejected cooperation with those entities earlier this year. More cooperation is needed to build an entity and software base like Debian, what we want to become. (?) XXX From warren at togami.com Fri Nov 7 20:21:02 2003 From: warren at togami.com (Warren Togami) Date: Fri, 07 Nov 2003 10:21:02 -1000 Subject: ftwall build broke FC1 tcp.h (glibc-kernheaders) Message-ID: <1068194839.30673.10.camel@laptop> Hi, I could really use assistance with the ftwall package. It fails build on FC1 due to glibc-kernheaders tcp.h while it builds successfully on RH9. Any suggestions for this problem? Thanks, Warren Togami warren at togami.com http://bugzilla.fedora.us/show_bug.cgi?id=941 http://videl.ics.hawaii.edu/~warren/fedora/ftwall-1.07-1.src.rpm http://videl.ics.hawaii.edu/~warren/fedora/md5sums.asc ftwall is a program for linux firewalls that allows the control of network traffic from "Fast Track" peer-to-peer clients like "Kazaa" and it's derivatives. It is designed to block network traffic from Fast track client applications running in the "home" (or "green") network from making access to any peers on the public internet. It is ideal for use in networks where the security paradigm is "open access" for outbound connections and "tightly limited" access for inbound ones. Ftwall can be used in such a network to prevent outbound Fast Track access, hence preventing illegal file downloads and uploads. Known Problems: * Makefile doesn't use proper CFLAGS. Suggestions please. * Due to the below change in glibc-kerneheaders /usr/include/linux/tcp.h in FC1, compiler fails with this message: In file included from /usr/include/linux/tcp.h:21, from ftwall.c:51: /usr/include/asm/byteorder.h:6:2: warning: #warning using private kernel header; include instead! In file included from ftwall.c:51: /usr/include/linux/tcp.h:105: error: enumerator value for `TCP_FLAG_CWR' not integer constant /usr/include/linux/tcp.h:106: error: enumerator value for `TCP_FLAG_ECE' not integer constant /usr/include/linux/tcp.h:107: error: enumerator value for `TCP_FLAG_URG' not integer constant /usr/include/linux/tcp.h:108: error: enumerator value for `TCP_FLAG_ACK' not integer constant /usr/include/linux/tcp.h:109: error: enumerator value for `TCP_FLAG_PSH' not integer constant /usr/include/linux/tcp.h:110: error: enumerator value for `TCP_FLAG_RST' not integer constant /usr/include/linux/tcp.h:111: error: enumerator value for `TCP_FLAG_SYN' not integer constant /usr/include/linux/tcp.h:112: error: enumerator value for `TCP_FLAG_FIN' not integer constant /usr/include/linux/tcp.h:113: error: enumerator value for `TCP_RESERVED_BITS' not integer constant /usr/include/linux/tcp.h:115: error: enumerator value for `TCP_DATA_OFFSET' not integer constant ftwall.c:938: warning: conflicting types for built-in function `log' make: *** [ftwall.o] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.86753 (%build) * SOURCES includes entire iptables tarball because ftwall requires libipq.h which is usually provided by iptables-devel in other distributions, but is not included in Red Hat. Instead ftwall appears to static link to libipq from the iptables tarball build. This is the change in tcp.h that causes the build failure in FC1: --- tcp.h-rh9 2003-11-06 21:45:40.000000000 -1000 +++ tcp.h-fc1 2003-11-06 21:46:08.000000000 -1000 @@ -102,16 +102,16 @@ #define tcp_flag_word(tp) ( ((union tcp_word_hdr *)(tp))->words [3]) enum { - TCP_FLAG_CWR = __constant_htonl(0x00800000), - TCP_FLAG_ECE = __constant_htonl(0x00400000), - TCP_FLAG_URG = __constant_htonl(0x00200000), - TCP_FLAG_ACK = __constant_htonl(0x00100000), - TCP_FLAG_PSH = __constant_htonl(0x00080000), - TCP_FLAG_RST = __constant_htonl(0x00040000), - TCP_FLAG_SYN = __constant_htonl(0x00020000), - TCP_FLAG_FIN = __constant_htonl(0x00010000), - TCP_RESERVED_BITS = __constant_htonl(0x0FC00000), - TCP_DATA_OFFSET = __constant_htonl(0xF0000000) + TCP_FLAG_CWR = htonl(0x00800000), + TCP_FLAG_ECE = htonl(0x00400000), + TCP_FLAG_URG = htonl(0x00200000), + TCP_FLAG_ACK = htonl(0x00100000), + TCP_FLAG_PSH = htonl(0x00080000), + TCP_FLAG_RST = htonl(0x00040000), + TCP_FLAG_SYN = htonl(0x00020000), + TCP_FLAG_FIN = htonl(0x00010000), + TCP_RESERVED_BITS = htonl(0x0FC00000), + TCP_DATA_OFFSET = htonl(0xF0000000) }; /* TCP socket options */ From esr at thyrsus.com Fri Nov 7 21:43:21 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 16:43:21 -0500 Subject: RPM submission script In-Reply-To: <1068239981.6576.0.camel@opus> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> <1068239981.6576.0.camel@opus> Message-ID: <20031107214321.GA16941@thyrsus.com> seth vidal : > > Not a problem. I'll just specify that the input is expected to be > > UTF-8 and screw all that multibyte crap. World's going that > > direction anyway. > > ugh - a lot of data in rpms is not utf-8 happy. Often in latin-1 or > beyond that in the encoding. Again, that's OK. The stuff in the message doesn't include the RPM itself, One of the fields is optionally an associated-file-resource URL that could *point* at an RPM, but that's a different matter. -- Eric S. Raymond From mharris at redhat.com Fri Nov 7 20:22:53 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 7 Nov 2003 15:22:53 -0500 (EST) Subject: RPM submission script In-Reply-To: <200311070934.28398.jkeating@j2solutions.net> References: <200311071720.hA7HKi1C015566@snark.thyrsus.com> <200311070934.28398.jkeating@j2solutions.net> Message-ID: On Fri, 7 Nov 2003, Jesse Keating wrote: >> The next point release of Bugzilla will include and support a script >> called bug-bugzilla, written by Christian Reis and myself, that >> allows posting of bugs without going through a Web interface. You >> supply an RFC822-like message on input instead. > >Eric, this seems very nice. My lack of knowledge in the RFC area though >brings me to ask if you could provide a small example of a >"RFC822-like" message? Another project I manage is pressuring me to >move away from bugzilla so that our users/developers can submit bugs >w/out using the web interface. This response is intended for the mailing list in general, and not really as a response directly to Jesse's comments. I'm just using this particular message at random, to reply to the thread in a general sense... Not using bugzilla is a MAJOR step backwards. I can't speak for other projects out there, however bugzilla ultimately is present firstly for developers and engineers actively working on the distribution first and foremost, and is available to others such as end users, testers, etc. second to that. Any changes to bugzilla which make the job of engineers _more_ difficult, or require more work on the part of engineers and other developers, means that the bug tracking solution is no longer doing its job adequately. Any change made to make things easier for users/testers absolutely must not have an opposite effect of making things more difficult for engineers/developers, or it wont be seen in good light. Bugzilla has an XMLRPC interface which can be used to write client applications instead of using the web UI. You could write a GTK or ncurses bugzilla client if you wish, or even write an email gateway. There is no reason to replace bugzilla whatsoever. Just use the existing interfaces and cook up a new frontend for email/ncurses/GTK/whatever that is desired. I believe Alex Larsson and Adrian Likins have both implemented alternative bugzilla frontends using the XMLRPC interface already, however I don't know how complete or fully functional they are. But please please please, don't suggest that we replace bugzilla with something else. We have a lot of time and effort invested in bugzilla, and a massive database behind it. The costs associated with replacing all of that would be extremely staggering, and to remotely consider such a change would have to come with a massive number of benefits to Red Hat and engineers here to make us work faster/better/etc. It's very unlikely we would consider any such change with much seriousness, when bugzilla is open source and we can (and do) modify it heavily to meet the needs of Red Hat already. Please - use the XMLRPC interface if the web interface is insufficient for your needs, and suggest improvements to bugzilla if you find it lacking in some area, because it is IMHO very highly unlikely that a replacement for bugzilla would be considered without much laughter. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From garrett at redhat.com Fri Nov 7 02:36:46 2003 From: garrett at redhat.com (Garrett LeSage) Date: Thu, 06 Nov 2003 21:36:46 -0500 Subject: regarding: Anyone else interested in graphics? In-Reply-To: <200311070055.04798.pmmm@rnl.ist.utl.pt> References: <3FAACFAA.60104@verizon.net> <3FAAD94B.9090309@silverorange.com> <1068162387.6649.254.camel@localhost.localdomain> <200311070055.04798.pmmm@rnl.ist.utl.pt> Message-ID: <3FAB053E.5050606@redhat.com> Hey all, Anyone interested in artwork, graphics, UI, or anything else desktop-related should sign up for fedora-desktop-list. I talked to Havoc and Brent about it yesterday and had fedora-desktop-list set up, as fedora-list, fedora-test-list, and fedora-devel-list are a little too high traffic for serious desktop-related discussions (except possibly something absolutely major, of which I have no real examples). Everything talked about in this thread would be perfect for the new desktop list! See you there. (: More info about the list: http://www.redhat.com/mailman/listinfo/fedora-desktop-list Garrett Pedro Morais wrote: >Em Quinta 06 Novembro 2003 23:46, David Farning escreveu: > > >>On Thu, 2003-11-06 at 17:29, Steven Garrity wrote: >> >> >>>Michael S. Fivis wrote: >>> > Are there other people on this list deeply interested in doing 2D >>> > graphical work for fedora? (wallpapers, handling, icons, etc)? >>> > michaelfivis at verizon.net Should start a forum or our own list of >>> >>>some > sort. >>> >>>I am interested in helping out in these areas. I am a designer for a web >>>development firm but have an interested in UI, window, and icon design. >>>I also have some talented help from some co-workers in these areas. >>> >>>Do you have any particular work in mind? >>> >>>Steven Garrity >>> >>> >>I would have to give a +1 to a consistent look and feel across the >>config suit. Granted it is not glamorous, but it would be nice! >> >> > >A big +1. >Also, maybe not graphics related, better gnome style guide adherance. > > > >>Dave Farning >> >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> > > > From aoliva at redhat.com Fri Nov 7 21:44:20 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 07 Nov 2003 19:44:20 -0200 Subject: RPM submission script In-Reply-To: <20031107212714.GA16837@thyrsus.com> References: <20031107203937.GC16285@thyrsus.com> <20031107210539.05BD516FC3@jmason.org> <20031107212714.GA16837@thyrsus.com> Message-ID: On Nov 7, 2003, "Eric S. Raymond" wrote: > Well, technically, yes...but not the way people usually mean it (16-bit > chars like Java). That's not UTF-8. That's another representation of Unicode. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From tmartin at physics.ucsd.edu Fri Nov 7 21:57:00 2003 From: tmartin at physics.ucsd.edu (Terrence Martin) Date: Fri, 07 Nov 2003 13:57:00 -0800 Subject: Support for Apple 23 inch High Definition LCD panel and XFree86 config. Message-ID: <3FAC152C.5050209@physics.ucsd.edu> Hi, I recently installed fedora core 1 on my system, replacing redhat 8.0 and wanted to share the work I had done to get my Apple HD 23in display to work in Fedora. By default fedora would not drive this monitor properly at all and would always give a blank screen so I had to use a text based install. The screen also blanked on boot the first time since the default was to use the frame buffer display. The redhat-config-xfree86 and firstboot also gave me no joy. To get the system to boot I took a stab and removed rhfb (sp?) from grub and that got me to a console prompt at least. Getting the monitor to display something was mostly as a result of some more accurate settings in the XF86Config file which I have attached. Hopefully it will be useful in making fedora support this monitor out of the box better. There are several changes, but I believe the important ones are the modeline and the vertical and horizontal refresh rates. As a side note while I am using nvidia's driver I did get a display with the default opensource nvidia driver. If anyone requires any additional information let me know. Terrence -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: XF86Config URL: From skvidal at phy.duke.edu Fri Nov 7 21:54:35 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 07 Nov 2003 16:54:35 -0500 Subject: RPM submission script In-Reply-To: <20031107214321.GA16941@thyrsus.com> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> <1068239981.6576.0.camel@opus> <20031107214321.GA16941@thyrsus.com> Message-ID: <1068242075.6576.2.camel@opus> On Fri, 2003-11-07 at 16:43, Eric S. Raymond wrote: > seth vidal : > > > Not a problem. I'll just specify that the input is expected to be > > > UTF-8 and screw all that multibyte crap. World's going that > > > direction anyway. > > > > ugh - a lot of data in rpms is not utf-8 happy. Often in latin-1 or > > beyond that in the encoding. > > Again, that's OK. The stuff in the message doesn't include the RPM itself, > One of the fields is optionally an associated-file-resource URL that could > *point* at an RPM, but that's a different matter. no I mean things like: descriptions vendor names packager names summaries filenames shall I continue? :) -sv From esr at thyrsus.com Fri Nov 7 22:01:32 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 17:01:32 -0500 Subject: RPM submission script In-Reply-To: References: <20031107203937.GC16285@thyrsus.com> <20031107210539.05BD516FC3@jmason.org> <20031107212714.GA16837@thyrsus.com> Message-ID: <20031107220132.GA17064@thyrsus.com> Alexandre Oliva : > On Nov 7, 2003, "Eric S. Raymond" wrote: > > > Well, technically, yes...but not the way people usually mean it (16-bit > > chars like Java). > > That's not UTF-8. That's another representation of Unicode. Um. Yes. Were you under the impression I had said otherwise? -- Eric S. Raymond From miguel at esdebian.org Fri Nov 7 22:25:41 2003 From: miguel at esdebian.org (Miguel Vazquez Gocobachi) Date: Fri, 7 Nov 2003 14:25:41 -0800 (PST) Subject: Participe Message-ID: <20031107222541.36040397D@sitemail.everyone.net> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From skvidal at phy.duke.edu Fri Nov 7 22:28:34 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 07 Nov 2003 17:28:34 -0500 Subject: FC2 release dates In-Reply-To: <20031107153844.C13384@devserv.devel.redhat.com> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> <1068167013.10735.19.camel@binkley> <20031107153844.C13384@devserv.devel.redhat.com> Message-ID: <1068244114.6576.14.camel@opus> > I should mention here my concept of Fedora leadership. I don't > believe that leadership by appointment works very well, at least > in this context. My intention for Fedora leadership is that > we'll be *recognizing* people who are already acting as the > leaders in the community. Not necessarily the people who have > the most to say all the time () but the ones who lead > by action, and whose goals as expressed in their actions are > aligned with our goals, the statement of which is available at > http://fedora.redhat.com/about/objectives.html and which we expect > to refine over time. This is good to hear. Better than appointing, you're definitely correct. I think nominations for people worthy of recognition might be useful. B/c, as you said, you've been busy and might not have noticed people who have been having an effect. I have a few people in the back of my head who deserve high praise for putting up with a fair bit of abuse, many of them at red hat. :) > I want to be clear that Red Hat will be bringing some clear objectives > to the table for this discussion. I'll say right away that a 2.6 > kernel as soon as possible has at least three reasons that we care about: > o We have a LOT of end users urgently requesting it. > o Linus has asked us to do a 2.6-kernel-default distribution > absolutely ASAP, and his request carries significant weight. > o Red Hat has an interest in doing a distribution with a 2.6 > kernel from the standpoint of our work on our Enterprise > products. All of those are pressing points and well understood, my only argument for delaying a bit is to try and include gnome 2.6. - As Jef Spaleta mentioned on irc - a cool release name is FC2(.6) ;) I know a month is a long time in free software but from the avg life cycle of linux 2.2->2.4->2.6 it won't be a very long in the linux 2.6->2.8 cycle. Getting gnome 2.6 would mean more gnome testing and that's got to be helpful for RHEL, as well. my thoughts, worth whatever they're worth. -sv > HTH, > > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From roland at redhat.com Fri Nov 7 22:28:44 2003 From: roland at redhat.com (Roland McGrath) Date: Fri, 7 Nov 2003 14:28:44 -0800 Subject: ftwall build broke FC1 tcp.h (glibc-kernheaders) In-Reply-To: Warren Togami's message of Friday, 7 November 2003 10:21:02 -1000 <1068194839.30673.10.camel@laptop> Message-ID: <200311072228.hA7MSiHY008852@magilla.sf.frob.com> I think those glibc-kernheaders changes are broken. htonl is not a valid constant expression macro in userland, though it might now be in kernelland. The userland macro will be optimized away to the constant by the compiler, but that does not make it a valid constant expression. Could you file a report against the FC glibc-kernheaders package on bugzilla.redhat.com? Thanks, Roland > --- tcp.h-rh9 2003-11-06 21:45:40.000000000 -1000 > +++ tcp.h-fc1 2003-11-06 21:46:08.000000000 -1000 > @@ -102,16 +102,16 @@ > #define tcp_flag_word(tp) ( ((union tcp_word_hdr *)(tp))->words [3]) > > enum { > - TCP_FLAG_CWR = __constant_htonl(0x00800000), > - TCP_FLAG_ECE = __constant_htonl(0x00400000), > - TCP_FLAG_URG = __constant_htonl(0x00200000), > - TCP_FLAG_ACK = __constant_htonl(0x00100000), > - TCP_FLAG_PSH = __constant_htonl(0x00080000), > - TCP_FLAG_RST = __constant_htonl(0x00040000), > - TCP_FLAG_SYN = __constant_htonl(0x00020000), > - TCP_FLAG_FIN = __constant_htonl(0x00010000), > - TCP_RESERVED_BITS = __constant_htonl(0x0FC00000), > - TCP_DATA_OFFSET = __constant_htonl(0xF0000000) > + TCP_FLAG_CWR = htonl(0x00800000), > + TCP_FLAG_ECE = htonl(0x00400000), > + TCP_FLAG_URG = htonl(0x00200000), > + TCP_FLAG_ACK = htonl(0x00100000), > + TCP_FLAG_PSH = htonl(0x00080000), > + TCP_FLAG_RST = htonl(0x00040000), > + TCP_FLAG_SYN = htonl(0x00020000), > + TCP_FLAG_FIN = htonl(0x00010000), > + TCP_RESERVED_BITS = htonl(0x0FC00000), > + TCP_DATA_OFFSET = htonl(0xF0000000) > }; > > /* TCP socket options */ From alan at redhat.com Fri Nov 7 22:29:10 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Nov 2003 17:29:10 -0500 (EST) Subject: i18n issues, was: FC2 release In-Reply-To: <200311071533.46328.pgampe@redhat.com> from "Paul Gampe" at Tach 07, 2003 03:33:46 Message-ID: <200311072229.hA7MTBV25113@devserv.devel.redhat.com> > On Fri, 7 Nov 2003 10:49 am, Alan Cox wrote: > > Does that mean that by mid December we can be thinking about getting the > > lost translations (for non install stuff) rolling out as or with errata, > > since Fedora doesn't have the errata restrictions RHEL does ? > > I may not be interpreting the question correctly Alan sorry, so do you mean > translations that have been committed for redhat-config-* but not picked up > in the rpm for the application? There are some translations that are missing (not many AFAIK) and also a pile of translation errata and updates that could go out with package errata as they are done. From skvidal at phy.duke.edu Fri Nov 7 22:36:33 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 07 Nov 2003 17:36:33 -0500 Subject: FC2 release dates In-Reply-To: <1068244114.6576.14.camel@opus> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> <1068167013.10735.19.camel@binkley> <20031107153844.C13384@devserv.devel.redhat.com> <1068244114.6576.14.camel@opus> Message-ID: <1068244593.6576.17.camel@opus> > I know a month is a long time in free software but from the avg life > cycle of linux 2.2->2.4->2.6 it won't be a very long in the linux > 2.6->2.8 cycle. Getting gnome 2.6 would mean more gnome testing and > that's got to be helpful for RHEL, as well. clarification of this. the 'it' in the first sentence refers to '1 month' not to the life cycle of 2.6->2.8. My point was that one month wasn't much time considering that the time between 2.2 and 2.4 and 2.4 and 2.6 was considerable. -sv From esr at thyrsus.com Fri Nov 7 22:36:50 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 17:36:50 -0500 Subject: RPM submission script In-Reply-To: <1068242075.6576.2.camel@opus> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> <1068239981.6576.0.camel@opus> <20031107214321.GA16941@thyrsus.com> <1068242075.6576.2.camel@opus> Message-ID: <20031107223650.GA17174@thyrsus.com> seth vidal : > > > ugh - a lot of data in rpms is not utf-8 happy. Often in latin-1 or > > > beyond that in the encoding. > > > > Again, that's OK. The stuff in the message doesn't include the > > RPM itself, One of the fields is optionally an > > associated-file-resource URL that could *point* at an RPM, but > > that's a different matter. > > no I mean things like: > descriptions > vendor names > packager names > summaries > filenames > > shall I continue? :) Maybe you'd better. You're not making any sense to me, which could mean either that you are being stupid, or that I am being stupid, or that we are talking right past one another. We'd better figure out which :-). All bug-bugzilla does is mine some strings out of an RFC822-conformant message and use them to script the bug-submission CGI on a Bugzilla instance. You can think of the message as a job card. (The fields in the job card can be supplied, or overridden, by command-line options.) One of the fields handed to the CGI may be a URL pointing to an RPM. It seems to me that the encoding of strings *in the RPM* is not an issue at all for bug-bugzilla. Only the contents of the fields in the job card is an issue. I don't understand why the requirement that those be UTF-8 should ever be onerous. -- Eric S. Raymond From jkeating at j2solutions.net Fri Nov 7 22:36:03 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 14:36:03 -0800 Subject: RPM submission script In-Reply-To: References: <200311071720.hA7HKi1C015566@snark.thyrsus.com> <200311070934.28398.jkeating@j2solutions.net> Message-ID: <200311071436.07850.jkeating@j2solutions.net> On Friday 07 November 2003 12:22, Mike A. Harris wrote: > Not using bugzilla is a MAJOR step backwards. I can't speak for > other projects out there, however bugzilla ultimately is present > firstly for developers and engineers actively working on the > distribution first and foremost, and is available to others such > as end users, testers, etc. second to that. > > Any changes to bugzilla which make the job of engineers _more_ > difficult, or require more work on the part of engineers and > other developers, means that the bug tracking solution is no > longer doing its job adequately. > > Any change made to make things easier for users/testers > absolutely must not have an opposite effect of making things more > difficult for engineers/developers, or it wont be seen in good > light. Hrm, I didn't think that this was an attempt to replace Bugzilla, only make it a slight bit easier to manage. I fail to see how this email-gateway thing will make things more difficult for the engineer. It's mostly a way to make things easier for the end-user to file the bug. Perhaps I'm not looking at the picture big enough, but isn't this just a method to get the initial information into the bugzilla system, and afterwhich the user/developer can use the web interface for anything else necessary? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 notting at redhat.com Fri Nov 7 17:06:29 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 7 Nov 2003 12:06:29 -0500 Subject: rawhide-release? In-Reply-To: ; from behdad@cs.toronto.edu on Fri, Nov 07, 2003 at 11:01:01AM -0500 References: Message-ID: <20031107120629.A591@devserv.devel.redhat.com> Behdad Esfahbod (behdad at cs.toronto.edu) said: > Where is rawhide-release gone? It's more or less dead. > BTW, I've noticed that /usr/share/doc/fedora-release-1/9 is > empty, while the other ones are not. Build process snafu. Bill From gauret at free.fr Fri Nov 7 22:49:39 2003 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 07 Nov 2003 23:49:39 +0100 Subject: Warren's Package Naming Proposal - Revision 2 References: <1068236427.12684.60.camel@laptop> Message-ID: Hi These guidelines seem fine, thanks for the work. However, I have recently bumped into a package naming problem which doesn't seem to be covered here. It's a program called K3B, a CD/DVD burning frontend for KDE. Here is their release numbers : 0.8 -> 0.9 -> 0.10 How should we set the RPM fields without using epochs in this type of versionning ? Is is a case where epoch is necessary ? Thanks Aurelien -- http://gauret.free.fr ~~~~~~~~~~~~~~~~~~~~~ Unix IS user-friendly. It is just very picky about who his friends are. From jkeating at j2solutions.net Fri Nov 7 22:52:16 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 14:52:16 -0800 Subject: fedora-legacy agrees to enforce rpm upgrades? (was: Warren's Package Naming Proposal - Revision 1) In-Reply-To: <1068239833.14859.296.camel@bobcat.mine.nu> References: <3FA229D3.4000104@togami.com> <1068231564.3252.1.camel@m70.net81-64-235.noos.fr> <1068239833.14859.296.camel@bobcat.mine.nu> Message-ID: <200311071452.16927.jkeating@j2solutions.net> On Friday 07 November 2003 13:17, Ville Skytt? wrote: > There was some support for moving/keeping non-numeric upstream > post-release version parts in %{version} instead of moving them into > %{release}, what is the consensus on that now? Please see Warren Togami's naming scheme proposal. Unless otherwise opposed, Fedora Legacy will adopt this naming scheme and move forward with it. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 xose at wanadoo.es Fri Nov 7 22:55:04 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Fri, 07 Nov 2003 23:55:04 +0100 Subject: Packages licenses References: Message-ID: <3FAC22C8.3020007@wanadoo.es> Mike A. Harris wrote: > I completely agree, however before people submit patches, or > suggest changes, I think we really do need to make an official > rubber stamped list of specific license names. The list should Maybe there is more... but rpmlint- a tool to check common errors on RPM packages -( http://people.mandrakesoft.com/~flepied/projects/rpmlint/ ) has a basic set of them. --cut-- # liste grabbed from www.opensource.org/licenses DEFAULT_VALID_LICENSES = ( 'GPL', 'LGPL', 'GFDL', 'OPL', 'Artistic', 'BSD', 'MIT', 'QPL', 'MPL', 'IBM Public License', 'Apache License', 'PHP License', 'Public Domain', 'Modified CNRI Open Source License', 'zlib License', 'CVW License', 'Ricoh Source Code Public License', 'Python license', 'Vovida Software License', 'Sun Internet Standards Source License', 'Intel Open Source License', 'Jabber Open Source License', 'Nokia Open Source License', 'Sleepycat License', 'Nethack General Public License', 'Common Public License', 'Apple Public Source License', 'X.Net License', 'Sun Public License', 'Eiffel Forum License', 'W3C License', 'Zope Public License', # non open source licences: 'Proprietary', 'Freeware', 'Shareware', 'Charityware' ) --end-- note: rpmlint is a python tool ;-) -- HTML mails are going to trash automagically From bill at noreboots.com Fri Nov 7 22:56:34 2003 From: bill at noreboots.com (Bill Anderson) Date: 07 Nov 2003 15:56:34 -0700 Subject: FC2 release dates In-Reply-To: <1068135502.1453.17.camel@opus> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <1068135502.1453.17.camel@opus> Message-ID: <1068245794.26232.4.camel@locutus> On Thu, 2003-11-06 at 09:18, seth vidal wrote: > Any other major programs that should be kept in mind? An installer supporting XFS and filesystems other than ext2/3 during install. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From jkeating at j2solutions.net Fri Nov 7 20:20:02 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 12:20:02 -0800 Subject: fedora-legacy agrees to enforce rpm upgrades? (was: Warren's Package Naming Proposal - Revision 1) In-Reply-To: References: <3FA229D3.4000104@togami.com> <20031107164717.GD27327@puariko.nirvana> Message-ID: <200311071220.03067.jkeating@j2solutions.net> On Friday 07 November 2003 12:06, Mike A. Harris wrote: > Make it 3 then... I support Warren's suggestion. Perhaps others > will speak up too if it is something up for democratic vote. If > it's not up for democratic vote, hail Warren! Well, I think right now I'd have the final say, but I do differ to warren on a lot of issues. I'd have to dig up some old email, but there were some locking bugs and upgrade version issues that we wanted to solve with a single rpm version set across all the supported Legacy distros. Fedora.us has done a lot of research on it so I've been told, and they haven't found any reason to not fix these nasty bugs. So I'm going to be a bit totalitarian for a moment, and unless somebody can show me a really good reason to _not_ fix RPM across these release, then rpm will be upgraded. Note, this is not an upgrade just to upgrade, we're fixing bugs here. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 jkeating at j2solutions.net Fri Nov 7 22:59:54 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 14:59:54 -0800 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: References: <1068236427.12684.60.camel@laptop> Message-ID: <200311071459.54580.jkeating@j2solutions.net> On Friday 07 November 2003 14:49, Aurelien Bompard wrote: > Here is their release numbers : 0.8 -> 0.9 -> 0.10 > How should we set the RPM fields without using epochs in this type of > versionning ? Is is a case where epoch is necessary ? Does rpm actually fail on this? My understanding was that it takes the number after the dot as a whole, where as "8" is less than "9" which is less than "10". -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 hugo at devin.com.br Fri Nov 7 12:02:04 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Fri, 07 Nov 2003 09:02:04 -0300 Subject: i18n issues, was: FC2 release In-Reply-To: <200311070034.25123.pmmm@rnl.ist.utl.pt> References: <1068146526.18754.36.camel@spatula> <200311070034.25123.pmmm@rnl.ist.utl.pt> Message-ID: <3FAB89BC.3090209@devin.com.br> Pedro Morais wrote: > Another "acessibility" issue is internationalization; the current process > isn't bad at all, but could be improved. > I was unfortunately very busy during this beta period (only managed to follow > the mailling lists and update portuguese translations), so I can't really > complain, but I kept i18n stats at 100% at almost all tims, and certainly at > the freeze point I'm sure that only the anaconda docs has a couple of > untranlated, and still there are powerdown messages in english (in the middle > of portuguese messages, so it's not a "too late for i18n issue") and, even > worse, up2date/rhn_register is half translated/half in english. > > Clearly there's room for improvement. Yes, and I'm here to help translating things to Brazilian Portuguese too :) Internationalization is much important... I wanted to help because every time I used RH and pick up the Brazilian Portuguese language for the system, I ended up with lots of Portuguese (From Portugal) mixed with Brazilian Portuguese. They are both Portuguese, but they have lots of diferences, mainly in tech words. []'s Hugo From jkeating at j2solutions.net Fri Nov 7 23:07:42 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 15:07:42 -0800 Subject: FC2 release dates In-Reply-To: <1068245794.26232.4.camel@locutus> References: <1068133330.1455.11.camel@opus> <1068135502.1453.17.camel@opus> <1068245794.26232.4.camel@locutus> Message-ID: <200311071507.42727.jkeating@j2solutions.net> On Friday 07 November 2003 14:56, Bill Anderson wrote: > An installer supporting XFS and filesystems other than ext2/3 during > install. ReiserFS and JFS are already options (linux reiserfs jfs). This time RH even included mkfs.jfs in the installer root file system (; XFS is the next biggy though. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 katzj at redhat.com Fri Nov 7 23:13:49 2003 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 07 Nov 2003 18:13:49 -0500 Subject: FC2 release dates In-Reply-To: <1068245794.26232.4.camel@locutus> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <1068135502.1453.17.camel@opus> <1068245794.26232.4.camel@locutus> Message-ID: <1068246829.17302.7.camel@mirkwood.devel.redhat.com> On Fri, 2003-11-07 at 17:56, Bill Anderson wrote: > On Thu, 2003-11-06 at 09:18, seth vidal wrote: > > > Any other major programs that should be kept in mind? > > An installer supporting XFS and filesystems other than ext2/3 during > install. The installer pretty much supports this all already, mostly just depends on kernel bits being there (okay, there are a few xfs pieces I haven't added mostly because of a lack of ability to test them since the kernel doesn't have support :-) Jeremy From Nicolas.Mailhot at laPoste.net Fri Nov 7 23:17:24 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 08 Nov 2003 00:17:24 +0100 Subject: RPM submission script In-Reply-To: <1068242075.6576.2.camel@opus> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> <1068239981.6576.0.camel@opus> <20031107214321.GA16941@thyrsus.com> <1068242075.6576.2.camel@opus> Message-ID: <1068247043.3644.12.camel@m70.net81-64-235.noos.fr> Le ven 07/11/2003 ? 22:54, seth vidal a ?crit : > On Fri, 2003-11-07 at 16:43, Eric S. Raymond wrote: > > seth vidal : > > > > Not a problem. I'll just specify that the input is expected to be > > > > UTF-8 and screw all that multibyte crap. World's going that > > > > direction anyway. > > > > > > ugh - a lot of data in rpms is not utf-8 happy. Often in latin-1 or > > > beyond that in the encoding. > > > > Again, that's OK. The stuff in the message doesn't include the RPM itself, > > One of the fields is optionally an associated-file-resource URL that could > > *point* at an RPM, but that's a different matter. > > no I mean things like: > descriptions > vendor names > packager names > summaries > filenames > > shall I continue? :) Ville Skytt? can tell you how people with non-ascii names feel about UTF-8. He's been actively converting the JPackage spec files to UTF-8 since we agreed on it (I must admit I like UTF-8 but I certainly can not match Ville's zeal). UTF-8 is not the problem. Hanging on 8-bit limited encodings is. The sooner everything is in i18n-resistant formats like xml and unicode the better I'll feel. I was quite amused about the FC1 comment on UTF-8 change problems. For most non-US people the move to UTF-8 was/is just wonderful. If you think current problems are bad, just try to actually work on a pre-unicode release using non-ascii encoding. 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 czar at czarc.net Fri Nov 7 08:38:21 2003 From: czar at czarc.net (Gene C.) Date: Fri, 7 Nov 2003 03:38:21 -0500 Subject: FC2 release dates In-Reply-To: <1068164005.12985.11.camel@mirkwood.devel.redhat.com> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> Message-ID: <200311070338.21667.czar@czarc.net> On Thursday 06 November 2003 19:13, Jeremy Katz wrote: > On Thu, 2003-11-06 at 10:42, seth vidal wrote: > > I think we should get an estimate on FC2 beta/freeze/release dates > > ironed out right now. > > I tend to agree, although they're test releases, not betas :-) > > > If we're looking at 4-6 months how about: > > > > Betas around Valentine's Day and St Patrick's Day: > > Freeze for the second week of April > > Maybe try for a release on Tax Day? > > How does that sound. > > I would personally prefer to get 2.6 out sooner rather than later. To > throw out something as an alternative plan for a faster release, > something like the following for availability of milestones could work. > It's definitely a more aggressive suggestion :) > > Test1 - January 13 > Test2 - February 3 > Test3/RC - March 1 > GA - March 22 > > Then, extrapolate back roughly a week earlier for freeze dates. I'd > love to actually get earlier, but that would require either less test > releases (which strikes me as a bad idea for 2.6), less time between > them (same) or getting test 1 out before Christmas (likely to be really > really hard to pull off) If the focus of the next round is the 2.6 kernel, then you can get lots of updates kernel tests via up2date. Are not the test1/test2/test3 releases really focused on the install process? With the release plus up2date process, individual packages (including the kernel) get a lot more rounds of testing than is implied by test release dates. -- Gene From jspaleta at princeton.edu Fri Nov 7 02:01:08 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Thu, 06 Nov 2003 21:01:08 -0500 Subject: i18n issues, was: FC2 release Message-ID: <1068170468.27579.14.camel@localhost.localdomain> Jeremy Katz wrote: > On Thu, 2003-11-06 at 19:42, Pedro Morais wrote: > > And, now that I read the rest of this thread :-) a tracking bug for i18n > > issues, similar to the proposed for a11y could be a step in that direction. > > (If it exists, i'm not aware of it) > > Yes, this is definitely a good idea. I've created an i18n keyword, but > right now keywords require bug editing access. If you want to create a > tracker, though, then that can be used to populate the keyword from > eventually. Tracking bugs.... here's is my example of what a public tracking bug looks like. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109188 I think a11y and i18n trackers are "good things"{tm} but i don't want to own those trackers. But if those trackers do get created i want to make a place for them in the Fedora Triage wiki listings. I just need to make a space for a collection of tracker bugs. And I want to encourage someone invested in a11y and i18n to be the owner of the associated trackers. It would be very good for someone who is in a position to make each of those issues a high personal priority to be the owner of each of those trackers. I'm not that person..i only attempt to speak english and i like eye-candy too much to be invested in a11y. -jef"netpeep as a11y system monitoring"spaleta -------------- 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 P at draigBrady.com Fri Nov 7 10:16:42 2003 From: P at draigBrady.com (P at draigBrady.com) Date: Fri, 07 Nov 2003 10:16:42 +0000 Subject: Much faster grep In-Reply-To: <20031106185231.GU1963@redhat.com> References: <20031106185231.GU1963@redhat.com> Message-ID: <3FAB710A.1000209@draigBrady.com> Tim Waugh wrote: > A quite invasive, experimental patch has been applied to this grep > package: wow, great! Could the same caching technique be used to speed coreutils? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82032 thanks, P?draig. From dag at wieers.com Fri Nov 7 23:29:55 2003 From: dag at wieers.com (Dag Wieers) Date: Sat, 8 Nov 2003 00:29:55 +0100 (CET) Subject: FC2 release dates In-Reply-To: <1068244114.6576.14.camel@opus> Message-ID: On 7 Nov 2003, seth vidal wrote: > > I want to be clear that Red Hat will be bringing some clear objectives > > to the table for this discussion. I'll say right away that a 2.6 > > kernel as soon as possible has at least three reasons that we care about: > > o We have a LOT of end users urgently requesting it. > > o Linus has asked us to do a 2.6-kernel-default distribution > > absolutely ASAP, and his request carries significant weight. > > o Red Hat has an interest in doing a distribution with a 2.6 > > kernel from the standpoint of our work on our Enterprise > > products. > > All of those are pressing points and well understood, my only argument > for delaying a bit is to try and include gnome 2.6. - As Jef Spaleta > mentioned on irc - a cool release name is FC2(.6) ;) > > I know a month is a long time in free software but from the avg life > cycle of linux 2.2->2.4->2.6 it won't be a very long in the linux > 2.6->2.8 cycle. Getting gnome 2.6 would mean more gnome testing and > that's got to be helpful for RHEL, as well. It would be nice to have at least one release where the kernel 2.6 may be optional. Arjan's test kernels for RH9 (or rather Rawhide) fits into this scheme. Enlarging the test-group without sacrificing too many (all?) people ;) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From alex.msilva at uol.com.br Fri Nov 7 10:51:41 2003 From: alex.msilva at uol.com.br (Alexander Martins) Date: Fri, 07 Nov 2003 08:51:41 -0200 Subject: Anyone else interested in graphics? In-Reply-To: <1068162387.6649.254.camel@localhost.localdomain> References: <3FAACFAA.60104@verizon.net> <3FAAD94B.9090309@silverorange.com> <1068162387.6649.254.camel@localhost.localdomain> Message-ID: <3FAB793D.7050902@uol.com.br> David Farning wrote: >On Thu, 2003-11-06 at 17:29, Steven Garrity wrote: > > >>Michael S. Fivis wrote: >> >> > Are there other people on this list deeply interested in doing 2D >> > graphical work for fedora? (wallpapers, handling, icons, etc)? >> > michaelfivis at verizon.net Should start a forum or our own list of >>some > sort. >> >>I am interested in helping out in these areas. I am a designer for a web >>development firm but have an interested in UI, window, and icon design. >>I also have some talented help from some co-workers in these areas. >> >>Do you have any particular work in mind? >> >>Steven Garrity >> >> > > > Hi, I'm interested too in helping in graphical work, but I'm not a expert but a entusiastic beginner. Alexander. >I would have to give a +1 to a consistent look and feel across the >config suit. Granted it is not glamorous, but it would be nice! > >Dave Farning > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- ************************************************************ + Alexander Martins da Silva 2nd email: alex at iq.ufrj.br + + Rio de Janeiro, Brazil 22,80 s 43,43 w + ************************************************************ From alan at redhat.com Fri Nov 7 23:51:14 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Nov 2003 18:51:14 -0500 (EST) Subject: i18n issues, was: FC2 release In-Reply-To: <200311071533.46328.pgampe@redhat.com> from "Paul Gampe" at Tach 07, 2003 03:33:46 Message-ID: <200311072351.hA7NpEJ31714@devserv.devel.redhat.com> > I may not be interpreting the question correctly Alan sorry, so do you mean > translations that have been committed for redhat-config-* but not picked up > in the rpm for the application? The other category that needs addressing is stuff which is horribly visible and down to a complete mess having been made during Fedora 1. However it happened doesn't really matter now but one errata urgently needed is redhat-menus because people fixed languages during Fedora beta 1 moaned they hadn't been updated in beta 2 and again in beta 3 and they are still missing in FC1, making the most critical part of the entire desktop English in those languages. It completely ruins the internationalisation when the root menu translations are still missing. That would be a *great* starting point for fixing the i18n problems in Fedora IMHO. Alan From alan at redhat.com Fri Nov 7 23:52:18 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Nov 2003 18:52:18 -0500 (EST) Subject: RPM submission script In-Reply-To: <200311071436.07850.jkeating@j2solutions.net> from "Jesse Keating" at Tach 07, 2003 02:36:03 Message-ID: <200311072352.hA7NqIu32174@devserv.devel.redhat.com> > make it a slight bit easier to manage. I fail to see how this=20 > email-gateway thing will make things more difficult for the engineer. =20 It fills bugzilla with junk. I suspect the Gnome people may have more to say on that subject. As a tool it also seems unneccessary given bug-buddy. From julo at altern.org Fri Nov 7 15:39:22 2003 From: julo at altern.org (Julien Olivier) Date: Fri, 07 Nov 2003 15:39:22 +0000 Subject: About fonts on Fedora Message-ID: <1068219561.2963.28.camel@localhost.localdomain> Hi I have installed Fedora Core on my laptop. And I noticed that fonts weren't so nice (not so bad, but not perfect). So, I went to the preferences and tried to use subpixel smoothing. It didn't change things very much. It was even a little worse. I guess that's the reason why, even if you selected an LCD screen at install time, Fedora doesn't use subpixel smoothing. But then I modified my /etc/fonts/local.conf to set Bitstream Vera fonts the default. And that brought me slightly better fonts. I then tried to enable subpixel smoothing on those Vera fonts. And the result was awesome ! The fonts were simply perfect. Not blury at all, not too thin. Perfect. So my question is: wouldn't it better to _use_ Vera fonts by default and, if you set them by default, woldn't it better to enable subpixel smoothing for laptops ? -- Julien Olivier From skvidal at phy.duke.edu Fri Nov 7 23:51:15 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 07 Nov 2003 18:51:15 -0500 Subject: FC2 release dates In-Reply-To: References: Message-ID: <1068249075.14565.0.camel@binkley> > It would be nice to have at least one release where the kernel 2.6 may be > optional. Arjan's test kernels for RH9 (or rather Rawhide) fits into this > scheme. Enlarging the test-group without sacrificing too many (all?) > people ;) I think that release is FC1 + the arjan test kernel repository. -sv From twaugh at redhat.com Fri Nov 7 23:56:55 2003 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 7 Nov 2003 23:56:55 +0000 Subject: Much faster grep In-Reply-To: <3FAB710A.1000209@draigBrady.com> References: <20031106185231.GU1963@redhat.com> <3FAB710A.1000209@draigBrady.com> Message-ID: <20031107235655.GL1963@redhat.com> On Fri, Nov 07, 2003 at 10:16:42AM +0000, P at draigBrady.com wrote: > Could the same caching technique be used > to speed coreutils? > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82032 Er.. that bug is marked closed. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Fri Nov 7 23:57:38 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 07 Nov 2003 18:57:38 -0500 Subject: RPM submission script In-Reply-To: <1068247043.3644.12.camel@m70.net81-64-235.noos.fr> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> <1068239981.6576.0.camel@opus> <20031107214321.GA16941@thyrsus.com> <1068242075.6576.2.camel@opus> <1068247043.3644.12.camel@m70.net81-64-235.noos.fr> Message-ID: <1068249458.14565.4.camel@binkley> > Ville Skytt? can tell you how people with non-ascii names feel about > UTF-8. He's been actively converting the JPackage spec files to UTF-8 > since we agreed on it (I must admit I like UTF-8 but I certainly can not > match Ville's zeal). > > UTF-8 is not the problem. Hanging on 8-bit limited encodings is. The > sooner everything is in i18n-resistant formats like xml and unicode the > better I'll feel. That's what I'm talking about. When you try to force latin-1 or other encodings into utf-8 you end up losing characters. So a fun example: take the Description field of cups and try to encode it in utf-8. the (R) next to UNIX is the latin-1 (R) as one byte so you end up having to drop the character entirely Unless you provide a mapping, for every existent encoding. ugh. That's my point. so mandating utf-8 is great, if you also do it in rpm spec files, and filenames, etc, etc, etc. -sv From skvidal at phy.duke.edu Fri Nov 7 23:59:57 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 07 Nov 2003 18:59:57 -0500 Subject: RPM submission script In-Reply-To: <20031107223650.GA17174@thyrsus.com> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> <1068239981.6576.0.camel@opus> <20031107214321.GA16941@thyrsus.com> <1068242075.6576.2.camel@opus> <20031107223650.GA17174@thyrsus.com> Message-ID: <1068249597.14565.8.camel@binkley> > Maybe you'd better. You're not making any sense to me, which could mean > either that you are being stupid, or that I am being stupid, or that we > are talking right past one another. We'd better figure out which :-). > One of the fields handed to the CGI may be a URL pointing to an RPM. > It seems to me that the encoding of strings *in the RPM* is not an issue at > all for bug-bugzilla. Only the contents of the fields in the job card > is an issue. I don't understand why the requirement that those be UTF-8 > should ever be onerous. b/c the content you're providing may well be data that is in an rpm header or in the output of rpm -qi somepkg. as the example I gave to Nicholas, rpm -qi cups - read the description field, note the (R), notice that's it is 1 character, not 3. your program can force the conversion and replace the characters outside the 128 range with ?, but in the case of filenames that are using non-utf-8 encoding you WILL lose some data. That's all I'm saying. -sv From dag at wieers.com Sat Nov 8 00:13:09 2003 From: dag at wieers.com (Dag Wieers) Date: Sat, 8 Nov 2003 01:13:09 +0100 (CET) Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: <1068236427.12684.60.camel@laptop> Message-ID: On Fri, 7 Nov 2003, Warren Togami wrote: > I would assert that the alliances of 3rd party repositories > that have tried to form in the recent past are not sustainable in the > long term, for the same controversial reasons that fedora.us rejected > cooperation with those entities earlier this year. Rejected cooperation ? Excuse me ? When did that happen ;) What controversial reasons ? It's funny, I remember you begging some 3rd party packagers to join (the old) Fedora and the 3rd party packagers you're refering to refused because of how (the old) Fedora was ran. Let me say clearly that I consider the old Fedora and the new Fedora two different things and I'm ready to work together with the new Fedora for a lot of the packages I build (hopefully those that are endorsed by the original developers, like distcc, nagios, avidemux, tvtime, conglomerate, sodipodi, dovecot, amavisd-new, glabels, gringotts, rhythmbox, squidguard, workrave, ... ). > More cooperation is needed to build an entity and software base like > Debian, what we want to become. (?) Well, your false statement in the naming proposal doesn't really help and has offended some people already. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From jkeating at j2solutions.net Sat Nov 8 00:02:32 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 16:02:32 -0800 Subject: RPM submission script In-Reply-To: <200311072352.hA7NqIu32174@devserv.devel.redhat.com> References: <200311072352.hA7NqIu32174@devserv.devel.redhat.com> Message-ID: <200311071602.37361.jkeating@j2solutions.net> On Friday 07 November 2003 15:52, Alan Cox wrote: > It fills bugzilla with junk. I suspect the Gnome people may have more > to say on that subject. As a tool it also seems unneccessary given > bug-buddy. Is bug-buddy still a live project? I'm not so concerned with rpm submission, but I have needs for a bug-buddy type thing for another project I maintain. How configurable is bug-buddy, can you make it work fairly easily for your own project? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 warren at togami.com Fri Nov 7 08:47:20 2003 From: warren at togami.com (Warren Togami) Date: Thu, 06 Nov 2003 22:47:20 -1000 Subject: ftwall build broke FC1 tcp.h (glibc-kernheaders) Message-ID: <1068194839.30673.10.camel@laptop> Hi, I could really use assistance with the ftwall package. It fails build on FC1 due to glibc-kernheaders tcp.h while it builds successfully on RH9. Any suggestions for this problem? Thanks, Warren Togami warren at togami.com http://bugzilla.fedora.us/show_bug.cgi?id=941 http://videl.ics.hawaii.edu/~warren/fedora/ftwall-1.07-1.src.rpm http://videl.ics.hawaii.edu/~warren/fedora/md5sums.asc ftwall is a program for linux firewalls that allows the control of network traffic from "Fast Track" peer-to-peer clients like "Kazaa" and it's derivatives. It is designed to block network traffic from Fast track client applications running in the "home" (or "green") network from making access to any peers on the public internet. It is ideal for use in networks where the security paradigm is "open access" for outbound connections and "tightly limited" access for inbound ones. Ftwall can be used in such a network to prevent outbound Fast Track access, hence preventing illegal file downloads and uploads. Known Problems: * Makefile doesn't use proper CFLAGS. Suggestions please. * Due to the below change in glibc-kerneheaders /usr/include/linux/tcp.h in FC1, compiler fails with this message: In file included from /usr/include/linux/tcp.h:21, from ftwall.c:51: /usr/include/asm/byteorder.h:6:2: warning: #warning using private kernel header; include instead! In file included from ftwall.c:51: /usr/include/linux/tcp.h:105: error: enumerator value for `TCP_FLAG_CWR' not integer constant /usr/include/linux/tcp.h:106: error: enumerator value for `TCP_FLAG_ECE' not integer constant /usr/include/linux/tcp.h:107: error: enumerator value for `TCP_FLAG_URG' not integer constant /usr/include/linux/tcp.h:108: error: enumerator value for `TCP_FLAG_ACK' not integer constant /usr/include/linux/tcp.h:109: error: enumerator value for `TCP_FLAG_PSH' not integer constant /usr/include/linux/tcp.h:110: error: enumerator value for `TCP_FLAG_RST' not integer constant /usr/include/linux/tcp.h:111: error: enumerator value for `TCP_FLAG_SYN' not integer constant /usr/include/linux/tcp.h:112: error: enumerator value for `TCP_FLAG_FIN' not integer constant /usr/include/linux/tcp.h:113: error: enumerator value for `TCP_RESERVED_BITS' not integer constant /usr/include/linux/tcp.h:115: error: enumerator value for `TCP_DATA_OFFSET' not integer constant ftwall.c:938: warning: conflicting types for built-in function `log' make: *** [ftwall.o] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.86753 (%build) * SOURCES includes entire iptables tarball because ftwall requires libipq.h which is usually provided by iptables-devel in other distributions, but is not included in Red Hat. Instead ftwall appears to static link to libipq from the iptables tarball build. This is the change in tcp.h that causes the build failure in FC1: --- tcp.h-rh9 2003-11-06 21:45:40.000000000 -1000 +++ tcp.h-fc1 2003-11-06 21:46:08.000000000 -1000 @@ -102,16 +102,16 @@ #define tcp_flag_word(tp) ( ((union tcp_word_hdr *)(tp))->words [3]) enum { - TCP_FLAG_CWR = __constant_htonl(0x00800000), - TCP_FLAG_ECE = __constant_htonl(0x00400000), - TCP_FLAG_URG = __constant_htonl(0x00200000), - TCP_FLAG_ACK = __constant_htonl(0x00100000), - TCP_FLAG_PSH = __constant_htonl(0x00080000), - TCP_FLAG_RST = __constant_htonl(0x00040000), - TCP_FLAG_SYN = __constant_htonl(0x00020000), - TCP_FLAG_FIN = __constant_htonl(0x00010000), - TCP_RESERVED_BITS = __constant_htonl(0x0FC00000), - TCP_DATA_OFFSET = __constant_htonl(0xF0000000) + TCP_FLAG_CWR = htonl(0x00800000), + TCP_FLAG_ECE = htonl(0x00400000), + TCP_FLAG_URG = htonl(0x00200000), + TCP_FLAG_ACK = htonl(0x00100000), + TCP_FLAG_PSH = htonl(0x00080000), + TCP_FLAG_RST = htonl(0x00040000), + TCP_FLAG_SYN = htonl(0x00020000), + TCP_FLAG_FIN = htonl(0x00010000), + TCP_RESERVED_BITS = htonl(0x0FC00000), + TCP_DATA_OFFSET = htonl(0xF0000000) }; /* TCP socket options */ From alan at redhat.com Sat Nov 8 00:18:27 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Nov 2003 19:18:27 -0500 (EST) Subject: RPM submission script In-Reply-To: <1068249458.14565.4.camel@binkley> from "seth vidal" at Tach 07, 2003 06:57:38 Message-ID: <200311080018.hA80IR115216@devserv.devel.redhat.com> > so mandating utf-8 is great, if you also do it in rpm spec files, and > filenames, etc, etc, etc. Linux filenames are utf-8 and defined that way. Gives the nautilus people something to do ;) From dag at wieers.com Sat Nov 8 00:20:35 2003 From: dag at wieers.com (Dag Wieers) Date: Sat, 8 Nov 2003 01:20:35 +0100 (CET) Subject: FC2 release dates In-Reply-To: <1068249075.14565.0.camel@binkley> Message-ID: On Fri, 7 Nov 2003, seth vidal wrote: > > It would be nice to have at least one release where the kernel 2.6 may be > > optional. Arjan's test kernels for RH9 (or rather Rawhide) fits into this > > scheme. Enlarging the test-group without sacrificing too many (all?) > > people ;) > > I think that release is FC1 + the arjan test kernel repository. Well, making the 2.6 kernel optional (maybe through apt) without requiring to add a new repository would help. I would consider adding Arjan's packages to FC1 as too experimental ('as there must be a reason why Fedora doesn't add it, right ?') Adding it to the updates (or testing) would probably reach a bigger target group. The next release could default to 2.6 and optionally 2.4 (for hardware or software that worked on 2.4 but doesn't on 2.6 anymore) It's a small difference (maybe even psychological), but if you want to test it in advance, the more people/hardware you can test it on, the better the next release will integrate. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From alan at redhat.com Sat Nov 8 00:23:57 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Nov 2003 19:23:57 -0500 (EST) Subject: RPM submission script In-Reply-To: <200311071602.37361.jkeating@j2solutions.net> from "Jesse Keating" at Tach 07, 2003 04:02:32 Message-ID: <200311080023.hA80NvP17968@devserv.devel.redhat.com> > Is bug-buddy still a live project? I'm not so concerned with rpm=20 Very much so > submission, but I have needs for a bug-buddy type thing for another=20 > project I maintain. How configurable is bug-buddy, can you make it=20 > work fairly easily for your own project? Assuming your bug tracker fits the standard patterns it ought to be. bug-buddy already supports delivering bugs to multiple bug repositories as well as useful stuff like dynamic updating. It is tied to the GUI so it doesn't help text mode apps too much From maxka at myrealbox.com Fri Nov 7 11:48:03 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Fri, 07 Nov 2003 03:48:03 -0800 Subject: The Fedora Hardware Project Message-ID: <1068205683.3488.15.camel@max.localdomain> That's what I'm calling it for right now. Feel free to recommend any name you desire. The updated specification/summary for the project is up at: I expect that to be a very temporary location -- the space may disappear any day now. Let me know if anybody else has any more ideas, now that we've got them in a more manageable and organized form. -M From david at fubar.dk Sat Nov 8 00:29:11 2003 From: david at fubar.dk (David Zeuthen) Date: Sat, 08 Nov 2003 01:29:11 +0100 Subject: Hardware Database (WAS Re: RH recommends using Windows? plus a Question!) In-Reply-To: <1068181537.3488.3.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <1068032835.7163.10.camel@laptop.fubar.dk> <1068064320.3427.1.camel@max.localdomain> <1068065532.32434.17.camel@laptop.fubar.dk> <1068066360.3427.28.camel@max.localdomain> <1068072068.32434.33.camel@laptop.fubar.dk> <1068181537.3488.3.camel@max.localdomain> Message-ID: <1068251350.2352.8.camel@laptop.fubar.dk> On Fri, 2003-11-07 at 06:05, Maxwell Kanat-Alexander wrote: > > Definately! I will however concentrate on getting hal 0.2 finished so it > > works with PCI and USB devices and storage. When that is done I'll look > > into packaging it for FC1 and see how it fits in. Automated retrival of > > .fdi files from a database such as yours and signing stuff is something > > that will come after that. > > All right. Should I join the xdg-list so that I can keep up-to-date on > this situation? > That would be great as hal is discussed there. > > Btw, I intend that each device object in HAL to export a lot of device > > specific information (right now only USB is documented, but I got PCI > > working as well); perhaps it would be good already now to agree on > > naming conventions (e.g. I call it usb.bDeviceClass) for specific > > hardware properties? > > Yes, it would be a really good idea to talk about naming conventions. > :-) For me, the priority is on flexibility. There are going to be buses > we can't imagine, and devices we can't imagine, and we want to be able > to use them some day. :-) Any naming convention that translates easily > into XML and makes sense without being too specific is good by me. > Ok, all that stuff will go into the hal spec as support for new buses is added; it should easily translate into XML as each bus is in a separate namespace. It would be good to use the naming conventions from the bus specs but it seems those are not necessarily freely available. Many thanks, David From jkeating at j2solutions.net Sat Nov 8 00:28:36 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 16:28:36 -0800 Subject: RPM submission script In-Reply-To: <200311080023.hA80NvP17968@devserv.devel.redhat.com> References: <200311080023.hA80NvP17968@devserv.devel.redhat.com> Message-ID: <200311071628.36578.jkeating@j2solutions.net> On Friday 07 November 2003 16:23, Alan Cox wrote: > Assuming your bug tracker fits the standard patterns it ought to be. > bug-buddy already supports delivering bugs to multiple bug > repositories as well as useful stuff like dynamic updating. > > It is tied to the GUI so it doesn't help text mode apps too much Is there a current project page for bug-buddy? I did some searching around but I couldn't find a current page. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 kaboom at gatech.edu Fri Nov 7 13:02:09 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Fri, 7 Nov 2003 08:02:09 -0500 (EST) Subject: FC2 release dates In-Reply-To: <1068141715.18754.24.camel@spatula> References: <1068141715.18754.24.camel@spatula> Message-ID: On Thu, 6 Nov 2003, Jef Spaleta wrote: > Chris Ricker wrote: > > > I think if marketing were a driving concern for this project, a more > > marketable name for releases than "Fedora Core" would have been chosen. I > > have a classful of students here who just watched me install it. Comments, > > in order, on watching it boot for the first time: > > Now, I could probably argue that there is quite a lot of room in this process to implement > 'a lessons learned' phase where we sit back and constructively try to navel gaze about how > certain decisions were good or bad or worth reconsidering. But I'm not > going to argue for anything like that till at least FC3. And I'm not > going to even try to imply that 'Core' is bad till we see 'Extras / > Alternatives' media out in the wild to complicate things. > > I'd rather not fight battles over decisions already made just yet...when > there are so many important decisions yet to make. I'm going to > concentrate on making sure the remaining decisions are as multi-facted, > win-win, opportunity advantageous as possible. You're missing my point. Criteria which should be used for decisions are the ones which are important to the project. I don't see marketability as being an important criteria here. The naming is just one evidence of that.... As such, release dates should be based on real criteria which actually matter to the project, not on unimportant factors like ease of marketing tie-ins. > -jef"someone didn't catch my song quote reference..oh well"spaleta I got it. It wasn't applicable. later, chris From fedora at rosamour.com Sat Nov 8 00:37:13 2003 From: fedora at rosamour.com (Ro) Date: Fri, 7 Nov 2003 18:37:13 -0600 Subject: ReiserFS in Anaconda? Message-ID: <004601c3a590$73e88dc0$6401a8c0@rohome> Is there or will it be support for ReiserFS in Disk Druid and the Kickstart installation process? Is there documentation out there about this? I know I can create ResiserFS partitions after the install is done. Cheers, Ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From esr at thyrsus.com Sat Nov 8 00:38:09 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 19:38:09 -0500 Subject: RPM submission script In-Reply-To: <1068249597.14565.8.camel@binkley> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> <1068239981.6576.0.camel@opus> <20031107214321.GA16941@thyrsus.com> <1068242075.6576.2.camel@opus> <20031107223650.GA17174@thyrsus.com> <1068249597.14565.8.camel@binkley> Message-ID: <20031108003809.GB17763@thyrsus.com> seth vidal : > > One of the fields handed to the CGI may be a URL pointing to an RPM. > > It seems to me that the encoding of strings *in the RPM* is not an issue at > > all for bug-bugzilla. Only the contents of the fields in the job card > > is an issue. I don't understand why the requirement that those be UTF-8 > > should ever be onerous. > > b/c the content you're providing may well be data that is in an rpm > header or in the output of rpm -qi somepkg. > > as the example I gave to Nicholas, rpm -qi cups - read the description > field, note the (R), notice that's it is 1 character, not 3. > > your program can force the conversion and replace the characters outside > the 128 range with ?, but in the case of filenames that are using > non-utf-8 encoding you WILL lose some data. Ahhhh. Now I see. This is not actually an issue sbout bug-bugzilla at all. It's an issue about how fedora-submit will transcode non-ASCII stuff that it mines out of RPM metadata fields. I was aware of this problem. fedora-submit will have to call iconv in certain circumstances to mung all the fields into UTF-8. Sometimes it will fail and fedora-submit will error out as a result. Life is hard. -- Eric S. Raymond From pgampe at redhat.com Sat Nov 8 00:44:55 2003 From: pgampe at redhat.com (Paul Gampe) Date: Sat, 8 Nov 2003 10:44:55 +1000 Subject: i18n issues, was: FC2 release In-Reply-To: <200311072351.hA7NpEJ31714@devserv.devel.redhat.com> References: <200311072351.hA7NpEJ31714@devserv.devel.redhat.com> Message-ID: <200311081044.55196.pgampe@redhat.com> I have added myself to the bugzilla ticket you have on this, and will see if we can assist the package maintainer in resolving this. Following Jeremy's suggestion I have also added the i18n keyword to this bug. Thanks Alan, Paul > It completely ruins the internationalisation when the root menu > translations are still missing. > > That would be a *great* starting point for fixing the i18n problems in > Fedora IMHO. > > Alan From jkeating at j2solutions.net Sat Nov 8 00:44:43 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 16:44:43 -0800 Subject: ReiserFS in Anaconda? In-Reply-To: <004601c3a590$73e88dc0$6401a8c0@rohome> References: <004601c3a590$73e88dc0$6401a8c0@rohome> Message-ID: <200311071644.43127.jkeating@j2solutions.net> On Friday 07 November 2003 16:37, Ro wrote: > Is there or will it be support for ReiserFS in Disk Druid and the > Kickstart installation process? Is there documentation out there > about this? I know I can create ResiserFS partitions after the > install is done. Start the install with: "linux reiserfs" to be able to make reiserfs file systems from disk druid. "jfs" is supported as well. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 bfox at redhat.com Fri Nov 7 02:19:24 2003 From: bfox at redhat.com (Brent Fox) Date: Thu, 6 Nov 2003 21:19:24 -0500 Subject: two new mailing lists Message-ID: <20031107021924.GA27306@redhat.com> I've created two new mailing lists: fedora-desktop-list - for desktop, UI, artwork, and usability related discussions fedora-config-list - for discussions about developing configuration tools We're going to keep these new lists focused and on topic, so please keep that in mind before you post. :) Cheers, Brent From esr at thyrsus.com Sat Nov 8 00:51:18 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 19:51:18 -0500 Subject: RPM submission script In-Reply-To: <1068249458.14565.4.camel@binkley> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> <1068239981.6576.0.camel@opus> <20031107214321.GA16941@thyrsus.com> <1068242075.6576.2.camel@opus> <1068247043.3644.12.camel@m70.net81-64-235.noos.fr> <1068249458.14565.4.camel@binkley> Message-ID: <20031108005118.GC17763@thyrsus.com> seth vidal : > take the Description field of cups and try to encode it in utf-8. > > the (R) next to UNIX is the latin-1 (R) as one byte so you end up having > to drop the character entirely Unless you provide a mapping, for every > existent encoding. Eh? Did somebody change Unicode so the low 256 chars aren't Latin-1 while I wasn't looking? > so mandating utf-8 is great, if you also do it in rpm spec files, and > filenames, etc, etc, etc. I think that would actually be a reasonable policy stipulation for Fedora. But we don't have to settle that argument in order to write fedora-submit. -- Eric S. Raymond From esr at thyrsus.com Sat Nov 8 00:52:57 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 19:52:57 -0500 Subject: RPM submission script In-Reply-To: <200311080023.hA80NvP17968@devserv.devel.redhat.com> References: <200311071602.37361.jkeating@j2solutions.net> <200311080023.hA80NvP17968@devserv.devel.redhat.com> Message-ID: <20031108005257.GD17763@thyrsus.com> Alan Cox : > It is tied to the GUI so it doesn't help text mode apps too much See, that's why I wanted bug-bugzilla. I maintain 36 projects; I *need* to be able to script releases, including shipping RPMs. -- Eric S. Raymond From dfarning at sbcglobal.net Fri Nov 7 14:31:21 2003 From: dfarning at sbcglobal.net (David Farning) Date: Fri, 07 Nov 2003 08:31:21 -0600 Subject: TradeMarked Name --redhat-config- Message-ID: <1068215481.2305.3.camel@localhost.localdomain> I have been working for the past several weeks on a visual gui front end for yum. I am considering bringing that knowledge with me to work on the fedora project. But, Frankly, I am concerned about contributing to a program with a trademarked name. I am interested in giving back to the entiregnu/linux community not just the redhat community. If someone likes my product, I would like them to be able to freely use my work irregardless of their distro/flavor. With this in mind what are your suggestions? a. Go ahead and work on redhat-config-*. b. Seek renaming of redhat-config-* to something vendor neutral. c. Put my work in an up stream project and let it trickle down. Thanks Dave Farning From kewley at cns.caltech.edu Fri Nov 7 01:55:25 2003 From: kewley at cns.caltech.edu (David Kewley) Date: Thu, 6 Nov 2003 17:55:25 -0800 Subject: FC2 release dates In-Reply-To: <20031106172048.0f31f3f6.pros-n-cons@bak.rr.com> References: <1068133330.1455.11.camel@opus> <1068135502.1453.17.camel@opus> <20031106172048.0f31f3f6.pros-n-cons@bak.rr.com> Message-ID: <200311061755.25950.kewley@cns.caltech.edu> Vincent wrote on Thursday 06 November 2003 17:20: > I think April is perfect. the EOL of RedHat 9 will be there and if these > ppl switch Fedora is where we'd want them to go right? kernel 2.6, Gnome > 2.6, etc plus a long 6 month release gives kernel2.6 time to iron out some > things, this should _not_ be a quick release. It is probably going to be a > defining release for Fedora most ppl are waiting for a second release to > see where its really going to stand in the market. However, people in larger or more conservative environments will need to do some heavy testing of FC2 before they roll it out, and that will take longer than two weeks (e.g. the two weeks between Tax Day and the RHL9 EOL). So those folks, who are already in a bind with "what version do I standardize on" will be basically *forced* to go with FC1 as an intermediary (since its EOL will be later than RHL9's), or else use a different distro altogether, which means that FC loses a "customer". I'm in a not-too-conservative environment. But my colleagues and I will already need to update to RHL9 or FC1 before the end of December, then to FC1 before the end of April. Or else depend on community-supplied security updates, which still looks like a very shaky proposition (I hope it will stabilize, but it's too soon to tell). Many folks are going to have to change their local release policies and methodology. Our choices seem to be: * roll out new releases *far* more often than we're used to, based on FC * fork over some significant cash e.g. for RHEL licenses (which many can't afford) * try to make our own distro based on the RHEL srpm's (which feels like cheating RH, but if it works, it could be a practical solution for us) * rely on community security updates (so far, too little concreteness to make an organization's plans around this!) * leave RH and Fedora This is a *big* decision for a *lot* of folks. So far my colleagues and I are still planning to stick with RHL (until EOL) and FC, but as I say, I anticipate we'll need to majorly rework our upgrade methods since we're going to have to do them more often, and we cannot spend a majority of our time adapting to the latest-greatest. Sorry this morphed from a discussion of FC2 release dates to a discussion of how to manage a Linux shop in this new age of flux. But they *are* tied together. If the FC2 release can be planned to allow shops a somewhat reasonable roll-out plan (say, April 1), that'd be good. I do not at all intend this to be a complaint or whatever, just pointing out of the reality that lots of folks are facing now. Anything we can do to encourage folks to stay with RH and FC is a good thing. So long as RH doesn't have to spend cash on it. ;) David From dag at wieers.com Sat Nov 8 01:30:25 2003 From: dag at wieers.com (Dag Wieers) Date: Sat, 8 Nov 2003 02:30:25 +0100 (CET) Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: <1068236427.12684.60.camel@laptop> Message-ID: On Fri, 7 Nov 2003, Warren Togami wrote: > XXX: > Should we actively discourage packages that *appear* to be plugin, > add-on or theme packages but are actually completely independent? One > example that has caught me off guard lately was Dag's mozilla-firebird > package. While Dag published mozilla-firebird, fedora.us decided > against a name change from MozillaFirebird to mozilla-firebird for these > reasons: > 1) No reason to change. > 2) Mozilla branding strategy document said the name was changing "soon" > anyway, (which still hasn't happened.) > 3) mozilla-firebird is within the long implicitly understood and > fedora.us codified standard of being a component or add-on to "mozilla", > which is clearly wrong in this case. > #2 and #3 were the strongest arguments in my opinion. > > I can't think of any other past examples off the top of my head, but I > really want to avoid these kinds of instances in the future if > possible. Please express your opinions. > XXX You say it *appears* to be a plugin, and I think that's the problem. There is already a multitude of packages that start off with the same base and are not plugins or add-ons per se. eg. amanda vs. amanda-client (one can be used without the other) bind vs. bind-utils compat-* control-center vs. control-panel (no connection) desktop-backgrounds-basic vs. desktop-file-utils ... They all appear to be plugins (if you only think of that rule) yet we don't urge to change. So #3 is not an exclusive rule, just a guideline for packagers. It never said that it only could be plugins though. #1 doesn't make a difference if you start off adopting a name. I never adopted 'MozillaFirebird' for several reasons (mixed casing is one of them, Debian and Mandrake's decision is another one). If Fedora started off adopting mozilla-firebird, there was no need to change the name either. And the branding doesn't dictate to use mixed casing or the elimination of the standard seperator '-'. Only that it is called 'mozilla firebird' and not just 'firebird'. Everybody knows why ;) So #2 doesn't really convince me. I had to call it mozilla-firebird, without casing and with a proper seperator. The only reason to adopt 'MozillaFirebird' is because the tarball is called that way. And although it is important to consider that name first, there are a lot of other considerations to be made, like mixed casing, what other distro's do, is it a plugin/add-on, is it a library for python/perl/php, what is the pragmatic thing to do. If you want to avoid this kind of clashes, it would be better to not allow upper-case in package-names and to forbid other seperators than '-' (not _ or ''). Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From skvidal at phy.duke.edu Sat Nov 8 01:30:00 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 07 Nov 2003 20:30:00 -0500 Subject: RPM submission script In-Reply-To: <200311080018.hA80IR115216@devserv.devel.redhat.com> References: <200311080018.hA80IR115216@devserv.devel.redhat.com> Message-ID: <1068254999.14565.10.camel@binkley> On Fri, 2003-11-07 at 19:18, Alan Cox wrote: > > so mandating utf-8 is great, if you also do it in rpm spec files, and > > filenames, etc, etc, etc. > > Linux filenames are utf-8 and defined that way. Gives the nautilus people > something to do ;) > and yet if you look at packages from europe you often find file names that are not. -sv From skvidal at phy.duke.edu Sat Nov 8 01:33:40 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 07 Nov 2003 20:33:40 -0500 Subject: FC2 release dates In-Reply-To: <200311061755.25950.kewley@cns.caltech.edu> References: <1068133330.1455.11.camel@opus> <1068135502.1453.17.camel@opus> <20031106172048.0f31f3f6.pros-n-cons@bak.rr.com> <200311061755.25950.kewley@cns.caltech.edu> Message-ID: <1068255219.14565.12.camel@binkley> > So those folks, who are already in a bind with "what version do I standardize > on" will be basically *forced* to go with FC1 as an intermediary (since its > EOL will be later than RHL9's), or else use a different distro altogether, > which means that FC loses a "customer". > > I'm in a not-too-conservative environment. But my colleagues and I will > already need to update to RHL9 or FC1 before the end of December, then to FC1 > before the end of April. Or else depend on community-supplied security > updates, which still looks like a very shaky proposition (I hope it will > stabilize, but it's too soon to tell). And those people should pay close attention to Fedora Legacy and try to help themselves and others when possible. -sv From skvidal at phy.duke.edu Sat Nov 8 01:40:14 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 07 Nov 2003 20:40:14 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068215481.2305.3.camel@localhost.localdomain> References: <1068215481.2305.3.camel@localhost.localdomain> Message-ID: <1068255614.14565.16.camel@binkley> On Fri, 2003-11-07 at 09:31, David Farning wrote: > I have been working for the past several weeks on a visual gui > front end for yum. I am considering bringing that knowledge with me to > work on the fedora project. > But, Frankly, I am concerned about contributing to a program > with a trademarked name. I am interested in giving back to the > entiregnu/linux community not just the redhat community. > If someone likes my product, I would like them to be able to > freely use my work irregardless of their distro/flavor. > With this in mind what are your suggestions? > a. Go ahead and work on redhat-config-*. > b. Seek renaming of redhat-config-* to something vendor neutral. > c. Put my work in an up stream project and let it trickle down. > David, I have similar worries. I've been encouraged to possibly look at using the rhpl package (red hat python library) for functions in yum and the rhpl functions/classes are really quite nice, but I'm a little hazy on requiring them for yum b/c I'd like yum to be useful on other platforms than just rhel/flc/rhl. I'd love to hear suggestions on this problem, especially from the red hat folks. I know at least one person at red hat does understand my concerns. -sv From hugo at devin.com.br Sat Nov 8 01:45:09 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Fri, 07 Nov 2003 22:45:09 -0300 Subject: ReiserFS in Anaconda? In-Reply-To: <004601c3a590$73e88dc0$6401a8c0@rohome> References: <004601c3a590$73e88dc0$6401a8c0@rohome> Message-ID: <3FAC4AA5.7030800@devin.com.br> Ro wrote: > Is there or will it be support for ReiserFS in Disk Druid and the > Kickstart installation process? Is there documentation out there about > this? I know I can create ResiserFS partitions after the install is done. > > Cheers, > Ro In the boot prompt from the install, you can use "linux reiserfs" (graphic) or "text reiserfs" to add support for reiserfs in the instalation. But I always asked... Why not put by default? Lots of people are using it instead of ext3. []'s Hugo From dfarning at sbcglobal.net Fri Nov 7 10:17:43 2003 From: dfarning at sbcglobal.net (David Farning) Date: Fri, 07 Nov 2003 04:17:43 -0600 Subject: Trademarked Name? --redhar-config-* Message-ID: <1068200262.2280.25.camel@localhost.localdomain> I have been working or the past several weeks on a visual gui front end for yum I am considering bring that knowledge with me to work on the fedora project. But, Frankly, I am concerned about contributing to a program with a trademarked name. I am interested in giving back to the entire gnu/linux community not just the redhat community. If someone likes my product, I would like them to be able to freely use my work irregardless of their distro/flavor. With this in mind what are your suggestions? a. Go ahead and work on redhat-config-* b. Seek renaming of redhat-config-* to something vendor neutral c. Put my work in an up stream project and let it trickle down. Thanks Dave Farning From salimma1 at yahoo.co.uk Fri Nov 7 04:28:40 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Fri, 07 Nov 2003 11:28:40 +0700 Subject: FC2 release dates In-Reply-To: <3FAAA679.8090206@devin.com.br> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <3FAAA679.8090206@devin.com.br> Message-ID: <1068179319.8454.24.camel@bushido.localdomain> On Fri, 2003-11-07 at 02:52, Hugo Cisneiros wrote: > I don't know if the implementation is stable enough, but I think when > kernel 2.6 arrives, it'll be a good "ride" to implement native ACL > support in the file system. > > I mean native = easy access and documented procedure on how to work with > ACL on files and such :) > We should ideally be able to select files in Nautilus, right-click, select Properties, select Permissions, then get an NT/2k-style tool to add/remove ACLs. Casual users would then be able to easily share selected files with others instead of having to mess with setfacl (or, as needed now, ask an admin to create a new group everytime files need to be shared. Ugh) If ACL is a stated goal for FC2 I'll bugzilla this request. Regards, Michel From katzj at redhat.com Sat Nov 8 02:15:50 2003 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 07 Nov 2003 21:15:50 -0500 Subject: FC2 release dates In-Reply-To: References: Message-ID: <1068257750.7225.4.camel@edoras.local.net> On Fri, 2003-11-07 at 19:20, Dag Wieers wrote: > Adding it to the updates (or testing) would probably reach a bigger target > group. The next release could default to 2.6 and optionally 2.4 (for > hardware or software that worked on 2.4 but doesn't on 2.6 anymore) Optional kernels are a losing proposition. The installer can really only run with one kernel (otherwise, there's a large number of things that has to be conditional on kernel version which leads to absurd amounts of pain, especially as only one path will get tested) at which point 2.6 *has* to work for people's hardware so that they can install. Even if you discount that, how do you present an option like that? [ ] My hardware sucks, use 2.4 [*] Use 2.6 like the rest of the world You don't even know if your hardware is going to have problems until you're already using 2.6. Also, there are some things that would be nice to do along with 2.6 that will then require the system to be using 2.6 -- things like switching to ALSA across the board, using udev to get persistent device naming, and others. > It's a small difference (maybe even psychological), but if you want to > test it in advance, the more people/hardware you can test it on, the > better the next release will integrate. Having things so that both 2.4 and 2.6 work mean that the integration of 2.6 isn't going to be as smooth. Cheers, Jeremy From jspaleta at princeton.edu Fri Nov 7 01:35:07 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Thu, 06 Nov 2003 20:35:07 -0500 Subject: i18n issues, was: FC2 release Message-ID: <1068168906.27579.11.camel@localhost.localdomain> Jeremy Katz wrote: > On Thu, 2003-11-06 at 19:42, Pedro Morais wrote: > > And, now that I read the rest of this thread :-) a tracking bug for i18n > > issues, similar to the proposed for a11y could be a step in that direction. > > (If it exists, i'm not aware of it) > > Yes, this is definitely a good idea. I've created an i18n keyword, but > right now keywords require bug editing access. If you want to create a > tracker, though, then that can be used to populate the keyword from > eventually. Tracking bugs.... here's is my example of what a public tracking bug looks like. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109188 I think a11y and i18n trackers are "good things"{tm} but i don't want to own those trackers. But if those trackers do get created i want to make a place for them in the Fedora Triage wiki listings. I just need to make a space for a collection of tracker bugs. And I want to encourage someone invested in a11y and i18n to be the owner of the associated trackers. It would be very good for someone who is in a position to make each of those issues a high personal priority to be the owner of each of those trackers. I'm not that person..i only attempt to speak english and i like eye-candy too much to be invested in a11y. -jef"netpeep as a11y system monitoring"spaleta -------------- 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 esr at thyrsus.com Sat Nov 8 02:30:41 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 7 Nov 2003 21:30:41 -0500 Subject: FC2 release dates In-Reply-To: <1068257750.7225.4.camel@edoras.local.net> References: <1068257750.7225.4.camel@edoras.local.net> Message-ID: <20031108023041.GA18437@thyrsus.com> Jeremy Katz : > Having things so that both 2.4 and 2.6 work mean that the integration of > 2.6 isn't going to be as smooth. Agreed. I don't know if my opinion counts for anything in this, nor even if it should. But I'd like to see FC2 go for 2.6 all the way unless 2.6 has showstopper problems. In general I think Fedora can, and should, take a bit more aggressive forward position than stock Red Hat releases did. Not that I'm knocking Red Hat's policy, it made a lot of sense for a packaged consumer product. But the tradeoffs are a little different now. One important difference is that apt-get/yum reduces the cost of being too aggressive in a major release by making fix propagation easier. -- Eric S. Raymond From alan at redhat.com Sat Nov 8 02:36:56 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Nov 2003 21:36:56 -0500 (EST) Subject: RPM submission script In-Reply-To: <1068254999.14565.10.camel@binkley> from "seth vidal" at Tach 07, 2003 08:30:00 Message-ID: <200311080236.hA82auI17339@devserv.devel.redhat.com> > > Linux filenames are utf-8 and defined that way. Gives the nautilus people > > something to do ;) > > and yet if you look at packages from europe you often find file names > that are not. Doesn't alter the way the Linux fs is specified. But yes you see this, and even programs like cd-record with invalid 8859-1 symbols in the C text From alan at redhat.com Sat Nov 8 02:38:46 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Nov 2003 21:38:46 -0500 (EST) Subject: RPM submission script In-Reply-To: <200311071628.36578.jkeating@j2solutions.net> from "Jesse Keating" at Tach 07, 2003 04:28:36 Message-ID: <200311080238.hA82ckS18118@devserv.devel.redhat.com> > > It is tied to the GUI so it doesn't help text mode apps too much > > Is there a current project page for bug-buddy? I did some searching=20 > around but I couldn't find a current page. Its part of gnome, although it can be happily run from non gnome X apps From alan at redhat.com Sat Nov 8 02:41:18 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Nov 2003 21:41:18 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068215481.2305.3.camel@localhost.localdomain> from "David Farning" at Tach 07, 2003 08:31:21 Message-ID: <200311080241.hA82fIA18902@devserv.devel.redhat.com> > If someone likes my product, I would like them to be able to > freely use my work irregardless of their distro/flavor. > With this in mind what are your suggestions? > a. Go ahead and work on redhat-config-*. > b. Seek renaming of redhat-config-* to something vendor neutral. > c. Put my work in an up stream project and let it trickle down. Do you worry about contributing to gnu-cc ? I do understand the point you are trying to make but its GPL code and so you can either rename it or not worry about it (Red Hat ships gnu-cc, nothing stops other folks shipping redhat-config-blah really as I understand it). You'd want different artwork of course. From notting at redhat.com Sat Nov 8 03:23:02 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 7 Nov 2003 22:23:02 -0500 Subject: The Fedora Hardware Project In-Reply-To: <1068205683.3488.15.camel@max.localdomain>; from maxka@myrealbox.com on Fri, Nov 07, 2003 at 03:48:03AM -0800 References: <1068205683.3488.15.camel@max.localdomain> Message-ID: <20031107222302.A19738@devserv.devel.redhat.com> Maxwell Kanat-Alexander (maxka at myrealbox.com) said: > > > I expect that to be a very temporary location -- the space may > disappear any day now. > > Let me know if anybody else has any more ideas, now that we've got them > in a more manageable and organized form. Random comments from looking over it for the first time... Storing brand names is a pain, as there will be 4000 branding variants of a particular device. (Video cards are a classic example, there are 5000 ways to spell out GeForce2). When you have large amounts of user data like this, you'll need a good way to go through and verify all the submissions for typos, variations in spelling, variations in wording, etc. Otherwise the list can become unmanageable. Having a system card URL can lead to privacy concerns. One of the issues you'll have to deal with is only presenting to the user the 'interesting' hardware. In general, the user isn't going to be able to diagnose efficiently enough to the hardware tool whether or not their PCI bridge works. On the other end, when you deal with something like a hard drive, there are 4000 models, most all of which work exactly the same. One comment made: "HWBrowser seems to make sense of hardware data somehow -- is there a way to get data out of it? Who's the maintainer of hwbrowser?" hwbrowser just calls libkudzu; that data is easily available. Bill From notting at redhat.com Sat Nov 8 03:29:47 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 7 Nov 2003 22:29:47 -0500 Subject: RPM submission script In-Reply-To: <200311080018.hA80IR115216@devserv.devel.redhat.com>; from alan@redhat.com on Fri, Nov 07, 2003 at 07:18:27PM -0500 References: <1068249458.14565.4.camel@binkley> <200311080018.hA80IR115216@devserv.devel.redhat.com> Message-ID: <20031107222947.B19738@devserv.devel.redhat.com> Alan Cox (alan at redhat.com) said: > > so mandating utf-8 is great, if you also do it in rpm spec files, and > > filenames, etc, etc, etc. > > Linux filenames are utf-8 and defined that way. Gives the nautilus people > something to do ;) Erm, then the kernel should default to UTF-8 for NLS on vfat & iso9660. Bill From notting at redhat.com Sat Nov 8 03:31:29 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 7 Nov 2003 22:31:29 -0500 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: <200311071459.54580.jkeating@j2solutions.net>; from jkeating@j2solutions.net on Fri, Nov 07, 2003 at 02:59:54PM -0800 References: <1068236427.12684.60.camel@laptop> <200311071459.54580.jkeating@j2solutions.net> Message-ID: <20031107223129.C19738@devserv.devel.redhat.com> Jesse Keating (jkeating at j2solutions.net) said: Content-Description: signed data > On Friday 07 November 2003 14:49, Aurelien Bompard wrote: > > Here is their release numbers : 0.8 -> 0.9 -> 0.10 > > How should we set the RPM fields without using epochs in this type of > > versionning ? Is is a case where epoch is necessary ? > > Does rpm actually fail on this? My understanding was that it takes the > number after the dot as a whole, where as "8" is less than "9" which is > less than "10". Yes, rpm should handle that fine. It's not done as a float comparison. Bill From nando at ccrma.Stanford.EDU Sat Nov 8 04:02:15 2003 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 07 Nov 2003 20:02:15 -0800 Subject: Distags in rpm sort order (yes, versioning again ;) In-Reply-To: <20031107105050.GC17587@puariko.nirvana> References: <20031031065846.GC4184@puariko.nirvana> <20031103103548.GC16946@puariko.nirvana> <20031107105050.GC17587@puariko.nirvana> Message-ID: <1068264135.21333.4.camel@cmn30.stanford.edu> > > No comments from RH? Should every repository and its cat come up with > > its own scheme creating more compatibility problems in the future? > > Well, this thread is becoming old and boring and is like beating a > dead horse, so I am giving up ;) > Previously on this thread > > disttag can be: > > A B C > > Red Hat Linux 7.3 fdr0.7.3 rh7.3 rh7.3 > > Red Hat Linux 8.0 fdr0.8.0 rh8.0 rh8.0 > > Red Hat Linux 9 fdr0.9 rh9 rh9 > > Fedora Core 1 fdr1 rh9.1 1fdr > > Fedora Core 2 test1 fdr1.95 rh9.1.95 1.95fdr > > While I personally think that scheme A (e.g. using fedora like > disttags for past RH releases) would solve the problems best, it only > makes sense to me, if that would become a standard, and not only > something atrpms follows. > > Since neither RH nor any other repo really commented on this > (constructively that is ;), I guess it means repos will go wild with > supporting multiple RH/FC releases. I for my part will use scheme B > (numbering FC with something higher than rh9, e.g. rh9.1, similar to > Rex Dieter's suggestion a while back). I'm starting to use something similar in Planet CCRMA, I was previously using: rh73 -> rh80 -> rh90 (so I can't really switch to rh7.3/rh8.0/rh9 at this point) And now I'm rebuilding for FC1 with: rh73 -> rh80 -> rh90 -> rhfc1 Seems to work fine. -- Fernando From jkeating at j2solutions.net Sat Nov 8 04:17:04 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 20:17:04 -0800 Subject: ReiserFS in Anaconda? In-Reply-To: <3FAC4AA5.7030800@devin.com.br> References: <004601c3a590$73e88dc0$6401a8c0@rohome> <3FAC4AA5.7030800@devin.com.br> Message-ID: <200311072017.04545.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 07 November 2003 17:45, Hugo Cisneiros wrote: > But I always asked... Why not put by default? Lots of people are using > it instead of ext3. Because it's not as heavily tested as ext3 by the RH folks. They don't have confidence in it enough to allow it to be a default installer option. I agree on this as well. - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/rG5A4v2HLvE71NURAoWeAKC6Y4LNfGuZdS1OgZmcIDFPCA5RqgCgxLcM vmyn7G7dG4843pjHjBY6eJc= =uqRx -----END PGP SIGNATURE----- From fedora at rosamour.com Sat Nov 8 04:22:53 2003 From: fedora at rosamour.com (Ro) Date: Fri, 7 Nov 2003 22:22:53 -0600 Subject: ReiserFS in Anaconda? In-Reply-To: <200311072017.04545.jkeating@j2solutions.net> Message-ID: <005101c3a5af$fa8dc240$6401a8c0@rohome> Could it "also" be because ReiserFS is heavily supported by SuSE, RH's main competitor? Or am I out of line on that statement? Don't get me wrong I'm an RH (Now Fedora) guy but I've wondered about this matter. I went through the RHCE course and in it they mentioned the ReiserFS as being in development. Well, we all know that ReiserFS is FAR from being in development... it's BEEN out... So I was wondering if someone could objectively answer this questions. I am really not trying to make anyone uncomfortable, just curious. :-) RO -----Original Message----- From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list-admin at redhat.com] On Behalf Of Jesse Keating Sent: Friday, November 07, 2003 10:17 PM To: fedora-devel-list at redhat.com Subject: Re: ReiserFS in Anaconda? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 07 November 2003 17:45, Hugo Cisneiros wrote: > But I always asked... Why not put by default? Lots of people are using > it instead of ext3. Because it's not as heavily tested as ext3 by the RH folks. They don't have confidence in it enough to allow it to be a default installer option. I agree on this as well. - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/rG5A4v2HLvE71NURAoWeAKC6Y4LNfGuZdS1OgZmcIDFPCA5RqgCgxLcM vmyn7G7dG4843pjHjBY6eJc= =uqRx -----END PGP SIGNATURE----- -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list From xose at wanadoo.es Sat Nov 8 04:23:13 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sat, 08 Nov 2003 05:23:13 +0100 Subject: ReiserFS in Anaconda? References: <004601c3a590$73e88dc0$6401a8c0@rohome> <3FAC4AA5.7030800@devin.com.br> <200311072017.04545.jkeating@j2solutions.net> Message-ID: <3FAC6FB1.10500@wanadoo.es> Jesse Keating wrote: > On Friday 07 November 2003 17:45, Hugo Cisneiros wrote: >>But I always asked... Why not put by default? Lots of people are using >>it instead of ext3. > Because it's not as heavily tested as ext3 by the RH folks. They don't > have confidence in it enough to allow it to be a default installer option. > I agree on this as well. me too. *ext3* is the _only_ native fs supported by RH. Neither jfs nor reiserfs are supported, though RH kernel brings them. Why does people want XFS? Any _special_ feature? -- HTML mails are going to trash automagically From mike at netlyncs.com Sat Nov 8 04:34:10 2003 From: mike at netlyncs.com (Mike Chambers) Date: Fri, 07 Nov 2003 22:34:10 -0600 Subject: ReiserFS in Anaconda? In-Reply-To: <005101c3a5af$fa8dc240$6401a8c0@rohome> References: <005101c3a5af$fa8dc240$6401a8c0@rohome> Message-ID: <1068266050.5843.5.camel@bart.netlyncs.com> On Fri, 2003-11-07 at 22:22, Ro wrote: > Could it "also" be because ReiserFS is heavily supported by SuSE, RH's main > competitor? Or am I out of line on that statement? SuSe and whoever else also support sendmail, postfix, http, etc.. but Red Hat still includes them. Point being? :) > Don't get me wrong I'm an > RH (Now Fedora) guy but I've wondered about this matter. I went through the > RHCE course and in it they mentioned the ReiserFS as being in development. > Well, we all know that ReiserFS is FAR from being in development... it's > BEEN out... So I was wondering if someone could objectively answer this > questions. I am really not trying to make anyone uncomfortable, just > curious. :-) It may be out, but doesn't mean it's not stable or stable enough. I believe Red Hat would include anything that helps make their distro(s) a better product, but only as long as it goes through Q/A and passes. And if something major as a database or file system has problems, no reason to include it if your going to have to spend money just to keep trying to fix the problem it creates and not be able to spend money on developing new things or helping improve old things. I'm sure there are better explanations out there, then again maybe I am way off topic on reasoning, so someone can chime in if I'm off base and/or wrong. -- Mike Chambers Madisonville, KY "Do you hear me now?....GOOD!" From jkeating at j2solutions.net Sat Nov 8 04:38:50 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 7 Nov 2003 20:38:50 -0800 Subject: ReiserFS in Anaconda? In-Reply-To: <005101c3a5af$fa8dc240$6401a8c0@rohome> References: <005101c3a5af$fa8dc240$6401a8c0@rohome> Message-ID: <200311072038.50137.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 07 November 2003 20:22, Ro wrote: > Well, we all know that ReiserFS is FAR from being in development... it's > BEEN out... So I was wondering if someone could objectively answer this > questions. I am really not trying to make anyone uncomfortable, just > curious. :-) Actually we don't know that. A lot of work is being done on Reiser4, and little on 3, and the author has stated that he's more concerned with feature sets than stability. Not exactly what I want to hear from my fs developer. Our company gave reiserfs a try a year or 2 back, given it's merits then, and everybody was saying it was stable, blah blah. It led to a lot of our customers losing their data when reiser would puke. We're re-evaulating our file system offerings, and at this point, JFS seems to be in the lead. - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/rHNa4v2HLvE71NURAmShAJ0S/woNUNHJM/Hc+c8DckYcxG20swCgiAWT N+VTgMb8/zsbGux8p5V8Ulw= =fi5Z -----END PGP SIGNATURE----- From paul at gear.dyndns.org Sat Nov 8 05:07:36 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Sat, 08 Nov 2003 15:07:36 +1000 Subject: FC2 release dates [hijacked thread] In-Reply-To: <200311061755.25950.kewley@cns.caltech.edu> References: <1068133330.1455.11.camel@opus> <1068135502.1453.17.camel@opus> <20031106172048.0f31f3f6.pros-n-cons@bak.rr.com> <200311061755.25950.kewley@cns.caltech.edu> Message-ID: <3FAC7A18.2050006@gear.dyndns.org> David Kewley wrote: > ... > Many folks are going to have to change their local release policies and > methodology. It seems a lot of us are in this position, and none of the options are good. > Our choices seem to be: > > * roll out new releases *far* more often than we're used to, based on FC Can't do that - not enough hours in the day already. > * fork over some significant cash e.g. for RHEL licenses (which many can't > afford) Definitely not affordable. Based on the pricing i've seen (here in .au), Solaris, Mac OS X, and NetWare are all cheaper, but none of them thrill me as a good alternative to RHL. For an academic institution, i can get an *unlimited site license* for NetWare for less than the cost of two RHEL ES licenses. It's possible that even Micro$oft licensing would work out cheaper in some scenarios. > * try to make our own distro based on the RHEL srpm's (which feels like > cheating RH, but if it works, it could be a practical solution for us) When they're releasing SRPMS, how can you say you're cheating them? The process is working as designed. > * rely on community security updates (so far, too little concreteness to make > an organization's plans around this!) A variant on this would be to roll your own security updates from the upstream sources and the sources in FC1. > * leave RH and Fedora Unless the community effort to produce a modified RHEL distribution is very successful, i see this as being the best of a bunch of bad alternatives. I'll be looking at Mandrake and possibly SuSE over the Dec-Jan period. If i switch, i'll be switching my home, work, and another .edu where i volunteer over to the new distribution - i simply can't afford the time committment to > This is a *big* decision for a *lot* of folks. Is there a way we could get together and try to make some co-ordinated effort to help RH understand what they've done in alienating the .edu/.org sector? And of course, if that fails, making a co-ordinated effort to help each other by providing a more stable FC or a free RHEL derivative would be a reasonable alternative. BTW, has there been any discussion on backporting RHEL features into FC? Does RH have a policy on this? It seems to me that getting FC to a state where security errata from RHEL could be applied to it would be a reasonable compromise. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jigorou3 at mail.goo.ne.jp Sat Nov 8 05:33:28 2003 From: jigorou3 at mail.goo.ne.jp (jigorou3 at mail.goo.ne.jp) Date: 8 Nov 2003 14:33:28 +0900 Subject: esound.spec has a description thats\\\' out-of-date Message-ID: <20031108053328.69796.qmail@mail.goo.ne.jp> sopwith at redhat.com wrote: > On 8 Nov 2003 jigorou3 at mail.goo.ne.jp wrote: > > > Recent version of Red Hat Linux (and Fedora Core) doesn't have > > /usr/lib/rpm/redhat > > , and esound's build fails in default setting. > > Make sure to install the redhat-rpm-config package. Sorry, I haven't installed that one... And after install, build succeed without problem. Thanks From fedora at rosamour.com Sat Nov 8 06:08:09 2003 From: fedora at rosamour.com (Ro) Date: Sat, 8 Nov 2003 00:08:09 -0600 Subject: ReiserFS in Anaconda? Message-ID: <006901c3a5be$af491f00$6401a8c0@rohome> Well I speak from inexperience, ergo, the reason I am questioning you all. So, my wrap up of this entire thread: I currently have RH 9.0 production Servers and since the Errata will end 'soon' for RH 9.0, I was wondering if moving to Fedora Core 1 would be a smart move. And should I continue with ext3 or perhaps explore other venues.... JFS perhaps. Your input is GREATLY appreciated. Cheers, Ro >>On Friday 07 November 2003 20:22, Ro wrote: >> Well, we all know that ReiserFS is FAR from being in development... >>it's BEEN out... So I was wondering if someone could objectively >>answer this questions. I am really not trying to make anyone >>uncomfortable, just curious. :-) >Actually we don't know that. A lot of work is being done on Reiser4, >and >little on 3, and the author has stated that he's more concerned with >feature sets than stability. Not exactly what I want to hear from my fs >developer. Our company gave reiserfs a try a year or 2 back, given it's >merits then, and everybody was saying it was stable, blah blah. It led to >a lot of our customers losing their data when reiser would puke. We're >re-evaulating our file system offerings, and at this point, JFS seems to >be in the lead. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at phy.duke.edu Sat Nov 8 06:56:44 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 08 Nov 2003 01:56:44 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: <200311080241.hA82fIA18902@devserv.devel.redhat.com> References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> Message-ID: <1068274604.14565.22.camel@binkley> > Do you worry about contributing to gnu-cc ? > > I do understand the point you are trying to make but its GPL code and so > you can either rename it or not worry about it (Red Hat ships gnu-cc, nothing > stops other folks shipping redhat-config-blah really as I understand it). Well I know this sounds silly, but, in the case of yum people use it on non-redhat platforms. I'd actually feel bad telling them 'yah you need this red hat specific library, named rhpl' in order to use it. putting the name of a commercial vendor in the library name is kinda 'blah' anyway. (this, of course coming from the guy who wrote yellowdog updater, modified, so I completely understand the hypocrisy) :) but to be honest most people miss the yellowdog part entirely, for some reason. -sv From ms-nospam-0306 at arcor.de Sat Nov 8 07:08:17 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 08:08:17 +0100 Subject: RPM submission script In-Reply-To: <1068254999.14565.10.camel@binkley> References: <200311080018.hA80IR115216@devserv.devel.redhat.com> <1068254999.14565.10.camel@binkley> Message-ID: <20031108080817.1945c478.ms-nospam-0306@arcor.de> On Fri, 07 Nov 2003 20:30:00 -0500, seth vidal wrote: > On Fri, 2003-11-07 at 19:18, Alan Cox wrote: > > > so mandating utf-8 is great, if you also do it in rpm spec files, and > > > filenames, etc, etc, etc. > > > > Linux filenames are utf-8 and defined that way. Gives the nautilus people > > something to do ;) > > > > and yet if you look at packages from europe you often find file names > that are not. It's sort of a virus, e.g. in Germany. One of the first things the average user does after a distribution upgrade is to edit /etc/sysconfig/i18n and change from UTF-8 to @euro or ISO 8859-1. The reason is that the effects of this change are not understood. It just "seems to work" with old Latin-1 file names, file contents and non-Unicode-aware applications. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ms-nospam-0306 at arcor.de Sat Nov 8 07:17:09 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 08:17:09 +0100 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: References: <1068236427.12684.60.camel@laptop> Message-ID: <20031108081709.0f9c776b.ms-nospam-0306@arcor.de> On Fri, 07 Nov 2003 23:49:39 +0100, Aurelien Bompard wrote: > These guidelines seem fine, thanks for the work. > > However, I have recently bumped into a package naming problem which doesn't > seem to be covered here. It's a program called K3B, a CD/DVD burning > frontend for KDE. > Here is their release numbers : 0.8 -> 0.9 -> 0.10 > How should we set the RPM fields without using epochs in this type of > versionning ? Is is a case where epoch is necessary ? Not a problem at all: 10 > 9 > 8 Btw, find k3b 0.10.2 and k3b i18n 0.10 src.rpms for Red Hat Linux 9 and Fedora Core here: https://bugzilla.fedora.us/show_bug.cgi?id=885 https://bugzilla.fedora.us/show_bug.cgi?id=886 This may look a bit like an advertisement, but as with all the other packages in the http://fedora.us/QA package queue, feedback is always appreciated. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ms-nospam-0306 at arcor.de Sat Nov 8 07:21:35 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 08:21:35 +0100 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: <1068236427.12684.60.camel@laptop> References: <1068236427.12684.60.camel@laptop> Message-ID: <20031108082135.3c09bc70.ms-nospam-0306@arcor.de> On Fri, 07 Nov 2003 10:20:28 -1000, Warren Togami wrote: > B. Version > C. Release Tag > 3. Non-Numeric Version to Release The post-release non-numeric versioning scheme at the bottom of these two section needs to be dropped when it conflicts with Red Hat's scheme (e.g. the perl-DateManip-5.42a example). -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bill at noreboots.com Sat Nov 8 07:57:06 2003 From: bill at noreboots.com (Bill Anderson) Date: 08 Nov 2003 00:57:06 -0700 Subject: ReiserFS in Anaconda? In-Reply-To: <3FAC6FB1.10500@wanadoo.es> References: <004601c3a590$73e88dc0$6401a8c0@rohome> <3FAC4AA5.7030800@devin.com.br> <200311072017.04545.jkeating@j2solutions.net> <3FAC6FB1.10500@wanadoo.es> Message-ID: <1068278226.26232.73.camel@locutus> On Fri, 2003-11-07 at 21:23, Xose Vazquez Perez wrote: > Jesse Keating wrote: > > > On Friday 07 November 2003 17:45, Hugo Cisneiros wrote: > > >>But I always asked... Why not put by default? Lots of people are using > >>it instead of ext3. > > > Because it's not as heavily tested as ext3 by the RH folks. They don't > > have confidence in it enough to allow it to be a default installer option. > > > I agree on this as well. > > me too. > > *ext3* is the _only_ native fs supported by RH. Neither jfs nor reiserfs are > supported, though RH kernel brings them. I coulda swore ext2 was in there too. ;) > Why does people want XFS? Any _special_ feature? A couple years ago I was one of the two Linux testers for HP's VA Fibre Channel enterprise storage product. As such I had to do a lot of reliability testing under such circumstances as someone accidentally pulling the fibre channel cable, the device resetting, etc.. ReiserFS Sucked big arse. Nasty corruption, but that's probably not a suprise to most here. Then to top it off, on my JBOD at home around that same time I had a disk develop some bad sectors. I lost nearly every bit of data on that FS, despite hours and hours of trying to fix it, right down to editing the FS. JFS Was barely reaching 1.0 and would hang the machine when trying to access FC devices. Every time. Ext2/3 Massive failures leading to corruption. It was repeatable and reported, but I don't know what came of it. Last tests we had ext[2,3] had serious problems when the device went away for short periods of time (IIRC, 45 seconds or so, on the nose). XFS The only FS capable of handling the terabyte sized filesystems I was needing to test. Also it handled extended lack of device due to cable swapping better than the rest. Further, the recovery of the filesystem when I would manually corrupt the FS was amazing and far outperformed others. Further, we had less issues with things like shared filesystems over multiple machines (don't ask ...) with XFS than the other (working) FSes. Also, unless things have changed since I last looked (entirely likely), only XFS supported the full ACL stuff via Samba for NT/W2k systems. Now, bear in mind this was back just before 2.4 came out. Things may have changed in the last couple years. ;) -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From maxka at myrealbox.com Sat Nov 8 08:45:26 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Sat, 08 Nov 2003 00:45:26 -0800 Subject: The Fedora Hardware Project In-Reply-To: <20031107222302.A19738@devserv.devel.redhat.com> References: <1068205683.3488.15.camel@max.localdomain> <20031107222302.A19738@devserv.devel.redhat.com> Message-ID: <1068281126.3346.9.camel@max.localdomain> On Fri, 2003-11-07 at 19:23, Bill Nottingham wrote: > Storing brand names is a pain, as there will be 4000 branding variants > of a particular device. I was hoping for people to use the pre-entered ones for their chipset ID, mostly, and making it slightly difficult to enter a new one. I can see your point, there, though. The problem is: Users will want to search for brand names. Are there other resolutions to this issue? Perhaps there's a way to get a canonical sort of brand name out of DMI. > Having a system card URL can lead to privacy concerns. I see the point, here. We'll have to give people the option to make their system private or public, something like MadOnion.com (or whatever it's called now) does with their 3DMark results and the related hardware. > One of the issues you'll have to deal with is only presenting > to the user the 'interesting' hardware. From lspci, at least, we have a "hardware type", like "USB Controller." We'd probably have to keep up, somewhat, on the hardware types, and make sure that we filter what we ask the user about based on that. > In general, the user > isn't going to be able to diagnose efficiently enough to the > hardware tool whether or not their PCI bridge works. On the > other end, when you deal with something like a hard drive, there > are 4000 models, most all of which work exactly the same. I would hope that for things like disk drives, we could just run some basic diagnostics and leave the user alone. > hwbrowser just calls libkudzu; that data is easily available. Thanks. -M From Nicolas.Mailhot at laPoste.net Sat Nov 8 09:14:14 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 08 Nov 2003 10:14:14 +0100 Subject: The Fedora Hardware Project In-Reply-To: <20031107222302.A19738@devserv.devel.redhat.com> References: <1068205683.3488.15.camel@max.localdomain> <20031107222302.A19738@devserv.devel.redhat.com> Message-ID: <1068282854.7520.4.camel@m70.net81-64-235.noos.fr> Le sam 08/11/2003 ? 04:23, Bill Nottingham a ?crit : > Maxwell Kanat-Alexander (maxka at myrealbox.com) said: > > > > > > I expect that to be a very temporary location -- the space may > > disappear any day now. > > > > Let me know if anybody else has any more ideas, now that we've got them > > in a more manageable and organized form. > > Random comments from looking over it for the first time... > > Storing brand names is a pain, as there will be 4000 branding variants > of a particular device. (Video cards are a classic example, there are > 5000 ways to spell out GeForce2). However the pci db people have been doing it for years It's not rocket science : you just print out the entries that have already associated to the id and/or entries for similar hardware and people will choose by themselves something that fits. (you still need someone to manually review stuff however) 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 Axel.Thimm at physik.fu-berlin.de Sat Nov 8 09:33:47 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 8 Nov 2003 10:33:47 +0100 Subject: Final solution: rhfc1 (was: Distags in rpm sort order (yes, versioning again ;)) In-Reply-To: <1068264135.21333.4.camel@cmn30.stanford.edu> References: <20031031065846.GC4184@puariko.nirvana> <20031103103548.GC16946@puariko.nirvana> <20031107105050.GC17587@puariko.nirvana> <1068264135.21333.4.camel@cmn30.stanford.edu> Message-ID: <20031108093347.GC16132@puariko.nirvana> On Fri, Nov 07, 2003 at 08:02:15PM -0800, Fernando Pablo Lopez-Lezcano wrote: > Previously on this thread > > > disttag can be: > > > A B C > > > Red Hat Linux 7.3 fdr0.7.3 rh7.3 rh7.3 > > > Red Hat Linux 8.0 fdr0.8.0 rh8.0 rh8.0 > > > Red Hat Linux 9 fdr0.9 rh9 rh9 > > > Fedora Core 1 fdr1 rh9.1 1fdr > > > Fedora Core 2 test1 fdr1.95 rh9.1.95 1.95fdr > I'm starting to use something similar in Planet CCRMA, I was previously > using: > rh73 -> rh80 -> rh90 > (so I can't really switch to rh7.3/rh8.0/rh9 at this point) > And now I'm rebuilding for FC1 with: > rh73 -> rh80 -> rh90 -> rhfc1 > Seems to work fine. Many 1000 thanks to Fernando. This is the best solution. I forgot that rpm compares segment-wise and that longer stings are "newer". I suggest all repos to use Fernando' suggestion, rhfc1, if they are using rhXX for RHL. Please do use the same disttag for creating a uniform versioning, .e.g. foo-1.2.3-4.rhfc1.at Replace ".at" with your own repotag, none, if you don't want one, or ".fr", ".dag", ".che", ".ccrma", ".rb", ".kde4rh" (just suggestions). Note: the repotag (contrary to the disttag) should not be part of the rpm ordering, which is why it should come last. Thank you Fernando, your brain was needed! This ******* thread was rotting for a month and a half, without anyone (incluing me) using their brains ... -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Sat Nov 8 09:41:04 2003 From: warren at togami.com (Warren Togami) Date: Fri, 07 Nov 2003 23:41:04 -1000 Subject: ftwall build broke FC1 tcp.h (glibc-kernheaders) In-Reply-To: <200311072228.hA7MSiHY008852@magilla.sf.frob.com> References: <200311072228.hA7MSiHY008852@magilla.sf.frob.com> Message-ID: <1068284464.4430.119.camel@laptop> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109474 Filed. On Fri, 2003-11-07 at 12:28, Roland McGrath wrote: > I think those glibc-kernheaders changes are broken. htonl is not a valid > constant expression macro in userland, though it might now be in > kernelland. The userland macro will be optimized away to the constant by > the compiler, but that does not make it a valid constant expression. > > Could you file a report against the FC glibc-kernheaders package on > bugzilla.redhat.com? > > > Thanks, > Roland > > > > > --- tcp.h-rh9 2003-11-06 21:45:40.000000000 -1000 > > +++ tcp.h-fc1 2003-11-06 21:46:08.000000000 -1000 > > @@ -102,16 +102,16 @@ > > #define tcp_flag_word(tp) ( ((union tcp_word_hdr *)(tp))->words [3]) > > > > enum { > > - TCP_FLAG_CWR = __constant_htonl(0x00800000), > > - TCP_FLAG_ECE = __constant_htonl(0x00400000), > > - TCP_FLAG_URG = __constant_htonl(0x00200000), > > - TCP_FLAG_ACK = __constant_htonl(0x00100000), > > - TCP_FLAG_PSH = __constant_htonl(0x00080000), > > - TCP_FLAG_RST = __constant_htonl(0x00040000), > > - TCP_FLAG_SYN = __constant_htonl(0x00020000), > > - TCP_FLAG_FIN = __constant_htonl(0x00010000), > > - TCP_RESERVED_BITS = __constant_htonl(0x0FC00000), > > - TCP_DATA_OFFSET = __constant_htonl(0xF0000000) > > + TCP_FLAG_CWR = htonl(0x00800000), > > + TCP_FLAG_ECE = htonl(0x00400000), > > + TCP_FLAG_URG = htonl(0x00200000), > > + TCP_FLAG_ACK = htonl(0x00100000), > > + TCP_FLAG_PSH = htonl(0x00080000), > > + TCP_FLAG_RST = htonl(0x00040000), > > + TCP_FLAG_SYN = htonl(0x00020000), > > + TCP_FLAG_FIN = htonl(0x00010000), > > + TCP_RESERVED_BITS = htonl(0x0FC00000), > > + TCP_DATA_OFFSET = htonl(0xF0000000) > > }; > > > > /* TCP socket options */ From maxka at myrealbox.com Sat Nov 8 09:42:21 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Sat, 08 Nov 2003 01:42:21 -0800 Subject: The Fedora Hardware Project In-Reply-To: <1068282854.7520.4.camel@m70.net81-64-235.noos.fr> References: <1068205683.3488.15.camel@max.localdomain> <20031107222302.A19738@devserv.devel.redhat.com> <1068282854.7520.4.camel@m70.net81-64-235.noos.fr> Message-ID: <1068284541.3272.1.camel@max.localdomain> On Sat, 2003-11-08 at 01:14, Nicolas Mailhot wrote: > > Storing brand names is a pain, as there will be 4000 branding variants > > of a particular device. (Video cards are a classic example, there are > > 5000 ways to spell out GeForce2). > > However the pci db people have been doing it for years > It's not rocket science : you just print out the entries that have > already associated to the id and/or entries for similar hardware and > people will choose by themselves something that fits. Hrm... seems like that where the brand name comes from should be a configurable data source. For PCI, we could use the pci db, perhaps. For other buses, we could use already-existing projects, or we could make our own. If somebody started a project, we could give them our data and reconfigure our database to pull from theirs. -M From Nicolas.Mailhot at laPoste.net Sat Nov 8 09:48:10 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 08 Nov 2003 10:48:10 +0100 Subject: RPM submission script In-Reply-To: <20031108080817.1945c478.ms-nospam-0306@arcor.de> References: <200311080018.hA80IR115216@devserv.devel.redhat.com> <1068254999.14565.10.camel@binkley> <20031108080817.1945c478.ms-nospam-0306@arcor.de> Message-ID: <1068284890.7520.27.camel@m70.net81-64-235.noos.fr> Le sam 08/11/2003 ? 08:08, Michael Schwendt a ?crit : > On Fri, 07 Nov 2003 20:30:00 -0500, seth vidal wrote: > > > On Fri, 2003-11-07 at 19:18, Alan Cox wrote: > > > > so mandating utf-8 is great, if you also do it in rpm spec files, and > > > > filenames, etc, etc, etc. > > > > > > Linux filenames are utf-8 and defined that way. Gives the nautilus people > > > something to do ;) > > > > > > > and yet if you look at packages from europe you often find file names > > that are not. > > It's sort of a virus, e.g. in Germany. One of the first things the average > user does after a distribution upgrade is to edit /etc/sysconfig/i18n and > change from UTF-8 to @euro or ISO 8859-1. Yeah, sure, sure way to kill the ? symbol. > The reason is that the effects > of this change are not understood. It just "seems to work" with old > Latin-1 file names, file contents and non-Unicode-aware applications. So you provide a stupid shell script that recodes filenames to UTF-8 if the old locale was something else (because you have access to the old locale). And/or a glade app that recodes files in unicode. As for file contents, either they have a sane encoding header and they'll be fine, either they haven't and you're in a lot of trouble anyway (in case you haven't noticed one of Java's top bugs is zip encoding problems - Java uses zip-based formats everywhere but their filename encoding is unspecified so java creates unicode zip filenames, windows cp437/cp850 ones, linux iso8859-1 and now UTF-8 and unzipping stuff can be... interesting) .specs does not specify encodings. People edit them in their default text editor which means the spec file can be in any of the various encodings available, most notably in UTF-8 for all recent setups and people who regularly use something else than base latin characters (and that includes a large part of even western Europe). Current specs are not ASCII already (not that it means anything anyway since few people use 7-bit encodings and there are langages where you need the upper 128 chars regularly). A growing number is in UTF-8, so you can not say "hold on, specs have always been ascii". Plus in the near future specs will have to be UTF-8 over the board, since that will be the default mode of every single text editor available. There is no easy solution. You have to require UTF-8 specs at some point, and treat non-UTF-8 as a (minor) bug. In fact, it's probably high time to do it, ie require all for-FC2 spec files to be converted as they are updated so by the time FC2 is out everything will be nicely UTF-8 (FC1 staying the encoding mess it already is). 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 Axel.Thimm at physik.fu-berlin.de Sat Nov 8 10:21:13 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 8 Nov 2003 11:21:13 +0100 Subject: RPM submission script In-Reply-To: <1068284890.7520.27.camel@m70.net81-64-235.noos.fr> References: <200311080018.hA80IR115216@devserv.devel.redhat.com> <1068254999.14565.10.camel@binkley> <20031108080817.1945c478.ms-nospam-0306@arcor.de> <1068284890.7520.27.camel@m70.net81-64-235.noos.fr> Message-ID: <20031108102113.GE11801@puariko.nirvana> On Sat, Nov 08, 2003 at 10:48:10AM +0100, Nicolas Mailhot wrote: > > It's sort of a virus, e.g. in Germany. One of the first things the average > > user does after a distribution upgrade is to edit /etc/sysconfig/i18n and > > change from UTF-8 to @euro or ISO 8859-1. > > Yeah, sure, sure way to kill the ? symbol. :) That's why they are all running back to UTF-8 nowadays ;) I think people did that upon upgrades (from pre RH8.0 generated filesystems?), because the existing filesystem or perhaps NFS didn't reflect the previous filenames and the introduction of UTF-8 in RH could have documented better how to deal with these issues. IIRC there wasn't any tool shipped with RH releases to migrate ext3 partitions with latin1 filenames to UTF-8. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aoliva at redhat.com Sat Nov 8 10:23:58 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 08 Nov 2003 08:23:58 -0200 Subject: RPM submission script In-Reply-To: <20031107220132.GA17064@thyrsus.com> References: <20031107203937.GC16285@thyrsus.com> <20031107210539.05BD516FC3@jmason.org> <20031107212714.GA16837@thyrsus.com> <20031107220132.GA17064@thyrsus.com> Message-ID: On Nov 7, 2003, "Eric S. Raymond" wrote: > Alexandre Oliva : >> On Nov 7, 2003, "Eric S. Raymond" wrote: >> >> > Well, technically, yes...but not the way people usually mean it (16-bit >> > chars like Java). >> >> That's not UTF-8. That's another representation of Unicode. > Um. Yes. Were you under the impression I had said otherwise? Since you said UTF-8 was not multibyte, I got the impression you were missing something. Now I reread your follow up e-mail and realize I had misunderstood it. Sorry. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From Axel.Thimm at physik.fu-berlin.de Sat Nov 8 10:26:38 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 8 Nov 2003 11:26:38 +0100 Subject: RPM submission script In-Reply-To: <20031108005118.GC17763@thyrsus.com> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> <1068239981.6576.0.camel@opus> <20031107214321.GA16941@thyrsus.com> <1068242075.6576.2.camel@opus> <1068247043.3644.12.camel@m70.net81-64-235.noos.fr> <1068249458.14565.4.camel@binkley> <20031108005118.GC17763@thyrsus.com> Message-ID: <20031108102638.GF11801@puariko.nirvana> On Fri, Nov 07, 2003 at 07:51:18PM -0500, Eric S. Raymond wrote: > seth vidal : > > take the Description field of cups and try to encode it in utf-8. > > > > the (R) next to UNIX is the latin-1 (R) as one byte so you end up having > > to drop the character entirely Unless you provide a mapping, for every > > existent encoding. > > Eh? Did somebody change Unicode so the low 256 chars aren't Latin-1 > while I wasn't looking? At least UTF-8 has only the lower 127 characters common with latin1. All other latin1 characters are multibyte. > > so mandating utf-8 is great, if you also do it in rpm spec files, and > > filenames, etc, etc, etc. > > I think that would actually be a reasonable policy stipulation for Fedora. > But we don't have to settle that argument in order to write fedora-submit. I think these issues are overdiscussed perhaps. Did rpm ever define the encoding of the specfiles? There is (little used) provision for providing i18n descriptions within specfiles. What is the encoding for these? If rpm had defined any encoding, then assume this for iconv and any non-conforming specfile will automatically be detected. If not, then let's define as of now, that rpm specfiles have to be encoded in UTF-8. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Nicolas.Mailhot at laPoste.net Sat Nov 8 10:31:54 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 08 Nov 2003 11:31:54 +0100 Subject: RPM submission script In-Reply-To: <20031108102113.GE11801@puariko.nirvana> References: <200311080018.hA80IR115216@devserv.devel.redhat.com> <1068254999.14565.10.camel@binkley> <20031108080817.1945c478.ms-nospam-0306@arcor.de> <1068284890.7520.27.camel@m70.net81-64-235.noos.fr> <20031108102113.GE11801@puariko.nirvana> Message-ID: <1068287514.8000.3.camel@m70.net81-64-235.noos.fr> Le sam 08/11/2003 ? 11:21, Axel Thimm a ?crit : > On Sat, Nov 08, 2003 at 10:48:10AM +0100, Nicolas Mailhot wrote: > > > It's sort of a virus, e.g. in Germany. One of the first things the average > > > user does after a distribution upgrade is to edit /etc/sysconfig/i18n and > > > change from UTF-8 to @euro or ISO 8859-1. > > > > Yeah, sure, sure way to kill the ? symbol. > > :) That's why they are all running back to UTF-8 nowadays ;) > > I think people did that upon upgrades (from pre RH8.0 generated > filesystems?), because the existing filesystem or perhaps NFS didn't > reflect the previous filenames and the introduction of UTF-8 in RH > could have documented better how to deal with these issues. > > IIRC there wasn't any tool shipped with RH releases to migrate ext3 > partitions with latin1 filenames to UTF-8. Not too difficult to code in shell using recode as backend but I agree with you, it would have helped a lot. Now most people have mixed latin1/UTF-8 filesystem so it's a bit too late for this:( Unicode migration is our 2k bug, and it's not been handled too well till now. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From michael at msdavies.net Sat Nov 8 11:09:54 2003 From: michael at msdavies.net (Michael Davies) Date: Sat, 8 Nov 2003 21:39:54 +1030 (CST) Subject: ReiserFS in Anaconda? In-Reply-To: <20031108093603.14438.97353.Mailman@listman.back-rdu.redhat.com> References: <20031108093603.14438.97353.Mailman@listman.back-rdu.redhat.com> Message-ID: <33076.144.136.187.136.1068289794.squirrel@hutton.sh> > Jesse Keating wrote: > > Why does people want XFS? Any _special_ feature? XFS was developed by SGI a while ago and has been in Irix for a longer _time_ than any of ext2/3 and reiserfs (not sure on jfs. ext2 probably has had more instances ever run, but I digress). This speaks for XFS's rock solid stability. As also mentioned here, terabyte filesystems and proper ACLs are included. Important stuff. I'd be installing XFS be default if anaconda had it. -- Michael Davies Linux.Conf.Au Adelaide Jan 12-17 2004 michael at msdavies dot net Australia's Premier Linux Conference http://lca2004.linux.org.au From Axel.Thimm at physik.fu-berlin.de Sat Nov 8 12:09:54 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 8 Nov 2003 13:09:54 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: References: <1068236427.12684.60.camel@laptop> Message-ID: <20031108120954.GA18487@puariko.nirvana> > On Fri, 7 Nov 2003, Warren Togami wrote: > > I would assert that the alliances of 3rd party repositories that > > have tried to form in the recent past are not sustainable in the > > long term, for the same controversial reasons that fedora.us > > rejected cooperation with those entities earlier this year. I am sorry to hear that you still think you were doing the Right Thing (TM). When Fedora (US) was being formed it attracted many repo maintainers like freshrpms, newrpms, dag and many others including myself. They hoped for a coordination institution within fedora, which should provide o interrepository specifications (note "inter"!!!) o merger proposals o common infrastructure In that sense a lot of input was provided for the versioning scheme. Instead the project was driven towards a competitive repo, refusing to add components that would make the specification more general, because "there could only be one repository". You also managed to create the largest repository compatibility problems ever (I just say epoch: 0), that you were supposedly trying to avoid. Many people left the fedora.us project because of that attitude. If the project had been more open we would be much further today than we are. I am not speaking about or flaming fedora.us' community here, only about the emerged leadership. Most fedora.us packagers have avoided participating in Warren's crusade against other repos. So please drop that attitude. You are damanging fedora.us, fedora.redhat.com and repository intercooperation in general. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at physik.fu-berlin.de Sat Nov 8 12:20:24 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 8 Nov 2003 13:20:24 +0100 Subject: fedora-legacy/Warren agrees to enforce rpm upgrades? In-Reply-To: <20031107164717.GD27327@puariko.nirvana> References: <3FA229D3.4000104@togami.com> <3FA2722D.6090504@togami.com> <20031031180006.1b3cad50.ms-nospam-0306@arcor.de> <1067622953.20763.164.camel@bobcat.mine.nu> <1068204440.12684.29.camel@laptop> <20031107164717.GD27327@puariko.nirvana> Message-ID: <20031108122024.GI11801@puariko.nirvana> On Fri, Nov 07, 2003 at 05:47:17PM +0100, Axel Thimm wrote: > On Fri, Nov 07, 2003 at 01:27:20AM -1000, Warren Togami wrote: > > This however does not matter, since it has been agreed upon on > > fedora-legacy list that ALL distributions supported by Fedora Legacy > > will force an upgrade of rpm as a requirement for users to begin using > > those repositories. > > When was this agreed upon? > [...] so unless we are the only left subscribers of fedora-legacy, > it is not yet an agreement of the whole list. ;) Am I the only one that finds it questionable that assertions like these are simply being made? Even if the whole list and the world agrees postscriptum (which it doesn't), what kind of tacticts are these? There was clearly not a list agreement (set aside if there is need for one), so why present your opinion as the list's? Did I mention that it was agreed upon all fedora-lists to remove glibc from ALL distributions? -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hugo at devin.com.br Sat Nov 8 12:22:42 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Sat, 08 Nov 2003 09:22:42 -0300 Subject: ReiserFS in Anaconda? In-Reply-To: <200311072038.50137.jkeating@j2solutions.net> References: <005101c3a5af$fa8dc240$6401a8c0@rohome> <200311072038.50137.jkeating@j2solutions.net> Message-ID: <3FACE012.2000401@devin.com.br> Jesse Keating wrote: > Actually we don't know that. A lot of work is being done on Reiser4, and > little on 3, and the author has stated that he's more concerned with > feature sets than stability. Not exactly what I want to hear from my fs > developer. Our company gave reiserfs a try a year or 2 back, given it's > merits then, and everybody was saying it was stable, blah blah. It led to > a lot of our customers losing their data when reiser would puke. We're > re-evaulating our file system offerings, and at this point, JFS seems to > be in the lead. Now I know why. I just didn't know because ther were always rumours here that the reiserfs is not stable enough, etc. But in practise, I use reiserfs a lot on many systems and it never had problems... So I assumed that the unstable thing was only rumours (because you know, ext3 is the "standard", so everyone uses it.) Now I see some real troube with ReiserFS for the first time. By the way, I think we should test and test it again, to see if can include to choose in the installation without telling the lilo prompt the argument "reiserfs". It'll be no "default" file system, but another file system for users to test. []'s Hugo From Axel.Thimm at physik.fu-berlin.de Sat Nov 8 12:26:16 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 8 Nov 2003 13:26:16 +0100 Subject: Best solution for disttags In-Reply-To: <20031108093347.GC16132@puariko.nirvana> References: <20031031065846.GC4184@puariko.nirvana> <20031103103548.GC16946@puariko.nirvana> <20031107105050.GC17587@puariko.nirvana> <1068264135.21333.4.camel@cmn30.stanford.edu> <20031108093347.GC16132@puariko.nirvana> Message-ID: <20031108122616.GJ11801@puariko.nirvana> Dear all, It was mentioned to me and I just verified that "final solution" is a reserved translated term for Nazi jargon at the end of the second world war ("Endl?sung"). There was no intention for any association with it, please change the subject if you want to reply to the previous mail. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hugo at devin.com.br Sat Nov 8 12:30:07 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Sat, 08 Nov 2003 09:30:07 -0300 Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068274604.14565.22.camel@binkley> References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068274604.14565.22.camel@binkley> Message-ID: <3FACE1CF.4070203@devin.com.br> seth vidal wrote: >>Do you worry about contributing to gnu-cc ? >> >>I do understand the point you are trying to make but its GPL code and so >>you can either rename it or not worry about it (Red Hat ships gnu-cc, nothing >>stops other folks shipping redhat-config-blah really as I understand it). > > Well I know this sounds silly, but, in the case of yum people use it on > non-redhat platforms. I'd actually feel bad telling them 'yah you need > this red hat specific library, named rhpl' in order to use it. > > putting the name of a commercial vendor in the library name is kinda > 'blah' anyway. > > (this, of course coming from the guy who wrote yellowdog updater, > modified, so I completely understand the hypocrisy) :) > but to be honest most people miss the yellowdog part entirely, for some > reason. I don't think this point is silly, naming something is an important issue ;) There are lots of Linux distributions, imagine that every distribution will begin to write programs and name them distro-program... Not good. Mainly because everyone will try to create their versions of the program (they are GPL'ed for example, so it's easy), and in some time, there will be many programs that do the same thing, but with different names. Or worse, the distributions will not use the applications because they're from specific vendors... This sucks. Linux is a community, creating the programs and giving them generic names will attract every distribution to take the program, analyze it, do some modifications if needed (good feedback to the author) and implement in their distribution. This is the way to go IMHO. > -sv []'s Hugo From david at fubar.dk Sat Nov 8 12:35:37 2003 From: david at fubar.dk (David Zeuthen) Date: Sat, 8 Nov 2003 13:35:37 +0100 (CET) Subject: The Fedora Hardware Project In-Reply-To: <20031107222302.A19738@devserv.devel.redhat.com> References: <1068205683.3488.15.camel@max.localdomain> <20031107222302.A19738@devserv.devel.redhat.com> Message-ID: <24134.80.62.54.30.1068294937.squirrel@fubar.dk> Bill Nottingham said: > Storing brand names is a pain, as there will be 4000 branding variants > of a particular device. (Video cards are a classic example, there are > 5000 ways to spell out GeForce2). When you have large amounts of > user data like this, you'll need a good way to go through and > verify all the submissions for typos, variations in spelling, > variations in wording, etc. Otherwise the list can become > unmanageable. Note that PCI has the concept of both (vendor_id, product_id) and (subsystem_vendor_id, subsystem_product_id). Now, for instance, all videocards with GeForce 2 MX chipsets will (as I understand it) report the same (vendor_id, product_id); the integrator, e.g. the name that is on the shrink-wrapped box, will set only the subsystem* parameters. It doesn't appear that USB supports this concept unfortunatly. The pci.ids and usb.ids database will help you map the *_id numbers to names. Cheers, David From Nicolas.Mailhot at laPoste.net Sat Nov 8 12:42:47 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 08 Nov 2003 13:42:47 +0100 Subject: The Fedora Hardware Project In-Reply-To: <24134.80.62.54.30.1068294937.squirrel@fubar.dk> References: <1068205683.3488.15.camel@max.localdomain> <20031107222302.A19738@devserv.devel.redhat.com> <24134.80.62.54.30.1068294937.squirrel@fubar.dk> Message-ID: <1068295367.3568.0.camel@m70.net81-64-235.noos.fr> Le sam 08/11/2003 ? 13:35, David Zeuthen a ?crit : > It doesn't appear that USB supports this concept unfortunatly. > > The pci.ids and usb.ids database will help you map the *_id numbers > to names. usb returns cleartext vendor/product - so it's better out of the box than pci. -- 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 dfarning at sbcglobal.net Sat Nov 8 12:52:06 2003 From: dfarning at sbcglobal.net (David Farning) Date: Sat, 08 Nov 2003 06:52:06 -0600 Subject: TradeMarked Name --redhat-config- In-Reply-To: <200311080241.hA82fIA18902@devserv.devel.redhat.com> References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> Message-ID: <1068295925.2545.17.camel@localhost.localdomain> On Fri, 2003-11-07 at 20:41, Alan Cox wrote: > Do you worry about contributing to gnu-cc ? > > I do understand the point you are trying to make but its GPL code and so > you can either rename it or not worry about it (Red Hat ships gnu-cc, nothing > stops other folks shipping redhat-config-blah really as I understand it). > > You'd want different artwork of course. I wonder what state GUN/Linux would be in if it was redhat-cc ;) Early on in my thinking, I looked at putting a paralle project called gupta (Grand Unified Packaging Tool) at sorceforge . Just pull off the trademarks and repackage. But, wouldn't that that just contribute to FUD. Same product two names, two locations, two appearances. I be honest--I think that the fedora/redhat effort can be a win-win for everyone involved. I'm just concerned that if the redhat side of the house starts to push it's fedora developers too hard, (the community ones at least) they'll jump ship. Then we will have a lose-lose. Dave Farning From dag at wieers.com Sat Nov 8 12:53:27 2003 From: dag at wieers.com (Dag Wieers) Date: Sat, 8 Nov 2003 13:53:27 +0100 (CET) Subject: Best solution: rhfc1 (was: Distags in rpm sort order (yes, versioning again ;)) In-Reply-To: <20031108093347.GC16132@puariko.nirvana> Message-ID: On Sat, 8 Nov 2003, Axel Thimm wrote: > On Fri, Nov 07, 2003 at 08:02:15PM -0800, Fernando Pablo Lopez-Lezcano wrote: > > Previously on this thread > > > > disttag can be: > > > > A B C > > > > Red Hat Linux 7.3 fdr0.7.3 rh7.3 rh7.3 > > > > Red Hat Linux 8.0 fdr0.8.0 rh8.0 rh8.0 > > > > Red Hat Linux 9 fdr0.9 rh9 rh9 > > > > Fedora Core 1 fdr1 rh9.1 1fdr > > > > Fedora Core 2 test1 fdr1.95 rh9.1.95 1.95fdr > > > I'm starting to use something similar in Planet CCRMA, I was previously > > using: > > rh73 -> rh80 -> rh90 > > (so I can't really switch to rh7.3/rh8.0/rh9 at this point) > > And now I'm rebuilding for FC1 with: > > rh73 -> rh80 -> rh90 -> rhfc1 > > Seems to work fine. > > Many 1000 thanks to Fernando. This is the best solution. I forgot that > rpm compares segment-wise and that longer stings are "newer". Hurray! > I suggest all repos to use Fernando' suggestion, rhfc1, if they are > using rhXX for RHL. Please do use the same disttag for creating a > uniform versioning, .e.g. > > foo-1.2.3-4.rhfc1.at > > Replace ".at" with your own repotag, none, if you don't want one, or > ".fr", ".dag", ".che", ".ccrma", ".rb", ".kde4rh" (just suggestions). > Note: the repotag (contrary to the disttag) should not be part of the > rpm ordering, which is why it should come last. I never intended to use the disttag as part of the EVR comparison. But I'm sure going to adapt DAR to work with the new scheme and use it by default. It does make more sense to have the repotag at the end of the release. Is there already a different repotag decided for fedora, fedora extras en/or fedora legacy ? Or is there no real gain to differentiate ? Thanks Axel for making this a priority. It should have been decided more in advance, because taking corrective actions is always a waste of valuable time. I for one am glad to have delayed building for Fedora Core. I already use the disttag 'rhel3' in the same manner. Is there already a standard for the apt/yum -directory structure ? It would be nice to have a single syntax that repositories could move to. I like rhel3: redhat/el3/i386 rhfc1: redhat/fc1/i386 in the same line as rh80: redhat/8.0/i386 rh90: redhat/9/i386 Future versions would then become: rhel3.1: redhat/el3.1/i386 rhfc1.2: redhat/fc1.2/i386 Could this subject be added to the naming convention proposal, together with the disttag ? -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From kmaraas at broadpark.no Sat Nov 8 13:40:14 2003 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sat, 08 Nov 2003 14:40:14 +0100 Subject: FC2 release dates In-Reply-To: <1068166072.10735.16.camel@binkley> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> Message-ID: <1068216523.4326.2.camel@localhost.localdomain> fre, 07.11.2003 kl. 01.47 skrev seth vidal: > > That's four weeks between all but test3 and final which is a slightly > > shorter one. Hopefully, having rawhide continually installable will > > help get installer feedback sooner and allow people to test fixes much > > sooner. Also, being able to do graphical installs via FTP or HTTP > > should be a nice help here as well. > > umm continually installable rawhide. hehe. > > /me holds his breath. :) > > > > > Because people are already asking for 2.6 stuff now and test releases > > aren't the same as an actual release. That's basically the fastest > > timeline I can come up with that I think can be hit and still have > > something that's robust. > > hmm Makes a crunch for gnome 2.6 then. Looks like it will just miss it > on that schedule. Maybe I'll talk to luis and see if there are plans for > a 2.4.X release to fix misc bugs. There is a 2.4.1 release out or staging at the moment, and I think I'll get a 2.4.2 release out too even, if there's a sufficient amount of bugfixes in the near future. Cheers Kjartan The stable GNOME release team :) From gauret at free.fr Sat Nov 8 14:16:22 2003 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 08 Nov 2003 15:16:22 +0100 Subject: Warren's Package Naming Proposal - Revision 2 References: <1068236427.12684.60.camel@laptop> <200311071459.54580.jkeating@j2solutions.net> <20031107223129.C19738@devserv.devel.redhat.com> Message-ID: > Yes, rpm should handle that fine. It's not done as a float comparison. Ok. On K3B's website, the developpers advise RPM packagers to use Epochs to ensure that 0.10 will actually be considered higher as 0.9. Thanks. Aurelien -- http://gauret.free.fr ~~~~~~~~~~~~~~~~~~~~~ "Software is like sex : it's better when it's Free." -- Linus Torvalds From milan.kerslager at pslib.cz Sat Nov 8 11:49:49 2003 From: milan.kerslager at pslib.cz (Milan Kerslager) Date: Sat, 8 Nov 2003 12:49:49 +0100 Subject: ReiserFS in Anaconda? In-Reply-To: <005101c3a5af$fa8dc240$6401a8c0@rohome> References: <200311072017.04545.jkeating@j2solutions.net> <005101c3a5af$fa8dc240$6401a8c0@rohome> Message-ID: <20031108114949.GB17084@pluto.pslib.cz> On Fri, Nov 07, 2003 at 10:22:53PM -0600, Ro wrote: > Could it "also" be because ReiserFS is heavily supported by SuSE, RH's main > competitor? Or am I out of line on that statement? Don't get me wrong I'm an No. ReiserFS always chage its binary representation on disk. ReiserFS always miss rock-stable quota, fsck and conversion tools. So supporting ReiserFS could be a pain for RH. Thus - no ReiserFS by default. > RH (Now Fedora) guy but I've wondered about this matter. I went through the > RHCE course and in it they mentioned the ReiserFS as being in development. > Well, we all know that ReiserFS is FAR from being in development... it's > BEEN out... Be out and be stable is two different things. When author says "it's stable" it is not the same like 1.000.000 peoples (testers) says "it's stable". I underestand what Hans Reiser wish but I need more than his wishes. > So I was wondering if someone could objectively answer this > questions. I am really not trying to make anyone uncomfortable, just > curious. :-) -- Milan Kerslager E-mail: milan.kerslager at pslib.cz WWW: http://www.pslib.cz/~kerslage/ From ms-nospam-0306 at arcor.de Sat Nov 8 14:48:28 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 15:48:28 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <20031108120954.GA18487@puariko.nirvana> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> Message-ID: <20031108154828.4084d33f.ms-nospam-0306@arcor.de> On Sat, 8 Nov 2003 13:09:54 +0100, Axel Thimm wrote: > > On Fri, 7 Nov 2003, Warren Togami wrote: > > > I would assert that the alliances of 3rd party repositories that > > > have tried to form in the recent past are not sustainable in the > > > long term, for the same controversial reasons that fedora.us > > > rejected cooperation with those entities earlier this year. > > I am sorry to hear that you still think you were doing the Right > Thing (TM). > > When Fedora (US) was being formed it attracted many repo maintainers > like freshrpms, newrpms, dag and many others including myself. They > hoped for a coordination institution within fedora, which should > provide > > o interrepository specifications (note "inter"!!!) > o merger proposals > o common infrastructure > > In that sense a lot of input was provided for the versioning scheme. > > Instead the project was driven towards a competitive repo, refusing to > add components that would make the specification more general, because > "there could only be one repository". You also managed to create the > largest repository compatibility problems ever (I just say epoch: 0), > that you were supposedly trying to avoid. While I'd like to stay out of this, because I've not been part of the pre-fedora.us discussions, I skimmed over the list archives when I subscribed to the list. May not count much, but it was -- and still is -- my impression that the maintainers of existing repos were not willing to compromise. That made it really difficult for fedora.us to start. > Many people left the fedora.us project because of that attitude. If > the project had been more open we would be much further today than we > are. I find it very unfortunate to see that a lot of work is still duplicated. If someone asked me whether I could explain why there are still several independent repo maintainers who do their own rather closed thing, I would admit that I don't know. Fedora.us provides the infrastructure for collaborated packaging efforts. Still, the reason why some repo maintainers don't team up, is not the "explicit Epoch" or the package release versioning scheme. It's the refusal to adhere to Fedora.us package submission and QA policies, because it's easier to pipe out a new binary package instead of depending on other people to review the src.rpm, and possibly having to fix broken build requirements or unclean spec files before a package would be approved. It would be really helpful if you, Axel, (or Dag or Matthias) would create a complete list of points you dislike about current Fedora.us policies. That would be interesting to understand what will be necessary to get you to contribute to the Fedora Project rather than keeping alive your independent repositories. > I am not speaking about or flaming fedora.us' community here, only > about the emerged leadership. Most fedora.us packagers have avoided > participating in Warren's crusade against other repos. "Crusade" is the wrong term, IMO. Fedora.us started as a vision. A vision to serve the Red Hat Community with add-on packages from a single repository which would make it easy for users to find additional software. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From heinlein at madboa.com Sat Nov 8 14:48:19 2003 From: heinlein at madboa.com (Paul Heinlein) Date: Sat, 8 Nov 2003 06:48:19 -0800 (PST) Subject: FC2 release dates In-Reply-To: <1068257750.7225.4.camel@edoras.local.net> References: <1068257750.7225.4.camel@edoras.local.net> Message-ID: On Fri, 7 Nov 2003, Jeremy Katz wrote: > Optional kernels are a losing proposition. Aye! I've not used 2.6 in any significant way, but recently I installed a minimal Debian stable on a machine at home, with plans to immediate report my sources.list at testing trees and do a fuller install. Debian stable, of course, still ships with 2.2.old, and the installer decided to use the rtl8139 modules for my NIC. It worked fine. Then I upgraded to a 2.4 kernel. Whoops, rtl8139 was nowhere to be found. It didn't take me too long to locate and load the newer 8139too module, but I pretty much knew what I was doing. Had I not, it would have been ugly. Again, I don't know if that sort of thing is an issue in a 2.4 -> 2.6 migration, since I haven't really done much with 2.6, but my hunch is that it's just a problem waiting to happen. --Paul Heinlein From tony at tgds.net Sat Nov 8 15:09:51 2003 From: tony at tgds.net (tony) Date: Sat, 08 Nov 2003 16:09:51 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <20031108154828.4084d33f.ms-nospam-0306@arcor.de> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> Message-ID: <1068304191.6375.14.camel@localhost.localdomain> Le sam 08/11/2003 ? 15:48, Michael Schwendt a ?crit : > "Crusade" is the wrong term, IMO. Fedora.us started as a vision. A vision > to serve the Red Hat Community with add-on packages from a single > repository which would make it easy for users to find additional software. Now that Fedora is also a Redhat repository does this mean that mp3, xine with decss, mplayer etc. etc. will be found there too? I think that we will still need to go elsewhere to get the rpms that put the finishing touch on any modern multimedia desktop OS. Cheers Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From windi at myrealbox.com Sat Nov 8 15:31:09 2003 From: windi at myrealbox.com (Stephan Windischmann) Date: Sat, 08 Nov 2003 16:31:09 +0100 Subject: ReiserFS in Anaconda? In-Reply-To: <3FAC6FB1.10500@wanadoo.es> References: <004601c3a590$73e88dc0$6401a8c0@rohome> <3FAC4AA5.7030800@devin.com.br> <200311072017.04545.jkeating@j2solutions.net> <3FAC6FB1.10500@wanadoo.es> Message-ID: <1068305469.2768.0.camel@homer.home> On Sat, 2003-11-08 at 05:23, Xose Vazquez Perez wrote: > Why does people want XFS? Any _special_ feature? Apart from what has already been said, XFS also has slightly better performance. -windi From windi at myrealbox.com Sat Nov 8 15:44:05 2003 From: windi at myrealbox.com (Stephan Windischmann) Date: Sat, 08 Nov 2003 16:44:05 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <1068304191.6375.14.camel@localhost.localdomain> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> Message-ID: <1068306245.2783.6.camel@homer.home> On Sat, 2003-11-08 at 16:09, tony wrote: > Now that Fedora is also a Redhat repository does this mean that mp3, > xine with decss, mplayer etc. etc. will be found there too? I think that > we will still need to go elsewhere to get the rpms that put the > finishing touch on any modern multimedia desktop OS. For now, we'll probably have to get the *-mp3, mplayer, anything with decss, and other mutlimedia packages from seperate repositories because of copyright and patent issues. While this is an inconvenience, I understand this, because I don't want the Fedora project to have to bother around with lawsuits regarding them. -windi From skvidal at phy.duke.edu Sat Nov 8 15:50:00 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 08 Nov 2003 10:50:00 -0500 Subject: FC2 release dates In-Reply-To: <1068216523.4326.2.camel@localhost.localdomain> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> <1068216523.4326.2.camel@localhost.localdomain> Message-ID: <1068306599.14565.26.camel@binkley> > There is a 2.4.1 release out or staging at the moment, and I think I'll > get a 2.4.2 release out too even, if there's a sufficient amount of > bugfixes in the near future. what things have been fixed, and how do you think it compares to the 2.6 devel at the moment? what things are slated to be in 2.6 over and above 2.4? -sv From ms-nospam-0306 at arcor.de Sat Nov 8 15:57:04 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 16:57:04 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <1068304191.6375.14.camel@localhost.localdomain> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> Message-ID: <20031108165704.31b158ab.ms-nospam-0306@arcor.de> On Sat, 08 Nov 2003 16:09:51 +0100, tony wrote: > Le sam 08/11/2003 ? 15:48, Michael Schwendt a ?crit : > > > "Crusade" is the wrong term, IMO. Fedora.us started as a vision. A vision > > to serve the Red Hat Community with add-on packages from a single > > repository which would make it easy for users to find additional software. > > Now that Fedora is also a Redhat repository does this mean that mp3, > xine with decss, mplayer etc. etc. will be found there too? I think that > we will still need to go elsewhere to get the rpms that put the > finishing touch on any modern multimedia desktop OS. Software with licensing and patenting issues is an exception, of course, due to legal requirements of the Fedora Project. Such software was removed from fedora.us and has been taken over by the people at rpm.livna.org who aim at staying fully compatible with fedora.us and who are working on setting up separate infrastructure, such as a bugzilla system and build server. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmatilai at welho.com Sat Nov 8 15:59:31 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Sat, 8 Nov 2003 17:59:31 +0200 (EET) Subject: Warren' rejection of cooperation with other repos In-Reply-To: <20031108120954.GA18487@puariko.nirvana> Message-ID: On Sat, 8 Nov 2003, Axel Thimm wrote: > > On Fri, 7 Nov 2003, Warren Togami wrote: > > > I would assert that the alliances of 3rd party repositories that > > > have tried to form in the recent past are not sustainable in the > > > long term, for the same controversial reasons that fedora.us > > > rejected cooperation with those entities earlier this year. > > I am sorry to hear that you still think you were doing the Right > Thing (TM). > > When Fedora (US) was being formed it attracted many repo maintainers > like freshrpms, newrpms, dag and many others including myself. They > hoped for a coordination institution within fedora, which should > provide > > o interrepository specifications (note "inter"!!!) Oh but that was NEVER the idea behind fedora.us. The idea was to create a repository run by community of packagers, not a community of repositories run by individuals. Why do you need 1000 different repositories if you can stick the packages into one? > o merger proposals > o common infrastructure Merger was always up to the individual packagers with their repositories to submit their packages to fedora.us QA, using the common infrastructure provided by fedora.us. Some did, others didn't. As to why, I can only agree with Michael: people didn't/don't want to change the way they do things, have their packages go through rigorous (and slow) QA etc. I find it kinda funny that people who refuse to co-operate within policies and specifications created by the fedora.us community complain about fedora.us not co-operating with them :-/ - Panu - From jcsitte at staticnull.org Sat Nov 8 15:58:20 2003 From: jcsitte at staticnull.org (Jonathan C. Sitte) Date: Sat, 08 Nov 2003 10:58:20 -0500 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <20031108165704.31b158ab.ms-nospam-0306@arcor.de> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> Message-ID: <3FAD129C.4010108@staticnull.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: | Such software was removed from fedora.us and has been taken over by the | people at rpm.livna.org who aim at staying fully compatible with fedora.us | and who are working on setting up separate infrastructure, such as a | bugzilla system and build server. Is the livna peoples rpm scheme fixed now? - -- Jonathan C. Sitte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/rRKcA60L5My8BKQRAit6AJ9WRT+SrpJgzjVDIzonMnn+SdwddQCfTrDg wNj3WnJ1HyynJ9NuLLo9SaY= =AnyP -----END PGP SIGNATURE----- From nhruby at uga.edu Sat Nov 8 15:59:43 2003 From: nhruby at uga.edu (nathan r. hruby) Date: Sat, 8 Nov 2003 10:59:43 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068274604.14565.22.camel@binkley> References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068274604.14565.22.camel@binkley> Message-ID: On Sat, 8 Nov 2003, seth vidal wrote: > (this, of course coming from the guy who wrote yellowdog updater, > modified, so I completely understand the hypocrisy) :) > but to be honest most people miss the yellowdog part entirely, for some > reason. > yup! -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From bfox at redhat.com Sat Nov 8 16:09:56 2003 From: bfox at redhat.com (Brent Fox) Date: Sat, 8 Nov 2003 11:09:56 -0500 Subject: Trademarked Name? --redhar-config-* In-Reply-To: <1068200262.2280.25.camel@localhost.localdomain> References: <1068200262.2280.25.camel@localhost.localdomain> Message-ID: <20031108160956.GB30262@redhat.com> On Fri, Nov 07, 2003 at 04:17:43AM -0600, David Farning wrote: > I have been working or the past several weeks on a visual gui front end > for yum I am considering bring that knowledge with me to work on the > fedora project. > But, Frankly, I am concerned about contributing to a program with a > trademarked name. I am interested in giving back to the entire > gnu/linux community not just the redhat community. > If someone likes my product, I would like them to be able to freely > use my work irregardless of their distro/flavor. > With this in mind what are your suggestions? > > a. Go ahead and work on redhat-config-* > b. Seek renaming of redhat-config-* to something vendor neutral > c. Put my work in an up stream project and let it trickle down. This is probably better discussed on fedora-config-list because it affects everyone working on config tools. I want to continue this discussion, so please send this message there. Cheers, Brent From tony at tgds.net Sat Nov 8 16:19:12 2003 From: tony at tgds.net (tony) Date: Sat, 08 Nov 2003 17:19:12 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <3FAD129C.4010108@staticnull.org> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> <3FAD129C.4010108@staticnull.org> Message-ID: <1068308351.6375.28.camel@localhost.localdomain> Le sam 08/11/2003 ? 16:58, Jonathan C. Sitte a ?crit : > | Such software was removed from fedora.us and has been taken over by the > | people at rpm.livna.org who aim at staying fully compatible with fedora.us > | and who are working on setting up separate infrastructure, such as a > | bugzilla system and build server. > > Is the livna peoples rpm scheme fixed now? I installed Xine, ogle and tried mplayer a couple of days ago with yum. Xine and ogle had a couple of missing libraries that I had to go get elsewhere and mplayer went into dependency loop hell and refused to install. I came away not very impressed. Cheers Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From dag at wieers.com Sat Nov 8 16:33:41 2003 From: dag at wieers.com (Dag Wieers) Date: Sat, 8 Nov 2003 17:33:41 +0100 (CET) Subject: Warren' rejection of cooperation with other repos In-Reply-To: Message-ID: On Sat, 8 Nov 2003, Panu Matilainen wrote: > I find it kinda funny that people who refuse to co-operate within policies > and specifications created by the fedora.us community complain about > fedora.us not co-operating with them :-/ Most packagers were fed up even before decent policies and specifications existed. Even before there was a common infrastructure or Fedora had any packages committed. Whereas most 3rd party packagers already had more packages then Fedora currently. This was a very different situation. How those policies and specifications were made and the atitude of those in charge towards existing repositories explain why a lot (most?) of packagers left frustrated. And of course the fact that some of these specifications made it impossible to be compatible didn't do any good either. I don't really understand how the project on one hand hopes/begs existing packagers to submit their packages and on the other hand treats them arrogantly and ignores their advice. I also don't understand why the current negative critism towards the 3rd party packagers will get us any closer and I was a bit of surprised that Warren had to bring that up _again_. I can only hope Red Hat's involvement can change the atmosphere a bit. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From Nicolas.Mailhot at laPoste.net Sat Nov 8 16:45:05 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 08 Nov 2003 17:45:05 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: References: Message-ID: <1068309905.8252.18.camel@m70.net81-64-235.noos.fr> Le sam 08/11/2003 ? 16:59, Panu Matilainen a ?crit : > On Sat, 8 Nov 2003, Axel Thimm wrote: > > > > On Fri, 7 Nov 2003, Warren Togami wrote: > > > > I would assert that the alliances of 3rd party repositories that > > > > have tried to form in the recent past are not sustainable in the > > > > long term, for the same controversial reasons that fedora.us > > > > rejected cooperation with those entities earlier this year. > > > > I am sorry to hear that you still think you were doing the Right > > Thing (TM). > > > > When Fedora (US) was being formed it attracted many repo maintainers > > like freshrpms, newrpms, dag and many others including myself. They > > hoped for a coordination institution within fedora, which should > > provide > > > > o interrepository specifications (note "inter"!!!) > > Oh but that was NEVER the idea behind fedora.us. The idea was to create a > repository run by community of packagers, not a community of repositories > run by individuals. Why do you need 1000 different repositories if you can > stick the packages into one? An individual can have his own repo as a staging/testing area (a lot of RH maintainers work like this), and there are repositories that will *never* merge with fedora because they target more than one distribution (ximian, jpackage...). Plus you can have several distros feeding from a same core repository (I certainly hope aurora and yellowdog will use fedora as source too) Ah, and there are licensing issues too... Even the kernel uses a multi-tree setup, and it's a *lot* more focused than your average distribution. So if you want an healthy ecosystem you need to recognise you're not alone. Never will be. I don't give a damn about splendid isolation. I want to be able to try Mdk bits, share stuff with RHEL, use experimental rpms, etc If I thought otherwise I'd be using Debian 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 pmatilai at welho.com Sat Nov 8 16:53:18 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Sat, 8 Nov 2003 18:53:18 +0200 (EET) Subject: Warren' rejection of cooperation with other repos In-Reply-To: Message-ID: On Sat, 8 Nov 2003, Dag Wieers wrote: > On Sat, 8 Nov 2003, Panu Matilainen wrote: > > > I find it kinda funny that people who refuse to co-operate within policies > > and specifications created by the fedora.us community complain about > > fedora.us not co-operating with them :-/ > > Most packagers were fed up even before decent policies and specifications > existed. Even before there was a common infrastructure or Fedora had any > packages committed. Whereas most 3rd party packagers already had more > packages then Fedora currently. This was a very different situation. > > How those policies and specifications were made and the atitude of those > in charge towards existing repositories explain why a lot (most?) of > packagers left frustrated. And of course the fact that some of these > specifications made it impossible to be compatible didn't do any good > either. Oh well, I'm speaking as someone who didn't have a repository of my own and didn't want to create one so there was no change and thus no pain. I think I do understand the pain involved for existing repositories and yes, there certainly was some rough rides in early fedora.us discussions. > > I don't really understand how the project on one hand hopes/begs existing > packagers to submit their packages and on the other hand treats them > arrogantly and ignores their advice. > I also don't understand why the current negative critism towards the 3rd > party packagers will get us any closer and I was a bit of surprised that > Warren had to bring that up _again_. > > I can only hope Red Hat's involvement can change the atmosphere a bit. Oh I sure hope the new Fedora project will bring peace and love to all as well, hostility wont get us anywhere. - Panu - From jkeating at j2solutions.net Sat Nov 8 16:53:29 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 8 Nov 2003 08:53:29 -0800 Subject: Final solution: rhfc1 (was: Distags in rpm sort order (yes, versioning again ;)) In-Reply-To: <20031108093347.GC16132@puariko.nirvana> References: <20031031065846.GC4184@puariko.nirvana> <1068264135.21333.4.camel@cmn30.stanford.edu> <20031108093347.GC16132@puariko.nirvana> Message-ID: <200311080853.30687.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 08 November 2003 01:33, Axel Thimm wrote: > Many 1000 thanks to Fernando. This is the best solution. I forgot that > rpm compares segment-wise and that longer stings are "newer". > > I suggest all repos to use Fernando' suggestion, rhfc1, if they are > using rhXX for RHL. Please do use the same disttag for creating a > uniform versioning, .e.g. > > foo-1.2.3-4.rhfc1.at > > Replace ".at" with your own repotag, none, if you don't want one, or > ".fr", ".dag", ".che", ".ccrma", ".rb", ".kde4rh" (just suggestions). > Note: the repotag (contrary to the disttag) should not be part of the > rpm ordering, which is why it should come last. > > Thank you Fernando, your brain was needed! This ******* thread was > rotting for a month and a half, without anyone (incluing me) using > their brains ... Why toss more text into there? Is it _really_ needed? Is not "1.at" rpm newer than "0.9.at" and newer than "rhl9.at" ? WHy are we continuing to put text where it really doesn't belong? What's wrong with Warren's proposal that you feel it necessary to use something different? - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/rR+J4v2HLvE71NURAgMZAJ9J4BW7OQPOez7NhX2/gGNRjrK/IQCcDQOZ 5bdeCeT81OPrv3nEqF8V/e8= =eTcF -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Sat Nov 8 16:59:23 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 17:59:23 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <3FAD129C.4010108@staticnull.org> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> <3FAD129C.4010108@staticnull.org> Message-ID: <20031108175923.4cb12de0.ms-nospam-0306@arcor.de> On Sat, 08 Nov 2003 10:58:20 -0500, Jonathan C. Sitte wrote: > Is the livna peoples rpm scheme fixed now? Seems so. At least the package release postfix looks sane: 0.lvn.%{release}.%{disttag} That's fedora.us style with "fdr" replaced with "lvn". -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Sat Nov 8 16:59:38 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 8 Nov 2003 08:59:38 -0800 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <20031108120954.GA18487@puariko.nirvana> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> Message-ID: <200311080859.39887.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 08 November 2003 04:09, Axel Thimm wrote: > I am sorry to hear that you still think you were doing the Right > Thing (TM). > > When Fedora (US) was being formed it attracted many repo maintainers > like freshrpms, newrpms, dag and many others including myself. They > hoped for a coordination institution within fedora, which should > provide So it would seem that you're going to discount Warren's package naming scheme, mearly because there is bad blood between him and some other package repots? Great... thats nice. Perhaps the rest of us should adopt Warren's proposal, and let the chips fall where they may... sound familiar? What happened last time? Individual repots that didn't work worth a crap with eachother, leading to confused and helpless end users. Perfect way to support a project... For cripes sake, drop the political crap and bad blood, review his proposal and make some decent feedback on it instead of bickering about the past. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/rSD64v2HLvE71NURAsaJAKDBYSj7nas4Z0Z67I+SK5cmdq1n1gCfZ+av HlPURNzuw1QTetrApGE2Uv4= =vnHo -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Nov 8 17:02:34 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 8 Nov 2003 09:02:34 -0800 Subject: ReiserFS in Anaconda? In-Reply-To: <33076.144.136.187.136.1068289794.squirrel@hutton.sh> References: <20031108093603.14438.97353.Mailman@listman.back-rdu.redhat.com> <33076.144.136.187.136.1068289794.squirrel@hutton.sh> Message-ID: <200311080902.35487.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 08 November 2003 03:09, Michael Davies wrote: > As also mentioned here, terabyte filesystems and proper ACLs are > included. Important stuff. I'd be installing XFS be default if anaconda > had it. Um, ext3 can create up to a 2TB file system. We do it all the time. Oh, and with RHEL3, there are now ext3 ACLs. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/rSGq4v2HLvE71NURAn3cAJ9PdazsCjTq6pSLVJPquoGaJODcLgCfS/R0 Y5OM5eOz0nQrr+Ggs6b87jY= =h7CD -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Nov 8 17:03:53 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 8 Nov 2003 09:03:53 -0800 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: References: <1068236427.12684.60.camel@laptop> <20031107223129.C19738@devserv.devel.redhat.com> Message-ID: <200311080903.53997.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 08 November 2003 06:16, Aurelien Bompard wrote: > Ok. On K3B's website, the developpers advise RPM packagers to use Epochs > to ensure that 0.10 will actually be considered higher as 0.9. > Thanks. Sounds to me that the k3b developers don't know enough about rpm to make such suggestions (; Adding in epochs is evil, and should be avoided at all costs. I sincerely hope that none of the 3'rd party packagers took said advice and added an epoch to their k3b package... - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/rSH54v2HLvE71NURAnt0AKCehn3TrKOGCTuolRbDJM4QsPlORACgsBaD 1+LrGO5zqB7JZV/AJq8cKZ4= =Iwx2 -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Sat Nov 8 17:16:58 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 18:16:58 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <1068308351.6375.28.camel@localhost.localdomain> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> <3FAD129C.4010108@staticnull.org> <1068308351.6375.28.camel@localhost.localdomain> Message-ID: <20031108181658.38df94ad.ms-nospam-0306@arcor.de> On Sat, 08 Nov 2003 17:19:12 +0100, tony wrote: > > Is the livna peoples rpm scheme fixed now? > > I installed Xine, ogle and tried mplayer a couple of days ago with yum. > > Xine and ogle had a couple of missing libraries that I had to go get > elsewhere It is *important* to understand that rpm.livna.org is not a standalone repository but depends on packages in Fedora Core _and_ Fedora.us. As long as the fedora.us repository for Fedora Core 1 is not filled with packages yet, you may need to live with the packages for Fedora Core 0.95 or even 0.94. Please give the build masters some time. > and mplayer went into dependency loop hell and refused to > install. Do you have console output for that? -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tony at tgds.net Sat Nov 8 17:32:21 2003 From: tony at tgds.net (tony) Date: Sat, 08 Nov 2003 18:32:21 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <20031108181658.38df94ad.ms-nospam-0306@arcor.de> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> <3FAD129C.4010108@staticnull.org> <1068308351.6375.28.camel@localhost.localdomain> <20031108181658.38df94ad.ms-nospam-0306@arcor.de> Message-ID: <1068312740.6375.69.camel@localhost.localdomain> Le sam 08/11/2003 ? 18:16, Michael Schwendt a ?crit : > > and mplayer went into dependency loop hell and refused to > > install. > > Do you have console output for that? # yum -c /etc/yum.conf install mplayer Gathering header information file(s) from server(s) Server: Red Hat Linux 9 - i386 - Base Server: Fedora Compatible Packages (stable) Server: Fedora Compatible Packages (testing) Server: Fedora Compatible Packages (unstable) Server: Red Hat Linux 9 - Updates Finding updated packages Resolving dependencies .....identical dependency loop exceeded package faad2 needs libsndfile.so.1(libsndfile.so.1.0) (not provided) I have of course installed libsndfile Cheers Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From alan at redhat.com Sat Nov 8 17:47:24 2003 From: alan at redhat.com (Alan Cox) Date: Sat, 8 Nov 2003 12:47:24 -0500 (EST) Subject: RPM submission script In-Reply-To: <20031108080817.1945c478.ms-nospam-0306@arcor.de> from "Michael Schwendt" at Tach 08, 2003 08:08:17 Message-ID: <200311081747.hA8HlOC03361@devserv.devel.redhat.com> > It's sort of a virus, e.g. in Germany. One of the first things the average > user does after a distribution upgrade is to edit /etc/sysconfig/i18n and > change from UTF-8 to @euro or ISO 8859-1. The reason is that the effects > of this change are not understood. It just "seems to work" with old > Latin-1 file names, file contents and non-Unicode-aware applications. The file system is still UTF-8, its just the user is filling it with garbage now. The update is a pain but there are some handy scripts for doing things like turning a subtree from 8859-15 to utf-8 From alan at redhat.com Sat Nov 8 17:50:47 2003 From: alan at redhat.com (Alan Cox) Date: Sat, 8 Nov 2003 12:50:47 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068274604.14565.22.camel@binkley> from "seth vidal" at Tach 08, 2003 01:56:44 Message-ID: <200311081750.hA8HolP04557@devserv.devel.redhat.com> > Well I know this sounds silly, but, in the case of yum people use it on > non-redhat platforms. I'd actually feel bad telling them 'yah you need > this red hat specific library, named rhpl' in order to use it. But you don't feel the same about "You need the gnu C library" or "gnu C compiler" or "Berkeley Yacc" or "Apache webserver" or or that matter "Linux"... Its only a problem if the library you really need makes it impossible to port the app over surely ? > putting the name of a commercial vendor in the library name is kinda > 'blah' anyway. IMHO it is the same in all cases. It's about credit. Whether you'd keep the command line redhat-config-foo on a non RH system is a different matter altogether. Alan From ms-nospam-0306 at arcor.de Sat Nov 8 17:54:26 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 18:54:26 +0100 Subject: rpm.livna.org (was: Warren' rejection of...) In-Reply-To: <1068312740.6375.69.camel@localhost.localdomain> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> <3FAD129C.4010108@staticnull.org> <1068308351.6375.28.camel@localhost.localdomain> <20031108181658.38df94ad.ms-nospam-0306@arcor.de> <1068312740.6375.69.camel@localhost.localdomain> Message-ID: <20031108185426.0c2f5129.ms-nospam-0306@arcor.de> On Sat, 08 Nov 2003 18:32:21 +0100, tony wrote: > Le sam 08/11/2003 ? 18:16, Michael Schwendt a ?crit : > > > > and mplayer went into dependency loop hell and refused to > > > install. > > > > Do you have console output for that? > > # yum -c /etc/yum.conf install mplayer > Gathering header information file(s) from server(s) > Server: Red Hat Linux 9 - i386 - Base > Server: Fedora Compatible Packages (stable) > Server: Fedora Compatible Packages (testing) > Server: Fedora Compatible Packages (unstable) > Server: Red Hat Linux 9 - Updates > Finding updated packages > > Resolving dependencies > .....identical dependency loop exceeded > package faad2 needs libsndfile.so.1(libsndfile.so.1.0) (not provided) > > I have of course installed libsndfile Hmmm, I don't see Fedora.us repositories in your server list. "libsndfile" is a Fedora.us package. As pointed out earlier, rpm.livna.org depends on Fedora.us packages. But "faad2" does not depend on libsndfile.so.1. Raises the question what faad2 and libsndfile packages you have installed and from where? And why do you have Red Hat Linux 9 repositories in there? -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Sat Nov 8 17:54:42 2003 From: alan at redhat.com (Alan Cox) Date: Sat, 8 Nov 2003 12:54:42 -0500 (EST) Subject: RPM submission script In-Reply-To: <20031107222947.B19738@devserv.devel.redhat.com> from "Bill Nottingham" at Tach 07, 2003 10:29:47 Message-ID: <200311081754.hA8HsjO10178@devserv.devel.redhat.com> > Alan Cox (alan at redhat.com) said: > > > so mandating utf-8 is great, if you also do it in rpm spec files, and > > > filenames, etc, etc, etc. > > > > Linux filenames are utf-8 and defined that way. Gives the nautilus people > > something to do ;) > > Erm, then the kernel should default to UTF-8 for NLS on vfat & iso9660. You want to be loading the modules to map your fs naming to/from utf-8 yes. Alan From jcsitte at staticnull.org Sat Nov 8 17:57:03 2003 From: jcsitte at staticnull.org (Jonathan C. Sitte) Date: Sat, 08 Nov 2003 12:57:03 -0500 Subject: rpm.livna.org In-Reply-To: <20031108185426.0c2f5129.ms-nospam-0306@arcor.de> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> <3FAD129C.4010108@staticnull.org> <1068308351.6375.28.camel@localhost.localdomain> <20031108181658.38df94ad.ms-nospam-0306@arcor.de> <1068312740.6375.69.camel@localhost.localdomain> <20031108185426.0c2f5129.ms-nospam-0306@arcor.de> Message-ID: <3FAD2E6F.5050204@staticnull.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: | Hmmm, I don't see Fedora.us repositories in your server list. | | "libsndfile" is a Fedora.us package. As pointed out earlier, | rpm.livna.org depends on Fedora.us packages. | | But "faad2" does not depend on libsndfile.so.1. Raises the question what | faad2 and libsndfile packages you have installed and from where? | | And why do you have Red Hat Linux 9 repositories in there? Rejection of scheme? Does that mean his rpms are not using the scheme that was agreed upon? If there was one that was agreed upon in the first place... - -- Jonathan C. Sitte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/rS5uA60L5My8BKQRAs4VAJ9rZ2SQm6HVqzjn3ZZ5HDLWmb5WtQCfam3f DQHYUjQFYgWUOR8+XIbeuN4= =iCYG -----END PGP SIGNATURE----- From Axel.Thimm at physik.fu-berlin.de Sat Nov 8 17:59:07 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 8 Nov 2003 18:59:07 +0100 Subject: Warren's rejection of cooperation with other repos In-Reply-To: References: <20031108120954.GA18487@puariko.nirvana> Message-ID: <20031108175907.GB22078@puariko.nirvana> On Sat, Nov 08, 2003 at 05:59:31PM +0200, Panu Matilainen wrote: > > o interrepository specifications (note "inter"!!!) > > Oh but that was NEVER the idea behind fedora.us. The idea was to create a > repository run by community of packagers, not a community of repositories > run by individuals. Of course it was, at least by the people that were finaly driven away ... > Why do you need 1000 different repositories if you can stick the > packages into one? Others have given good explanations to why we need that. > I find it kinda funny that people who refuse to co-operate within policies > and specifications created by the fedora.us community complain about > fedora.us not co-operating with them :-/ Well, you should know that current fedora.us specs were also shaped by the same people. Unfortunately vital components like interrepository interaction were left out, and discussing these issues in March/April wore all parties off, until many gave up on fedora.us. The same question can be set the other way around: Why did fedora.us had to reinvent the wheel once again? -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jcsitte at staticnull.org Sat Nov 8 18:00:43 2003 From: jcsitte at staticnull.org (Jonathan C. Sitte) Date: Sat, 08 Nov 2003 13:00:43 -0500 Subject: rpm.livna.org In-Reply-To: <3FAD2E6F.5050204@staticnull.org> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> <3FAD129C.4010108@staticnull.org> <1068308351.6375.28.camel@localhost.localdomain> <20031108181658.38df94ad.ms-nospam-0306@arcor.de> <1068312740.6375.69.camel@localhost.localdomain> <20031108185426.0c2f5129.ms-nospam-0306@arcor.de> <3FAD2E6F.5050204@staticnull.org> Message-ID: <3FAD2F4B.60504@staticnull.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan C. Sitte wrote: | Rejection of scheme? Does that mean his rpms are not using the scheme | that was agreed upon? If there was one that was agreed upon in the first | place... The reason that I am asking is the fact that if he rejects the scheme than I will possibly make my own rpms then. I thought it would be nice to use his if the repository was using the correctly agreed scheme. It is really easy to stop using that repos. Remove the rpm xmms-mp3 and remove it from yum.conf. Heh. No skin off my back. This seems odd that there is so much fragmentation with the rpm issue. - -- Jonathan C. Sitte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/rS9LA60L5My8BKQRAuVnAJ9vWNyXrP6x7CIZwubHWELXrz5DJQCfVxTa XVC2A62Q5Tb0UyE47X35V2c= =GZbc -----END PGP SIGNATURE----- From Nicolas.Mailhot at laPoste.net Sat Nov 8 18:01:11 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 08 Nov 2003 19:01:11 +0100 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <200311080859.39887.jkeating@j2solutions.net> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <200311080859.39887.jkeating@j2solutions.net> Message-ID: <1068314471.3263.6.camel@m70.net81-64-235.noos.fr> Le sam 08/11/2003 ? 17:59, Jesse Keating a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Saturday 08 November 2003 04:09, Axel Thimm wrote: > > I am sorry to hear that you still think you were doing the Right > > Thing (TM). > > > > When Fedora (US) was being formed it attracted many repo maintainers > > like freshrpms, newrpms, dag and many others including myself. They > > hoped for a coordination institution within fedora, which should > > provide > > So it would seem that you're going to discount Warren's package naming > scheme, mearly because there is bad blood between him and some other > package repots? Great... thats nice. Nobody wrote so here. Quite the contrary - a lot of people are/were expecting to do a new start with the new fedora and forget old history. And that means working out something were multiple repositories can coexist peacefully. Answers like "there is no need for 3rd party repositories" do not help at all. -- 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 katzj at redhat.com Sat Nov 8 18:02:53 2003 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 08 Nov 2003 13:02:53 -0500 Subject: ReiserFS in Anaconda? In-Reply-To: <33076.144.136.187.136.1068289794.squirrel@hutton.sh> References: <20031108093603.14438.97353.Mailman@listman.back-rdu.redhat.com> <33076.144.136.187.136.1068289794.squirrel@hutton.sh> Message-ID: <1068314573.7225.9.camel@edoras.local.net> On Sat, 2003-11-08 at 06:09, Michael Davies wrote: > > Jesse Keating wrote: > > Why does people want XFS? Any _special_ feature? > > XFS was developed by SGI a while ago and has been in Irix for a longer > _time_ than any of ext2/3 and reiserfs (not sure on jfs. ext2 probably > has had more instances ever run, but I digress). This speaks for XFS's > rock solid stability. Even if you assume existence for a long time implies stability, it only implies stability under Irix. The VM and VFS of Linux and Irix are vastly different in a lot of ways, so it's sort of like saying that because one SCSI controller is rock solid under one it'll be solid under the other ;) *Not* that I'm against other filesystems in general or XFS in particular. I just caution against over-generalization. > As also mentioned here, terabyte filesystems and proper ACLs are included. > Important stuff. I'd be installing XFS be default if anaconda had it. You have to get past the block layer limitations for terabyte filesystems to be much of an issue -- 2.6 should help there, but could do with some testing in this area. ext[23] will support up to 8 (iirc, might have been 16) terabyte filesystems. And ext3 acls are in 2.6 as well. Cheers, Jeremy From tony at tgds.net Sat Nov 8 18:02:58 2003 From: tony at tgds.net (tony) Date: Sat, 08 Nov 2003 19:02:58 +0100 Subject: rpm.livna.org (was: Warren' rejection of...) In-Reply-To: <20031108185426.0c2f5129.ms-nospam-0306@arcor.de> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> <3FAD129C.4010108@staticnull.org> <1068308351.6375.28.camel@localhost.localdomain> <20031108181658.38df94ad.ms-nospam-0306@arcor.de> <1068312740.6375.69.camel@localhost.localdomain> <20031108185426.0c2f5129.ms-nospam-0306@arcor.de> Message-ID: <1068314577.6375.99.camel@localhost.localdomain> Le sam 08/11/2003 ? 18:54, Michael Schwendt a ?crit : > > Hmmm, I don't see Fedora.us repositories in your server list. > > "libsndfile" is a Fedora.us package. As pointed out earlier, > rpm.livna.org depends on Fedora.us packages. > > But "faad2" does not depend on libsndfile.so.1. Raises the question what > faad2 and libsndfile packages you have installed and from where? > > And why do you have Red Hat Linux 9 repositories in there? > OK I'm catching on now. This isn't very end user friendly... I'll get all this straight now thanks. In any case xine works better than mplayer on my machine... Thanks again Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From Axel.Thimm at physik.fu-berlin.de Sat Nov 8 18:07:14 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 8 Nov 2003 19:07:14 +0100 Subject: Warren's rejection of cooperation with other repos In-Reply-To: <20031108154828.4084d33f.ms-nospam-0306@arcor.de> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <20031108120954.GA18487@puariko.nirvana> Message-ID: <20031108180714.GC22078@puariko.nirvana> On Sat, Nov 08, 2003 at 03:48:28PM +0100, Michael Schwendt wrote: > On Sat, 8 Nov 2003 13:09:54 +0100, Axel Thimm wrote: > > > On Fri, 7 Nov 2003, Warren Togami wrote: > > > > I would assert that the alliances of 3rd party repositories > > > > that have tried to form in the recent past are not sustainable > > > > in the long term, for the same controversial reasons that > > > > fedora.us rejected cooperation with those entities earlier > > > > this year. > While I'd like to stay out of this, because I've not been part of > the pre-fedora.us discussions, I skimmed over the list archives when > I subscribed to the list. May not count much, but it was -- and > still is -- my impression that the maintainers of existing repos > were not willing to compromise. That made it really difficult for > fedora.us to start. You have the wrong picture then. What compromises are you talking of? Accepting fedora.us' non-comaptibility to their own repos? > I find it very unfortunate to see that a lot of work is still duplicated. > If someone asked me whether I could explain why there are still several > independent repo maintainers who do their own rather closed thing, I would > admit that I don't know. > > Fedora.us provides the infrastructure for collaborated packaging > efforts. Still, the reason why some repo maintainers don't team up, is not > the "explicit Epoch" or the package release versioning scheme. It's the > refusal to adhere to Fedora.us package submission and QA policies, because > it's easier to pipe out a new binary package instead of depending on other > people to review the src.rpm, and possibly having to fix broken build > requirements or unclean spec files before a package would be approved. On Sat, Nov 08, 2003 at 05:59:31PM +0200, Panu Matilainen wrote: > As to why, I can only agree with Michael: people didn't/don't want > to change the way they do things, have their packages go through > rigorous (and slow) QA etc. To answer to both of you: Personally I am fond of strict rules and QA. I wouldn't mind a submission system similar to fedora's and hope that the merger will polish it. The problems are by far not technical. This would be a far too simple explanation, and if I were the lazy type'a'guy, I wouldn't have wasted so much time in getting the disttag's (and other specs) rolling. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmatilai at welho.com Sat Nov 8 18:14:16 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Sat, 8 Nov 2003 20:14:16 +0200 (EET) Subject: Warren' rejection of cooperation with other repos In-Reply-To: <1068314471.3263.6.camel@m70.net81-64-235.noos.fr> Message-ID: On Sat, 8 Nov 2003, Nicolas Mailhot wrote: > Le sam 08/11/2003 ? 17:59, Jesse Keating a ?crit : > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Saturday 08 November 2003 04:09, Axel Thimm wrote: > > > I am sorry to hear that you still think you were doing the Right > > > Thing (TM). > > > > > > When Fedora (US) was being formed it attracted many repo maintainers > > > like freshrpms, newrpms, dag and many others including myself. They > > > hoped for a coordination institution within fedora, which should > > > provide > > > > So it would seem that you're going to discount Warren's package naming > > scheme, mearly because there is bad blood between him and some other > > package repots? Great... thats nice. > > Nobody wrote so here. Quite the contrary - a lot of people are/were > expecting to do a new start with the new fedora and forget old history. > And that means working out something were multiple repositories can > coexist peacefully. > Answers like "there is no need for 3rd party repositories" do not help > at all. I assume that's got to do with my "why you need 1000 repositories" comment - sure, 3rd party repositories will always exist and are needed, things like a special repos of kernel, jpackake etc for those special interest groups are quite a different matter. What I meant by the "1000 repos" comment is that it's just plain silly and waste of time that the same pieces of software which basically everybody uses are re-re-re-re-re-repackaged in various repositories just because people can't agree on some policies. And now I'm out of this political crap and back to doing something hopefully remotely usefull :) - Panu - From Axel.Thimm at physik.fu-berlin.de Sat Nov 8 18:19:37 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 8 Nov 2003 19:19:37 +0100 Subject: Warren's rejection of cooperation with other repos In-Reply-To: <200311080859.39887.jkeating@j2solutions.net> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <200311080859.39887.jkeating@j2solutions.net> Message-ID: <20031108181937.GD22078@puariko.nirvana> > On Fri, 7 Nov 2003, Warren Togami wrote: > > I would assert that the alliances of 3rd party repositories that > > have tried to form in the recent past are not sustainable in the > > long term, for the same controversial reasons that fedora.us > > rejected cooperation with those entities earlier this year. On Sat, Nov 08, 2003 at 08:59:38AM -0800, Jesse Keating wrote: > On Saturday 08 November 2003 04:09, Axel Thimm wrote: > > I am sorry to hear that you still think you were doing the Right > > Thing (TM). > > > > When Fedora (US) was being formed it attracted many repo maintainers > > like freshrpms, newrpms, dag and many others including myself. They > > hoped for a coordination institution within fedora, which should > > provide > > So it would seem that you're going to discount Warren's package > naming scheme, mearly because there is bad blood between him and > some other package repots? Great... thats nice. Were did you read any reference on his naming scheme above to deduce your statements? > Perhaps the rest of us should adopt Warren's proposal, and let the > chips fall where they may... sound familiar? What happened last > time? Individual repots that didn't work worth a crap with > eachother, leading to confused and helpless end users. Perfect way > to support a project... > > For cripes sake, drop the political crap and bad blood, review his > proposal and make some decent feedback on it instead of bickering > about the past. To see it soberly: The strategical question is whether to have multiple repos or only one. People with their own repo tend not to prefer solutions allowing repository mixing. This was and is out of Warren's scope and is fine that way, and is is fine that he explicitly states so. It is also fine to believe otherwise. But you cannot bring the two concepts together. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Sat Nov 8 16:45:39 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 8 Nov 2003 08:45:39 -0800 Subject: fedora-legacy/Warren agrees to enforce rpm upgrades? In-Reply-To: <20031108122024.GI11801@puariko.nirvana> References: <3FA229D3.4000104@togami.com> <20031107164717.GD27327@puariko.nirvana> <20031108122024.GI11801@puariko.nirvana> Message-ID: <200311080845.40547.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 08 November 2003 04:20, Axel Thimm wrote: > Am I the only one that finds it questionable that assertions like > these are simply being made? > > Even if the whole list and the world agrees postscriptum (which it > doesn't), what kind of tacticts are these? There was clearly not a > list agreement (set aside if there is need for one), so why present > your opinion as the list's? > > Did I mention that it was agreed upon all fedora-lists to remove glibc > from ALL distributions? Alex, calm down. It has been proposed, then modified slightly (which I forgot) by Warren, to just upgrade to the latest that rpm.org has to offer for each respective os. There were reasons posted as well. At the time, nobody seemed to oppose it. Now there seems to be some opposition. No need to get your feathers ruffled, we can discuss it once more. We have until mid December to make some decisions. - -- Jesse Keating RHCE MCSE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/rR2z4v2HLvE71NURAo8PAJwPx8r5O8cuBG2hHj08mJwMTVoRsQCaAnFu nJ3KRZkvTOg47Bdiq5yrrho= =hKfN -----END PGP SIGNATURE----- -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list From ms-nospam-0306 at arcor.de Sat Nov 8 18:55:08 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 19:55:08 +0100 Subject: Warren's rejection of cooperation with other repos In-Reply-To: <20031108180714.GC22078@puariko.nirvana> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <20031108120954.GA18487@puariko.nirvana> <20031108180714.GC22078@puariko.nirvana> Message-ID: <20031108195508.75e1e35e.ms-nospam-0306@arcor.de> On Sat, 8 Nov 2003 19:07:14 +0100, Axel Thimm wrote: > On Sat, Nov 08, 2003 at 05:59:31PM +0200, Panu Matilainen wrote: > > As to why, I can only agree with Michael: people didn't/don't want > > to change the way they do things, have their packages go through > > rigorous (and slow) QA etc. > > To answer to both of you: Personally I am fond of strict rules and > QA. I wouldn't mind a submission system similar to fedora's and hope > that the merger will polish it. > > The problems are by far not technical. This would be a far too simple > explanation, and if I were the lazy type'a'guy, I wouldn't have wasted > so much time in getting the disttag's (and other specs) rolling. Parting in blood is the wrong thing to do. Pushing alternative concepts would be better. What is your list of disagreements with fedora.us' policies? Have you posted a complete list before? Maybe you have a pointer into the list archives? With "not willing to compromise" I refer also to recent controversies, such as Red Hat's move from redhat-release-9 to fedora-release-1. Asking for a redhat-release-10 package or changing the disttag from "rh9" (Red Hat Linux 9) to "rh9.1" (Fedora Core 1) are pretty much unfortunate suggestions. "rhfc1" is a hack, too. Or your package release versioning scheme: Why don't your packages start at release 0 like fedora.us' packages do? So when a package is included in Fedora Core or Fedora Extras, by default it would override the lower release package in the 3rd party repository. And one request, please don't take these mails so personal. You always sound as if you're constantly fed up and take everything as insult. ;) -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Sat Nov 8 18:59:39 2003 From: warren at togami.com (Warren Togami) Date: Sat, 08 Nov 2003 08:59:39 -1000 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <20031108120954.GA18487@puariko.nirvana> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> Message-ID: <1068317979.4430.134.camel@laptop> http://www.fedora.us/wiki/RepositoryMixingProblems Many months ago I wrote this, and my stance has not changed. The top 3 bullets are my arguments in this topic. The inevitable instances where your 3rd party repositories were inconsistent with each other and thus breaking consistency have happened several times since. The crux of the matter ... Cooperation among an arbitrary mix of repositories controlled by _individuals_ in a closed nature is inherently problematic. It is however fine if you don't mind it being broken sometimes, and almost zero peer review of the sources going into the packages. After all these months we are still arguing over the same tired points and my position has still not changed. I will say nothing more on this matter. Granted this page never suggested a viable solution to license problematic packages which cannot be contained at fedora.us. I will then give you the solution now: The same type of group needs to form their own collaborative repository project outside of the USA for non-American use where it is legal. This theoretical project needs their own Bugzilla, QA process, mirrors and such. Unfortunately due to my country's laws it would be unlawful for me to use work on or use software from such a theoretical project. Warren From ms-nospam-0306 at arcor.de Sat Nov 8 19:07:15 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 20:07:15 +0100 Subject: rpm.livna.org In-Reply-To: <3FAD2F4B.60504@staticnull.org> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> <3FAD129C.4010108@staticnull.org> <1068308351.6375.28.camel@localhost.localdomain> <20031108181658.38df94ad.ms-nospam-0306@arcor.de> <1068312740.6375.69.camel@localhost.localdomain> <20031108185426.0c2f5129.ms-nospam-0306@arcor.de> <3FAD2E6F.5050204@staticnull.org> <3FAD2F4B.60504@staticnull.org> Message-ID: <20031108200715.574a7c86.ms-nospam-0306@arcor.de> On Sat, 08 Nov 2003 13:00:43 -0500, Jonathan C. Sitte wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jonathan C. Sitte wrote: > | Rejection of scheme? Does that mean his rpms are not using the scheme > | that was agreed upon? If there was one that was agreed upon in the first > | place... > > The reason that I am asking is the fact that if he rejects the scheme > than I will possibly make my own rpms then. I thought it would be nice > to use his if the repository was using the correctly agreed scheme. It > is really easy to stop using that repos. Remove the rpm xmms-mp3 and > remove it from yum.conf. Heh. No skin off my back. This seems odd that > there is so much fragmentation with the rpm issue. Ehm, what are you talking of? I'm afraid I don't understand anything of this. Please rephrase. "Rejection of scheme"? ...? Fragmentation? Where do you see problems? Practically, rpm.livna.org would not need to adhere to any package versioning scheme at all. But its current 0.lvn.%{vepoch}.%{disttag} scheme looks good and is beneficial. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jcsitte at staticnull.org Sat Nov 8 19:13:37 2003 From: jcsitte at staticnull.org (Jonathan C. Sitte) Date: Sat, 08 Nov 2003 14:13:37 -0500 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <1068317979.4430.134.camel@laptop> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <1068317979.4430.134.camel@laptop> Message-ID: <3FAD4061.1070106@staticnull.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Warren Togami wrote: | After all these months we are still arguing over the same tired points | and my position has still not changed. I will say nothing more on this | matter. I agree with you completely on this matter as well. I do not know why this is even an issue. I thought the whole idea of the project was for the people of redhat and the community to work as a team. I have been telling this to people on the fedora-list as well. They don't seem to care much on irc.freenode.net #fedora. I don't even bother there. All I get is go to this repos or that to get this or that. I ask them. Is the repos a fedora standard. They seem to not care. Just a thought. ;) - -- Jonathan C. Sitte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/rUBhA60L5My8BKQRAqjDAKCeG+kn5tUP4teA4mSRD3M4YEpyDACeMIEL F5ni632FFgfP7KiTFVqhgxY= =3Jd0 -----END PGP SIGNATURE----- From jcsitte at staticnull.org Sat Nov 8 19:15:46 2003 From: jcsitte at staticnull.org (Jonathan C. Sitte) Date: Sat, 08 Nov 2003 14:15:46 -0500 Subject: rpm.livna.org In-Reply-To: <20031108200715.574a7c86.ms-nospam-0306@arcor.de> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <1068304191.6375.14.camel@localhost.localdomain> <20031108165704.31b158ab.ms-nospam-0306@arcor.de> <3FAD129C.4010108@staticnull.org> <1068308351.6375.28.camel@localhost.localdomain> <20031108181658.38df94ad.ms-nospam-0306@arcor.de> <1068312740.6375.69.camel@localhost.localdomain> <20031108185426.0c2f5129.ms-nospam-0306@arcor.de> <3FAD2E6F.5050204@staticnull.org> <3FAD2F4B.60504@staticnull.org> <20031108200715.574a7c86.ms-nospam-0306@arcor.de> Message-ID: <3FAD40E2.3090607@staticnull.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: | Ehm, what are you talking of? I'm afraid I don't understand anything | of this. Please rephrase. "Rejection of scheme"? ...? Fragmentation? | Where do you see problems? | | Practically, rpm.livna.org would not need to adhere to any package | versioning scheme at all. But its current 0.lvn.%{vepoch}.%{disttag} | scheme looks good and is beneficial. As long as it is safe then I am ok with it. I just want to make sure people stay with the big picture here :). I boycott any repos that does not follow the scheme that Fedora wants. It is good to know that it is ok then :)) - -- Jonathan C. Sitte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/rUDiA60L5My8BKQRAnGGAJ0TmQfJ2BfOhcQZmodtxyDVxABDagCeLq8p 0RXVibwC5HSLkLRnpLvH9Dg= =Usxy -----END PGP SIGNATURE----- From Axel.Thimm at physik.fu-berlin.de Sat Nov 8 19:42:32 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sat, 8 Nov 2003 20:42:32 +0100 Subject: Warren's rejection of cooperation with other repos In-Reply-To: <20031108195508.75e1e35e.ms-nospam-0306@arcor.de> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <20031108120954.GA18487@puariko.nirvana> <20031108180714.GC22078@puariko.nirvana> <20031108195508.75e1e35e.ms-nospam-0306@arcor.de> Message-ID: <20031108194232.GA25382@puariko.nirvana> On Sat, Nov 08, 2003 at 07:55:08PM +0100, Michael Schwendt wrote: > On Sat, 8 Nov 2003 19:07:14 +0100, Axel Thimm wrote: > Pushing alternative concepts would be better. What is your list of > disagreements with fedora.us' policies? Have you posted a complete > list before? Maybe you have a pointer into the list archives? Others and I tried to in March/April. fedora.us' archives is full of that and the reaction. > With "not willing to compromise" I refer also to recent controversies, > such as Red Hat's move from redhat-release-9 to fedora-release-1. Asking > for a redhat-release-10 package or changing the disttag from "rh9" (Red > Hat Linux 9) to "rh9.1" (Fedora Core 1) are pretty much unfortunate > suggestions. "rhfc1" is a hack, too. No, it's not. I hope you will understand the issue and see that Fernando delivered a magnificent solution compatible with rpm version to Before Christ. Even one that I highly recommend for fedora.us. > Or your package release versioning scheme: Why don't your packages > start at release 0 like fedora.us' packages do? So when a package is > included in Fedora Core or Fedora Extras, by default it would > override the lower release package in the 3rd party repository. Look closer, you are using my arguments from half a year ago that made this part of fedora.us' specs. There are cases where this is neccessary and these cases are reflected in the repo. This idiom is also only then strictly neccessary when dealing with a closed vendor (i.e. one that doesn't care about the outside world). That is said to not be the case anymore. > And one request, please don't take these mails so personal. You always > sound as if you're constantly fed up and take everything as insult. ;) On Tue, Oct 07, 2003 at 12:38:27PM +0200, Michael Schwendt wrote: > Wrong. Please consider thinking about it a bit longer before you pipe > out your usual quick replies. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ms-nospam-0306 at arcor.de Sat Nov 8 20:03:52 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 8 Nov 2003 21:03:52 +0100 Subject: Warren's rejection of cooperation with other repos In-Reply-To: <20031108194232.GA25382@puariko.nirvana> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <20031108120954.GA18487@puariko.nirvana> <20031108180714.GC22078@puariko.nirvana> <20031108195508.75e1e35e.ms-nospam-0306@arcor.de> <20031108194232.GA25382@puariko.nirvana> Message-ID: <20031108210352.77fbedfb.ms-nospam-0306@arcor.de> On Sat, 8 Nov 2003 20:42:32 +0100, Axel Thimm wrote: > On Sat, Nov 08, 2003 at 07:55:08PM +0100, Michael Schwendt wrote: > > On Sat, 8 Nov 2003 19:07:14 +0100, Axel Thimm wrote: > > Pushing alternative concepts would be better. What is your list of > > disagreements with fedora.us' policies? Have you posted a complete > > list before? Maybe you have a pointer into the list archives? > > Others and I tried to in March/April. fedora.us' archives is full of > that and the reaction. It's a pain to find relevant postings in 1400 (or such) postings. So, a list does not exist? > > With "not willing to compromise" I refer also to recent controversies, > > such as Red Hat's move from redhat-release-9 to fedora-release-1. Asking > > for a redhat-release-10 package or changing the disttag from "rh9" (Red > > Hat Linux 9) to "rh9.1" (Fedora Core 1) are pretty much unfortunate > > suggestions. "rhfc1" is a hack, too. > > No, it's not. I hope you will understand the issue and see that > Fernando delivered a magnificent solution compatible with rpm version > to Before Christ. Even one that I highly recommend for fedora.us. Why "rhfc1" and not "vfc1"? Why "rh" == "Red Hat" in the disttag when the distribution does not have the name "Red Hat Fedora Core" but just "Fedora Core"? > > Or your package release versioning scheme: Why don't your packages > > start at release 0 like fedora.us' packages do? So when a package is > > included in Fedora Core or Fedora Extras, by default it would > > override the lower release package in the 3rd party repository. > > Look closer, How close should that be? To realize that you decide on a case by case basis whether to add the "0." prefix or not? That prefix should be used consistently, because you cannot assume whether a package will appear in Fedora Core (Extras, Alternatives, Development, Testing, whatsoever), e.g. apt-0.5.5cnc7-36.rh9.1.at.src.rpm -- Btw, Cc to so many lists is a bad idea, since rpm-list at freshrpms.net is not open for non-subscribers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From yinyang at eburg.com Sat Nov 8 21:02:40 2003 From: yinyang at eburg.com (Gordon Messmer) Date: Sat, 08 Nov 2003 13:02:40 -0800 Subject: RPM submission script In-Reply-To: <1068249597.14565.8.camel@binkley> References: <20031107181926.GA15796@thyrsus.com> <200311072020.hA7KK0g09484@devserv.devel.redhat.com> <20031107203937.GC16285@thyrsus.com> <1068239981.6576.0.camel@opus> <20031107214321.GA16941@thyrsus.com> <1068242075.6576.2.camel@opus> <20031107223650.GA17174@thyrsus.com> <1068249597.14565.8.camel@binkley> Message-ID: <3FAD59F0.3000507@eburg.com> seth vidal wrote: > > as the example I gave to Nicholas, rpm -qi cups - read the description > field, note the (R), notice that's it is 1 character, not 3. What version of the package? Maybe I'm missing something, but it looks like three characters to me: [gordon at herald:~]$ rpm -qi cups | od -c ... 0001360 i n g l a y e r f o r \n U N 0001400 I X ( R ) o p e r a t i n g [gordon at herald:~]$ rpm -qi cups Name : cups Relocations: (not relocateab Version : 1.1.19 Vendor: Red Hat, Inc. Release : 13 Build Date: Thu 02 Oct 2003 From skvidal at phy.duke.edu Sat Nov 8 22:15:46 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 08 Nov 2003 17:15:46 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: <200311081750.hA8HolP04557@devserv.devel.redhat.com> References: <200311081750.hA8HolP04557@devserv.devel.redhat.com> Message-ID: <1068329746.16134.0.camel@binkley> > IMHO it is the same in all cases. It's about credit. Whether you'd keep > the command line redhat-config-foo on a non RH system is a different > matter altogether. Right, but I'm not doing advertising for a corporation by having apache, or gnu or berkeley in the reqs. I don't wear clothing with brand labels present, for a reason. -sv From nando at ccrma.Stanford.EDU Sat Nov 8 22:22:32 2003 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 08 Nov 2003 14:22:32 -0800 Subject: Warren's rejection of cooperation with other repos In-Reply-To: <20031108210352.77fbedfb.ms-nospam-0306@arcor.de> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> <20031108120954.GA18487@puariko.nirvana> <20031108180714.GC22078@puariko.nirvana> <20031108195508.75e1e35e.ms-nospam-0306@arcor.de> <20031108194232.GA25382@puariko.nirvana> <20031108210352.77fbedfb.ms-nospam-0306@arcor.de> Message-ID: <1068330151.4921.91.camel@cmn13.stanford.edu> > > > With "not willing to compromise" I refer also to recent controversies, > > > such as Red Hat's move from redhat-release-9 to fedora-release-1. Asking > > > for a redhat-release-10 package or changing the disttag from "rh9" (Red > > > Hat Linux 9) to "rh9.1" (Fedora Core 1) are pretty much unfortunate > > > suggestions. "rhfc1" is a hack, too. > > > > No, it's not. I hope you will understand the issue and see that > > Fernando delivered a magnificent solution A bit of an exageration, to say the least. It is another option... > > compatible with rpm version > > to Before Christ. Even one that I highly recommend for fedora.us. > > Why "rhfc1" and not "vfc1"? Why "rh" == "Red Hat" in the disttag > when the distribution does not have the name "Red Hat Fedora Core" > but just "Fedora Core"? It could also be zfc1, of course. "rhfc1" seemed to me a reasonable(*) choice that solved the problem of upgradability _I_ have. Fedora Core is not (yet?) an independent project, it is sponsored by RedHat, so "rh"+"fc" felt right(*). If I understand correctly the proper alternative as defined in the naming guidelines would be to use a "1" (right?), but I really like the readability of a string. This [may|will] not scale in the future, of course, depending on how future distros in the same lineage are named. -- Fernando (*) of course this is subjective, somebody else [may|will] think that it is a completely absurd choice. From skvidal at phy.duke.edu Sat Nov 8 22:21:35 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 08 Nov 2003 17:21:35 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068329746.16134.0.camel@binkley> References: <200311081750.hA8HolP04557@devserv.devel.redhat.com> <1068329746.16134.0.camel@binkley> Message-ID: <1068330095.16134.2.camel@binkley> On Sat, 2003-11-08 at 17:15, seth vidal wrote: > > IMHO it is the same in all cases. It's about credit. Whether you'd keep > > the command line redhat-config-foo on a non RH system is a different > > matter altogether. > > Right, but I'm not doing advertising for a corporation by having apache, > or gnu or berkeley in the reqs. > > I don't wear clothing with brand labels present, for a reason. I'd like to add one more thing, it's not the end of the world to use rhpl, but I do have some concerns over 1. where and how rhpl is developed and 2. it's api stability. -sv From herrold at owlriver.com Sat Nov 8 21:23:55 2003 From: herrold at owlriver.com (R P Herrold) Date: Sat, 8 Nov 2003 16:23:55 -0500 (EST) Subject: Warren' rejection of cooperation with other repos In-Reply-To: <20031108154828.4084d33f.ms-nospam-0306@arcor.de> References: <1068236427.12684.60.camel@laptop> <20031108120954.GA18487@puariko.nirvana> <20031108154828.4084d33f.ms-nospam-0306@arcor.de> Message-ID: On Sat, 8 Nov 2003, Michael Schwendt wrote: > I find it very unfortunate to see that a lot of work is > still duplicated. If someone asked me whether I could > explain why there are still several independent repo > maintainers who do their own rather closed thing, I would > admit that I don't know. A polite answer to that someone might be: Open Source encourages freedom, experimentation and diversity -- Several independendent packagers is the sign of a healthy Open Source ecosystem. A less 'politically correct' might mention fact that 'independent repo maintainers' are stubborn and independent, see little reason to change, and cannot be _forced_ to change. /me? I don't find it unfortunate at all that things have not settled down. Looking beyond the initial Fedora project, lots of interesting and practical work on RPM, SRPM mediated package building, cvs checkout building, and build environment has emerged in the last year. seth vidal's yum development, Michael Redinger's rhel-rebuild, Greg Kurtzer cAos, several of the independents' approaches, and the much awaited RH unveiling of an echo of the Beehive (being item 3 of the RH fedora annmouncement outline) all have or will help push the art of RPM based package management. Developers who are not working _just_ for monetary compensation have have some other motivation to do research, and implement testing harnesses to advance. We would not have seen such fast progress without diversity and stubborn independence. ------------ > "Crusade" is the wrong term, IMO. Fedora.us started as a vision. A vision > to serve the Red Hat Community with add-on packages from a single > repository which would make it easy for users to find additional software. Well, this is a less happy topic for me. The history is what the history is, although we each bring our own interpretations. Let's look through the record, and then decide. The initial Fedora proposal which was at: http://videl.ics.hawaii.edu/~warren/fedora.html has gone dark; a copy is here: http://www.owlriver.com/projects/packaging/fedora-manifesto-1.txt but it did not 'start' as a 'single repository' proposal. It arose in the clear success of FreshRPMs (indeed, was proposed there), and followed other independent packaging efforts of 'add-ons'. and later as to the 'crusade' aspect: http://www.owlriver.com/projects/packaging/valediction.txt [07:47:32] _warren- thomasvs: I understand the risk very well, and I can only say that if Fedora has RH updated packages as the result of extensive regression testing that is something I would personally be comfortable using. If you don't feel comfortable using it, then please don't use it. The former IRC archive linked at: http://www.fedora.us/index-main.html has gone dark, but the 'crusade' aspect arose from several such statements on IRC and in the mailing list, which were noted as dominance, control and process problems at that time (as well as now). http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000243.html http://videl.ics.hawaii.edu/pipermail/fedora-devel/2003-February/000244.html (herrold responding to a post) On Fri, 21 Feb 2003, Warren Togami wrote: > I hope that people do not see me as trying a "hostile takeover" of > FreshRPMS. I have great respect for Matthias and his good work with his > excellent packages. I am only pointing out these issues of co-existence. [... ] But you have to expect criticism when you propose a massive independent packager repository fork. There are not that many of us, and after reflection, you have to know it would leave a bad taste. The 'issue' of "co-existence" only arises because of overlap. No overlap -- no issue. ... As to the 'hostile takeover' matter, I certainly try to keep perspective that we are only packaging software -- and that a person who blindly relies on others, and automated maintenance without understanding the issues is going to get wedged, from time to time. [...] ... so there are simply issues, benign and malicious, which Fedora cannot solve. Accept it, get over it, and move on. I'm gonna' keep packaging my way for my use in my repository; until and unless the Fedora process gets documented, open, and running, I'm not gonna sign any Fedora packages. [...] Anyway, back to [warren's] post, how else can one casually read the comments at 03:34:52 and 03:34:55, other than as a 'there can be only one' Highlander ending... . If you want essentially perfect, but exceedingly stale, you should probably package only for Debian stable. [... The IRC transcript section:] [03:34:52] freshrpms and fedora cannot co-exist [03:34:55] in the long run ----------------------------------- quote ends And to me, there was simply no other answer for my rhetorical 'how else can one casually read the comments' question, because the 'single archive' and 'crusade' aspect of what his vision of Fedora was clear, regardless of stated benign intent. My solution: be stubborn and independent. -- Russ Herrold _______________________________________________ Fedora-devel mailing list Fedora-devel at fedora.us http://www.fedora.us/mailman/listinfo/fedora-devel From matthew at zeut.net Sat Nov 8 23:31:27 2003 From: matthew at zeut.net (Matthew T. O'Connor) Date: Sat, 08 Nov 2003 18:31:27 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068329746.16134.0.camel@binkley> References: <200311081750.hA8HolP04557@devserv.devel.redhat.com> <1068329746.16134.0.camel@binkley> Message-ID: <1068334287.9439.0.camel@zedora.zeut.net> On Sat, 2003-11-08 at 17:15, seth vidal wrote: > > IMHO it is the same in all cases. It's about credit. Whether you'd keep > > the command line redhat-config-foo on a non RH system is a different > > matter altogether. > > Right, but I'm not doing advertising for a corporation by having apache, > or gnu or berkeley in the reqs. > > I don't wear clothing with brand labels present, for a reason. Lots of people / distros use RPM which is an advertisement for Redhat. From alan at redhat.com Sun Nov 9 00:26:38 2003 From: alan at redhat.com (Alan Cox) Date: Sat, 8 Nov 2003 19:26:38 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068329746.16134.0.camel@binkley> from "seth vidal" at Tach 08, 2003 05:15:46 Message-ID: <200311090026.hA90Qct04615@devserv.devel.redhat.com> > > IMHO it is the same in all cases. It's about credit. Whether you'd keep > > the command line redhat-config-foo on a non RH system is a different > > matter altogether. > > Right, but I'm not doing advertising for a corporation by having apache, > or gnu or berkeley in the reqs. Actually Apache is a corporation. MySQL is a business, UC Berkeley pretty much is, sendmail is. Alan From d.quince at comcast.net Sun Nov 9 00:51:27 2003 From: d.quince at comcast.net (Devin Quince) Date: Sat, 8 Nov 2003 17:51:27 -0700 Subject: Fedora / RH 9 iso's Message-ID: I am having serious issues burning disk 2 of either Fedora or RH 9. I can successfully burn 1 and 3, but not 2. Any ideas? Devin --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.534 / Virus Database: 329 - Release Date: 10/31/2003 From hugo at devin.com.br Sun Nov 9 01:12:23 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Sat, 08 Nov 2003 22:12:23 -0300 Subject: Fedora / RH 9 iso's In-Reply-To: References: Message-ID: <3FAD9477.7040006@devin.com.br> Devin Quince wrote: > I am having serious issues burning disk 2 of either Fedora or RH 9. I can > successfully burn 1 and 3, but not 2. Any ideas? > Devin I don't think this is the right list to post your message, but check the md5 of the files and match with the MD5SUM file in the iso directory to see if you got the ISO's without any problem. $ md5sum yarrow-i386-disc2.iso fd23fe32fafe7557f5d1fa1d31100580 yarrow-i386-disc2.iso $ md5sum shrike-i386-disc2.iso 6b8ba42f56b397d536826c78c9679c0a shrike-i386-disc2.iso They are ok to burn here. []'s Hugo From dburcaw at terrasoftsolutions.com Sun Nov 9 01:16:08 2003 From: dburcaw at terrasoftsolutions.com (Dan Burcaw) Date: 08 Nov 2003 18:16:08 -0700 Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068334287.9439.0.camel@zedora.zeut.net> References: <200311081750.hA8HolP04557@devserv.devel.redhat.com> <1068329746.16134.0.camel@binkley> <1068334287.9439.0.camel@zedora.zeut.net> Message-ID: <1068340568.1127.559.camel@localhost.localdomain> > Lots of people / distros use RPM which is an advertisement for Redhat. But RPM has been an acronym for "RPM Package Manager" for some time now... ;-) From chuckw at quantumlinux.com Sun Nov 9 01:35:12 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sat, 8 Nov 2003 17:35:12 -0800 (PST) Subject: Fedora / RH 9 iso's In-Reply-To: Message-ID: > I am having serious issues burning disk 2 of either Fedora or RH 9. I > can successfully burn 1 and 3, but not 2. Any ideas? Did you verify the md5sum of disk 2? -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com A: Because we read from top to bottom, left to right. Q: Why should i start my reply below the quoted text? From dag at wieers.com Sun Nov 9 02:17:29 2003 From: dag at wieers.com (Dag Wieers) Date: Sun, 9 Nov 2003 03:17:29 +0100 (CET) Subject: Warren' rejection of cooperation with other repos In-Reply-To: <200311080859.39887.jkeating@j2solutions.net> Message-ID: On Sat, 8 Nov 2003, Jesse Keating wrote: > So it would seem that you're going to discount Warren's package naming > scheme, mearly because there is bad blood between him and some other > package repots? Great... thats nice. Your insinuating things. Warren's proposal contains items that 3rd party repositories have also contributed to, but it also lacks stuff we've discussed before. This thread is about a hostile comment in the proposal. A diplomatic hitch. > For cripes sake, drop the political crap and bad blood, review his proposal > and make some decent feedback on it instead of bickering about the past. Well, I think you can summarize this thread as follows: please remove the hostile comment about 3rd party repositories and the twisted view of history ;) If it wasn't in there, this thread wouldn't have existed in the first place. And I've already submitted some other feedback about the content of the proposal. Did you ? -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From jkeating at j2solutions.net Sun Nov 9 03:03:59 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 8 Nov 2003 19:03:59 -0800 Subject: Warren' rejection of cooperation with other repos In-Reply-To: References: Message-ID: <200311081903.59676.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 08 November 2003 18:17, Dag Wieers wrote: > Well, I think you can summarize this thread as follows: please remove > the hostile comment about 3rd party repositories and the twisted view of > history ;) If it wasn't in there, this thread wouldn't have existed in > the first place. That i can live with. If the comment is removed, will this tread die? please? > And I've already submitted some other feedback about the content of the > proposal. Did you ? I've discussed some of the points with Warren on IRC, but I'm still trying to sort through this mess that has spread across 3 different lists. - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/ra6f4v2HLvE71NURAmdFAJ4vS0gsbqUetFZaWpC8LLCBEy3ujgCbBRsU aGOWUWHc49m41k4auzAsLss= =W2P1 -----END PGP SIGNATURE----- From warren at togami.com Sun Nov 9 03:08:54 2003 From: warren at togami.com (Warren Togami) Date: Sat, 08 Nov 2003 17:08:54 -1000 Subject: Warren' rejection of cooperation with other repos In-Reply-To: <200311081903.59676.jkeating@j2solutions.net> References: <200311081903.59676.jkeating@j2solutions.net> Message-ID: <1068347334.4430.149.camel@laptop> On Sat, 2003-11-08 at 17:03, Jesse Keating wrote: > On Saturday 08 November 2003 18:17, Dag Wieers wrote: > > Well, I think you can summarize this thread as follows: please remove > > the hostile comment about 3rd party repositories and the twisted view of > > history ;) If it wasn't in there, this thread wouldn't have existed in > > the first place. > > That i can live with. If the comment is removed, will this tread die? > please? I have to admit it was the wrong place to put that comment and it was worded in a poor way. Again I shouldn't be posting things at 4AM. At the time I wanted discussion on all of the sections marked with "XXX", which I still do. Don't worry, the actual document wont contain anything about that. > > > And I've already submitted some other feedback about the content of the > > proposal. Did you ? > > I've discussed some of the points with Warren on IRC, but I'm still trying > to sort through this mess that has spread across 3 different lists. I would encourage everyone not to cross-post anymore, it further confuses issues. Warren From warren at togami.com Sun Nov 9 03:39:26 2003 From: warren at togami.com (Warren Togami) Date: Sat, 08 Nov 2003 17:39:26 -1000 Subject: Arjan AMD64 kernel-2.6.0-testX RPMS Message-ID: <1068349165.4430.163.camel@laptop> http://people.redhat.com/arjanv/2.5/ I just noticed that Arjan has x86_64 (AMD64) kernels in addition to the i586 and i686 kernels of 2.6.0-testX. Cool! Warren From d.quince at comcast.net Sun Nov 9 04:02:03 2003 From: d.quince at comcast.net (Devin Quince) Date: Sat, 8 Nov 2003 21:02:03 -0700 Subject: Fedora / RH 9 iso's In-Reply-To: <3FAD9477.7040006@devin.com.br> Message-ID: What would be the correct list? I thought this product was now 'community supported'! -----Original Message----- From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list-admin at redhat.com]On Behalf Of Hugo Cisneiros Sent: Saturday, November 08, 2003 6:12 PM To: fedora-devel-list at redhat.com Subject: Re: Fedora / RH 9 iso's Devin Quince wrote: > I am having serious issues burning disk 2 of either Fedora or RH 9. I can > successfully burn 1 and 3, but not 2. Any ideas? > Devin I don't think this is the right list to post your message, but check the md5 of the files and match with the MD5SUM file in the iso directory to see if you got the ISO's without any problem. $ md5sum yarrow-i386-disc2.iso fd23fe32fafe7557f5d1fa1d31100580 yarrow-i386-disc2.iso $ md5sum shrike-i386-disc2.iso 6b8ba42f56b397d536826c78c9679c0a shrike-i386-disc2.iso They are ok to burn here. []'s Hugo -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.534 / Virus Database: 329 - Release Date: 10/31/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.534 / Virus Database: 329 - Release Date: 10/31/2003 From warren at togami.com Sun Nov 9 04:09:27 2003 From: warren at togami.com (Warren Togami) Date: Sat, 08 Nov 2003 18:09:27 -1000 Subject: ifmonitor broken by mysql RH9 errata and FC1 Message-ID: <1068350967.4430.166.camel@laptop> https://bugzilla.fedora.us/show_bug.cgi?id=946 http://videl.ics.hawaii.edu/~warren/fedora/ifmonitor-0.30-0.fdr.3.src.rpm http://videl.ics.hawaii.edu/~warren/fedora/md5sums.asc ifmonitor is a very simple MySQL + PHP bandwidth monitor for Linux hosts. A simple C daemon stores your bandwidth usage in a MySQL table, and the bandwidth data can be viewed with a simple PHP web interface. Known Problem: ifmonitor fails to insert data into mysql-3.23.56-1.9 from RH9 Errata and mysql-3.23.58-4 from FC1. The original mysql-3.23.54a-11 from RH9 stock works fine with ifmonitor. The upstream author does not have any Red Hat boxes or time so he cannot look at the problem. Any ideas? Warren Togami warren at togami.com From jkeating at j2solutions.net Sun Nov 9 04:14:08 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 8 Nov 2003 20:14:08 -0800 Subject: Fedora / RH 9 iso's In-Reply-To: References: Message-ID: <200311082014.08791.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 08 November 2003 20:02, Devin Quince wrote: > What would be the correct list? I thought this product was now > 'community supported'! Fedora-devel is for discussion of development on/of Fedora Core. Just fedora-list is for end users. - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/rb8Q4v2HLvE71NURAjwZAJ48jRG+cvmJqCqdl026bSfWeZY6VwCgnzwe YbcWMWsKDCZjHqhr/UO4maE= =edMI -----END PGP SIGNATURE----- From lowen at pari.edu Sun Nov 9 04:40:36 2003 From: lowen at pari.edu (Lamar Owen) Date: Sat, 8 Nov 2003 23:40:36 -0500 Subject: ifmonitor broken by mysql RH9 errata and FC1 In-Reply-To: <1068350967.4430.166.camel@laptop> References: <1068350967.4430.166.camel@laptop> Message-ID: <200311082340.36178.lowen@pari.edu> On Saturday 08 November 2003 11:09 pm, Warren Togami wrote: > ifmonitor is a very simple MySQL + PHP bandwidth monitor for Linux hosts. > A simple C daemon stores your bandwidth usage in a MySQL table, and the > bandwidth data can be viewed with a simple PHP web interface. > Known Problem: > ifmonitor fails to insert data into mysql-3.23.56-1.9 from RH9 Errata and > mysql-3.23.58-4 from FC1. The original mysql-3.23.54a-11 from RH9 stock > works fine with ifmonitor. Does mysql have an equivalent to PostgreSQL's tcpip_socket config setting? That is, can the server daemon be set to not listen to TCP/IP ports and only to a unix domain socket? This sort of complaint is common with PostgreSQL; the canonical answer is to set tcpip_socket=true. No, I don't use mysql. PostgreSQL does everything I need; but the concept is similar. What does netstat -a --inet say with the FC1/RH9update mysql running? Diff to the RH9 stock? -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From behdad at cs.toronto.edu Sun Nov 9 06:57:06 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sun, 9 Nov 2003 01:57:06 -0500 Subject: Intro, and userhelper question In-Reply-To: <1068232932.13028.1323.camel@island> References: <1068232932.13028.1323.camel@island> Message-ID: I'm pretty sure I have unlocked screen save with root password once a few months ago. And I'm pretty sure I have not used anything other than RH&FC. But right now I can't do that. Anyone knows if there have been such an option that is removed? behdad On Fri, 7 Nov 2003, Alastair Neil wrote: > > Hello > > I am Alastair Neil, a lapsed physicist and currently unix admin for IT&E > labs at George Mason University. I've been using linux since late '93, > slackware and then redhat since 96 or so. > > An issue we have with some of our redhat systems is co-management where > I retain root access but create an account with admin privileges. All > easy enough to do with sudo. However, the desire for access to the gui > tools, again relatively easy enough to change the authorised account for > the tools in /etc/security/console.apps, the problem is that now I have > to remember the ladmin account password to access the apps. I would > rather be able to always be granted access with the root password. > > It seems there are two ways to approach this, allow userhelper to have a > list of authorised users, possibly selected from a dropdown list in > consolehelper or modify pam to check the root password if the user > password does not match. > > I modified pam in RH8 to do this because I liked the ability to unlock > screensavers with the root passwd ala HPUX, but I noted that > xscreensaver in Ximian allows this and as far as I can see it is not a > pam level change. > > Does anyone think these modifications are a good idea and if so what is > the preference? Or perhaps in my ignorance I am reinventing the wheel? > > From warren at togami.com Sun Nov 9 07:02:30 2003 From: warren at togami.com (Warren Togami) Date: Sat, 08 Nov 2003 21:02:30 -1000 Subject: ifmonitor broken by mysql RH9 errata and FC1 In-Reply-To: <200311082340.36178.lowen@pari.edu> References: <1068350967.4430.166.camel@laptop> <200311082340.36178.lowen@pari.edu> Message-ID: <1068361349.4430.171.camel@laptop> On Sat, 2003-11-08 at 18:40, Lamar Owen wrote: > > Known Problem: > > ifmonitor fails to insert data into mysql-3.23.56-1.9 from RH9 Errata and > > mysql-3.23.58-4 from FC1. The original mysql-3.23.54a-11 from RH9 stock > > works fine with ifmonitor. > > Does mysql have an equivalent to PostgreSQL's tcpip_socket config setting? > That is, can the server daemon be set to not listen to TCP/IP ports and only > to a unix domain socket? This sort of complaint is common with PostgreSQL; > the canonical answer is to set tcpip_socket=true. No, I don't use mysql. > PostgreSQL does everything I need; but the concept is similar. > > What does netstat -a --inet say with the FC1/RH9update mysql running? Diff to > the RH9 stock? Doesn't appear to be any difference between the two with netstat. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109536 Filed in Bugzilla Warren From paul at gear.dyndns.org Sun Nov 9 07:47:18 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Sun, 09 Nov 2003 17:47:18 +1000 Subject: TradeMarked Name --redhat-config- In-Reply-To: <200311081750.hA8HolP04557@devserv.devel.redhat.com> References: <200311081750.hA8HolP04557@devserv.devel.redhat.com> Message-ID: <3FADF106.3020700@gear.dyndns.org> Alan Cox wrote: > ... >> putting the name of a commercial vendor in the library name is >> kinda 'blah' anyway. > > > IMHO it is the same in all cases. It's about credit. Whether you'd > keep the command line redhat-config-foo on a non RH system is a > different matter altogether. With all due respect (i've never disagreed with a Linux luminary before ;-), there's something else here other than credit: Red Hat's trademark guidelines: http://www.redhat.com/about/corporate/trademark/guidelines/. From my reading of them, it is possible that it is a trademark violation for the Fedora Project to make use of the name Red Hat (or anything similar enough to be confusing), anywhere in its distribution. In .../guidelines/page4.html it states: You may not use "Red Hat" or any confusingly similar mark as a trademark for your product, or use "Red Hat" in any other manner that might cause confusion in the marketplace, including in advertising, on auction sites, or on software or hardware. Additionally, there appears to be no relevant exception made for Fedora in .../guidelines/page9.html. Now, the overall name of the product seems to be the main point of the trademark pages, but it would seem incongruent to me (and i suspect to lawyer-types as well - although i'm not one) that the guidelines for the naming of a subset of the product would be any different to the overall product. Thus it would seem to me that one or more of the following are required: 1. Red Hat change their trademark policy to either: a) make it clear that the trademark policy applies only to the overall distribution, not specific products, and/or b) make a specific trademark policy exception for Fedora (and any other distribution based upon it). 2. Fedora rename or remove redhat-* packages to ensure that anyone redistributing Fedora would not be in grey areas of the Red Hat trademark guidelines. 3. Depending on the outcome of 1. above, Red Hat take another approach to their RPM package naming so as not to put any unnecessary blocks in the way of the Fedora project. Paul P.S. Despite what RPM stands for, it is still a trademark of Red Hat (.../guidelines/page2.html) and could conceivably come under similar trademark guidelines in the future (although i'm not sure what legal difference registered vs. unregistered makes). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 249 bytes Desc: not available URL: From alex.msilva at uol.com.br Sun Nov 9 10:33:06 2003 From: alex.msilva at uol.com.br (Alexander Martins) Date: Sun, 09 Nov 2003 08:33:06 -0200 Subject: Update on RH 7.3 Message-ID: <3FAE17E2.5040604@uol.com.br> Hi, I'd like to know if someone could install the FC1 from a update on RH 7.3. Is it possible? Alexander. -- ************************************************************ + Alexander Martins da Silva 2nd email: alex at iq.ufrj.br + + Rio de Janeiro, Brazil 22,80 s 43,43 w + ************************************************************ From kms at passback.co.uk Sun Nov 9 11:09:25 2003 From: kms at passback.co.uk (Keith Sharp) Date: Sun, 09 Nov 2003 11:09:25 +0000 Subject: FC2 release dates In-Reply-To: <1068306599.14565.26.camel@binkley> References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> <1068216523.4326.2.camel@localhost.localdomain> <1068306599.14565.26.camel@binkley> Message-ID: <1068376164.3959.35.camel@animal> On Sat, 2003-11-08 at 15:50, seth vidal wrote: > > There is a 2.4.1 release out or staging at the moment, and I think I'll > > get a 2.4.2 release out too even, if there's a sufficient amount of > > bugfixes in the near future. > > what things have been fixed, and how do you think it compares to the 2.6 > devel at the moment? > > what things are slated to be in 2.6 over and above 2.4? I would guess the Slashdot headline grabbing feature will be GTK+ 2.4 with the new File Chooser. For more detail you'll need to wait until the call for modules is completed. Keith. From felix at enternett.no Sun Nov 9 11:32:26 2003 From: felix at enternett.no (felix at enternett.no) Date: Sun, 09 Nov 2003 12:32:26 +0100 Subject: Startmenu not allways in correct language.. Message-ID: <3FAE33DA.16487.C30F6F@localhost> Hi all! Successfully installed Fedora Core 1, but I'm having problems with the startmenu. When I choose nynorsk (nn) as language, the menu appears in english. This goes for GNOME and KDE alike. It seems that the rest of GNOME and KDE is more or less translated.. Is this a bug, or is the translation missing? Is there a way I could fix it? Felix From behdad at cs.toronto.edu Sun Nov 9 11:28:33 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sun, 9 Nov 2003 06:28:33 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068274604.14565.22.camel@binkley> Message-ID: On Sat, 8 Nov 2003, nathan r. hruby wrote: > On Sat, 8 Nov 2003, seth vidal wrote: > > > (this, of course coming from the guy who wrote yellowdog updater, > > modified, so I completely understand the hypocrisy) :) > > but to be honest most people miss the yellowdog part entirely, for some > > reason. > > > > yup! yellowdog updater, petrified? > -n From alan at redhat.com Sun Nov 9 11:41:21 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 9 Nov 2003 06:41:21 -0500 (EST) Subject: Startmenu not allways in correct language.. In-Reply-To: <3FAE33DA.16487.C30F6F@localhost> from "felix@enternett.no" at Tach 09, 2003 12:32:26 Message-ID: <200311091141.hA9BfMH09174@devserv.devel.redhat.com> > Successfully installed Fedora Core 1, but I'm having problems with the startmenu. > When I choose nynorsk (nn) as language, the menu appears in english. This goes for > GNOME and KDE alike. It seems that the rest of GNOME and KDE is more or less > translated.. > > Is this a bug, or is the translation missing? Is there a way I could fix it? The menu root comes from redhat-menus which is missing a lot of translations. It doesn't come directly from gnome/kde so you may also want to check the files are translated at all. With Welsh they are but are missing so I just built the missing .po file pending an errata to fix this one. From alan at redhat.com Sun Nov 9 11:43:01 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 9 Nov 2003 06:43:01 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: <3FADF106.3020700@gear.dyndns.org> from "Paul Gear" at Tach 09, 2003 05:47:18 Message-ID: <200311091143.hA9Bh1l09879@devserv.devel.redhat.com> > With all due respect (i've never disagreed with a Linux luminary before > ;-), there's something else here other than credit: Red Hat's trademark > guidelines: http://www.redhat.com/about/corporate/trademark/guidelines/ I don't believe it is an issue. I've forwarded your mail to the right people for comment on whether this needs clarifying however. From alan at redhat.com Sun Nov 9 11:46:07 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 9 Nov 2003 06:46:07 -0500 (EST) Subject: Fedora / RH 9 iso's In-Reply-To: from "Devin Quince" at Tach 08, 2003 09:02:03 Message-ID: <200311091146.hA9Bk7T11051@devserv.devel.redhat.com> > What would be the correct list? I thought this product was now 'community > supported'! Daft question - but is your burner failing on diskc 2 or failing every alternate disk it burns ? From mharris at redhat.com Sun Nov 9 13:10:36 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 9 Nov 2003 08:10:36 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068215481.2305.3.camel@localhost.localdomain> References: <1068215481.2305.3.camel@localhost.localdomain> Message-ID: On Fri, 7 Nov 2003, David Farning wrote: >Date: Fri, 07 Nov 2003 08:31:21 -0600 >From: David Farning >To: fedora-contacts >Content-Type: text/plain >List-Id: For developers, developers, developers >Subject: TradeMarked Name --redhat-config- > > I have been working for the past several weeks on a visual gui >front end for yum. I am considering bringing that knowledge with me to >work on the fedora project. > But, Frankly, I am concerned about contributing to a program >with a trademarked name. I am interested in giving back to the >entiregnu/linux community not just the redhat community. > If someone likes my product, I would like them to be able to >freely use my work irregardless of their distro/flavor. > With this in mind what are your suggestions? > a. Go ahead and work on redhat-config-*. > b. Seek renaming of redhat-config-* to something vendor neutral. > c. Put my work in an up stream project and let it trickle down. Do you have any concerns about contributing to XFree86(TM)? If you have no concerns about contributing to XFree86(TM), why would there be any concerns for contributing to other software which has the name of a trademark in it's title? Are you suggesting we rename XFree86 to XFedora86? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From xspace at slackpkg.ath.cx Sun Nov 9 13:27:59 2003 From: xspace at slackpkg.ath.cx (xspace) Date: Sun, 09 Nov 2003 14:27:59 +0100 Subject: unsubscribing Message-ID: <1068384479.5180.14.camel@slack.ath.cx> anyone know how to unsubscribing from this list i dont know who adds me to the fedora-devel-list > im a happy slackware user From mharris at redhat.com Sun Nov 9 13:18:22 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 9 Nov 2003 08:18:22 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068295925.2545.17.camel@localhost.localdomain> References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068295925.2545.17.camel@localhost.localdomain> Message-ID: On Sat, 8 Nov 2003, David Farning wrote: >> Do you worry about contributing to gnu-cc ? >> >> I do understand the point you are trying to make but its GPL code and so >> you can either rename it or not worry about it (Red Hat ships gnu-cc, nothing >> stops other folks shipping redhat-config-blah really as I understand it). >> >> You'd want different artwork of course. >I wonder what state GUN/Linux would be in if it was redhat-cc ;) > >Early on in my thinking, I looked at putting a paralle project called >gupta (Grand Unified Packaging Tool) at sorceforge . Just pull off the >trademarks and repackage. > >But, wouldn't that that just contribute to FUD. Same product two names, >two locations, two appearances. > >I be honest--I think that the fedora/redhat effort can be a win-win for >everyone involved. I'm just concerned that if the redhat side of the >house starts to push it's fedora developers too hard, (the community >ones at least) they'll jump ship. Then we will have a lose-lose. "Ximian" of "Ximian Evolution" is also a trademark, as is "Linux" itself. Are people going to jump ship and use the GNU Hurd kernel now because these are trademarked? Please people, with all due respect... get a life. ;o) Write some code, and contribute it. Improve the morass of open source code out there, and make all of our lives better. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From dennis at ausil.us Sun Nov 9 13:30:16 2003 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 9 Nov 2003 23:30:16 +1000 Subject: unsubscribing In-Reply-To: <1068384479.5180.14.camel@slack.ath.cx> References: <1068384479.5180.14.camel@slack.ath.cx> Message-ID: <200311092330.16779.dennis@ausil.us> Once upon a time at band camp Sun, 9 Nov 2003 11:27 pm, xspace wrote: > anyone know how to unsubscribing from this list i dont know who adds me > to the fedora-devel-list > im a happy slackware user > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list Sure Do ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ its on the bottom of every mail to the list Dennis From kmaraas at broadpark.no Sun Nov 9 13:28:08 2003 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sun, 09 Nov 2003 14:28:08 +0100 Subject: Startmenu not allways in correct language.. In-Reply-To: <3FAE33DA.16487.C30F6F@localhost> References: <3FAE33DA.16487.C30F6F@localhost> Message-ID: <1068384488.4333.5.camel@localhost.localdomain> s?n, 09.11.2003 kl. 12.32 skrev felix at enternett.no: > Hi all! > > Successfully installed Fedora Core 1, but I'm having problems with the startmenu. > When I choose nynorsk (nn) as language, the menu appears in english. This goes for > GNOME and KDE alike. It seems that the rest of GNOME and KDE is more or less > translated.. > > Is this a bug, or is the translation missing? Is there a way I could fix it? > It's probably just the translation that is missing or not updated. I've been taking care of the bokm?l side of the norwegian translations, but haven't found a volunteer for the nynorsk translations. Are you it? :-) If so you can apply for an account here: http://fedora.redhat.com/projects/translations/ Cheers Kjartan From lance at uklinux.net Sun Nov 9 13:38:54 2003 From: lance at uklinux.net (Lance Davis) Date: Sun, 9 Nov 2003 13:38:54 +0000 (GMT) Subject: TradeMarked Name --redhat-config- In-Reply-To: Message-ID: On Sun, 9 Nov 2003, Mike A. Harris wrote: > On Sat, 8 Nov 2003, David Farning wrote: > > >> Do you worry about contributing to gnu-cc ? > >> > >> I do understand the point you are trying to make but its GPL code and so > >> you can either rename it or not worry about it (Red Hat ships gnu-cc, nothing > >> stops other folks shipping redhat-config-blah really as I understand it). > >> > >> You'd want different artwork of course. > >I wonder what state GUN/Linux would be in if it was redhat-cc ;) > > > >Early on in my thinking, I looked at putting a paralle project called > >gupta (Grand Unified Packaging Tool) at sorceforge . Just pull off the > >trademarks and repackage. > > > >But, wouldn't that that just contribute to FUD. Same product two names, > >two locations, two appearances. > > > >I be honest--I think that the fedora/redhat effort can be a win-win for > >everyone involved. I'm just concerned that if the redhat side of the > >house starts to push it's fedora developers too hard, (the community > >ones at least) they'll jump ship. Then we will have a lose-lose. > > "Ximian" of "Ximian Evolution" is also a trademark, as is "Linux" > itself. Are people going to jump ship and use the GNU Hurd > kernel now because these are trademarked? > > Please people, with all due respect... get a life. ;o) > > Write some code, and contribute it. Improve the morass of open > source code out there, and make all of our lives better. That really sums up redhats attitude does it ?? None of the other projects / companies mentioned , including XFree86 , Apache etc, use trademarks to restrict the distribution of GPL software like Redhat does. Who is to say that in the next release we may be told to rename all of the redhat- rpms as well as redhat-artwork and anaconda-images, because they use redhats trademark - it is redhat inc that have chosen the rules and changed the goalposts at each release of Redhat(TM) Linux(TM). And even though neither we nor our lawyers may agree with redhats interpretation of trademark law we do not have deep enough pockets to argue. It is right that the questions are asked now, and hopefully anmswers given. The use of redhat- for an rpm in theory contravenes redhats published tradmark guidelines, and permission is not given anywhere for its use. Surely if redhat does allow this use then it may be weakening its trademark position .... And what about all of those people calling up redhat inc for support on the redhat- rpms when they havent paid for it because they got it from a back street cd vendor ?? What if I called my package redhat-config-widgit because it configures a widgit to work with redhat/fedora/other rpm based distro ??? So - get yourself a life ... and ask your lawyers to give the answers. Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From erc.caldera at gmx.net Sun Nov 9 13:40:35 2003 From: erc.caldera at gmx.net (=?ISO-8859-1?Q?Er=E7in?= EKER) Date: Sun, 09 Nov 2003 15:40:35 +0200 Subject: OpenOffice i18n pack. Message-ID: <1068385234.3216.29.camel@ATHENA> Hi all, Isn't it better to provide i18n files in seperate packages (OOo-1.1.0-i18n-tr_TR.rpm for turkish) instead of one huge, space killer pack? in Mandrake it's so and i think its better. From behdad at cs.toronto.edu Sun Nov 9 13:51:52 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sun, 9 Nov 2003 08:51:52 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: References: Message-ID: On Sun, 9 Nov 2003, Lance Davis wrote: > That really sums up redhats attitude does it ?? > > None of the other projects / companies mentioned , including XFree86 , > Apache etc, use trademarks to restrict the distribution of GPL software > like Redhat does. Quoting GPL FAQ: The GPL says that anyone who receives a copy of your version from you has the right to redistribute copies (modified or not) of that version. It does not give you permission to distribute the work on any more restrictive basis. So isn't Red Hat already violating that by their restrictions on using their trademark and releasing software with the trademark in it as GPL? > Who is to say that in the next release we may be told to rename all of the > redhat- rpms as well as redhat-artwork and anaconda-images, because they > use redhats trademark - it is redhat inc that have chosen the rules and > changed the goalposts at each release of Redhat(TM) Linux(TM). GPL should protect you perhaps. > And even though neither we nor our lawyers may agree with redhats > interpretation of trademark law we do not have deep enough pockets to > argue. > > It is right that the questions are asked now, and hopefully anmswers > given. The use of redhat- for an rpm in theory contravenes redhats published tradmark guidelines, and > permission is not given anywhere for its use. > > Surely if redhat does allow this use then it may be weakening its > trademark position .... > > And what about all of those people calling up redhat inc for support on > the redhat- rpms when they havent paid for it because they got it from a > back street cd vendor ?? > > What if I called my package redhat-config-widgit because it configures a > widgit to work with redhat/fedora/other rpm based distro ??? > > So - get yourself a life ... and ask your lawyers to give the answers. > > > Lance > > From Yaakov.Bezalel at ca.com Sun Nov 9 13:55:31 2003 From: Yaakov.Bezalel at ca.com (Bezalel, Yaakov) Date: Sun, 9 Nov 2003 13:55:31 -0000 Subject: Cached File system for use over the WAN Message-ID: <9132D793C6CCE34EB1BC9370C631C4A8C1EEA2@ukslms24.ca.com> Hi Fellows, Is there any current project or planned project that supports file system access over the WAN so that any access to a file on a remote server, will result in a file copy to a local cache on the requesting system, and all further requests for that file, will be provided from the local cache, unless the file was modified. For now I am discussing Read Only access on the remote client. I think that I read of a future development for kernel 2.6 that includes "cachefs" as a general cached file system mechanism that can be incorporated within other file system implementations. For now I've since those options, but they do not seem as close to "GA"... http://www.inter-mezzo.org/ http://shfs.sourceforge.net/ Thanks, Jack. Yaakov Bezalel, GCIH Computer Associates Manager, Development Information Technology Israel Tel: +972 3 6450072 Fax: +972 3 5480166 Pager: +972 3 6107199 Mobile: +972 53 994579 mailto:yaakov.bezalel at cai.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharris at redhat.com Sun Nov 9 14:03:28 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 9 Nov 2003 09:03:28 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: References: Message-ID: On Sun, 9 Nov 2003, Lance Davis wrote: >> "Ximian" of "Ximian Evolution" is also a trademark, as is "Linux" >> itself. Are people going to jump ship and use the GNU Hurd >> kernel now because these are trademarked? >> >> Please people, with all due respect... get a life. ;o) >> >> Write some code, and contribute it. Improve the morass of open >> source code out there, and make all of our lives better. > >That really sums up redhats attitude does it ?? Attitude? Um, no. That sums up my personal opinion. Perhaps I shouldn't be feeding the trolls on a Sunday. >None of the other projects / companies mentioned , including >XFree86 , Apache etc, use trademarks to restrict the >distribution of GPL software like Redhat does. We're not using trademarks to restrict the distribution of GPL software, so you are very wrong there. >Who is to say that in the next release we may be told to rename >all of the redhat- rpms as well as redhat-artwork and >anaconda-images, because they use redhats trademark - it is >redhat inc that have chosen the rules and changed the goalposts >at each release of Redhat(TM) Linux(TM). /me rolls eyes >It is right that the questions are asked now, and hopefully >anmswers given. The use of redhat- for an rpm in theory >contravenes redhats published tradmark guidelines, and >permission is not given anywhere for its use. The Red Hat legal department has clarified this issue in the past when people asked, and they've been re-contacted to once again clarify the issue. >Surely if redhat does allow this use then it may be weakening >its trademark position .... You may wish to consult an IP attourney before making such assumptions, but feel free to speculate by all means. >And what about all of those people calling up redhat inc for >support on the redhat- rpms when they havent paid for it because >they got it from a back street cd vendor ?? They are more than happy to participate in the Fedora project also, and contribute patches and improvements to the code, as it is open source and GPL licensed. The more people who are interested in doing so, the merrier. >What if I called my package redhat-config-widgit because it >configures a widgit to work with redhat/fedora/other rpm based >distro ??? IANAL, so I don't have an answer for that one. >So - get yourself a life ... and ask your lawyers to give the >answers. Feel free to call Red Hat legal on the phone and have it clarified directly if you wish. I'm not particularly interested in this pointless flamewar however. Alas, perhaps someone will invoke Godwin's and the S/N ratio will improve on the list. Fingers crossed. Any takers? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sun Nov 9 14:04:34 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 9 Nov 2003 09:04:34 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: References: Message-ID: On Sun, 9 Nov 2003, Behdad Esfahbod wrote: >So isn't Red Hat already violating that by their restrictions on >using their trademark and releasing software with the trademark >in it as GPL? No. The GPL does not have any clause concerning trademarks. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From lance at uklinux.net Sun Nov 9 14:08:41 2003 From: lance at uklinux.net (Lance Davis) Date: Sun, 9 Nov 2003 14:08:41 +0000 (GMT) Subject: TradeMarked Name --redhat-config- In-Reply-To: Message-ID: On Sun, 9 Nov 2003, Mike A. Harris wrote: > On Sun, 9 Nov 2003, Behdad Esfahbod wrote: > > >So isn't Red Hat already violating that by their restrictions on > >using their trademark and releasing software with the trademark > >in it as GPL? > > No. The GPL does not have any clause concerning trademarks. 'any more restrictive basis' would IMHO and IANAL include the use of trademarks. Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From lance at uklinux.net Sun Nov 9 14:14:33 2003 From: lance at uklinux.net (Lance Davis) Date: Sun, 9 Nov 2003 14:14:33 +0000 (GMT) Subject: TradeMarked Name --redhat-config- In-Reply-To: Message-ID: On Sun, 9 Nov 2003, Mike A. Harris wrote: > >That really sums up redhats attitude does it ?? > > Attitude? Um, no. That sums up my personal opinion. Perhaps I > shouldn't be feeding the trolls on a Sunday. or even trolling yourself. .. > > > >None of the other projects / companies mentioned , including > >XFree86 , Apache etc, use trademarks to restrict the > >distribution of GPL software like Redhat does. > > We're not using trademarks to restrict the distribution of GPL > software, so you are very wrong there. > 'released under the GPL as long as you conform to our trademark requirements' seems clear cut to me. http://www.redhat.com/about/corporate/trademark/guidelines/page6.html is even clearer. > >Who is to say that in the next release we may be told to rename > >all of the redhat- rpms as well as redhat-artwork and > >anaconda-images, because they use redhats trademark - it is > >redhat inc that have chosen the rules and changed the goalposts > >at each release of Redhat(TM) Linux(TM). > > /me rolls eyes attitude again ??? > >It is right that the questions are asked now, and hopefully > >anmswers given. The use of redhat- for an rpm in theory > >contravenes redhats published tradmark guidelines, and > >permission is not given anywhere for its use. > > The Red Hat legal department has clarified this issue in the past > when people asked, and they've been re-contacted to once > again clarify the issue. I dont believe they have clarified this actual issue, which is why AC said he would refer it to them. > >Surely if redhat does allow this use then it may be weakening > >its trademark position .... > > You may wish to consult an IP attourney before making such > assumptions, but feel free to speculate by all means. I already have - I am just going by missives from redhat ... > >What if I called my package redhat-config-widgit because it > >configures a widgit to work with redhat/fedora/other rpm based > >distro ??? > > IANAL, so I don't have an answer for that one. > ... ask your lawyers to give the > >answers. Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From behdad at cs.toronto.edu Sun Nov 9 14:27:15 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sun, 9 Nov 2003 09:27:15 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: References: Message-ID: On Sun, 9 Nov 2003, Mike A. Harris wrote: > On Sun, 9 Nov 2003, Behdad Esfahbod wrote: > > >So isn't Red Hat already violating that by their restrictions on > >using their trademark and releasing software with the trademark > >in it as GPL? > > No. The GPL does not have any clause concerning trademarks. Not the trademark itself, the fact that Red Hat puts constraints on using their trademark that happens to be in the name of the software released under GPL. From mharris at redhat.com Sun Nov 9 14:28:27 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 9 Nov 2003 09:28:27 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: References: Message-ID: On Sun, 9 Nov 2003, Lance Davis wrote: >> >So isn't Red Hat already violating that by their restrictions on >> >using their trademark and releasing software with the trademark >> >in it as GPL? >> >> No. The GPL does not have any clause concerning trademarks. > >'any more restrictive basis' would IMHO and IANAL include the use of >trademarks. There is no restriction on the use, copying, modification, redistribution of the code, which is what the GPL covers. Since these restrictions do not exist, there is no conflict with the GPL. Feel free to point out any case law which contradicts this however, I'd definitely be interested in reading up on any legal precedents. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From skvidal at phy.duke.edu Sun Nov 9 14:27:07 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 Nov 2003 09:27:07 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068295925.2545.17.camel@localhost.localdomain> Message-ID: <1068388026.16321.12.camel@binkley> > "Ximian" of "Ximian Evolution" is also a trademark, as is "Linux" > itself. Are people going to jump ship and use the GNU Hurd > kernel now because these are trademarked? > curiously enough it is not called ximian evolution in the menus, although it used to be. > Please people, with all due respect... get a life. ;o) > > Write some code, and contribute it. Improve the morass of open > source code out there, and make all of our lives better. Ok, I have written some code, I have made some people's lives better, I think. So let me ask a few questions: - If I were to use the Novell-Python-Libraries that were under a non-renaming but open license and require them for yum would your marketing and license people like that advertisement for your competitors? - What about naming yum redhat-config-packages-tui - could I do that? OR would I have lawyers up my butt in 30 minutes? I think some clarification would be good and I also think that there is no need for telling people to get a life. They're confused about this issue as I am, and b/c they are not lawyers we'd love to have some clarification. B/c of the trademark issue people are afraid of running afoul of red hat's lawyers, I know I am. -sv From behdad at cs.toronto.edu Sun Nov 9 14:32:20 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sun, 9 Nov 2003 09:32:20 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: References: Message-ID: On Sun, 9 Nov 2003, Mike A. Harris wrote: > >What if I called my package redhat-config-widgit because it > >configures a widgit to work with redhat/fedora/other rpm based > >distro ??? > > IANAL, so I don't have an answer for that one. > > > >So - get yourself a life ... and ask your lawyers to give the > >answers. > > Feel free to call Red Hat legal on the phone and have it > clarified directly if you wish. I'm not particularly interested > in this pointless flamewar however. I don't call it flamewar still. I'm a bit concerned about the issue, as I'm thinking about something I'm working on redhat-config-laptop, just to go with the other stuff... > Alas, perhaps someone will invoke Godwin's and the S/N ratio will > improve on the list. Fingers crossed. Any takers? Counting ships...zzz... behdad From hugo at devin.com.br Sun Nov 9 14:37:44 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Sun, 09 Nov 2003 11:37:44 -0300 Subject: Update on RH 7.3 In-Reply-To: <3FAE17E2.5040604@uol.com.br> References: <3FAE17E2.5040604@uol.com.br> Message-ID: <3FAE5138.30105@devin.com.br> Alexander Martins wrote: > Hi, > > I'd like to know if someone could install the FC1 from a update on > RH 7.3. Is it possible? I think it's possible because someone already reported sucessfull updates from RH to FC1. But since you're using an older version of RH, you may want to try (I don't see any problem updating). I recommend you using apt for that. I used to convert all my RH 7.3 systems to RH9 and it was very very easy to do. I think doing this with FC is not a bad idea (I didn't tested it yet too). Give it a try and tell us :) > Alexander. []'s Hugo From hugo at devin.com.br Sun Nov 9 14:41:07 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Sun, 09 Nov 2003 11:41:07 -0300 Subject: OpenOffice i18n pack. In-Reply-To: <1068385234.3216.29.camel@ATHENA> References: <1068385234.3216.29.camel@ATHENA> Message-ID: <3FAE5203.7060302@devin.com.br> Er?in EKER wrote: > Hi all, > > Isn't it better to provide i18n files in seperate packages > (OOo-1.1.0-i18n-tr_TR.rpm for turkish) instead of one huge, space killer > pack? in Mandrake it's so and i think its better. I agree with that, mainly because users may want to install one or two language on their system, but sometimes they end with lots of unusued language files filling up their space. []'s Hugo From dennis at ausil.us Sun Nov 9 14:47:58 2003 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 10 Nov 2003 00:47:58 +1000 Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068388026.16321.12.camel@binkley> References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068388026.16321.12.camel@binkley> Message-ID: <200311100047.58962.dennis@ausil.us> Once upon a time at band camp Mon, 10 Nov 2003 12:27 am, seth vidal wrote: > Ok, > I have written some code, I have made some people's lives better, I > think. So let me ask a few questions: > - If I were to use the Novell-Python-Libraries that were under a > non-renaming but open license and require them for yum would your > marketing and license people like that advertisement for your > competitors? > - What about naming yum redhat-config-packages-tui - could I do that? > OR would I have lawyers up my butt in 30 minutes? Thank you for your work Seth why not just call it just call it linux-config-packages or something like that. something i think that would be good for newbies is a wrapper for all the different config tools like kcontrol is for the different kde control modules you can run the control center or you can run each tool seperatly. Dennis From jakub at redhat.com Sun Nov 9 14:53:12 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Sun, 9 Nov 2003 09:53:12 -0500 Subject: OpenOffice i18n pack. In-Reply-To: <3FAE5203.7060302@devin.com.br>; from hugo@devin.com.br on Sun, Nov 09, 2003 at 11:41:07AM -0300 References: <1068385234.3216.29.camel@ATHENA> <3FAE5203.7060302@devin.com.br> Message-ID: <20031109095312.E8854@devserv.devel.redhat.com> On Sun, Nov 09, 2003 at 11:41:07AM -0300, Hugo Cisneiros wrote: > Er?in EKER wrote: > > > Hi all, > > > > Isn't it better to provide i18n files in seperate packages > > (OOo-1.1.0-i18n-tr_TR.rpm for turkish) instead of one huge, space killer > > pack? in Mandrake it's so and i think its better. > > I agree with that, mainly because users may want to install one or two > language on their system, but sometimes they end with lots of unusued > language files filling up their space. The files are marked with %lang() (similarly to e.g. glibc-common locales). If you are too concerned about disk space, you can just select different languages instead of all in rpm configuration (e.g. override %_install_langs in ~/.rpmmacros). Older RH distributions used to do that, I think since RHL9 the default is all, since the confusion it created (people installing say en and de language support only and then wondering why they cannot use italian) overweighted the disk space savings for average disk sizes these days. Jakub From skvidal at phy.duke.edu Sun Nov 9 14:53:11 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 Nov 2003 09:53:11 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: <200311100047.58962.dennis@ausil.us> References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068388026.16321.12.camel@binkley> <200311100047.58962.dennis@ausil.us> Message-ID: <1068389590.16321.14.camel@binkley> > Thank you for your work Seth > > why not just call it just call it linux-config-packages or something like > that. something i think that would be good for newbies is a wrapper for all > the different config tools like kcontrol is for the different kde control > modules you can run the control center or you can run each tool seperatly. yum runs on opendarwin and should run just fine on freebsd + openpkg rpm or solaris + openpkg rpm. so, it's not just a linux-config-packages. But your suggestion is not a bad one. -sv From alan at redhat.com Sun Nov 9 15:05:28 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 9 Nov 2003 10:05:28 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: from "Lance Davis" at Tach 09, 2003 01:38:54 Message-ID: <200311091505.hA9F5Sr05171@devserv.devel.redhat.com> > > Write some code, and contribute it. Improve the morass of open > > source code out there, and make all of our lives better. > > That really sums up redhats attitude does it ?? Yes. Those two lines really catch what Fedora is all about. Perhaps you should go troll somewhere else ? From erc.caldera at gmx.net Sun Nov 9 15:08:31 2003 From: erc.caldera at gmx.net (=?ISO-8859-9?Q?Er=E7in?= EKER) Date: Sun, 9 Nov 2003 17:08:31 +0200 Subject: OpenOffice i18n pack. In-Reply-To: <20031109095312.E8854@devserv.devel.redhat.com> References: <1068385234.3216.29.camel@ATHENA> <3FAE5203.7060302@devin.com.br> <20031109095312.E8854@devserv.devel.redhat.com> Message-ID: <20031109170831.5adcc619.erc.caldera@gmx.net> Sun, 9 Nov 2003 09:53:12 -0500 tarihinde Jakub Jelinek 'nin yazd?klar?: > The files are marked with %lang() (similarly to e.g. glibc-common > locales). If you are too concerned about disk space, you can just > select different languages instead of all in rpm configuration (e.g. > override%_install_langs in ~/.rpmmacros). > Older RH distributions used to do that, I think since RHL9 the default > is all, since the confusion it created (people installing say en and > de language support only and then wondering why they cannot use > italian) overweighted the disk space savings for average disk sizes > these days. > > Jakub On MDK locales thats going to be installed is sellected automaticly, for example if i am using turkish for installation turkish locales are installed by default. -- Er?in EKER UIN: 8216618 Jabber: ercineker at jabber.org Time out error: Operator fell asleep while waiting for Windows NT to complete boot procedure. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From strange at nsk.yi.org Sun Nov 9 15:27:32 2003 From: strange at nsk.yi.org (Luciano Miguel Ferreira Rocha) Date: Sun, 9 Nov 2003 15:27:32 +0000 Subject: TradeMarked Name --redhat-config- In-Reply-To: References: Message-ID: <20031109152732.GA3214@nsk.no-ip.org> On Sun, Nov 09, 2003 at 02:08:41PM +0000, Lance Davis wrote: > On Sun, 9 Nov 2003, Mike A. Harris wrote: > > > On Sun, 9 Nov 2003, Behdad Esfahbod wrote: > > > > >So isn't Red Hat already violating that by their restrictions on > > >using their trademark and releasing software with the trademark > > >in it as GPL? > > > > No. The GPL does not have any clause concerning trademarks. > > 'any more restrictive basis' would IMHO and IANAL include the use of > trademarks. Copyright law is independent of trademark law. The GPL is a distribution licence dependent on copyright law. It's one thing to take all GPL packages on RedHat Linux and sell it as Super Linux for $2000, it's another to name a product Best RedHat, whether based on RedHat software or some other software. Linux is also a registered trademark, not to be used at free. Linus, the trademark owner, allows a lot of uses by 3rd parties, but reserves for himself the right to prosecute malicious uses, or just damaging uses. You can take all the Linux kernel source, rename it to Optimux or something, and sell it if following the GPL. But you can't take a BSD kernel and sell it as Linux. The same is, I suppose, for RedHat, but in your case you're not selling a product but creating a package. It, in itself is just a product, but it isn't a damaging to RedHat's trademark as a new software distribution. And it would be damaging, not because RedHat feels like your damaging it, but because trademark law states that it must be actively prosecuted, or it may be lost, contrary to copyright. I'll give you two advices: 1. If you really want to use that name for your software, contact Red Hat's legal department as Mike Harris has suggested. 2. Change the name. redhat-config-* is a recent name, used by Red Hat to name the packages it made for configuration of services distributed within its RedHat Linux product. widget-config is as good as name as any. Regards, Luciano Rocha PS: AINAL From d.quince at comcast.net Sun Nov 9 15:43:18 2003 From: d.quince at comcast.net (Devin Quince) Date: Sun, 9 Nov 2003 08:43:18 -0700 Subject: Fedora / RH 9 iso's In-Reply-To: <200311091146.hA9Bk7T11051@devserv.devel.redhat.com> Message-ID: I failed to check to checksum of the image. It was bad, as was my 9.0. Thanks for the input. I will direct questions like this to fedora-list group, but I am still confused, as if I plan to develop on this platform, I need to install it it first, so I come to those with the most knowledge, but it is done. Thanks again. -----Original Message----- From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list-admin at redhat.com]On Behalf Of Alan Cox Sent: Sunday, November 09, 2003 4:46 AM To: fedora-devel-list at redhat.com Subject: Re: Fedora / RH 9 iso's > What would be the correct list? I thought this product was now 'community > supported'! Daft question - but is your burner failing on diskc 2 or failing every alternate disk it burns ? -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.534 / Virus Database: 329 - Release Date: 10/31/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.534 / Virus Database: 329 - Release Date: 10/31/2003 From kernel at pacrimopen.com Sun Nov 9 17:55:11 2003 From: kernel at pacrimopen.com (Joshua Schmidlkofer) Date: Sun, 09 Nov 2003 09:55:11 -0800 Subject: OpenOffice i18n pack. In-Reply-To: <20031109095312.E8854@devserv.devel.redhat.com> References: <1068385234.3216.29.camel@ATHENA> <3FAE5203.7060302@devin.com.br> <20031109095312.E8854@devserv.devel.redhat.com> Message-ID: <1068400510.13561.155.camel@menion.home> > The files are marked with %lang() (similarly to e.g. glibc-common locales). > If you are too concerned about disk space, you can just select different > languages instead of all in rpm configuration (e.g. override > %_install_langs in ~/.rpmmacros). > Older RH distributions used to do that, I think since RHL9 the default > is all, since the confusion it created (people installing say en and de > language support only and then wondering why they cannot use italian) > overweighted the disk space savings for average disk sizes these days. Yeah, and that is easy and intuitive. js From corsepiu at faw.uni-ulm.de Sun Nov 9 18:19:27 2003 From: corsepiu at faw.uni-ulm.de (Ralf Corsepius) Date: Sun, 09 Nov 2003 19:19:27 +0100 Subject: OpenOffice i18n pack. In-Reply-To: <20031109095312.E8854@devserv.devel.redhat.com> References: <1068385234.3216.29.camel@ATHENA> <3FAE5203.7060302@devin.com.br> <20031109095312.E8854@devserv.devel.redhat.com> Message-ID: <1068401967.10640.125.camel@mccallum.corsepiu.faw.uni-ulm.de> On Sun, 2003-11-09 at 15:53, Jakub Jelinek wrote: > On Sun, Nov 09, 2003 at 11:41:07AM -0300, Hugo Cisneiros wrote: > > Er?in EKER wrote: > > > > > Hi all, > > > > > > Isn't it better to provide i18n files in seperate packages > > > (OOo-1.1.0-i18n-tr_TR.rpm for turkish) instead of one huge, space killer > > > pack? in Mandrake it's so and i think its better. > > > > I agree with that, mainly because users may want to install one or two > > language on their system, but sometimes they end with lots of unusued > > language files filling up their space. > > The files are marked with %lang() (similarly to e.g. glibc-common locales). > If you are too concerned about disk space, you can just select different > languages instead of all in rpm configuration (e.g. override > %_install_langs in ~/.rpmmacros). > Older RH distributions used to do that, I think since RHL9 the default > is all, since the confusion it created (people installing say en and de > language support only and then wondering why they cannot use italian) > overweighted the disk space savings for average disk sizes these days. I don't like this approach ;) Anyway, for modem users the diskspace isn't the actual problem. It's the size of the openoffice.org tarballs allocating bandwidth and producing phone costs. Remember, Fedora can be installed selectively via yum/apt from a distant server, which can help modem users save a lot of bandwidth/money. Ralf From skvidal at phy.duke.edu Sun Nov 9 18:22:52 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 Nov 2003 13:22:52 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068274604.14565.22.camel@binkley> Message-ID: <1068402172.16321.56.camel@binkley> On Sun, 2003-11-09 at 06:28, Behdad Esfahbod wrote: > On Sat, 8 Nov 2003, nathan r. hruby wrote: > > > On Sat, 8 Nov 2003, seth vidal wrote: > > > > > (this, of course coming from the guy who wrote yellowdog updater, > > > modified, so I completely understand the hypocrisy) :) > > > but to be honest most people miss the yellowdog part entirely, for some > > > reason. > > > > > > > yup! > > yellowdog updater, petrified? > YUP was the Yellowdog UPdater. so maybe yum should be yupm but considering it shares maybe 2 functions with yup it doesn't seem all that important. To be completely honest, yum was selected as a name b/c it was: 1. short 2. not already taken :) -sv From pozsy at uhulinux.hu Sun Nov 9 18:29:27 2003 From: pozsy at uhulinux.hu (Pozsar Balazs) Date: Sun, 9 Nov 2003 19:29:27 +0100 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: <1068236427.12684.60.camel@laptop> References: <1068236427.12684.60.camel@laptop> Message-ID: <20031109182927.GB20480@unicorn.sch.bme.hu> On Fri, Nov 07, 2003 at 10:20:28AM -1000, Warren Togami wrote: > C-3. Non-Numeric Version to Release > ----------------------------------- > As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric > versioned packages can be problematic so they must be treated with care. > These are cases where the upstream version has letters rather than > simple numbers in their version. Often they have tags like alpha, beta, > rc, or letters like a and b denoting that it is a version before or > after the number. Read section B to understand why we cannot simply put > these letters into the version tag. > > Release Tag for Pre-Release Packages: > 0.%{X}.%{alphatag} > Release Tag for Non-Numeric Post-Release Packages: > %{X}.%{alphatag} > Where %{X} is the vepoch increment, and %{alphatag} is the string that > came from the version. [...] PLEASE, take a look at dpkg's and apt-get's way of handling pre-release versions, I really do think that should be used in rpm-based distros too. The idea is to introduce a character, namely '~' (tilde), which is sorted specially: in comparison it comes before anything else. This way, you can get ordering like this: 1.0~alpha1 < 1.0~alpha2 < 1.0~beta < 1.0 < 1.0a < 1.0b 1.0~pre1 < 1.0~rc1 < 1.0 < 1.0.1 < 1.0.2 ... and so on. Hope you got the point. I know it should be implemented in rpm, and this is not a trivial move, but please do think about it. It will make all these pre-release-versioning nightmares go away. bye, -- pozsy From jakub at redhat.com Sun Nov 9 18:53:57 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Sun, 9 Nov 2003 13:53:57 -0500 Subject: OpenOffice i18n pack. In-Reply-To: <1068401967.10640.125.camel@mccallum.corsepiu.faw.uni-ulm.de>; from corsepiu@faw.uni-ulm.de on Sun, Nov 09, 2003 at 07:19:27PM +0100 References: <1068385234.3216.29.camel@ATHENA> <3FAE5203.7060302@devin.com.br> <20031109095312.E8854@devserv.devel.redhat.com> <1068401967.10640.125.camel@mccallum.corsepiu.faw.uni-ulm.de> Message-ID: <20031109135357.F8854@devserv.devel.redhat.com> On Sun, Nov 09, 2003 at 07:19:27PM +0100, Ralf Corsepius wrote: > Anyway, for modem users the diskspace isn't the actual problem. It's the > size of the openoffice.org tarballs allocating bandwidth and producing > phone costs. > Remember, Fedora can be installed selectively via yum/apt from a distant > server, which can help modem users save a lot of bandwidth/money. E.g. with glibc-common, separating the rpm into smaller rpms per locale is a bad idea, since locales which can be hardlinked (e.g. lots of UTF-8 locales use identical (and quite big) LC_CTYPE and/or LC_COLLATE) suddenly cannot be and thus eat way more disk space. Jakub From aoliva at redhat.com Sun Nov 9 19:06:02 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 09 Nov 2003 17:06:02 -0200 Subject: TradeMarked Name --redhat-config- In-Reply-To: References: Message-ID: On Nov 9, 2003, Behdad Esfahbod wrote: > On Sun, 9 Nov 2003, Lance Davis wrote: >> That really sums up redhats attitude does it ?? >> >> None of the other projects / companies mentioned , including XFree86 , >> Apache etc, use trademarks to restrict the distribution of GPL software >> like Redhat does. > So isn't Red Hat already violating that by their restrictions on > using their trademark and releasing software with the trademark > in it as GPL? redhat is not a trademark. Red Hat is, and so are the logos. Those, that Red Hat needs to protect, are in separate packages, whose licenses are not the GNU GPL. My understanding is that those that *are* GPLed can't be encumbered with trademark, just like they can't be encumbered by patents. But then, IANAL, so my understanding may be off. > GPL should protect you perhaps. I'm convinced it does, for packages that are indeed released under the GNU GPL. This is not the case of fedora-logos or anaconda-images, since their license is not the GNU GPL. But then again, IANAL. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From skvidal at phy.duke.edu Sun Nov 9 19:10:39 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 Nov 2003 14:10:39 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: References: Message-ID: <1068405039.16321.69.camel@binkley> > redhat is not a trademark. Red Hat is, and so are the logos. Those, > that Red Hat needs to protect, are in separate packages, whose > licenses are not the GNU GPL. My understanding is that those that > *are* GPLed can't be encumbered with trademark, just like they can't > be encumbered by patents. But then, IANAL, so my understanding may be > off. > > > GPL should protect you perhaps. > > I'm convinced it does, for packages that are indeed released under the > GNU GPL. This is not the case of fedora-logos or anaconda-images, > since their license is not the GNU GPL. But then again, IANAL. Does the GPL protect you? http://www.open-mag.com/features/Vol_24/GPL/gpl.htm not sure it does. Do any of the people who might want to help out want have the money to find out if it protects you? I don't. But let's drop this as a trademark issue and bring up a more solid point, if there are new tools written by !red hat people why would this programs be named redhat-config-something. For that matter why fedora-config-something as 'fedora' JUST fedora is a TM of red hat. config-something seems fine to me, but somebrand-config-something seems unnecessary. -sv From stan at ccs.neu.edu Sun Nov 9 19:39:58 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Sun, 09 Nov 2003 14:39:58 -0500 Subject: Waste of time... (aka. Trademarks) Message-ID: <1068406797.4299.6.camel@wvanl14.resnet.neu.edu> Hey, Why is that whenever I've looked in my Inbox this weekend it has been full of this trademark crap. I've read over some of the messages, but I think I can speak for many people when I say: just get off it. Many of the large and small companies who contribute to opensource have patents, trademarks, etc... but they are used in a way that they are not a nuisance to developers or users. They have spent time and money to fund this 'Free Software' we use today and its time some of you ungrateful pricks realize this and move on. Fedora Core 1 was just released, and there is plenty to be done before the next release. And there are plenty of bugs left out there that the community could help with, so could attention please be refocused to the issues this list and project were meant to involve? -sb -------------- 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 Sun Nov 9 19:47:54 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 Nov 2003 14:47:54 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: <200311090026.hA90Qct04615@devserv.devel.redhat.com> References: <200311090026.hA90Qct04615@devserv.devel.redhat.com> Message-ID: <1068407274.16321.82.camel@binkley> On Sat, 2003-11-08 at 19:26, Alan Cox wrote: > > > IMHO it is the same in all cases. It's about credit. Whether you'd keep > > > the command line redhat-config-foo on a non RH system is a different > > > matter altogether. > > > > Right, but I'm not doing advertising for a corporation by having apache, > > or gnu or berkeley in the reqs. > > Actually Apache is a corporation. MySQL is a business, UC Berkeley pretty > much is, sendmail is. > UC Berkeley is a school, just like duke - non-profit organizations, Apache is Apache Software Foundation, I believe, and that's also a non-profit. Mysql and sendmail are business, You're entirely correct, but sendmail was a program before it was a company-oriented one, iirc. and mysql has already had trademark trouble. But neither of those are companies that directly compete with red hat in the distro field, I really would be curious about novell-config-foo being included in red hat enterprise linux, or even in fedora core. -sv From lance at uklinux.net Sun Nov 9 19:52:54 2003 From: lance at uklinux.net (Lance Davis) Date: Sun, 9 Nov 2003 19:52:54 +0000 (GMT) Subject: TradeMarked Name --redhat-config- In-Reply-To: Message-ID: On Sun, 9 Nov 2003, Mike A. Harris wrote: > On Sun, 9 Nov 2003, Lance Davis wrote: > > >> >So isn't Red Hat already violating that by their restrictions on > >> >using their trademark and releasing software with the trademark > >> >in it as GPL? > >> > >> No. The GPL does not have any clause concerning trademarks. > > > >'any more restrictive basis' would IMHO and IANAL include the use of > >trademarks. > > There is no restriction on the use, of course there is a restriction on the use ...... (especially in the case of Enterprise Linux if you are a customer ;) > copying, modification, redistribution errmm and of the redistribution ... Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From skvidal at phy.duke.edu Sun Nov 9 19:56:05 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 Nov 2003 14:56:05 -0500 Subject: Waste of time... (aka. Trademarks) In-Reply-To: <1068406797.4299.6.camel@wvanl14.resnet.neu.edu> References: <1068406797.4299.6.camel@wvanl14.resnet.neu.edu> Message-ID: <1068407764.16321.88.camel@binkley> On Sun, 2003-11-09 at 14:39, Stan Bubrouski wrote: > Hey, > > Why is that whenever I've looked in my Inbox this weekend it has been > full of this trademark crap. I've read over some of the messages, but I > think I can speak for many people when I say: just get off it. > Let me ask this - if you were worried about being sued for Trademark infringement would you want this ironed out now, or later? > Many of the large and small companies who contribute to opensource have > patents, trademarks, etc... but they are used in a way that they are not > a nuisance to developers or users. They have spent time and money to > fund this 'Free Software' we use today and its time some of you > ungrateful pricks realize this and move on. Oh, but what about when I spent my time and no money to develop software that red hat uses, should they stop being ungrateful pricks and realize I am owed something? Oh, wait, I'm not owed anything, I chose to release it under a license which said no one owes me anything. > Fedora Core 1 was just released, and there is plenty to be done before > the next release. And there are plenty of bugs left out there that the > community could help with, so could attention please be refocused to the > issues this list and project were meant to involve? Yep, and a lot of us want to make sure we're going to be contributing in such a way that 1. will make it possible for others not associated with red hat to use it and 2. won't cause us to be victim of a lawsuit. -sv From mharris at redhat.com Sun Nov 9 20:05:49 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 9 Nov 2003 15:05:49 -0500 (EST) Subject: S/N ratio of this list is just too low for my tastes... In-Reply-To: References: Message-ID: On Sun, 9 Nov 2003, Lance Davis wrote: >> >'any more restrictive basis' would IMHO and IANAL include the use of >> >trademarks. >> >> There is no restriction on the use, > >of course there is a restriction on the use ...... > >(especially in the case of Enterprise Linux if you are a customer ;) > >> copying, modification, redistribution > >errmm and of the redistribution ... Sorry, but you seem dead set on just arguing for the sake of arguing, and I've got more productive things to do with my time than waste it on this list with petty threads like this. In fact, the majority of traffic on this list is useless garbage unrelated to actual real development issues, and is thus not really useful to me. Since this forum isn't moderated and has no controls on keeping it focused on any form of actual development topic, I've decided to unsubscribe from the list in hopes in a month or so it will have turned into something more useful to actual developmental issues, and not just idle chit chat, mp3/dvd/ntfs whining and other legal issues including patents, copyrights, trademarks, etc. There's just too much volume and too little useful content for the list to be useful to me. If anyone has bugs to report about X et al. or feature requests, file them in bugzilla. For email related development or tech support discussion join xfree86-list at redhat.com and post there. I'll be in IRC on #fedora-devel if anyone needs to discuss anything actually technical or remotely related to development or creativity at all in the meantime. Goodbye all. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From stan at ccs.neu.edu Sun Nov 9 20:14:26 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Sun, 09 Nov 2003 15:14:26 -0500 Subject: Waste of time... (aka. Trademarks) In-Reply-To: <1068407764.16321.88.camel@binkley> References: <1068406797.4299.6.camel@wvanl14.resnet.neu.edu> <1068407764.16321.88.camel@binkley> Message-ID: <1068408866.4299.14.camel@wvanl14.resnet.neu.edu> On Sun, 2003-11-09 at 14:56, seth vidal wrote: > Let me ask this - if you were worried about being sued for Trademark > infringement would you want this ironed out now, or later? > If you're so paranoid then join another project or work it out with RH personally. They do have lawyers you can talk to. > Oh, but what about when I spent my time and no money to develop software > that red hat uses, should they stop being ungrateful pricks and realize > I am owed something? Oh, wait, I'm not owed anything, I chose to release > it under a license which said no one owes me anything. > Yeah and so did thousands of other people who aren't on this list whining about trademarks. RH answered your questions, if your not satisfied take this up with them personally. > Yep, and a lot of us want to make sure we're going to be contributing in > such a way that 1. will make it possible for others not associated with > red hat to use it and 2. won't cause us to be victim of a lawsuit. > You and your cohorts can take this up with RH personally, despite how you feel, development goes on, and this is the development list, not a trademark list. -sb -------------- 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 xose at wanadoo.es Sun Nov 9 20:17:43 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sun, 09 Nov 2003 21:17:43 +0100 Subject: Arjan AMD64 kernel-2.6.0-testX RPMS References: <1068349165.4430.163.camel@laptop> Message-ID: <3FAEA0E7.5060906@wanadoo.es> Warren Togami wrote: > http://people.redhat.com/arjanv/2.5/ > > I just noticed that Arjan has x86_64 (AMD64) kernels in addition to the > i586 and i686 kernels of 2.6.0-testX. Cool! It would be nice that someone will package some user space tools like lvm2, evms, XFS utils........ -- HTML mails are going to trash automagically From skvidal at phy.duke.edu Sun Nov 9 20:20:52 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 Nov 2003 15:20:52 -0500 Subject: Waste of time... (aka. Trademarks) In-Reply-To: <1068408866.4299.14.camel@wvanl14.resnet.neu.edu> References: <1068406797.4299.6.camel@wvanl14.resnet.neu.edu> <1068407764.16321.88.camel@binkley> <1068408866.4299.14.camel@wvanl14.resnet.neu.edu> Message-ID: <1068409252.16321.91.camel@binkley> > If you're so paranoid then join another project or work it out with RH > personally. They do have lawyers you can talk to. I intend to do the latter. > Yeah and so did thousands of other people who aren't on this list > whining about trademarks. RH answered your questions, if your not > satisfied take this up with them personally. Whining? When red hat states their position on trademarks is that whining too? People want greater clarity as the whole fedora project blurs the issue with regard to trademarks. > You and your cohorts can take this up with RH personally, despite how > you feel, development goes on, and this is the development list, not a > trademark list. and 'my cohorts'? hehe I'll, no wait, "We'll", do that. -sv From alan at redhat.com Sun Nov 9 20:32:24 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 9 Nov 2003 15:32:24 -0500 (EST) Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068407274.16321.82.camel@binkley> from "seth vidal" at Tach 09, 2003 02:47:54 Message-ID: <200311092032.hA9KWOf17574@devserv.devel.redhat.com> > UC Berkeley is a school, just like duke - non-profit organizations, > Apache is Apache Software Foundation, I believe, and that's also a > non-profit. Apache Software foundation is a corporation. At least learn what a corporation is -before- you start moaning about it From skvidal at phy.duke.edu Sun Nov 9 20:33:29 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 Nov 2003 15:33:29 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: <200311092032.hA9KWOf17574@devserv.devel.redhat.com> References: <200311092032.hA9KWOf17574@devserv.devel.redhat.com> Message-ID: <1068410009.16321.94.camel@binkley> On Sun, 2003-11-09 at 15:32, Alan Cox wrote: > > UC Berkeley is a school, just like duke - non-profit organizations, > > Apache is Apache Software Foundation, I believe, and that's also a > > non-profit. > > Apache Software foundation is a corporation. At least learn what a > corporation is -before- you start moaning about it > > odd - maybe their webpage is wrong. The Apache Software Foundation is a private operating foundation that is registered as a non-profit, charitable organization under Section 501(c)(3) of the U.S. Internal Revenue Code. This means that, for individuals within the U.S., donations to the ASF should be tax-deductible. We are not accountants, so this cannot be trusted as financial advice of any kind, but hopefully this description will be useful to those who advise you in these matters. or should I be more clear. NOT-for-profit corporations. -sv From alan at redhat.com Sun Nov 9 20:44:57 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 9 Nov 2003 15:44:57 -0500 (EST) Subject: Bootstrapping Fedora off old Red Hat Message-ID: <200311092044.hA9KivT22354@devserv.devel.redhat.com> I'm wondering if any of the folks who build off very old Red Hat (7.x) like MIPS, Sparc and ARM have tried bootstrapping FC from that base and what approach they found best. I'm pondering setting a box crunching through Fedora for S/390 but initially its a maze of twisty little dependancies between libraries, tools and compilers. Alan From katzj at redhat.com Sun Nov 9 20:50:09 2003 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 09 Nov 2003 15:50:09 -0500 Subject: Arjan AMD64 kernel-2.6.0-testX RPMS In-Reply-To: <3FAEA0E7.5060906@wanadoo.es> References: <1068349165.4430.163.camel@laptop> <3FAEA0E7.5060906@wanadoo.es> Message-ID: <1068411009.7225.58.camel@edoras.local.net> On Sun, 2003-11-09 at 15:17, Xose Vazquez Perez wrote: > Warren Togami wrote: > > http://people.redhat.com/arjanv/2.5/ > > > > I just noticed that Arjan has x86_64 (AMD64) kernels in addition to the > > i586 and i686 kernels of 2.6.0-testX. Cool! > > It would be nice that someone will package some user space tools > like lvm2, evms, XFS utils........ We'll get there, at least on lvm2/evms. Have to have time to sit down and evaluate the two and decide which looks more promising. Jeremy From kjb at dds.nl Sun Nov 9 22:22:59 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Sun, 09 Nov 2003 23:22:59 +0100 Subject: Bootstrapping Fedora off old Red Hat In-Reply-To: <200311092044.hA9KivT22354@devserv.devel.redhat.com> References: <200311092044.hA9KivT22354@devserv.devel.redhat.com> Message-ID: <1068416579.4564.15.camel@isengard> On Sun, 2003-11-09 at 21:44, Alan Cox wrote: > I'm wondering if any of the folks who build off very old Red Hat (7.x) like > MIPS, Sparc and ARM have tried bootstrapping FC from that base and what > approach they found best. I'm pondering setting a box crunching through > Fedora for S/390 but initially its a maze of twisty little dependancies > between libraries, tools and compilers. I'm wondering: is there some public documentation about doing a full rebuild for Fedora? Some build scripts would also help people to rebuild for the more exotic architectures (or optimization flags and maybe attract a few gentoo users in the process ;) Btw. The Aurora Sparc Linux distribution has a "rawhide" tree very close to Fedora. Klaasjan From davej at redhat.com Sun Nov 9 22:32:05 2003 From: davej at redhat.com (Dave Jones) Date: Sun, 9 Nov 2003 22:32:05 +0000 Subject: FC2 release dates In-Reply-To: <1068179319.8454.24.camel@bushido.localdomain> References: <1068133330.1455.11.camel@opus> <20031106160431.GG1548864@hiwaay.net> <3FAAA679.8090206@devin.com.br> <1068179319.8454.24.camel@bushido.localdomain> Message-ID: <20031109223205.GD8954@redhat.com> On Fri, Nov 07, 2003 at 11:28:40AM +0700, Michel Alexandre Salim wrote: > > I mean native = easy access and documented procedure on how to work with > > ACL on files and such :) > > > We should ideally be able to select files in Nautilus, right-click, > select Properties, select Permissions, then get an NT/2k-style tool to > add/remove ACLs. Casual users would then be able to easily share > selected files with others instead of having to mess with setfacl (or, > as needed now, ask an admin to create a new group everytime files need > to be shared. Ugh) > > If ACL is a stated goal for FC2 I'll bugzilla this request. Go for it. The 2.6 kernel features ACL's without us having to add extra patches, so this is something that's incredibly likely to show up in FC2. Dave From davej at redhat.com Sun Nov 9 22:39:41 2003 From: davej at redhat.com (Dave Jones) Date: Sun, 9 Nov 2003 22:39:41 +0000 Subject: Hardware Database In-Reply-To: <20031107133425.A13384@devserv.devel.redhat.com> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <20031107133425.A13384@devserv.devel.redhat.com> Message-ID: <20031109223941.GE8954@redhat.com> On Fri, Nov 07, 2003 at 01:34:25PM -0500, Michael K. Johnson wrote: > I don't know if there's a version of dmidecode that prints xml, but I > can't imagine that it would be remotely difficult to add, nor that it > would make the source code less clean. > > http://www.nongnu.org/dmidecode/ > > Also note that there are a few other tools that come with dmidecode that > might have useful information for this project. Beware that a lot of BIOS vendors put utter garbage in their DMI tables. Dave From pros-n-cons at bak.rr.com Sun Nov 9 23:28:13 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Sun, 09 Nov 2003 15:28:13 -0800 Subject: Waste of time... (aka. Trademarks) In-Reply-To: <1068407764.16321.88.camel@binkley> References: <1068406797.4299.6.camel@wvanl14.resnet.neu.edu> <1068407764.16321.88.camel@binkley> Message-ID: <1068420492.3993.7.camel@Turtle> > Yep, and a lot of us want to make sure we're going to be contributing in > such a way that 1. will make it possible for others not associated with > red hat to use it and 2. won't cause us to be victim of a lawsuit. > > -sv Who has Red Hat sued for anything ever? SCO and...? You're chasing ppl away from this list, It is ment for developers not legal issues. It's like going to the back of the grocery store and asking the butcher where to find toilet bowl cleaner. -------------- 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 Sun Nov 9 23:30:34 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 Nov 2003 18:30:34 -0500 Subject: Waste of time... (aka. Trademarks) In-Reply-To: <1068420492.3993.7.camel@Turtle> References: <1068406797.4299.6.camel@wvanl14.resnet.neu.edu> <1068407764.16321.88.camel@binkley> <1068420492.3993.7.camel@Turtle> Message-ID: <1068420634.16321.142.camel@binkley> > Who has Red Hat sued for anything ever? SCO and...? You're > chasing ppl away from this list, It is ment for developers > not legal issues. It's like going to the back of the grocery > store and asking the butcher where to find toilet bowl cleaner. Who had caldera ever sued before the sco takeover? They sued microsoft. -sv From msnitzer at lnxi.com Sun Nov 9 23:34:38 2003 From: msnitzer at lnxi.com (Mike Snitzer) Date: Sun, 9 Nov 2003 16:34:38 -0700 Subject: FC1 APT repo on fedora.us is hosed Message-ID: <20031109163438.A26458@lnxi.com> Trying to update from FCtest2 to FC1 using APT with download.fedora.us appears to be impossible. the repo layout transitioned to RPMS.{os,updates,etc...} and SRPMS.{os,updates,etc...} yet the base/{pkglist,srclist}.* files rely on the old naming scheme; e.g os rather than RPMS.os SO.. in the end when using these entries in sources.list: rpm http://download.fedora.us/ fedora/fedora/1/i386 RPMS.os RPMS.updates rpm-src http://download.fedora.us/ fedora/fedora/1/i386 SRPMS.os SRPMS.updates I get messages like: Failed to fetch http://download.fedora.us/fedora/fedora/1/i386/base/pkglist.RPMS.os 404 Not Found Failed to fetch http://download.fedora.us/fedora/fedora/1/i386/base/pkglist.RPMS.updates 404 Not Found So it would seem like the fedora.us APT infrastructure has been left out in the cold; will the fedora.us APT repo continue to be maintained? Are there other APT'ified FC1 repos I should try out? Please advise, thanks! Mike From Axel.Thimm at physik.fu-berlin.de Sun Nov 9 23:52:25 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 10 Nov 2003 00:52:25 +0100 Subject: FC1 APT repo on fedora.us is hosed In-Reply-To: <20031109163438.A26458@lnxi.com> References: <20031109163438.A26458@lnxi.com> Message-ID: <20031109235225.GC30944@puariko.nirvana> On Sun, Nov 09, 2003 at 04:34:38PM -0700, Mike Snitzer wrote: > Are there other APT'ified FC1 repos I should try out? > > Please advise, thanks! Try rpm http://ayo.freshrpms.net fedora/linux/1/i386 core updates #rpm-src http://ayo.freshrpms.net fedora/linux/1/i386 core updates -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Mon Nov 10 01:28:51 2003 From: warren at togami.com (Warren Togami) Date: Sun, 09 Nov 2003 15:28:51 -1000 Subject: FC1 APT repo on fedora.us is hosed In-Reply-To: <20031109163438.A26458@lnxi.com> References: <20031109163438.A26458@lnxi.com> Message-ID: <3FAEE9D3.2010102@togami.com> Mike Snitzer wrote: > Trying to update from FCtest2 to FC1 using APT with download.fedora.us > appears to be impossible. > > the repo layout transitioned to RPMS.{os,updates,etc...} and > SRPMS.{os,updates,etc...} yet the base/{pkglist,srclist}.* files rely on > the old naming scheme; e.g os rather than RPMS.os > > SO.. in the end when using these entries in sources.list: > > rpm http://download.fedora.us/ fedora/fedora/1/i386 RPMS.os RPMS.updates > rpm-src http://download.fedora.us/ fedora/fedora/1/i386 SRPMS.os SRPMS.updates > > I get messages like: > Failed to fetch http://download.fedora.us/fedora/fedora/1/i386/base/pkglist.RPMS.os 404 Not Found > Failed to fetch http://download.fedora.us/fedora/fedora/1/i386/base/pkglist.RPMS.updates 404 Not Found > > So it would seem like the fedora.us APT infrastructure has been left out > in the cold; will the fedora.us APT repo continue to be maintained? > > Are there other APT'ified FC1 repos I should try out? > > Please advise, thanks! > Mike > I am investigating... but upon looking at the structure manually nothing appears to be wrong. This is exactly the structure that fedora.us has used for almost a year now. Doing more investigations... hold... Warren From warren at togami.com Mon Nov 10 01:47:32 2003 From: warren at togami.com (Warren Togami) Date: Sun, 09 Nov 2003 15:47:32 -1000 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: <20031109182927.GB20480@unicorn.sch.bme.hu> References: <1068236427.12684.60.camel@laptop> <20031109182927.GB20480@unicorn.sch.bme.hu> Message-ID: <3FAEEE34.30005@togami.com> Pozsar Balazs wrote: > > PLEASE, take a look at dpkg's and apt-get's way of handling pre-release > versions, I really do think that should be used in rpm-based distros > too. > The idea is to introduce a character, namely '~' (tilde), which is > sorted specially: in comparison it comes before anything else. > > This way, you can get ordering like this: > > 1.0~alpha1 < 1.0~alpha2 < 1.0~beta < 1.0 < 1.0a < 1.0b > 1.0~pre1 < 1.0~rc1 < 1.0 < 1.0.1 < 1.0.2 > ... and so on. > > Hope you got the point. > > I know it should be implemented in rpm, and this is not a trivial move, > but please do think about it. It will make all these > pre-release-versioning nightmares go away. > Interesting concept. This is the first time I heard of this. It would take a serious amount of analysis to figure out if this can be implemented in rpm in a way that wont break backward compatibility. There is also the question of if we *want* to do this or not. Much discussion is needed. In any case it would take a long time to analyze if we want to implement this in rpm and all related tools or not. I currently have no opinion on this matter because I don't know enough about it. In the mean time this package naming scheme describes how to properly avoid packaging problems in the rpm of today. Warren From warren at togami.com Mon Nov 10 01:49:29 2003 From: warren at togami.com (Warren Togami) Date: Sun, 09 Nov 2003 15:49:29 -1000 Subject: FC1 APT repo on fedora.us is hosed In-Reply-To: <20031109163438.A26458@lnxi.com> References: <20031109163438.A26458@lnxi.com> Message-ID: <3FAEEEA9.80308@togami.com> Mike Snitzer wrote: > > rpm http://download.fedora.us/ fedora/fedora/1/i386 RPMS.os RPMS.updates > rpm-src http://download.fedora.us/ fedora/fedora/1/i386 SRPMS.os SRPMS.updates Confirmed, you simply configured it improperly. rpm http://download.fedora.us/fedora fedora/1/i386 os updates stable rpm-src http://download.fedora.us/fedora fedora/1/i386 os updates stable This is the default apt configuration for fedora.us. Warren From msnitzer at lnxi.com Mon Nov 10 01:56:38 2003 From: msnitzer at lnxi.com (Mike Snitzer) Date: Sun, 9 Nov 2003 18:56:38 -0700 Subject: FC1 APT repo on fedora.us is hosed In-Reply-To: <3FAEEEA9.80308@togami.com>; from warren@togami.com on Sun, Nov 09, 2003 at 03:49:29PM -1000 References: <20031109163438.A26458@lnxi.com> <3FAEEEA9.80308@togami.com> Message-ID: <20031109185638.A26821@lnxi.com> On Sun, Nov 09 2003 at 18:49, Warren Togami wrote: > Mike Snitzer wrote: > > > > rpm http://download.fedora.us/ fedora/fedora/1/i386 RPMS.os RPMS.updates > > rpm-src http://download.fedora.us/ fedora/fedora/1/i386 SRPMS.os SRPMS.updates > > Confirmed, you simply configured it improperly. > > rpm http://download.fedora.us/fedora fedora/1/i386 os updates stable > rpm-src http://download.fedora.us/fedora fedora/1/i386 os updates stable > > This is the default apt configuration for fedora.us. yeap; that I did.. sorry for the noise. Mike From anvil at livna.org Mon Nov 10 01:59:33 2003 From: anvil at livna.org (Dams) Date: Mon, 10 Nov 2003 02:59:33 +0100 Subject: FC1 APT repo on fedora.us is hosed In-Reply-To: <20031109163438.A26458@lnxi.com> References: <20031109163438.A26458@lnxi.com> Message-ID: <1068429573.1681.137.camel@gruyere> Le lun 10/11/2003 ? 00:34, Mike Snitzer a ?crit : > rpm http://download.fedora.us/ fedora/fedora/1/i386 RPMS.os RPMS.updates ^^^^^ ^^^^^ > rpm-src http://download.fedora.us/ fedora/fedora/1/i386 SRPMS.os SRPMS.updates ^^^^^^ ^^^^^^ 'RPMS.' 'SRPMS.' must not appear in the config file. So you should have something like : rpm http://download.fedora.us/fedora fedora/1/i386 os updates You can also add 'stable', 'testing' and 'unstable' components. If you wants some add-ons (media players..) you can also use http://rpm.livna.org/ repository > will the fedora.us APT repo continue to be maintained? yes D -- Dams Nad? Anvil/Anvilou on irc.freenode.net : #Linux-Fr, #Fedora I am looking for a job : http://livna.org/~anvil/cv.php "Dona Nobis Pacem E Dona Eis Requiem". Noir. -------------- 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 skvidal at phy.duke.edu Mon Nov 10 03:40:21 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 09 Nov 2003 22:40:21 -0500 Subject: straw rpms Message-ID: <1068435620.16321.252.camel@binkley> Hi all, Straw: http://www.nongnu.org/straw/ - a gnome rss newsfeed aggregation tool is packaged up some. You can get rpms (in a yum repo) from here: http://linux.duke.edu/~skvidal/RPMS/straw/ These might be missing a dep or two in the Requires: field of straw, let me know what breaks, but if they corrupt your system in hideous ways it's not my fault even a little. :) enjoy. -sv From behdad at cs.toronto.edu Mon Nov 10 05:36:19 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 10 Nov 2003 00:36:19 -0500 Subject: Much faster? i18n? tls? Message-ID: Hi, Was tweaking with the grep patch, and also tracking another thread in another list, which was showing how on Red Hat 9 a simple text intensive program (called hspell) is much slower than Red Hat 8, and investigations have shown so far that it's all caused by /lib/tls. Switching to /lib/i686 makes things go much faster. Any idea? And it's not a multi-threaded application. So I focus on sed: Pretty slow on non-C locales:-( [behdad at mces behdad]$ echo $LANG en_US.UTF-8 [behdad at mces behdad]$ ll /bin/ls -rwxr-xr-x 1 root root 73460 Oct 12 04:50 /bin/ls [behdad at mces behdad]$ time sed -e 's/./x/g' /bin/ls > /dev/null real 0m4.248s user 0m3.800s sys 0m0.000s [behdad at mces behdad]$ time LANG=C sed -e 's/./x/g' /bin/ls > /dev/null real 0m0.180s user 0m0.050s sys 0m0.000s [behdad at mces behdad]$ And /bin/ls is only 72kb!!! But you should have noticed that /bin/ls is not a valid UTF-8 piece. Actually /bin/ls is very small, if you run it on a bigger piece of garbage (speaking encoding ofcourse), it's hard not to get a SegFault. I have reported that here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109606 Any idea? May some one look if the same caching can be done here? behdad From michael at koziarski.com Mon Nov 10 05:45:57 2003 From: michael at koziarski.com (Michael A. Koziarski) Date: Mon, 10 Nov 2003 18:45:57 +1300 Subject: straw rpms In-Reply-To: <1068435620.16321.252.camel@binkley> References: <1068435620.16321.252.camel@binkley> Message-ID: <3FAF2615.7060705@koziarski.com> seth vidal wrote: > Hi all, > Straw: http://www.nongnu.org/straw/ - a gnome rss newsfeed aggregation > tool is packaged up some. > > You can get rpms (in a yum repo) from here: > http://linux.duke.edu/~skvidal/RPMS/straw/ > > > These might be missing a dep or two in the Requires: field of straw, let > me know what breaks, but if they corrupt your system in hideous ways > it's not my fault even a little. :) Seems to work fine for me. Could you submit them to fedora.us so they become yummable? I'd be happy to take over the packages if you'd prefer not to go through the QA? Cheers Koz From skvidal at phy.duke.edu Mon Nov 10 05:54:27 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 10 Nov 2003 00:54:27 -0500 Subject: straw rpms In-Reply-To: <3FAF2615.7060705@koziarski.com> References: <1068435620.16321.252.camel@binkley> <3FAF2615.7060705@koziarski.com> Message-ID: <1068443666.16321.278.camel@binkley> > > Seems to work fine for me. Could you submit them to fedora.us so they > become yummable? I'd be happy to take over the packages if you'd prefer > not to go through the QA? sold, take them, consider them yours. Thanks! -sv From mharris at redhat.com Mon Nov 10 08:14:58 2003 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 10 Nov 2003 03:14:58 -0500 (EST) Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: <3FAEEE34.30005@togami.com> References: <1068236427.12684.60.camel@laptop> <20031109182927.GB20480@unicorn.sch.bme.hu> <3FAEEE34.30005@togami.com> Message-ID: On Sun, 9 Nov 2003, Warren Togami wrote: >> PLEASE, take a look at dpkg's and apt-get's way of handling pre-release >> versions, I really do think that should be used in rpm-based distros >> too. >> The idea is to introduce a character, namely '~' (tilde), which is >> sorted specially: in comparison it comes before anything else. >> >> This way, you can get ordering like this: >> >> 1.0~alpha1 < 1.0~alpha2 < 1.0~beta < 1.0 < 1.0a < 1.0b >> 1.0~pre1 < 1.0~rc1 < 1.0 < 1.0.1 < 1.0.2 >> ... and so on. >> >> Hope you got the point. >> >> I know it should be implemented in rpm, and this is not a trivial move, >> but please do think about it. It will make all these >> pre-release-versioning nightmares go away. >> > >Interesting concept. This is the first time I heard of this. It would >take a serious amount of analysis to figure out if this can be >implemented in rpm in a way that wont break backward compatibility. >There is also the question of if we *want* to do this or not. Much >discussion is needed. In any case it would take a long time to analyze >if we want to implement this in rpm and all related tools or not. I >currently have no opinion on this matter because I don't know enough >about it. > >In the mean time this package naming scheme describes how to properly >avoid packaging problems in the rpm of today. One problem is that the word "pre", or "rc" or others are not used consistently between software projects. Some use "pre" like: Prerelease: 2.7.95pre1 (prerelease of version 2.8, or perhaps 2.7.96) Release: 2.8 Others use "pre" like: Prerelease: 2.8pre1 (Prerelease of version 2.8) Release: 2.8 It's possible that one project does it like above, and another does it like: Release: 2.8 Prerelease: 2.8pre1 (Prerelease of version 2.9) Both types of versioning are out there. There is no way of knowing wether the "pre" part is newer or older based solely upon alphanumeric comparison, because different projects use the keyword differently. The only way is by human interpretation. As such, having the software consistently use one single interpretation is the best solution, as you know 50% of the projects out there will work without thinking about it. Then it's only the other 50% that need manual developer attention, and that can't be voided as it isn't possible to know which of the two interpretations is intended via software alone. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Mon Nov 10 08:18:31 2003 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 10 Nov 2003 03:18:31 -0500 (EST) Subject: Much faster? i18n? tls? In-Reply-To: References: Message-ID: On Mon, 10 Nov 2003, Behdad Esfahbod wrote: >Was tweaking with the grep patch, and also tracking another >thread in another list, which was showing how on Red Hat 9 a >simple text intensive program (called hspell) is much slower than >Red Hat 8, and investigations have shown so far that it's all >caused by /lib/tls. Switching to /lib/i686 makes things go much >faster. Any idea? And it's not a multi-threaded application. > > >So I focus on sed: Pretty slow on non-C locales:-( > >[behdad at mces behdad]$ echo $LANG >en_US.UTF-8 >[behdad at mces behdad]$ ll /bin/ls >-rwxr-xr-x 1 root root 73460 Oct 12 04:50 /bin/ls >[behdad at mces behdad]$ time sed -e 's/./x/g' /bin/ls > /dev/null > >real 0m4.248s >user 0m3.800s >sys 0m0.000s >[behdad at mces behdad]$ time LANG=C sed -e 's/./x/g' /bin/ls > /dev/null > >real 0m0.180s >user 0m0.050s >sys 0m0.000s >[behdad at mces behdad]$ > >And /bin/ls is only 72kb!!! You should average the times of multiple runs, at least 5-10 for each test case to help remove noise from the numbers, and remove/reduce cache colouring and other factors from getting in the way of your numbers. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From pozsy at uhulinux.hu Mon Nov 10 08:35:23 2003 From: pozsy at uhulinux.hu (Pozsar Balazs) Date: Mon, 10 Nov 2003 09:35:23 +0100 (CET) Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: Message-ID: On Mon, 10 Nov 2003, Mike A. Harris wrote: > One problem is that the word "pre", or "rc" or others are not > used consistently between software projects. > > Some use "pre" like: > > Prerelease: 2.7.95pre1 (prerelease of version 2.8, or perhaps 2.7.96) > Release: 2.8 > > Others use "pre" like: > > Prerelease: 2.8pre1 (Prerelease of version 2.8) > Release: 2.8 These two are obviously not a problem. > It's possible that one project does it like above, and another > does it like: > > Release: 2.8 > Prerelease: 2.8pre1 (Prerelease of version 2.9) Could you give me an example of this? (Imho this scheme is braindamaged...) I've never seen any projects with this versioning. Anyway, 2.8 < 2.8pre1 is true, so these are ordered correctly. Though if a version "2.8q" was released (as a bug-fix release for the stable 2.8 branch) 2.8q and 2.8pre1 would be ordered incorrently, but this is really a problem with the author, not the algorithm. Introducing '~' would solve problems, and the only con I see is backward compatibility. Hope it can worked out :) -- pozsy From maxka at myrealbox.com Mon Nov 10 08:51:37 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Mon, 10 Nov 2003 00:51:37 -0800 Subject: Hardware Database In-Reply-To: <20031109223941.GE8954@redhat.com> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <20031107133425.A13384@devserv.devel.redhat.com> <20031109223941.GE8954@redhat.com> Message-ID: <1068454297.3280.5.camel@max.localdomain> On Sun, 2003-11-09 at 14:39, Dave Jones wrote: > Beware that a lot of BIOS vendors put utter garbage in their DMI tables. > > Dave Do you know if there's any sense to this garbage? I've noticed a lot of "System Manufacturer: System Manufacturer" sort of things -- is this a common pattern, or do we just have to figure it out in some fuzzy way? -M From mharris at redhat.com Mon Nov 10 09:32:08 2003 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 10 Nov 2003 04:32:08 -0500 (EST) Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: References: Message-ID: On Mon, 10 Nov 2003, Pozsar Balazs wrote: >> It's possible that one project does it like above, and another >> does it like: >> >> Release: 2.8 >> Prerelease: 2.8pre1 (Prerelease of version 2.9) > >Could you give me an example of this? (Imho this scheme is >braindamaged...) I've never seen any projects with this versioning. The Linux kernel. kernel-2.6.0testN There are tonnes of projects that do this however, so I'm kindof surprised if you've never seen any. Do you use the GNU hurd kernel perhaps? ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From behdad at cs.toronto.edu Mon Nov 10 09:45:31 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 10 Nov 2003 04:45:31 -0500 Subject: Much faster? i18n? tls? In-Reply-To: References: Message-ID: On Mon, 10 Nov 2003, Mike A. Harris wrote: > On Mon, 10 Nov 2003, Behdad Esfahbod wrote: > >Was tweaking with the grep patch, and also tracking another > >thread in another list, which was showing how on Red Hat 9 a > >simple text intensive program (called hspell) is much slower than > >Red Hat 8, and investigations have shown so far that it's all > >caused by /lib/tls. Switching to /lib/i686 makes things go much > >faster. Any idea? And it's not a multi-threaded application. > > > > > >So I focus on sed: Pretty slow on non-C locales:-( > > > >[behdad at mces behdad]$ echo $LANG > >en_US.UTF-8 > >[behdad at mces behdad]$ ll /bin/ls > >-rwxr-xr-x 1 root root 73460 Oct 12 04:50 /bin/ls > >[behdad at mces behdad]$ time sed -e 's/./x/g' /bin/ls > /dev/null > > > >real 0m4.248s > >user 0m3.800s > >sys 0m0.000s > >[behdad at mces behdad]$ time LANG=C sed -e 's/./x/g' /bin/ls > /dev/null > > > >real 0m0.180s > >user 0m0.050s > >sys 0m0.000s > >[behdad at mces behdad]$ > > > >And /bin/ls is only 72kb!!! > > You should average the times of multiple runs, at least 5-10 for > each test case to help remove noise from the numbers, and > remove/reduce cache colouring and other factors from getting in > the way of your numbers. Well, I have already done that. And with a few hundred megs of free memory and a 2.4 P4M idle CPU, and such a huge difference, I believe s/n is high enough. From peter.backlund at home.se Mon Nov 10 10:03:07 2003 From: peter.backlund at home.se (Peter Backlund) Date: Mon, 10 Nov 2003 11:03:07 +0100 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: References: Message-ID: <3FAF625B.3000202@home.se> Mike A. Harris wrote: > On Mon, 10 Nov 2003, Pozsar Balazs wrote: > > >>>It's possible that one project does it like above, and another >>>does it like: >>> >>> Release: 2.8 >>> Prerelease: 2.8pre1 (Prerelease of version 2.9) >> >>Could you give me an example of this? (Imho this scheme is >>braindamaged...) I've never seen any projects with this versioning. > > > The Linux kernel. kernel-2.6.0testN > > There are tonnes of projects that do this however, so I'm kindof > surprised if you've never seen any. Do you use the GNU hurd > kernel perhaps? ;o) Not the same thing, this scenario was about using "2.6.0test1" as version number for something leading up to 2.7.0, which I've never seen either. The kernel method or using 2.6.0testX leading up to 2.6.0 is however very common. /Peter From ms-nospam-0306 at arcor.de Mon Nov 10 11:07:31 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 10 Nov 2003 12:07:31 +0100 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: References: Message-ID: <20031110120731.10b44e6e.ms-nospam-0306@arcor.de> On Mon, 10 Nov 2003 04:32:08 -0500 (EST), Mike A. Harris wrote: > On Mon, 10 Nov 2003, Pozsar Balazs wrote: > > >> It's possible that one project does it like above, and another > >> does it like: > >> > >> Release: 2.8 > >> Prerelease: 2.8pre1 (Prerelease of version 2.9) > > > >Could you give me an example of this? (Imho this scheme is > >braindamaged...) I've never seen any projects with this versioning. > > The Linux kernel. kernel-2.6.0testN That would become: 2.6.0~testN < 2.6.0 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Nicolas.Mailhot at laPoste.net Mon Nov 10 11:12:48 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 10 Nov 2003 12:12:48 +0100 Subject: Logrotating single-issue files Message-ID: <1068462768.12794.2.camel@ulysse.olympe.o2t> [re-sending as subscribed user ] Hi, I'm battling with a few apps that create uniquely-named traces/logs in a logdir (typically using PID / date or a sequence number as a unique identifier). I naively though it might be possible to use logrotate to compress old traces and remove them after a while. The problem is of course once the files have been rotated once nothing will recreate the original files so they'll be stuck in first rotation forever (of course one might tell logrotate to create empty new files after compression but that means filling the disk with empty files - plus gziped empty files are *not* zero-sized anymore). I've been trying various workarounds such as creating empty foo.x.gz files in prerotate and removing them in postrotate but it seems prerotate is not even entered when pattern files are not present. So I'm stuck - it seems logrotate can not handle this case and I'll have to cook up my own cron script. Anyone got an idea ? Is the modified SuSE logrotate some people have been talking about able to cope with this ? Cheers, -- Nicolas Mailhot -- 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 reader at newsguy.com Mon Nov 10 11:40:12 2003 From: reader at newsguy.com (Harry Putnam) Date: Mon, 10 Nov 2003 05:40:12 -0600 Subject: Logrotating single-issue files In-Reply-To: <1068462768.12794.2.camel@ulysse.olympe.o2t> (Nicolas Mailhot's message of "Mon, 10 Nov 2003 12:12:48 +0100") References: <1068462768.12794.2.camel@ulysse.olympe.o2t> Message-ID: Nicolas Mailhot writes: > The problem is of course once the files have been rotated once nothing > will recreate the original files so they'll be stuck in first rotation > forever (of course one might tell logrotate to create empty new files > after compression but that means filling the disk with empty files - > plus gziped empty files are *not* zero-sized anymore). Investigate the `create', `size' and compress specs in man logrotate.conf Will something like this in /etc/lograte.conf work? /home/reader/t/var/log/*.log { create 0600 reader reader size=1000k rotate 10 compress } From jos at xos.nl Mon Nov 10 11:50:59 2003 From: jos at xos.nl (Jos Vos) Date: Mon, 10 Nov 2003 12:50:59 +0100 Subject: Logrotating single-issue files In-Reply-To: <1068462768.12794.2.camel@ulysse.olympe.o2t>; from Nicolas.Mailhot@laPoste.net on Mon, Nov 10, 2003 at 12:12:48PM +0100 References: <1068462768.12794.2.camel@ulysse.olympe.o2t> Message-ID: <20031110125059.A5080@xos037.xos.nl> On Mon, Nov 10, 2003 at 12:12:48PM +0100, Nicolas Mailhot wrote: > The problem is of course once the files have been rotated once nothing > will recreate the original files so they'll be stuck in first rotation > forever (of course one might tell logrotate to create empty new files > after compression but that means filling the disk with empty files - > plus gziped empty files are *not* zero-sized anymore). Well, yes, but at first sight creating new empty files seems to be the best solution. Furthermore, IIRC you can define a shell script as "compresscmd" in your logrotate config, that could be like this (all untested, RTFM, I don't know the exact interface): if [ -s $1 ]; then gzip $1 else mv $1 $1.gz fi Cheers, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From Nicolas.Mailhot at laPoste.net Mon Nov 10 12:51:49 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 10 Nov 2003 13:51:49 +0100 Subject: Logrotating single-issue files In-Reply-To: References: <1068462768.12794.2.camel@ulysse.olympe.o2t> Message-ID: <1068468709.13146.5.camel@ulysse.olympe.o2t> Le lun 10/11/2003 ? 12:40, Harry Putnam a ?crit : > Nicolas Mailhot writes: > > > The problem is of course once the files have been rotated once nothing > > will recreate the original files so they'll be stuck in first rotation > > forever (of course one might tell logrotate to create empty new files > > after compression but that means filling the disk with empty files - > > plus gziped empty files are *not* zero-sized anymore). > > Investigate the `create', `size' and compress specs in man logrotate.conf > > Will something like this in /etc/lograte.conf work? Size won't help - the size switch means some traces won't ever be rotated (so instead of having all traces stuck at rotation 1 some of them will be stuck at rotation 0). And lots of very small files do fill a partition after a while. The core problem seems to be you can not tell logrotate to rotate a log inconditionally, it'll only do it if other versions of the file exist so to treat a log/trace you have to accept $rotation number of this file will exist on the disk forever. When you add the compress+create+ifempty switch in the balance your $rotation file will each take 31k of disk. 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 lfarkas at bnap.hu Mon Nov 10 13:49:40 2003 From: lfarkas at bnap.hu (Farkas Levente) Date: Mon, 10 Nov 2003 14:49:40 +0100 Subject: rawhide or fedora/development Message-ID: <3FAF9774.9070408@bnap.hu> hi, what is the current rpm directory for fedora's development packages? - redhat's rawhide - fedora/development - or something else? thanks. -- Levente "Si vis pacem para bellum!" From davej at redhat.com Mon Nov 10 14:08:58 2003 From: davej at redhat.com (Dave Jones) Date: Mon, 10 Nov 2003 14:08:58 +0000 Subject: Hardware Database In-Reply-To: <1068454297.3280.5.camel@max.localdomain> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <20031107133425.A13384@devserv.devel.redhat.com> <20031109223941.GE8954@redhat.com> <1068454297.3280.5.camel@max.localdomain> Message-ID: <20031110140858.GF8954@redhat.com> On Mon, Nov 10, 2003 at 12:51:37AM -0800, Maxwell Kanat-Alexander wrote: > On Sun, 2003-11-09 at 14:39, Dave Jones wrote: > > Beware that a lot of BIOS vendors put utter garbage in their DMI tables. > > > > Dave > > Do you know if there's any sense to this garbage? I've noticed a lot of > "System Manufacturer: System Manufacturer" sort of things -- is this a > common pattern, or do we just have to figure it out in some fuzzy way? Sometimes its empty fields, sometimes random characters, sometimes complete lies (Like saying it has a full length EISA slot in a laptop) Dave From nalin at redhat.com Mon Nov 10 14:24:24 2003 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 10 Nov 2003 09:24:24 -0500 Subject: Intro, and userhelper question In-Reply-To: <1068232932.13028.1323.camel@island> References: <1068232932.13028.1323.camel@island> Message-ID: <20031110142424.GB3983@redhat.com> On Fri, Nov 07, 2003 at 02:22:12PM -0500, Alastair Neil wrote: > It seems there are two ways to approach this, allow userhelper to have a > list of authorised users, possibly selected from a dropdown list in > consolehelper or modify pam to check the root password if the user > password does not match. > > I modified pam in RH8 to do this because I liked the ability to unlock > screensavers with the root passwd ala HPUX, but I noted that > xscreensaver in Ximian allows this and as far as I can see it is not a > pam level change. > > Does anyone think these modifications are a good idea and if so what is > the preference? Or perhaps in my ignorance I am reinventing the wheel? Allowing unlocking of a user's screen saver using the root password is unfortunately not a good idea. A naive sysadmin has no way of knowing whether or not the application which is asking for a password was built by the user to log that password for later (nefarious) uses. Cheers, Nalin From jf_balto at hotmail.com Mon Nov 10 14:27:54 2003 From: jf_balto at hotmail.com (Jean-Francois Veillette) Date: Mon, 10 Nov 2003 14:27:54 +0000 Subject: /etc/localtime isn't world readable Message-ID: Hi, I wonder why /etc/localtime isn't world readable in the Fedora Core distribution. Let say you put your hardware clock in UTC and your computer is set to whatever timezone. Then by default, when you log as a user gnome/kde clock applet display time as UTC because /etc/localtime isn't readable. Is tbere a security issue about this file being world readable. Jean-Francois Veillette _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://messenger.fr.msn.ca/ From Nicolas.Mailhot at laPoste.net Mon Nov 10 14:39:02 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 10 Nov 2003 15:39:02 +0100 Subject: Logrotating single-issue files In-Reply-To: <20031110125059.A5080@xos037.xos.nl> References: <1068462768.12794.2.camel@ulysse.olympe.o2t> <20031110125059.A5080@xos037.xos.nl> Message-ID: <1068475142.14006.18.camel@ulysse.olympe.o2t> Le lun 10/11/2003 ? 12:50, Jos Vos a ?crit : > On Mon, Nov 10, 2003 at 12:12:48PM +0100, Nicolas Mailhot wrote: > > > The problem is of course once the files have been rotated once nothing > > will recreate the original files so they'll be stuck in first rotation > > forever (of course one might tell logrotate to create empty new files > > after compression but that means filling the disk with empty files - > > plus gziped empty files are *not* zero-sized anymore). > > Well, yes, but at first sight creating new empty files seems to be > the best solution. Furthermore, IIRC you can define a shell script > as "compresscmd" in your logrotate config, that could be like this > (all untested, RTFM, I don't know the exact interface): > > if [ -s $1 ]; then > gzip $1 > else > mv $1 $1.gz > fi Thank you for the idea, if got this awful hack to work now : "/var/log/mydir" { rotate 4 weekly nomissingok create ifempty compress compresscmd /usr/bin/rotatecomp compressext .bz2 sharedscripts postrotate /usr/bin/rotateclean /var/log/mydir endscript } With /usr/bin/rotatecomp : if ! [ "$#" -eq 2 -a -f "$2" ] ; then echo "$0: Usage $(basename $0) option file" >&2 exit 1 fi [ -s "$2" ] && bzip2 $1 $2 || mv $2 $2.bz2 And /usr/bin/rotateclean : if ! [ "$#" -eq 1 -a -d "$1" ] ; then echo "$0: Usage $(basename $0) directory" >&2 exit 1 fi # Remove old logrotate leftovers for file in $(find "$1" -type f | grep -E "\.[0-9]*\.bz2$" |\ sed "s+^\(.*\)\.\([0-9]*\)\.bz2$+\1+g") ; do [ $(du -c $file* | tail -1 | sed "s+total$++g") -eq 0 ] && rm -f $file* done Now this is all really ugly and I'd probably got as good a solution writing a non-logrotate cron. Which proves logrotate is seriously lacking when used in this (very simple and common) case:(. 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 reader at newsguy.com Mon Nov 10 15:36:27 2003 From: reader at newsguy.com (Harry Putnam) Date: Mon, 10 Nov 2003 09:36:27 -0600 Subject: Logrotating single-issue files In-Reply-To: <20031110125059.A5080@xos037.xos.nl> (Jos Vos's message of "Mon, 10 Nov 2003 12:50:59 +0100") References: <1068462768.12794.2.camel@ulysse.olympe.o2t> <20031110125059.A5080@xos037.xos.nl> Message-ID: Jos Vos writes: > if [ -s $1 ]; then > gzip $1 > else > mv $1 $1.gz > fi Will something like this work? The scripting below in /etc/logrotate would: Put all the lines from each trace.*, prefaced by filename in BIGTRACE.file. Then it deletes the trace* files. The next log entry checks BIGTRACE.file for size then rotates and compresses if necessary. You can test it by creating the files and dirs then placing this code in some.file and running: `logrotate -v some.file' /home/reader/t/var/test/trace.* { size=2 nocreate rotate 2 firstaction awk '{print FILENAME,$0}' /home/reader/t/var/test/trace* >> /home/reader/t/va r/test/BIGTRACE.file endscript lastaction rm -f /home/reader/t/var/test/trace* endscript } /home/reader/t/var/test/BIGTRACE.file { nocreate rotate 2 compress size=500k } From czar at czarc.net Mon Nov 10 15:40:09 2003 From: czar at czarc.net (Gene C.) Date: Mon, 10 Nov 2003 10:40:09 -0500 Subject: bugzilla for Fedora Core Message-ID: <200311101040.09997.czar@czarc.net> bugzilla has been set up with a Product name of Fedora Core and Versions 1, test1, test2, and test3. When Fedora Core 2 testing begins, I assume that there will be a test1, test2, etc. Won't searches be confusing with (for example) test1 applying to bothe FC-1 and FC-2? For previous Public Betas, each beta had a unique name so which was used for the Version identifier. -- Gene From Nicolas.Mailhot at laPoste.net Mon Nov 10 16:11:38 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 10 Nov 2003 17:11:38 +0100 Subject: Logrotating single-issue files In-Reply-To: References: <1068462768.12794.2.camel@ulysse.olympe.o2t> <20031110125059.A5080@xos037.xos.nl> Message-ID: <1068480697.15211.2.camel@ulysse.olympe.o2t> Le lun 10/11/2003 ? 16:36, Harry Putnam a ?crit : > Jos Vos writes: > > > if [ -s $1 ]; then > > gzip $1 > > else > > mv $1 $1.gz > > fi > > Will something like this work? The scripting below in /etc/logrotate > would: Put all the lines from each trace.*, prefaced by filename in > BIGTRACE.file. Then it deletes the trace* files. Unfortunately, you do not really want to concatenate the traces since the app utils expect them to be broken into bits (plus the nice thing about individual files is it's much easier to see where an "event" starts and ends - linear logs is really bad for parallel stuff) 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 julia at magma.com Mon Nov 10 17:04:44 2003 From: julia at magma.com (Julia Elbert) Date: Mon, 10 Nov 2003 09:04:44 -0800 Subject: posting to the list In-Reply-To: <20031110165903.25113.50600.Mailman@listman.back-rdu.redhat .com> Message-ID: <200311101706.JAA28130@magma.com> An HTML attachment was scrubbed... URL: From rms at 1407.org Mon Nov 10 17:27:44 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 10 Nov 2003 17:27:44 +0000 Subject: kernel with swsusp Message-ID: <1068485264.16189.17.camel@roque> Hi, Is anyone trying working on adding swsusp to Fedora's Linux? I'd be willing to collaborate, but I doubt I can bring it on all by myself. Yours, 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 aoliva at redhat.com Mon Nov 10 17:35:52 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Nov 2003 15:35:52 -0200 Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068405039.16321.69.camel@binkley> References: <1068405039.16321.69.camel@binkley> Message-ID: >> I'm convinced it does, for packages that are indeed released under the >> GNU GPL. This is not the case of fedora-logos or anaconda-images, >> since their license is not the GNU GPL. But then again, IANAL. On Nov 9, 2003, seth vidal wrote: > Does the GPL protect you? > not sure it does. I don't believe this is any different from patents. If you release GPLed code that builds upon patents you own, you cannot sue anyone for patent violation because, by the GPL, you cannot impose any further restrictions on the distribution of the software. I don't see that with trademarks this would be any different. Hmm... On second thought, maybe this limitation doesn't apply to the copyright holder, only to redistributors? At this point, I have to claim again that IANAL and leave it at that :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From aoliva at redhat.com Mon Nov 10 17:40:46 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Nov 2003 15:40:46 -0200 Subject: /etc/localtime isn't world readable In-Reply-To: References: Message-ID: On Nov 10, 2003, "Jean-Francois Veillette" wrote: > I wonder why /etc/localtime isn't world readable in the Fedora Core > distribution. Err... It is for me. And I think it has to be. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From aoliva at redhat.com Mon Nov 10 17:41:48 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Nov 2003 15:41:48 -0200 Subject: bugzilla for Fedora Core In-Reply-To: <200311101040.09997.czar@czarc.net> References: <200311101040.09997.czar@czarc.net> Message-ID: On Nov 10, 2003, "Gene C." wrote: > For previous Public Betas, each beta had a unique name so which was used for > the Version identifier. Not always, and the way it worked was that bugs filed against betas were mechanically reassigned to the final release that followed the betas. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From kjb at dds.nl Mon Nov 10 19:11:41 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Mon, 10 Nov 2003 20:11:41 +0100 Subject: kernel with swsusp In-Reply-To: <1068485264.16189.17.camel@roque> References: <1068485264.16189.17.camel@roque> Message-ID: <1068491501.1515.2.camel@isengard> On Mon, 2003-11-10 at 18:27, Rui Miguel Seabra wrote: > Hi, > > Is anyone trying working on adding swsusp to Fedora's Linux? I'd be > willing to collaborate, but I doubt I can bring it on all by myself. Don't know for sure, but swsuspend is integrated in the 2.6 kernel of which there are test rpms at: http://people.redhat.com/arjanv/2.5/ Klaasjan From jsmith at drgutah.com Mon Nov 10 19:23:09 2003 From: jsmith at drgutah.com (Jared Smith) Date: Mon, 10 Nov 2003 12:23:09 -0700 Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068402172.16321.56.camel@binkley> References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068274604.14565.22.camel@binkley> <1068402172.16321.56.camel@binkley> Message-ID: <1068492189.7394.1.camel@banff.drgutah.com> On Sun, 2003-11-09 at 11:22, seth vidal wrote: > YUP was the Yellowdog UPdater. > so maybe yum should be yupm but considering it shares maybe 2 functions > with yup it doesn't seem all that important. > To be completely honest, yum was selected as a name b/c it was: > 1. short > 2. not already taken > Hmmmn... I just had a thought... why not rename it to "rum", as in Redhat Updater, iMproved! (OK, this borders on trolling, so I'll stop.) Jared From keithl at kl-ic.com Mon Nov 10 19:24:45 2003 From: keithl at kl-ic.com (Keith Lofstrom) Date: Mon, 10 Nov 2003 11:24:45 -0800 Subject: Logrotating single-issue files Message-ID: <20031110192445.GA23402@gate.kl-ic.com> Nicolas Mailhot writes: > I'm battling with a few apps that create uniquely-named traces/logs in > a logdir (typically using PID / date or a sequence number as a unique > identifier). I naively though it might be possible to use logrotate to > compress old traces and remove them after a while. ... > Anyone got an idea ? Is the modified SuSE logrotate some people have > been talking about able to cope with this ? The SUSE modified logrotate takes an original and appends one date extension (YYYYMMDD) then tosses it after a while. Not what you are dealing with. Logrotate is probably not the proper tool. You may be able to use a pair of "find ... exec ..." commands in a shell script called by cron to do what you want. While you might build some ugly scripts and call them from logrotate, the next maintainer will have no idea where the behavior is coming from - logrotate is expected to do only certain things. For example: ----------------------------------------------------------------- #!/bin/bash # /etc/cron.daily/myapp-log-maintainer # compress all unused myapp log files of type A older than 2 days find -atime 48 /var/log/myapp/logA* -exec gzip '{}' ';' # delete all unused myapp log files of type A older than 2 weeks # (plus the above 2 days) find -atime 336 /var/log/myapp/logA*gz -exec rm -f '{}' ';' #all done exit 0 ----------------------------------------------------------------- This is untested, and I often get the -exec part wrong, use at your own risk. I also tend to code the file paths as variables (for example, MYAPPLOG=/var/log/myapp) and give full paths for executables in my own shell scripts so I do not have to rely on possibly hacked PATHs, so the example script should probably be modified those ways. You should also put a README in the log/myapp directory telling future maintainers what the heck is going on. You probably also want to log the fact that this script was run in /var/log/messages. You probably do not want to compress right away (hence the -atime). You might actually be running the app making the log when cron starts up. But you may be happy with "-atime 1" or something, where the log file can get compressed only an hour after you stop actively looking at it. Remember, you may still be running myapp when this script runs. Lastly, if you have a nightly backup procedure called by cron.daily, you probably want to call this first. And if you are using an rsync-based disk backup procedure like I am, you do not want to modify the files at all, or it causes just another copy (albeit compressed) to happen. Just delete them when they get old to keep your directories uncluttered. Keith -- Keith Lofstrom keithl at ieee.org Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs From bos at serpentine.com Mon Nov 10 19:29:20 2003 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon, 10 Nov 2003 11:29:20 -0800 Subject: Arjan AMD64 kernel-2.6.0-testX RPMS In-Reply-To: <1068349165.4430.163.camel@laptop> References: <1068349165.4430.163.camel@laptop> Message-ID: <1068492560.3542.13.camel@serpentine.internal.keyresearch.com> On Sat, 2003-11-08 at 19:39, Warren Togami wrote: > I just noticed that Arjan has x86_64 (AMD64) kernels in addition to the > i586 and i686 kernels of 2.6.0-testX. Cool! 2.6 and Fedora mix happily. All that's remaining is x86_64 RPMs of all of userland :-) References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> Message-ID: <1068492814.3239.2.camel@roque> On Mon, 2003-11-10 at 19:11, Klaasjan Brand wrote: > Don't know for sure, but swsuspend is integrated in the 2.6 kernel of > which there are test rpms at: http://people.redhat.com/arjanv/2.5/ I'd rather check for a backport than jump into the 2.6 world right now. I have absolutely no suspend: this is an acpi only laptop, and S3 does nothing on it. So nobody else is trying or has tried to bundle swsusp with the currently distributed kernel? Thanks, 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 Nicolas.Mailhot at laPoste.net Mon Nov 10 19:44:01 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 10 Nov 2003 20:44:01 +0100 Subject: Logrotating single-issue files In-Reply-To: <20031110192445.GA23402@gate.kl-ic.com> References: <20031110192445.GA23402@gate.kl-ic.com> Message-ID: <1068493441.15414.4.camel@m70.net81-64-235.noos.fr> Le lun 10/11/2003 ? 20:24, Keith Lofstrom a ?crit : > Nicolas Mailhot writes: > > > I'm battling with a few apps that create uniquely-named traces/logs in > > a logdir (typically using PID / date or a sequence number as a unique > > identifier). I naively though it might be possible to use logrotate to > > compress old traces and remove them after a while. > > ... > > > Anyone got an idea ? Is the modified SuSE logrotate some people have > > been talking about able to cope with this ? > > The SUSE modified logrotate takes an original and appends one date extension > (YYYYMMDD) then tosses it after a while. Not what you are dealing with. > > Logrotate is probably not the proper tool. You may be able to use a pair > of "find ... exec ..." commands in a shell script called by cron to do > what you want. While you might build some ugly scripts and call them > from logrotate, the next maintainer will have no idea where the behavior > is coming from - logrotate is expected to do only certain things. I was seriously considering this way, right. I got logrotate to work but it's way too ugly. The downside of it is when you write custom scripts nobody enhances them for you and the next user won't know where to find them :( (plus you don't have the nice logrotate config interface). It's really sad the logrotate authors seem to have forgotten/ignored this case. I started because I app crashed a system filling up the disks with unhandled traces, and I've already identified two other apps which behave the same way:( Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From notting at redhat.com Mon Nov 10 19:46:54 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Nov 2003 14:46:54 -0500 Subject: The Fedora Hardware Project In-Reply-To: <1068281126.3346.9.camel@max.localdomain>; from maxka@myrealbox.com on Sat, Nov 08, 2003 at 12:45:26AM -0800 References: <1068205683.3488.15.camel@max.localdomain> <20031107222302.A19738@devserv.devel.redhat.com> <1068281126.3346.9.camel@max.localdomain> Message-ID: <20031110144654.A3432@devserv.devel.redhat.com> Maxwell Kanat-Alexander (maxka at myrealbox.com) said: > On Fri, 2003-11-07 at 19:23, Bill Nottingham wrote: > > Storing brand names is a pain, as there will be 4000 branding variants > > of a particular device. > > I was hoping for people to use the pre-entered ones for their chipset > ID, mostly, and making it slightly difficult to enter a new one. > > I can see your point, there, though. > > The problem is: Users will want to search for brand names. > > Are there other resolutions to this issue? Well, if you have a place for an alternate brand name, you can enter it there, so people could search that way. (The other place this will hit is on motherboard sound chipsets; the variation in names for something that turns out to either be one of a) i810_audio b) via82cxxx_audio is rather staggering. :) ) > Perhaps there's a way to get a canonical sort of brand name out of DMI. Not for anything attached in a slot, no. > > One of the issues you'll have to deal with is only presenting > > to the user the 'interesting' hardware. > > From lspci, at least, we have a "hardware type", like "USB Controller." > We'd probably have to keep up, somewhat, on the hardware types, and make > sure that we filter what we ask the user about based on that. That's pretty easy to do. Only a subset of the PCI ids are really interesting. Bill From notting at redhat.com Mon Nov 10 19:48:11 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Nov 2003 14:48:11 -0500 Subject: The Fedora Hardware Project In-Reply-To: <24134.80.62.54.30.1068294937.squirrel@fubar.dk>; from david@fubar.dk on Sat, Nov 08, 2003 at 01:35:37PM +0100 References: <1068205683.3488.15.camel@max.localdomain> <20031107222302.A19738@devserv.devel.redhat.com> <24134.80.62.54.30.1068294937.squirrel@fubar.dk> Message-ID: <20031110144811.B3432@devserv.devel.redhat.com> David Zeuthen (david at fubar.dk) said: > Note that PCI has the concept of both (vendor_id, product_id) and > (subsystem_vendor_id, subsystem_product_id). Now, for instance, all > videocards with GeForce 2 MX chipsets will (as I understand it) report > the same (vendor_id, product_id); the integrator, e.g. the name that is > on the shrink-wrapped box, will set only the subsystem* parameters. Exactly. Upstream in pci.ids the subsystem/subdevice is only spottily populated though; probablyy because for operational purposes you just don't care. Bill From Nicolas.Mailhot at laPoste.net Mon Nov 10 19:50:37 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 10 Nov 2003 20:50:37 +0100 Subject: kernel with swsusp In-Reply-To: <1068492814.3239.2.camel@roque> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> Message-ID: <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> Le lun 10/11/2003 ? 20:33, Rui Miguel Seabra a ?crit : > On Mon, 2003-11-10 at 19:11, Klaasjan Brand wrote: > > Don't know for sure, but swsuspend is integrated in the 2.6 kernel of > > which there are test rpms at: http://people.redhat.com/arjanv/2.5/ > > I'd rather check for a backport than jump into the 2.6 world right now. > I have absolutely no suspend: this is an acpi only laptop, and S3 does > nothing on it. Not to mention suspend on 2.6 is not really ready now (last time I chacked there were three ! different implementations competing) > So nobody else is trying or has tried to bundle swsusp with the > currently distributed kernel? OTOH, there are loads of stuff available in 2.6 that people have been awaiting for ages (alsa, ipsec, acls, xfs, sane cd burning, dm, udev...) At this point fedora devel should switch to 2.6 asap to get it ready for FC2. 2.4 enhancements seem more a job for the legacy project 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 aoliva at redhat.com Mon Nov 10 20:06:43 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Nov 2003 18:06:43 -0200 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: References: Message-ID: On Nov 10, 2003, Pozsar Balazs wrote: >> Release: 2.8 >> Prerelease: 2.8pre1 (Prerelease of version 2.9) > Could you give me an example of this? (Imho this scheme is > braindamaged...) I've never seen any projects with this versioning. Autotools (autoconf, automake and libtool) have agreed to use such a scheme quite a while ago, and one of the reasons behind such a scheme was exactly to accomodate RPM's versioning rules. Say libtool 1.4.2a was a CVS snapshot out of the 1.4 branch right after release 1.4.2; 1.4.2b was a semi-stable released snapshot leading towards 1.4.3. 1.4.2c was a CVS snapshot after 1.4.2b, etc, with `odd' letters being used for CVS snapshots and `even' letters used for tarballs released out of alpha.gnu.org. Meanwhile, mainline was be versioned 1.4a, meaning it targeted release 1.5. 1.4b was a semi-stable released snapshot, 1.4c was again a CVS snapshot. At some points right after cutting a branch, we'd have something like 1.4.0a, to distinguish it from 1.4a, and to make it clear it's leading towards 1.4.1. I no longer remember the exact details, so I may have got something wrong, but the scheme actually makes some sense, given the design constraints. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From balister at vt.edu Mon Nov 10 20:09:03 2003 From: balister at vt.edu (Philip Balister) Date: Mon, 10 Nov 2003 15:09:03 -0500 Subject: kernel with swsusp In-Reply-To: <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> Message-ID: <20031110200903.GZ27791@nemesis.maddog.net> > > I'd rather check for a backport than jump into the 2.6 world right now. > > I have absolutely no suspend: this is an acpi only laptop, and S3 does > > nothing on it. > > Not to mention suspend on 2.6 is not really ready now (last time I > chacked there were three ! different implementations competing) > > > So nobody else is trying or has tried to bundle swsusp with the > > currently distributed kernel? Add me to the list of people interested in improving laptop support for Fedora. I might be able to spend some time working/testing, but I want to make sure I am doing the right thing before I start fooling with this stuff. It seems like there are two choices: 1) Fix 2.4 kernel distributed with fedora, or 2) WOrk with 2.6 kernel. Which is the best choice? Philip From notting at redhat.com Mon Nov 10 20:27:58 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Nov 2003 15:27:58 -0500 Subject: rawhide or fedora/development In-Reply-To: <3FAF9774.9070408@bnap.hu>; from lfarkas@bnap.hu on Mon, Nov 10, 2003 at 02:49:40PM +0100 References: <3FAF9774.9070408@bnap.hu> Message-ID: <20031110152758.D3432@devserv.devel.redhat.com> Farkas Levente (lfarkas at bnap.hu) said: > hi, > what is the current rpm directory for fedora's development packages? > - redhat's rawhide > - fedora/development rawhide moved from: ftp.redhat.com/pub/redhat/linux/rawhide to: download.fedora.redhat.com/pub/fedora/linux/core/development/ It will be updated with newer content later this week-ish. Bill From pozsy at uhulinux.hu Mon Nov 10 20:47:03 2003 From: pozsy at uhulinux.hu (Pozsar Balazs) Date: Mon, 10 Nov 2003 21:47:03 +0100 (CET) Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: Message-ID: On 10 Nov 2003, Alexandre Oliva wrote: > On Nov 10, 2003, Pozsar Balazs wrote: > > >> Release: 2.8 > >> Prerelease: 2.8pre1 (Prerelease of version 2.9) > > > Could you give me an example of this? (Imho this scheme is > > braindamaged...) I've never seen any projects with this versioning. > > Autotools (autoconf, automake and libtool) have agreed to use such a > scheme quite a while ago, and one of the reasons behind such a scheme > was exactly to accomodate RPM's versioning rules. [...] Okay, I understand your example. I was focusing on 'pre', which I still think is not used this way, but other postfixes, most commonly 'a', 'b', 'c'... are do used. But, as you also mention, these schemes can be handled long ago easily, so they do not need fixing, and they do not need the usage of the proposed '~' special tag. You might misunderstood me: the purpose of the '~' marking is _NOT_ to use it every time when a version number is kind of 'pre', but to use it when you want to express ordering impossible (without 'hacks') without it. So 1.4.0 < 1.4.0a < 1.4.0b < 1.4.1 is perfectly ordered now and ever, but if you want to order '1.4.0', '1.4.1-pre1' and '1.4.1' you either have to use tricks, or simply use '~': 1.4.0 < 1.4.1~pre1 < 1.4.1 ps: sorry if this is overexplanation, shoot me :) -- pozsy From johnsonm at redhat.com Mon Nov 10 20:53:32 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 10 Nov 2003 15:53:32 -0500 Subject: FC2 release dates In-Reply-To: <1068244114.6576.14.camel@opus>; from skvidal@phy.duke.edu on Fri, Nov 07, 2003 at 05:28:34PM -0500 References: <1068133330.1455.11.camel@opus> <1068164005.12985.11.camel@mirkwood.devel.redhat.com> <1068164392.10735.6.camel@binkley> <1068165254.12985.20.camel@mirkwood.devel.redhat.com> <1068166072.10735.16.camel@binkley> <1068167013.10735.19.camel@binkley> <20031107153844.C13384@devserv.devel.redhat.com> <1068244114.6576.14.camel@opus> Message-ID: <20031110155332.A1493@devserv.devel.redhat.com> I took the weekend off (horrors!) so this may seem a bit late :-) On Fri, Nov 07, 2003 at 05:28:34PM -0500, seth vidal wrote: > This is good to hear. Better than appointing, you're definitely correct. > I think nominations for people worthy of recognition might be useful. > B/c, as you said, you've been busy and might not have noticed people who > have been having an effect. I have a few people in the back of my head > who deserve high praise for putting up with a fair bit of abuse, many of > them at red hat. :) :-) My first goal is to refine the definitions of the groups. I think that we'll end up with different names and a slightly different structure; we might not have the "Advisory Committee" per se (name is confusing and some of the delineation seems a bit artificial) so I'm making some proposals that I need to get Steering Committee approval for. My intent is to roll out better definitions soon before worrying about final membership. > All of those are pressing points and well understood, my only argument > for delaying a bit is to try and include gnome 2.6. - As Jef Spaleta > mentioned on irc - a cool release name is FC2(.6) ;) > > I know a month is a long time in free software but from the avg life > cycle of linux 2.2->2.4->2.6 it won't be a very long in the linux > 2.6->2.8 cycle. Getting gnome 2.6 would mean more gnome testing and > that's got to be helpful for RHEL, as well. > > my thoughts, worth whatever they're worth. Absolutely worth consideration. I just wanted to present our reasons because one of the points of the new regime is to not appear arbitrary by keeping silent about our reasons... (I don't think we've every really been arbitrary, but I know it has looked that way sometimes.) michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From johnsonm at redhat.com Mon Nov 10 21:13:46 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 10 Nov 2003 16:13:46 -0500 Subject: FC2 release dates In-Reply-To: <20031108023041.GA18437@thyrsus.com>; from esr@thyrsus.com on Fri, Nov 07, 2003 at 09:30:41PM -0500 References: <1068257750.7225.4.camel@edoras.local.net> <20031108023041.GA18437@thyrsus.com> Message-ID: <20031110161346.B1493@devserv.devel.redhat.com> On Fri, Nov 07, 2003 at 09:30:41PM -0500, Eric S. Raymond wrote: > Jeremy Katz : > > Having things so that both 2.4 and 2.6 work mean that the integration of > > 2.6 isn't going to be as smooth. > > Agreed. I don't know if my opinion counts for anything in this, nor > even if it should. But I'd like to see FC2 go for 2.6 all the way > unless 2.6 has showstopper problems. I'll stick my neck out and say: It's either 2.4 or 2.6, no middle ground. If 2.6 isn't good enough to not need an alternative, then we've got a problem. But I don't think we'll have a problem; 2.6 is progressing much more nicely than 2.4 did from my viewpoint. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From razvan.vilt at linux360.ro Mon Nov 10 21:17:06 2003 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Mon, 10 Nov 2003 23:17:06 +0200 Subject: Apache headers Message-ID: <1068499026.1976.17.camel@home-04019.b.astral.ro> While building a module for apache I've noticed the following problem Out of pages of errors the most important lines are: (...) /usr/include/httpd/ap_config.h:58:17: apr.h: No such file or directory (...) There are similar ones for other .h files in /usr/include/apr-0 The work-around was to move all the file from /usr/include/apr-0 to /usr/include Someone rearanged the header files in apr but forgot to update the apache headers with the new location... ntz...ntz...ntz... From johnsonm at redhat.com Mon Nov 10 21:19:25 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 10 Nov 2003 16:19:25 -0500 Subject: ReiserFS in Anaconda? In-Reply-To: <005101c3a5af$fa8dc240$6401a8c0@rohome>; from fedora@rosamour.com on Fri, Nov 07, 2003 at 10:22:53PM -0600 References: <200311072017.04545.jkeating@j2solutions.net> <005101c3a5af$fa8dc240$6401a8c0@rohome> Message-ID: <20031110161925.C1493@devserv.devel.redhat.com> On Fri, Nov 07, 2003 at 10:22:53PM -0600, Ro wrote: > Could it "also" be because ReiserFS is heavily supported by SuSE, RH's main > competitor? Or am I out of line on that statement? Don't get me wrong I'm an > RH (Now Fedora) guy but I've wondered about this matter. I went through the > RHCE course and in it they mentioned the ReiserFS as being in development. > Well, we all know that ReiserFS is FAR from being in development... it's > BEEN out... So I was wondering if someone could objectively answer this > questions. I am really not trying to make anyone uncomfortable, just > curious. :-) There is plenty of technology in the kernel developed by our competitors as well as technology developed by us; that's simply not a factor. 1) We do have strong in-house expertise in ext3, and it is a good general-purpose filesystem, so it's a good default. 2) We disagree with Hans about the importance of data portability -- we think that you should be able to have both forward and backward data portability. When Hans changes filesystem format, there has historically eventually been a tool to migrate you forward, but if you don't like it you are stuck. NEITHER OF THESE is intended to bash Hans. He just has different priorities and makes different tradeoffs than we believe are appropriate for our technology. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From drepper at redhat.com Mon Nov 10 21:21:48 2003 From: drepper at redhat.com (Ulrich Drepper) Date: Mon, 10 Nov 2003 13:21:48 -0800 Subject: Much faster? i18n? tls? In-Reply-To: References: Message-ID: <3FB0016C.1030005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Behdad Esfahbod wrote: >>>Was tweaking with the grep patch, and also tracking another >>>thread in another list, which was showing how on Red Hat 9 a >>>simple text intensive program (called hspell) is much slower than >>>Red Hat 8, and investigations have shown so far that it's all >>>caused by /lib/tls. Switching to /lib/i686 makes things go much >>>faster. Any idea? And it's not a multi-threaded application. I doubt that going with the /lib/i686 version makes it faster. In fact, the TLS code should be between 5-10% faster. >>>[behdad at mces behdad]$ time sed -e 's/./x/g' /bin/ls > /dev/null >>> >>>real 0m4.248s >>>user 0m3.800s >>>sys 0m0.000s >>>[behdad at mces behdad]$ time LANG=C sed -e 's/./x/g' /bin/ls > /dev/null >>> >>>real 0m0.180s >>>user 0m0.050s >>>sys 0m0.000s >>>[behdad at mces behdad]$ That's expected. UTF-8 handling is complicated. And we do have special support for single-byte encodings. You should be happy about that. Having this said, we might have some speedups for the regex code at some point. Speedups specifically for UTF-8. If you want to see this sooner, get out your editor and start hacking regex. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/sAFs2ijCOnn/RHQRArtCAJ0XfiQ9fB/6flSoK7zUtny6I/x2SwCgl68R BlLZ0oL31fqRiR5AHHauE8A= =z2H8 -----END PGP SIGNATURE----- From razvan.vilt at linux360.ro Mon Nov 10 21:31:39 2003 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Mon, 10 Nov 2003 23:31:39 +0200 Subject: Apache headers and other ones such as Xft In-Reply-To: <1068499026.1976.17.camel@home-04019.b.astral.ro> References: <1068499026.1976.17.camel@home-04019.b.astral.ro> Message-ID: <1068499899.1976.30.camel@home-04019.b.astral.ro> On Mon, 2003-11-10 at 23:17, Razvan Corneliu C.R. "d3vi1" VILT wrote: > While building a module for apache I've noticed the following problem > Out of pages of errors the most important lines are: > (...) > /usr/include/httpd/ap_config.h:58:17: apr.h: No such file or directory > (...) > There are similar ones for other .h files in /usr/include/apr-0 > The work-around was to move all the file from /usr/include/apr-0 to > /usr/include > Someone rearanged the header files in apr but forgot to update the > apache headers with the new location... ntz...ntz...ntz... > I've noticed this problem for Xft but in redhat 9, I'm not sure if they are still present in fedora core... Some X11 lib (namely /usr/include/X11/Xft/Xft.h) wanted some Xft1 headers (/usr/include/freetype/freetype.h) but in my case it wanted freetype 1 which was not there at the time... now apparently it works better due to a link from freetype to freetype2 But the problem may still be there for other -devel packages... > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From otaylor at redhat.com Mon Nov 10 21:51:58 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 10 Nov 2003 16:51:58 -0500 Subject: Apache headers and other ones such as Xft In-Reply-To: <1068499899.1976.30.camel@home-04019.b.astral.ro> References: <1068499026.1976.17.camel@home-04019.b.astral.ro> <1068499899.1976.30.camel@home-04019.b.astral.ro> Message-ID: <1068501118.9619.121.camel@poincare.devel.redhat.com> On Mon, 2003-11-10 at 16:31, Razvan Corneliu C.R. "d3vi1" VILT wrote: > On Mon, 2003-11-10 at 23:17, Razvan Corneliu C.R. "d3vi1" VILT wrote: > > While building a module for apache I've noticed the following problem > > Out of pages of errors the most important lines are: > > (...) > > /usr/include/httpd/ap_config.h:58:17: apr.h: No such file or directory > > (...) > > There are similar ones for other .h files in /usr/include/apr-0 > > The work-around was to move all the file from /usr/include/apr-0 to > > /usr/include > > Someone rearanged the header files in apr but forgot to update the > > apache headers with the new location... ntz...ntz...ntz... > > > I've noticed this problem for Xft but in redhat 9, I'm not sure if they > are still present in fedora core... Some X11 lib (namely > /usr/include/X11/Xft/Xft.h) wanted some Xft1 headers > (/usr/include/freetype/freetype.h) but in my case it wanted freetype 1 > which was not there at the time... now apparently it works better due to > a link from freetype to freetype2 * Xft always has used freetype2 * In order to link to freetype2, you need to use freetype-config to find the correct -I flags for freetype2 * 'pkg-config --cflags xft' will already include that -I directory, $ pkg-config --cflags xft -I/usr/X11R6/include -I/usr/include/freetype2 Regards, Owen From razvan.vilt at linux360.ro Mon Nov 10 22:02:54 2003 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Tue, 11 Nov 2003 00:02:54 +0200 Subject: Apache headers and other ones such as Xft In-Reply-To: <1068501118.9619.121.camel@poincare.devel.redhat.com> References: <1068499026.1976.17.camel@home-04019.b.astral.ro> <1068499899.1976.30.camel@home-04019.b.astral.ro> <1068501118.9619.121.camel@poincare.devel.redhat.com> Message-ID: <1068501774.1976.37.camel@home-04019.b.astral.ro> On Mon, 2003-11-10 at 23:51, Owen Taylor wrote: > On Mon, 2003-11-10 at 16:31, Razvan Corneliu C.R. "d3vi1" VILT wrote: > > On Mon, 2003-11-10 at 23:17, Razvan Corneliu C.R. "d3vi1" VILT wrote: > > > While building a module for apache I've noticed the following problem > > > Out of pages of errors the most important lines are: > > > (...) > > > /usr/include/httpd/ap_config.h:58:17: apr.h: No such file or directory > > > (...) > > > There are similar ones for other .h files in /usr/include/apr-0 > > > The work-around was to move all the file from /usr/include/apr-0 to > > > /usr/include > > > Someone rearanged the header files in apr but forgot to update the > > > apache headers with the new location... ntz...ntz...ntz... > > > > > I've noticed this problem for Xft but in redhat 9, I'm not sure if they > > are still present in fedora core... Some X11 lib (namely > > /usr/include/X11/Xft/Xft.h) wanted some Xft1 headers > > (/usr/include/freetype/freetype.h) but in my case it wanted freetype 1 > > which was not there at the time... now apparently it works better due to > > a link from freetype to freetype2 > > * Xft always has used freetype2 > > * In order to link to freetype2, you need to use freetype-config to > find the correct -I flags for freetype2 > > * 'pkg-config --cflags xft' will already include that -I directory, > > $ pkg-config --cflags xft > -I/usr/X11R6/include -I/usr/include/freetype2 > It was a bug which I've found on RHLinux9 while compiling gdkxft. It's not here anymore... It was only another example of header file stuff which I've been a witness of... Using the same sources (ver1.5) it works out of the box now on fedora because of that link from /usr/include/freetype to /usr/include/freetype2/freetype Also while compiling nvidia kernel module source-code due to some other weird stuff I had to make a link from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2 to /usr/lib/gcc-lib/i386-redhat-linux/3.2.3. Don't really know where it still thought that it was 3.2.2, forgot to report-it when I had the logs in sight... I assume that this is the right place to report problems caused by header files... right??? > Regards, > Owen > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From otaylor at redhat.com Mon Nov 10 22:25:47 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 10 Nov 2003 17:25:47 -0500 Subject: Apache headers and other ones such as Xft In-Reply-To: <1068501774.1976.37.camel@home-04019.b.astral.ro> References: <1068499026.1976.17.camel@home-04019.b.astral.ro> <1068499899.1976.30.camel@home-04019.b.astral.ro> <1068501118.9619.121.camel@poincare.devel.redhat.com> <1068501774.1976.37.camel@home-04019.b.astral.ro> Message-ID: <1068503147.19257.8.camel@poincare.devel.redhat.com> On Mon, 2003-11-10 at 17:02, Razvan Corneliu C.R. "d3vi1" VILT wrote: > On Mon, 2003-11-10 at 23:51, Owen Taylor wrote: > > On Mon, 2003-11-10 at 16:31, Razvan Corneliu C.R. "d3vi1" VILT wrote: > > > On Mon, 2003-11-10 at 23:17, Razvan Corneliu C.R. "d3vi1" VILT wrote: > > > > While building a module for apache I've noticed the following problem > > > > Out of pages of errors the most important lines are: > > > > (...) > > > > /usr/include/httpd/ap_config.h:58:17: apr.h: No such file or directory > > > > (...) > > > > There are similar ones for other .h files in /usr/include/apr-0 > > > > The work-around was to move all the file from /usr/include/apr-0 to > > > > /usr/include > > > > Someone rearanged the header files in apr but forgot to update the > > > > apache headers with the new location... ntz...ntz...ntz... > > > > > > > I've noticed this problem for Xft but in redhat 9, I'm not sure if they > > > are still present in fedora core... Some X11 lib (namely > > > /usr/include/X11/Xft/Xft.h) wanted some Xft1 headers > > > (/usr/include/freetype/freetype.h) but in my case it wanted freetype 1 > > > which was not there at the time... now apparently it works better due to > > > a link from freetype to freetype2 > > > > * Xft always has used freetype2 > > > > * In order to link to freetype2, you need to use freetype-config to > > find the correct -I flags for freetype2 > > > > * 'pkg-config --cflags xft' will already include that -I directory, > > > > $ pkg-config --cflags xft > > -I/usr/X11R6/include -I/usr/include/freetype2 > > > It was a bug which I've found on RHLinux9 while compiling gdkxft. ^^^^^^ Most likely gdkxft doesn't have appropriate configure scripts. I would strongly advise against using gdkxft in any case: it can cause a lot of different hard-to-diagnose problems on your system. (Especially if it gets loaded into gtk2 apps, as we've had reported in the GTK+ bug tracker many times.) > It's not here anymore... > It was only another example of header file stuff which I've been a > witness of... > Using the same sources (ver1.5) it works out of the box now on fedora > because of that link from /usr/include/freetype to > /usr/include/freetype2/freetype There's no such link. You must have created it locally. Regards, Owen From msnitzer at lnxi.com Mon Nov 10 22:52:28 2003 From: msnitzer at lnxi.com (Mike Snitzer) Date: Mon, 10 Nov 2003 15:52:28 -0700 Subject: rpm 4.2.1-0.30 sleeps in futex system call Message-ID: <20031110155228.A1994@lnxi.com> In attempting to import the Fedora GPG key with rpm 4.2.1-0.30 (from beta2 of FC) to upgrade to FC1; rpm goes to sleep in the futex system call. ... open("/var/lib/rpm/Packages", O_RDWR|O_LARGEFILE) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=31690752, ...}) = 0 futex(0x406d0280, FUTEX_WAIT, 0, NULL I am running 2.6.0-test9-mm1 and all has worked fine up until now; if I attempt to shove the GPG key in there with: LD_ASSUME_KERNEL=2.2.4 rpm --import fedora.RPM-GPG-KEY.txt I get: rpm: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory so _really_ old pthreads libs (non-tls) don't offer librt.so (or a compatibility symlink is missing?); but this did the trick: LD_ASSUME_KERNEL=2.4.1 rpm --import fedora.RPM-GPG-KEY.txt In any case, why might the futex system call get reliably wedged during an rpm --import given that I'm using an nptl, futex, tls, enabled kernel? Might an internal rpm lock be held? thanks, Mike From rms at 1407.org Mon Nov 10 23:36:18 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 10 Nov 2003 23:36:18 +0000 Subject: kernel with swsusp In-Reply-To: <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> Message-ID: <1068507378.3135.4.camel@roque> On Mon, 2003-11-10 at 19:50, Nicolas Mailhot wrote: > Le lun 10/11/2003 ? 20:33, Rui Miguel Seabra a ?crit : > > I'd rather check for a backport than jump into the 2.6 world right now. > > I have absolutely no suspend: this is an acpi only laptop, and S3 does > > nothing on it. > Not to mention suspend on 2.6 is not really ready now (last time I > chacked there were three ! different implementations competing) Well, swsusp seems to be working right enough on 2.6 (yes, I dared), but I had to come back: natsemi not working == !eth == BAD BAD! > OTOH, there are loads of stuff available in 2.6 that people have been > awaiting for ages (alsa, ipsec, acls, xfs, sane cd burning, dm, udev...) > At this point fedora devel should switch to 2.6 asap to get it ready for > FC2. 2.4 enhancements seem more a job for the legacy project now. I think so. Most of the things I like on RedHat's (now Fedora's) kernel is that it has cool things backported to the stable kernel. With 2.6 they're there, but 2.6 needs heavy testing. Before I noticed I had no eth, I tested swsusp and acpi which seemed to be fine. Then I went for alsa, when I remembered I didn't have the required utils, and when I tried to fetch them DUH no net. Basically, natsemi loads, the interface gets up, but I see no packets going on with tcpdump except for me who-has'ing the net for my home gw. 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 behdad at cs.toronto.edu Tue Nov 11 02:59:47 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 10 Nov 2003 21:59:47 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068492189.7394.1.camel@banff.drgutah.com> References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068274604.14565.22.camel@binkley> <1068402172.16321.56.camel@binkley> <1068492189.7394.1.camel@banff.drgutah.com> Message-ID: On Mon, 10 Nov 2003, Jared Smith wrote: > On Sun, 2003-11-09 at 11:22, seth vidal wrote: > > > YUP was the Yellowdog UPdater. > > so maybe yum should be yupm but considering it shares maybe 2 functions > > with yup it doesn't seem all that important. > > To be completely honest, yum was selected as a name b/c it was: > > 1. short > > 2. not already taken > > > > Hmmmn... I just had a thought... why not rename it to "rum", as in > Redhat Updater, iMproved! (OK, this borders on trolling, so I'll stop.) > > Jared While yum is a short and nice name, renaming it to something like system-package-* (or making a symlink?) helps so that the new user/admin simply types syste-TAB and finds what he's looking for. From skvidal at phy.duke.edu Tue Nov 11 03:07:34 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 10 Nov 2003 22:07:34 -0500 Subject: TradeMarked Name --redhat-config- In-Reply-To: References: <200311080241.hA82fIA18902@devserv.devel.redhat.com> <1068274604.14565.22.camel@binkley> <1068402172.16321.56.camel@binkley> <1068492189.7394.1.camel@banff.drgutah.com> Message-ID: <1068520054.29905.0.camel@binkley> > While yum is a short and nice name, renaming it to something like > system-package-* (or making a symlink?) helps so that the new > user/admin simply types syste-TAB and finds what he's looking > for. I'd have no problem with a symlink for the command executable but I think yum is such a cute name :) -sv From behdad at cs.toronto.edu Tue Nov 11 03:18:18 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 10 Nov 2003 22:18:18 -0500 Subject: Much faster? i18n? tls? In-Reply-To: <3FB0016C.1030005@redhat.com> References: <3FB0016C.1030005@redhat.com> Message-ID: On Mon, 10 Nov 2003, Ulrich Drepper wrote: > Behdad Esfahbod wrote: > >>>Was tweaking with the grep patch, and also tracking another > >>>thread in another list, which was showing how on Red Hat 9 a > >>>simple text intensive program (called hspell) is much slower than > >>>Red Hat 8, and investigations have shown so far that it's all > >>>caused by /lib/tls. Switching to /lib/i686 makes things go much > >>>faster. Any idea? And it's not a multi-threaded application. > > I doubt that going with the /lib/i686 version makes it faster. In fact, > the TLS code should be between 5-10% faster. I've already seen the thread on LKML with Linus which I assume solves this problem. > >>>[behdad at mces behdad]$ time sed -e 's/./x/g' /bin/ls > /dev/null > >>> > >>>real 0m4.248s > >>>user 0m3.800s > >>>sys 0m0.000s > >>>[behdad at mces behdad]$ time LANG=C sed -e 's/./x/g' /bin/ls > /dev/null > >>> > >>>real 0m0.180s > >>>user 0m0.050s > >>>sys 0m0.000s > >>>[behdad at mces behdad]$ > > That's expected. UTF-8 handling is complicated. And we do have special > support for single-byte encodings. You should be happy about that. Sure, but UTF-8 is not such a hard thing to handle. > Having this said, we might have some speedups for the regex code at some > point. Speedups specifically for UTF-8. If you want to see this > sooner, get out your editor and start hacking regex. I would definitely do. I'm afraid the problem is not UTF-8 itself, but other legacy multi-byte ones. I mean, may it be that special support for UTF-8 may be needed... behdad From drepper at redhat.com Tue Nov 11 03:27:40 2003 From: drepper at redhat.com (Ulrich Drepper) Date: Mon, 10 Nov 2003 19:27:40 -0800 Subject: Much faster? i18n? tls? In-Reply-To: References: <3FB0016C.1030005@redhat.com> Message-ID: <3FB0572C.5010903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Behdad Esfahbod wrote: > I've already seen the thread on LKML with Linus which I assume > solves this problem. If any code needed that specific patch, make sure the author never touches a keyboard again and rewrite the code. No production code should ever be affected by that change in any noticeable way. > Sure, but UTF-8 is not such a hard thing to handle. Then do it. > I would definitely do. I'm afraid the problem is not UTF-8 > itself, but other legacy multi-byte ones. I mean, may it be that > special support for UTF-8 may be needed... No legacy encoding is of any interest. If we add any special encoding optimization this will be only and exclusively for UTF-8. It's the only encoding one needs. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/sFcs2ijCOnn/RHQRAm+kAJ9NxvBrrhBd1OMSUH6VRz/mlPJ9RwCgnavR /4sVH1KVdr8Xbyd+UIPWsTc= =6TS5 -----END PGP SIGNATURE----- From paul at dishone.st Tue Nov 11 05:57:46 2003 From: paul at dishone.st (Paul Jakma) Date: Tue, 11 Nov 2003 05:57:46 +0000 (GMT) Subject: Bootstrapping Fedora off old Red Hat In-Reply-To: <1068416579.4564.15.camel@isengard> References: <200311092044.hA9KivT22354@devserv.devel.redhat.com> <1068416579.4564.15.camel@isengard> Message-ID: On Sun, 9 Nov 2003, Klaasjan Brand wrote: > I'm wondering: is there some public documentation about doing a > full rebuild for Fedora? I'd be interested in such docs too. (though, my target would be non-linux, and i wouldnt be interested in linux specific packages, rather general userspace apps and GNOME). > Klaasjan regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: When speculation has done its worst, two plus two still equals four. -- S. Johnson From kjb at dds.nl Tue Nov 11 08:24:03 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Tue, 11 Nov 2003 09:24:03 +0100 Subject: kernel with swsusp In-Reply-To: <1068507378.3135.4.camel@roque> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> Message-ID: <3FB09CA3.9060002@dds.nl> Rui Miguel Seabra wrote: > >>Not to mention suspend on 2.6 is not really ready now (last time I >>chacked there were three ! different implementations competing) >> >> > >Well, swsusp seems to be working right enough on 2.6 (yes, I dared), but >I had to come back: natsemi not working == !eth == BAD BAD! > > > Could you please submit a bug report or help te developers get that driver working? 2.6 will always be "bad" if noone makes sure things get fixed... Klaasjan From rms at 1407.org Tue Nov 11 01:09:10 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 11 Nov 2003 01:09:10 +0000 Subject: kernel with swsusp In-Reply-To: <3FB09CA3.9060002@dds.nl> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> <3FB09CA3.9060002@dds.nl> Message-ID: <1068512950.3003.2.camel@roque> On Tue, 2003-11-11 at 08:24, Klaasjan Brand wrote: > Rui Miguel Seabra wrote: > >>Not to mention suspend on 2.6 is not really ready now (last time I > >>chacked there were three ! different implementations competing) > >Well, swsusp seems to be working right enough on 2.6 (yes, I dared), but > >I had to come back: natsemi not working == !eth == BAD BAD! > Could you please submit a bug report or help te developers get that > driver working? 2.6 will always be "bad" if noone makes sure things get > fixed... Where's the best place for driver bug reports? The developer listed for it or is there a bugzilla for Linux? Anyway, I found out that the problem was that the driver didn't like the swsusp thing, so I just changed the acpi script I made to unload natsemi before suspending. Right now, all that's missing is the 'wheel' of this HP/Compaq NX9010 which is misteriously gone. 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 maxka at myrealbox.com Tue Nov 11 09:40:46 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Tue, 11 Nov 2003 01:40:46 -0800 Subject: Hardware Database In-Reply-To: <20031110140858.GF8954@redhat.com> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <20031107133425.A13384@devserv.devel.redhat.com> <20031109223941.GE8954@redhat.com> <1068454297.3280.5.camel@max.localdomain> <20031110140858.GF8954@redhat.com> Message-ID: <1068543646.3296.18.camel@max.localdomain> On Mon, 2003-11-10 at 06:08, Dave Jones wrote: > On Mon, Nov 10, 2003 at 12:51:37AM -0800, Maxwell Kanat-Alexander wrote: > > On Sun, 2003-11-09 at 14:39, Dave Jones wrote: > > > Beware that a lot of BIOS vendors put utter garbage in their DMI tables. > > > > Do you know if there's any sense to this garbage? I've noticed a lot of > > "System Manufacturer: System Manufacturer" sort of things -- is this a > > common pattern, or do we just have to figure it out in some fuzzy way? > > Sometimes its empty fields, sometimes random characters, sometimes > complete lies (Like saying it has a full length EISA slot in a laptop) Sigh. I guess we'll have to fuzz it one way or another. We'll have to check for certain impossible things, too, like that full-length EISA slot in a laptop. -M From jorton at redhat.com Tue Nov 11 09:59:35 2003 From: jorton at redhat.com (Joe Orton) Date: Tue, 11 Nov 2003 09:59:35 +0000 Subject: Apache headers In-Reply-To: <1068499026.1976.17.camel@home-04019.b.astral.ro> References: <1068499026.1976.17.camel@home-04019.b.astral.ro> Message-ID: <20031111095935.GA10427@redhat.com> On Mon, Nov 10, 2003 at 11:17:06PM +0200, Razvan Corneliu C.R. d3vi1 VILT wrote: > While building a module for apache I've noticed the following problem > Out of pages of errors the most important lines are: > (...) > /usr/include/httpd/ap_config.h:58:17: apr.h: No such file or directory > (...) > There are similar ones for other .h files in /usr/include/apr-0 > The work-around was to move all the file from /usr/include/apr-0 to > /usr/include > Someone rearanged the header files in apr but forgot to update the > apache headers with the new location... ntz...ntz...ntz... How are you building your module? You should either: 1. use apxs -c directly, in which case the include paths will be correct, i.e. apxs -c mod_foo.c or 2. query apxs for the correct include paths, i.e. add -I`apxs -q includedir` -I`apxs -q APR_INCLUDEDIR` to CFLAGS. Regards, joe From kjb at dds.nl Tue Nov 11 10:58:55 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Tue, 11 Nov 2003 11:58:55 +0100 Subject: kernel with swsusp In-Reply-To: <1068512950.3003.2.camel@roque> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> <3FB09CA3.9060002@dds.nl> <1068512950.3003.2.camel@roque> Message-ID: <3FB0C0EF.3030600@dds.nl> Rui Miguel Seabra wrote: > >>Could you please submit a bug report or help te developers get that >>driver working? 2.6 will always be "bad" if noone makes sure things get >>fixed... >> >> > >Where's the best place for driver bug reports? The developer listed for >it or is there a bugzilla for Linux? > > > It's on http://bugzilla.kernel.org/ Alternatively you could try harassing the maintainer of swsuspend or the driver, I've found out that actually works ;) >Anyway, I found out that the problem was that the driver didn't like the >swsusp thing, so I just changed the acpi script I made to unload natsemi >before suspending. > > > Which is a bug that should be fixed... >Right now, all that's missing is the 'wheel' of this HP/Compaq NX9010 >which is misteriously gone. > > Is that a "wheel mouse" problem? Klaasjan From rms at 1407.org Tue Nov 11 11:09:34 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 11 Nov 2003 11:09:34 +0000 Subject: kernel with swsusp In-Reply-To: <3FB0C0EF.3030600@dds.nl> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> <3FB09CA3.9060002@dds.nl> <1068512950.3003.2.camel@roque> <3FB0C0EF.3030600@dds.nl> Message-ID: <1068548974.1500.28.camel@roque> On Tue, 2003-11-11 at 10:58, Klaasjan Brand wrote: > Rui Miguel Seabra wrote: > >Right now, all that's missing is the 'wheel' of this HP/Compaq NX9010 > >which is misteriously gone. > Is that a "wheel mouse" problem? With Linux 2.4.22-1.2115.nptl the mouse pad works (including 'wheel' -- which in fact is part of the mousepad), and XFree's driver is mouse. With Linux 2.6.0-test9 the mouse pad works partially (no 'wheel'). Trying to solve this, I added support for synaptics (the pad seems to be a synaptics) but X wouldn't support the mouse pad. I tried using a more recent driver for X, it would load, but I'd have no mouse pad, only button 1 and button 3 (no middle even with Emulate). It might be a matter of XFree86 driver for the pad, so I will wait for a newer release, swsusp is a benefit that compensates lack of a 'wheeled' mouse (if if I was getting used to it *sigh*). 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 Axel.Thimm at physik.fu-berlin.de Tue Nov 11 11:13:19 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 11 Nov 2003 12:13:19 +0100 Subject: kernel with swsusp In-Reply-To: <1068492814.3239.2.camel@roque> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> Message-ID: <20031111111319.GC25706@puariko.nirvana> On Mon, Nov 10, 2003 at 07:33:35PM +0000, Rui Miguel Seabra wrote: > On Mon, 2003-11-10 at 19:11, Klaasjan Brand wrote: > > Don't know for sure, but swsuspend is integrated in the 2.6 kernel of > > which there are test rpms at: http://people.redhat.com/arjanv/2.5/ > > I'd rather check for a backport than jump into the 2.6 world right now. > I have absolutely no suspend: this is an acpi only laptop, and S3 does > nothing on it. > > So nobody else is trying or has tried to bundle swsusp with the > currently distributed kernel? I tried based on patches provided by Tom "spot" Callaway on http://people.redhat.com/tcallawa/swsusp/ There are some people that have tried to get swsusp working with nptl on swsusp-devel at lists.sourceforge.net. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at gear.dyndns.org Tue Nov 11 11:17:02 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Tue, 11 Nov 2003 21:17:02 +1000 Subject: /etc/localtime isn't world readable In-Reply-To: References: Message-ID: <3FB0C52E.4080707@gear.dyndns.org> Alexandre Oliva wrote: > On Nov 10, 2003, "Jean-Francois Veillette" wrote: > > >>I wonder why /etc/localtime isn't world readable in the Fedora Core >>distribution. > > > Err... It is for me. And I think it has to be. I've seen this bug appear after using timeconfig if root's umask was not 022 or something similar. (I always set it to 027, and i've had several problems caused by this.) -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kjb at dds.nl Tue Nov 11 11:23:49 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Tue, 11 Nov 2003 12:23:49 +0100 Subject: kernel with swsusp In-Reply-To: <1068548974.1500.28.camel@roque> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> <3FB09CA3.9060002@dds.nl> <1068512950.3003.2.camel@roque> <3FB0C0EF.3030600@dds.nl> <1068548974.1500.28.camel@roque> Message-ID: <3FB0C6C5.3030503@dds.nl> Rui Miguel Seabra wrote: > >With Linux 2.6.0-test9 the mouse pad works partially (no 'wheel'). >Trying to solve this, I added support for synaptics (the pad seems to be >a synaptics) but X wouldn't support the mouse pad. >I tried using a more recent driver for X, it would load, but I'd have no >mouse pad, only button 1 and button 3 (no middle even with Emulate). > > Synaptics is known to be problematic, but the choice remains yours: do nothing and hope other people fix it, or try helping the driver maintainer to fix it. Klaasjan From rms at 1407.org Tue Nov 11 11:34:09 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 11 Nov 2003 11:34:09 +0000 Subject: kernel with swsusp In-Reply-To: <3FB0C6C5.3030503@dds.nl> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> <3FB09CA3.9060002@dds.nl> <1068512950.3003.2.camel@roque> <3FB0C0EF.3030600@dds.nl> <1068548974.1500.28.camel@roque> <3FB0C6C5.3030503@dds.nl> Message-ID: <1068550449.1500.48.camel@roque> On Tue, 2003-11-11 at 11:23, Klaasjan Brand wrote: > Synaptics is known to be problematic, but the choice remains yours: do > nothing and hope other people fix it, or try helping the driver > maintainer to fix it. I would like to help, but I don't know if I am capable :|. I don't even know whether it's just a Linux problem, or an XFree86 problem or both :} What I know is that the mouse support in Linux 2.4 get's me a fully working mousepad, but the driver interface may have changed ever so slightly, and development series X might support it properly already. I don't know. 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 kjb at dds.nl Tue Nov 11 12:03:17 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Tue, 11 Nov 2003 13:03:17 +0100 Subject: kernel with swsusp In-Reply-To: <1068550449.1500.48.camel@roque> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> <3FB09CA3.9060002@dds.nl> <1068512950.3003.2.camel@roque> <3FB0C0EF.3030600@dds.nl> <1068548974.1500.28.camel@roque> <3FB0C6C5.3030503@dds.nl> <1068550449.1500.48.camel@roque> Message-ID: <3FB0D005.2060505@dds.nl> Rui Miguel Seabra wrote: >On Tue, 2003-11-11 at 11:23, Klaasjan Brand wrote: > > >>Synaptics is known to be problematic, but the choice remains yours: do >>nothing and hope other people fix it, or try helping the driver >>maintainer to fix it. >> >> > >I would like to help, but I don't know if I am capable :|. > > Often just reporting to the driver author if some changes improve the situation or not can be helpful. >I don't even know whether it's just a Linux problem, or an XFree86 >problem or both :} > > If it's working with 2.4 my guess would be a kernel problem. The event interface is fairly standardized (unless synaptics is some weird special case of course...) >What I know is that the mouse support in Linux 2.4 get's me a fully >working mousepad, but the driver interface may have changed ever so >slightly, and development series X might support it properly already. I >don't know. > > Could be, maybe you could try the redhat-xfree86 mailing list. Klaasjan From Nicolas.Mailhot at laPoste.net Tue Nov 11 12:10:17 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 11 Nov 2003 13:10:17 +0100 Subject: kernel with swsusp In-Reply-To: <3FB0D005.2060505@dds.nl> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> <3FB09CA3.9060002@dds.nl> <1068512950.3003.2.camel@roque> <3FB0C0EF.3030600@dds.nl> <1068548974.1500.28.camel@roque> <3FB0C6C5.3030503@dds.nl> <1068550449.1500.48.camel@roque> <3FB0D005.2060505@dds.nl> Message-ID: <1068552617.20891.1.camel@m70.net81-64-235.noos.fr> Le mar 11/11/2003 ? 13:03, Klaasjan Brand a ?crit : > If it's working with 2.4 my guess would be a kernel problem. The event > interface is fairly standardized (unless synaptics is some weird special > case of course...) The synaptics driver in 2.6 is a new implementation. It needs updated userspace (XFree driver). Since I don't have a synaptics device, can't comment on the new driver quality. 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 rms at 1407.org Tue Nov 11 12:19:56 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 11 Nov 2003 12:19:56 +0000 Subject: kernel with swsusp In-Reply-To: <3FB0D005.2060505@dds.nl> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> <3FB09CA3.9060002@dds.nl> <1068512950.3003.2.camel@roque> <3FB0C0EF.3030600@dds.nl> <1068548974.1500.28.camel@roque> <3FB0C6C5.3030503@dds.nl> <1068550449.1500.48.camel@roque> <3FB0D005.2060505@dds.nl> Message-ID: <1068553196.1500.52.camel@roque> On Tue, 2003-11-11 at 12:03, Klaasjan Brand wrote: > Often just reporting to the driver author if some changes improve the > situation or not can be helpful. I'm going to try arjanv's Linux rpms first. 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 Tue Nov 11 12:40:34 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 11 Nov 2003 12:40:34 +0000 Subject: kernel with swsusp In-Reply-To: <1068553196.1500.52.camel@roque> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> <3FB09CA3.9060002@dds.nl> <1068512950.3003.2.camel@roque> <3FB0C0EF.3030600@dds.nl> <1068548974.1500.28.camel@roque> <3FB0C6C5.3030503@dds.nl> <1068550449.1500.48.camel@roque> <3FB0D005.2060505@dds.nl> <1068553196.1500.52.camel@roque> Message-ID: <1068554434.1484.0.camel@roque> Same problem, as I expected. On Tue, 2003-11-11 at 12:19, Rui Miguel Seabra wrote: > On Tue, 2003-11-11 at 12:03, Klaasjan Brand wrote: > > Often just reporting to the driver author if some changes improve the > > situation or not can be helpful. > > I'm going to try arjanv's Linux rpms first. > > 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 tony at tgds.net Tue Nov 11 12:49:47 2003 From: tony at tgds.net (tony) Date: Tue, 11 Nov 2003 13:49:47 +0100 Subject: more yum problems Message-ID: <1068554986.5435.83.camel@localhost.localdomain> I thought I would try a yum update of a machine from RH9 -> Fedora Core 1 I have gnome errors because I am running Ximian Desktop 2 - no problems there I know how to fix that - but the libraries are installed (in the wrong place?) .package gnome-libs needs libdb.so.2 (not provided) package ghfaxviewer needs libdb.so.2 (not provided) package gnome-libs needs libdb.so.2(GLIBC_2.0) (not provided) # locate libdb.so.2 /usr/lib/libdb.so.2 But this is more annoying package samba needs libcom_err.so.3 (not provided) # locate libcom /usr/kerberos/lib/libcom_err.so.3.0 /usr/kerberos/lib/libcom_err.so.3 /usr/kerberos/lib/libcom_err.a /usr/kerberos/lib/libcom_err.so /lib/libcom_err.so.2.0 /lib/libcom_err.so.2 Samba 3 was installed from an rpm found from link on samba.org Any light shed greatly appreciated. Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From skvidal at phy.duke.edu Tue Nov 11 13:04:41 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 11 Nov 2003 08:04:41 -0500 Subject: more yum problems In-Reply-To: <1068554986.5435.83.camel@localhost.localdomain> References: <1068554986.5435.83.camel@localhost.localdomain> Message-ID: <1068555880.29905.41.camel@binkley> > I thought I would try a yum update of a machine from RH9 > -> Fedora Core 1 > > I have gnome errors because I am running Ximian Desktop 2 - no problems > there I know how to fix that - but the libraries are installed (in the > wrong place?) > read through the fedora core release notes, note the sections about ximian packages. You pretty much need to follow those same things for yum updating if you've install the XD2 packages. > Samba 3 was installed from an rpm found from link on samba.org the samba3 was not built on fc1 so it's using the wrong library. -sv From tony at tgds.net Tue Nov 11 13:25:50 2003 From: tony at tgds.net (tony) Date: Tue, 11 Nov 2003 14:25:50 +0100 Subject: more yum problems In-Reply-To: <1068555880.29905.41.camel@binkley> References: <1068554986.5435.83.camel@localhost.localdomain> <1068555880.29905.41.camel@binkley> Message-ID: <1068557150.5435.85.camel@localhost.localdomain> Le mar 11/11/2003 ? 14:04, seth vidal a ?crit : > > Samba 3 was installed from an rpm found from link on samba.org > > the samba3 was not built on fc1 so it's using the wrong library. OK thanks that is what I thought! Tony -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From johnsonm at redhat.com Tue Nov 11 14:15:46 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 11 Nov 2003 09:15:46 -0500 Subject: Warren's rejection of cooperation with other repos In-Reply-To: <20031108175907.GB22078@puariko.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Sat, Nov 08, 2003 at 06:59:07PM +0100 References: <20031108120954.GA18487@puariko.nirvana> <20031108175907.GB22078@puariko.nirvana> Message-ID: <20031111091546.A14986@devserv.devel.redhat.com> On Sat, Nov 08, 2003 at 06:59:07PM +0100, Axel Thimm wrote: > On Sat, Nov 08, 2003 at 05:59:31PM +0200, Panu Matilainen wrote: > > Oh but that was NEVER the idea behind fedora.us. The idea was to create a > > repository run by community of packagers, not a community of repositories > > run by individuals. > > Of course it was, at least by the people that were finaly driven away ... I'd like to state Red Hat's opinion on this matter, so I'll don my "Technical Lead" hat for a moment. It's VERY important to have a unified repository with shared packaging standards where people can come for extra/alternative packages. It's VERY important to enable ARBITRARY third-party repositories, for software that for any of many reasons (level of testing, different legal status in different countries, different licenses, maturity of project, preference of packager) isn't in the unified repository. These two goals are not in competition; they are separate goals (with roughly equal weight) that Red Hat has for its participation in this project. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From dhollis at davehollis.com Tue Nov 11 14:31:35 2003 From: dhollis at davehollis.com (David T Hollis) Date: Tue, 11 Nov 2003 09:31:35 -0500 Subject: ifup-ipsec adds route Message-ID: <1068560819.5124.5.camel@dhollis-lnx.kpmg.com> I recently managed to get the Linux 2.6 IPSEC up and running using the ipsec-tools RPM that was briefly in Rawhide. While converting to use the support that is in initscripts for IPSEC, I noticed that the scripts attempt to create an IP route: ip route add to $DSTNET via $DST if it's a tunnel connection. In my scenario (which I think is the pretty typical scenario of LAN_A -> gw1 -> Internet <- gw2 <- LAN_B), that call fails with: RTNETLINK answers: Network is unreachable. This call is failing because $DST is not on my local network so it can't be the next hop. I've found that the scripts work fine with that line erroring out or commented out so it is innocuous. Just curious as to what the reasoning was for that statement. Otherwise, thanks a bunch for putting the support into initscripts, really cuts down on a lot of work! From johnsonm at redhat.com Tue Nov 11 14:43:39 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 11 Nov 2003 09:43:39 -0500 Subject: Update on RH 7.3 In-Reply-To: <3FAE5138.30105@devin.com.br>; from hugo@devin.com.br on Sun, Nov 09, 2003 at 11:37:44AM -0300 References: <3FAE17E2.5040604@uol.com.br> <3FAE5138.30105@devin.com.br> Message-ID: <20031111094339.B14986@devserv.devel.redhat.com> On Sun, Nov 09, 2003 at 11:37:44AM -0300, Hugo Cisneiros wrote: > Alexander Martins wrote: > > I'd like to know if someone could install the FC1 from a update on > > RH 7.3. Is it possible? > > I think it's possible because someone already reported sucessfull > updates from RH to FC1. But since you're using an older version of RH, > you may want to try (I don't see any problem updating). If you have linuxconf installed, remove it before you try. There's a now-known bug where having linuxconf installed before upgrading from older releases will break the installer. Fortunately, it's before package installation happens, so you do not end up with a scrambled system, you still should be able to remove linuxconf manually and then re-start the install process. Other than that glitch (oops) it should work; we know of success stories... michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From johnsonm at redhat.com Tue Nov 11 14:58:58 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 11 Nov 2003 09:58:58 -0500 Subject: Hardware Database In-Reply-To: <20031109223941.GE8954@redhat.com>; from davej@redhat.com on Sun, Nov 09, 2003 at 10:39:41PM +0000 References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <20031107133425.A13384@devserv.devel.redhat.com> <20031109223941.GE8954@redhat.com> Message-ID: <20031111095858.C14986@devserv.devel.redhat.com> On Sun, Nov 09, 2003 at 10:39:41PM +0000, Dave Jones wrote: > Beware that a lot of BIOS vendors put utter garbage in their DMI tables. Well, then their carelessness will show up in a public database. :-) michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From daly at rio.sci.ccny.cuny.edu Tue Nov 11 14:38:48 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Tue, 11 Nov 2003 09:38:48 -0500 Subject: legal issues Message-ID: <200311111438.hABEcm132027@rio.sci.ccny.cuny.edu> Perhaps there should be a fedora-legal mailing list so the legal questions can be taken out of fedora-devel? Tim Daly Sr. daly at rio.sci.ccny.cuny.edu From skvidal at phy.duke.edu Tue Nov 11 15:23:46 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 11 Nov 2003 10:23:46 -0500 Subject: legal issues In-Reply-To: <200311111438.hABEcm132027@rio.sci.ccny.cuny.edu> References: <200311111438.hABEcm132027@rio.sci.ccny.cuny.edu> Message-ID: <1068564226.26123.35.camel@opus> On Tue, 2003-11-11 at 09:38, Tim Daly wrote: > Perhaps there should be a fedora-legal mailing list > so the legal questions can be taken out of fedora-devel? already been requested. Thanks! -sv From daly at rio.sci.ccny.cuny.edu Tue Nov 11 14:52:04 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Tue, 11 Nov 2003 09:52:04 -0500 Subject: package submission guidelines Message-ID: <200311111452.hABEq4v00317@rio.sci.ccny.cuny.edu> Are there package submission guidelines? I'm the lead developer on two open source packages and I want to build rpms for yarrow. Tim Daly Sr. daly at rio.sci.ccny.cuny.edu From vianez at vodafone.it Tue Nov 11 15:40:48 2003 From: vianez at vodafone.it (Nicola Vianelli) Date: Tue, 11 Nov 2003 16:40:48 +0100 Subject: vianez@vofaone! DELETE ME!!! Message-ID: <200311111640.48943.vianez@vodafone.it> DELETE ME FROM THE NEWS LIST!!! From johnsonm at redhat.com Tue Nov 11 15:51:23 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 11 Nov 2003 10:51:23 -0500 Subject: package submission guidelines In-Reply-To: <200311111452.hABEq4v00317@rio.sci.ccny.cuny.edu>; from daly@rio.sci.ccny.cuny.edu on Tue, Nov 11, 2003 at 09:52:04AM -0500 References: <200311111452.hABEq4v00317@rio.sci.ccny.cuny.edu> Message-ID: <20031111105123.D14986@devserv.devel.redhat.com> On Tue, Nov 11, 2003 at 09:52:04AM -0500, Tim Daly wrote: > Are there package submission guidelines? I'm the lead developer on > two open source packages and I want to build rpms for yarrow. While we build these guidelines and the infrastructure required, we are recommending submitting packages to fedora.us michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From notting at redhat.com Tue Nov 11 16:22:43 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Nov 2003 11:22:43 -0500 Subject: Hardware Database In-Reply-To: <1068543646.3296.18.camel@max.localdomain>; from maxka@myrealbox.com on Tue, Nov 11, 2003 at 01:40:46AM -0800 References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <20031107133425.A13384@devserv.devel.redhat.com> <20031109223941.GE8954@redhat.com> <1068454297.3280.5.camel@max.localdomain> <20031110140858.GF8954@redhat.com> <1068543646.3296.18.camel@max.localdomain> Message-ID: <20031111112243.D30891@devserv.devel.redhat.com> Maxwell Kanat-Alexander (maxka at myrealbox.com) said: > > Sometimes its empty fields, sometimes random characters, sometimes > > complete lies (Like saying it has a full length EISA slot in a laptop) > > Sigh. I guess we'll have to fuzz it one way or another. We'll have to > check for certain impossible things, too, like that full-length EISA > slot in a laptop. In general, I don't think you need to use DMI for anything other than: - system type - system model/serial number - bios mfr/rev Any of the other stuff (memory installed, slot types, etc.) is either mostly irrelevant, or can be gotten by other means. Bill From notting at redhat.com Tue Nov 11 16:35:43 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Nov 2003 11:35:43 -0500 Subject: ifup-ipsec adds route In-Reply-To: <1068560819.5124.5.camel@dhollis-lnx.kpmg.com>; from dhollis@davehollis.com on Tue, Nov 11, 2003 at 09:31:35AM -0500 References: <1068560819.5124.5.camel@dhollis-lnx.kpmg.com> Message-ID: <20031111113543.F30891@devserv.devel.redhat.com> David T Hollis (dhollis at davehollis.com) said: > I recently managed to get the Linux 2.6 IPSEC up and running using the > ipsec-tools RPM that was briefly in Rawhide. While converting to use > the support that is in initscripts for IPSEC, I noticed that the scripts > attempt to create an IP route: > > ip route add to $DSTNET via $DST > > if it's a tunnel connection. In my scenario (which I think is the > pretty typical scenario of LAN_A -> gw1 -> Internet <- gw2 <- LAN_B), > that call fails with: RTNETLINK answers: Network is unreachable. It's needed in some scenarios, namely when you can't get to $DSTNET via your normal default gateway. Bill From phuegelm at uos.de Tue Nov 11 16:42:04 2003 From: phuegelm at uos.de (Philipp Huegelmeyer) Date: Tue, 11 Nov 2003 17:42:04 +0100 Subject: kernel with swsusp In-Reply-To: <1068554434.1484.0.camel@roque> References: <1068485264.16189.17.camel@roque> <1068491501.1515.2.camel@isengard> <1068492814.3239.2.camel@roque> <1068493837.15414.11.camel@m70.net81-64-235.noos.fr> <1068507378.3135.4.camel@roque> <3FB09CA3.9060002@dds.nl> <1068512950.3003.2.camel@roque> <3FB0C0EF.3030600@dds.nl> <1068548974.1500.28.camel@roque> <3FB0C6C5.3030503@dds.nl> <1068550449.1500.48.camel@roque> <3FB0D005.2060505@dds.nl> <1068553196.1500.52.camel@roque> <1068554434.1484.0.camel@roque> Message-ID: <3FB1115C.5050403@uos.de> Rui Miguel Seabra wrote: > Same problem, as I expected. > > > On Tue, 2003-11-11 at 12:19, Rui Miguel Seabra wrote: > >>On Tue, 2003-11-11 at 12:03, Klaasjan Brand wrote: >> >>>Often just reporting to the driver author if some changes improve the >>>situation or not can be helpful. >> >>I'm going to try arjanv's Linux rpms first. >> >>Rui Have a look at this: http://kerneltrap.org/node/view/1587 seems like mouse is a real problem in 2.6 -- Philipp H\"ugelmeyer Universit\"at Osnabr\"uck Tel: 0541-969-3351 (B\"uro)Zentrum VirtUOS Fax: 0541-969-3352 Rolandstr 8 D-49069 url: http:/www.error-42.de http://www.virtuos.uos.de ------------------------------------------------------------------ pgp-fingerprint: D008 BB2B 0B48 80EC CDF0 CBF0 D665 8CFF 63D9 DF8A From kewley at cns.caltech.edu Tue Nov 11 17:59:46 2003 From: kewley at cns.caltech.edu (David Kewley) Date: Tue, 11 Nov 2003 09:59:46 -0800 Subject: sk98lin driver disks Message-ID: <200311110959.46940.kewley@cns.caltech.edu> A quick update to a differently-named thread back in July: I needed updated sk98lin drivers for the 3C940 interface on the Asus P4P800 motherboard (also used for the Asus P4C800). I wanted to use the drivers during a network kickstart. I ended up making driver disks for RHL9, and it should be easy to produce them for other versions of RHL and FC as well. I've provided the driver disk images and described the process for making them at: http://www.klab.caltech.edu/~kewley/driverdisk/sk98lin.html In addition, I've written up some general guidance for making driver disks using Doug Ledford's kit: http://www.klab.caltech.edu/~kewley/driverdisk/dd.html Hope this is helpful to some of you, and to those who search this list for help. :) David From jkeating at j2solutions.net Tue Nov 11 18:06:05 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 11 Nov 2003 10:06:05 -0800 Subject: rc.local blocking Message-ID: <200311111006.06047.jkeating@j2solutions.net> Is rc.local blocking no longer honered? With RHL9 and below, we could run some scripts that would query the user for some information, using echo, and read and all that fun stuff. Even if the system was configured for GUI login (init 5) these scripts would run, and hold the system until the user input the information, at which point it would then flip out to the GUI login screen. This worked great for our uses. I cannot seem to duplicate this behavior with FC1. I've tried disabling rhgb, both in grub and /etc/sysconfig/init, but it seems that no matter what, on the FIRST BOOT of an installed system, the text console out put stops right before the "Entering non-interactive run level 5" banner would show up. After the first boot, then I would get all the text, but by then my scripts have cleaned up after themselves and will no longer run. Could somebody please help me figure out what is going on, and how to re-enable my scripts to block any further progression? -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 cmadams at hiwaay.net Tue Nov 11 18:29:10 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 11 Nov 2003 12:29:10 -0600 Subject: sk98lin driver disks In-Reply-To: <200311110959.46940.kewley@cns.caltech.edu> References: <200311110959.46940.kewley@cns.caltech.edu> Message-ID: <20031111182910.GC1557072@hiwaay.net> Once upon a time, David Kewley said: > I needed updated sk98lin drivers for the 3C940 interface on the Asus P4P800 > motherboard (also used for the Asus P4C800). I wanted to use the drivers > during a network kickstart. If you just need to add one driver, you can use my script at: http://www.iruntheinter.net/files/misc/custom-modules.pl-1.8 to add and delete modules on the boot disk (so no extra driver disk is necessary). I haven't yet tried it with Fedora, but I have used it with RHL 9 and RHEL 3. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From xspace at slackpkg.ath.cx Tue Nov 11 18:50:49 2003 From: xspace at slackpkg.ath.cx (xspace) Date: Tue, 11 Nov 2003 19:50:49 +0100 Subject: xspace@slackpkg!DELETE ME!!! Message-ID: <1068576649.5180.18.camel@slack.ath.cx> DELETE ME FROM THE NEWS LIST!!! From cmadams at hiwaay.net Tue Nov 11 18:42:39 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 11 Nov 2003 12:42:39 -0600 Subject: sk98lin driver disks In-Reply-To: <20031111182910.GC1557072@hiwaay.net> References: <200311110959.46940.kewley@cns.caltech.edu> <20031111182910.GC1557072@hiwaay.net> Message-ID: <20031111184239.GF1557072@hiwaay.net> Once upon a time, Chris Adams said: > If you just need to add one driver, you can use my script at: > > http://www.iruntheinter.net/files/misc/custom-modules.pl-1.8 which is now (had a new version on there and just didn't update): http://www.iruntheinter.net/files/misc/custom-modules.pl-1.9 -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From michael at koziarski.com Tue Nov 11 19:02:12 2003 From: michael at koziarski.com (Michael A. Koziarski) Date: Wed, 12 Nov 2003 08:02:12 +1300 Subject: Fedora.us Packages for FC1 Message-ID: <3FB13234.5070603@koziarski.com> Hey guys, Any update on the progress of building fedora.us' stable packages for FC1? I thought once packages were approved for 0.9x they would automatically get published for 1? Cheers Koz From dcbw at redhat.com Tue Nov 11 18:58:20 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 11 Nov 2003 13:58:20 -0500 Subject: State of OpenOffice.org in Fedora Message-ID: <1068577100.515.9.camel@dhcp64-188.boston.redhat.com> Hi, Yes, that I am. I have already integrated the Red Hat patchset from OOo 1.1 into the gnome.org 'openoffice' module, which many of you would know by another name, OpenOffice.org Ximian Edition. Michael Meeks, the OOo developer for Ximian, has been working with Chris Halls of the Debian project for a while to build an infrastructure in Gnome.org CVS around OOo, and I have now joined that effort. This effort will provide, as Ximian has for a while, advanced patches that are not yet upstream but are ones users should have. While all the patches that are in the Red Hat OOo 1.1.0-x series are already integrated, I am still working on the install and RPM packaging steps. However, in the near future Red Hat OOo packages for Fedora will be functionally similar to OOo Ximian edition. I hope this effort between Red Hat, Ximian, Debian, and others serves to provide users with a much more functional and well-integrated version of OpenOffice.org. Also note that this is definitely not a fork of OOo, and all patches in gnome.org CVS for openoffice will be upstreamed sooner or later. Cheers, Dan On Thu, 2003-11-06 at 12:58, seth vidal wrote: > > What about OpenOffice ? Any chance to have a Ximian-ised OpenOffice in > > Fedora Core 2 ? > > I think Dan Williams is currently Captain OpenOffice at RH - might be > worth getting his input. > > -sv > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From dcbw at redhat.com Tue Nov 11 19:11:48 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 11 Nov 2003 14:11:48 -0500 Subject: State of OpenOffice.org in Fedora In-Reply-To: <1068577100.515.9.camel@dhcp64-188.boston.redhat.com> References: <1068577100.515.9.camel@dhcp64-188.boston.redhat.com> Message-ID: <1068577908.515.16.camel@dhcp64-188.boston.redhat.com> BTW, if anyone wants to track progress of this, feel free to grab a checkout of the "openoffice" module from gnome.org CVS. Michael also makes regular releases of ooo-build which are simply checkouts that have been tarred up. Bits not in yet: - the specfile - random things like the Icons, extra gallery and template content Dan On Tue, 2003-11-11 at 13:58, Dan Williams wrote: > Hi, > > Yes, that I am. I have already integrated the Red Hat patchset from OOo > 1.1 into the gnome.org 'openoffice' module, which many of you would know > by another name, OpenOffice.org Ximian Edition. > > Michael Meeks, the OOo developer for Ximian, has been working with Chris > Halls of the Debian project for a while to build an infrastructure in > Gnome.org CVS around OOo, and I have now joined that effort. This > effort will provide, as Ximian has for a while, advanced patches that > are not yet upstream but are ones users should have. > > While all the patches that are in the Red Hat OOo 1.1.0-x series are > already integrated, I am still working on the install and RPM packaging > steps. However, in the near future Red Hat OOo packages for Fedora will > be functionally similar to OOo Ximian edition. I hope this effort > between Red Hat, Ximian, Debian, and others serves to provide users with > a much more functional and well-integrated version of OpenOffice.org. > Also note that this is definitely not a fork of OOo, and all patches in > gnome.org CVS for openoffice will be upstreamed sooner or later. > > Cheers, > Dan > > On Thu, 2003-11-06 at 12:58, seth vidal wrote: > > > What about OpenOffice ? Any chance to have a Ximian-ised OpenOffice in > > > Fedora Core 2 ? > > > > I think Dan Williams is currently Captain OpenOffice at RH - might be > > worth getting his input. > > > > -sv > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From ms-nospam-0306 at arcor.de Tue Nov 11 19:23:28 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 11 Nov 2003 20:23:28 +0100 Subject: Fedora.us Packages for FC1 In-Reply-To: <3FB13234.5070603@koziarski.com> References: <3FB13234.5070603@koziarski.com> Message-ID: <20031111202328.7abc5e20.ms-nospam-0306@arcor.de> On Wed, 12 Nov 2003 08:02:12 +1300, Michael A. Koziarski wrote: > Any update on the progress of building fedora.us' stable packages for > FC1? I thought once packages were approved for 0.9x they would > automatically get published for 1? They are being rebuilt. The FC1 repositories are not complete yet. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jaap at haitsma.org Tue Nov 11 20:14:25 2003 From: jaap at haitsma.org (Jaap A. Haitsma) Date: Tue, 11 Nov 2003 21:14:25 +0100 Subject: State of OpenOffice.org in Fedora In-Reply-To: <1068577100.515.9.camel@dhcp64-188.boston.redhat.com> References: <1068577100.515.9.camel@dhcp64-188.boston.redhat.com> Message-ID: <3FB14321.1060402@haitsma.org> Great initiative Jaap Dan Williams wrote: > Hi, > > Yes, that I am. I have already integrated the Red Hat patchset from OOo > 1.1 into the gnome.org 'openoffice' module, which many of you would know > by another name, OpenOffice.org Ximian Edition. > > Michael Meeks, the OOo developer for Ximian, has been working with Chris > Halls of the Debian project for a while to build an infrastructure in > Gnome.org CVS around OOo, and I have now joined that effort. This > effort will provide, as Ximian has for a while, advanced patches that > are not yet upstream but are ones users should have. > > While all the patches that are in the Red Hat OOo 1.1.0-x series are > already integrated, I am still working on the install and RPM packaging > steps. However, in the near future Red Hat OOo packages for Fedora will > be functionally similar to OOo Ximian edition. I hope this effort > between Red Hat, Ximian, Debian, and others serves to provide users with > a much more functional and well-integrated version of OpenOffice.org. > Also note that this is definitely not a fork of OOo, and all patches in > gnome.org CVS for openoffice will be upstreamed sooner or later. > > Cheers, > Dan > > On Thu, 2003-11-06 at 12:58, seth vidal wrote: > >>>What about OpenOffice ? Any chance to have a Ximian-ised OpenOffice in >>>Fedora Core 2 ? >> >>I think Dan Williams is currently Captain OpenOffice at RH - might be >>worth getting his input. >> >>-sv >> >> >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From maxka at myrealbox.com Tue Nov 11 22:42:43 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Tue, 11 Nov 2003 14:42:43 -0800 Subject: Hardware Database In-Reply-To: <20031111112243.D30891@devserv.devel.redhat.com> References: <3FA7F935.4050705@atl.lmco.com> <20031104165952.B30342@devserv.devel.redhat.com> <1068016387.6414.42.camel@max.localdomain> <20031107133425.A13384@devserv.devel.redhat.com> <20031109223941.GE8954@redhat.com> <1068454297.3280.5.camel@max.localdomain> <20031110140858.GF8954@redhat.com> <1068543646.3296.18.camel@max.localdomain> <20031111112243.D30891@devserv.devel.redhat.com> Message-ID: <1068590562.7168.16.camel@max.localdomain> On Tue, 2003-11-11 at 08:22, Bill Nottingham wrote: > In general, I don't think you need to use DMI for anything other than: > > - system type > - system model/serial number > - bios mfr/rev > > Any of the other stuff (memory installed, slot types, etc.) is > either mostly irrelevant, or can be gotten by other means. Right, that makes sense. We'll have to decide which tool is the "authoritative" source of information for each field. -M From drepper at redhat.com Tue Nov 11 22:52:21 2003 From: drepper at redhat.com (Ulrich Drepper) Date: Tue, 11 Nov 2003 14:52:21 -0800 Subject: /etc/localtime isn't world readable In-Reply-To: <3FB0C52E.4080707@gear.dyndns.org> References: <3FB0C52E.4080707@gear.dyndns.org> Message-ID: <3FB16825.5010903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Gear wrote: >>>I wonder why /etc/localtime isn't world readable in the Fedora Core >>>distribution. Try the patch in bz #109803. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/sWgl2ijCOnn/RHQRApBrAJoDU4EkA/eRu66CNRPvLZAN7M75CQCfUjbQ G6L+gh8bWAVcjmHxV2y0Gp4= =SBUe -----END PGP SIGNATURE----- From cms at kronos.net Wed Nov 12 01:58:59 2003 From: cms at kronos.net (Christopher M. Smith) Date: Tue, 11 Nov 2003 20:58:59 -0500 Subject: Question regarding Fedora / PPC support Message-ID: <20031112015859.GG8280@kronos.net> I am looking to get involved with helping to test / possibly assist in rolling out Fedora releases on PPC based hardware. In looking around there does not appear to be ISOs of the current content of Rawhide for installing. I know that this is not really the best list to ask this on, but most of the users who are on the fedora-list at redhat.com mailing list aren't really doing this, and to this point haven't been able to give me any pointers. I guess my questions thus far are: 1. What are people who are testing / developing for PPC based hardware doing to bootstrap an installation of Fedora? 2. Are there any documents out there right now that discuss this? if not, I'd be more than happy to throw some together once I have got this worked out. Thanks for your time! Kind Regards, CMS -- Christopher M. Smith Key ID: 0x44D59911 Fingerprint: C1A0 EBC3 B036 8037 B4FC 2108 537E A50D 44D5 9911 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available URL: From notting at redhat.com Wed Nov 12 02:05:43 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Nov 2003 21:05:43 -0500 Subject: Question regarding Fedora / PPC support In-Reply-To: <20031112015859.GG8280@kronos.net>; from cms@kronos.net on Tue, Nov 11, 2003 at 08:58:59PM -0500 References: <20031112015859.GG8280@kronos.net> Message-ID: <20031111210543.D17216@devserv.devel.redhat.com> Christopher M. Smith (cms at kronos.net) said: > 1. What are people who are testing / developing for PPC based > hardware doing to bootstrap an installation of Fedora? To get a PPC tree you need, basically: a) a kernel Then you can build a tree, it should more-or-less work. Bill From skvidal at phy.duke.edu Wed Nov 12 02:17:04 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 11 Nov 2003 21:17:04 -0500 Subject: rhythmbox 0.6.0 rpms Message-ID: <1068603423.32071.10.camel@binkley> if anyone is interested: rhythmbox 0.6.0 rpms - they work nicely with fc1. http://linux.duke.edu/~skvidal/RPMS/rhythmbox/ enjoy. -sv From k_wayne at linuxpower.org Wed Nov 12 02:48:24 2003 From: k_wayne at linuxpower.org (Wayne Schuller) Date: Wed, 12 Nov 2003 13:48:24 +1100 Subject: State of OpenOffice.org in Fedora In-Reply-To: <1068577100.515.9.camel@dhcp64-188.boston.redhat.com> References: <1068577100.515.9.camel@dhcp64-188.boston.redhat.com> Message-ID: <1068605304.2926.0.camel@toottoot> hi Dan, This is great news. I look forward to updates and FC2 having the very best Ximian editions of OOO. Very significant fro desktop users. thanks, wayne On Wed, 2003-11-12 at 05:58, Dan Williams wrote: > Hi, > > Yes, that I am. I have already integrated the Red Hat patchset from OOo > 1.1 into the gnome.org 'openoffice' module, which many of you would know > by another name, OpenOffice.org Ximian Edition. > > Michael Meeks, the OOo developer for Ximian, has been working with Chris > Halls of the Debian project for a while to build an infrastructure in > Gnome.org CVS around OOo, and I have now joined that effort. This > effort will provide, as Ximian has for a while, advanced patches that > are not yet upstream but are ones users should have. > > While all the patches that are in the Red Hat OOo 1.1.0-x series are > already integrated, I am still working on the install and RPM packaging > steps. However, in the near future Red Hat OOo packages for Fedora will > be functionally similar to OOo Ximian edition. I hope this effort > between Red Hat, Ximian, Debian, and others serves to provide users with > a much more functional and well-integrated version of OpenOffice.org. > Also note that this is definitely not a fork of OOo, and all patches in > gnome.org CVS for openoffice will be upstreamed sooner or later. > > Cheers, > Dan > > On Thu, 2003-11-06 at 12:58, seth vidal wrote: > > > What about OpenOffice ? Any chance to have a Ximian-ised OpenOffice in > > > Fedora Core 2 ? > > > > I think Dan Williams is currently Captain OpenOffice at RH - might be > > worth getting his input. > > > > -sv > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Wayne Schuller From jf_balto at hotmail.com Wed Nov 12 03:32:42 2003 From: jf_balto at hotmail.com (Jean-Francois Veillette) Date: Wed, 12 Nov 2003 03:32:42 +0000 Subject: /etc/localtime isn't world readable Message-ID: the patch works just fine. Jean-Francois Veillette >From: Ulrich Drepper >Reply-To: fedora-devel-list at redhat.com >To: fedora-devel-list at redhat.com >Subject: Re: /etc/localtime isn't world readable >Date: Tue, 11 Nov 2003 14:52:21 -0800 > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Paul Gear wrote: > > >>>I wonder why /etc/localtime isn't world readable in the Fedora Core > >>>distribution. > >Try the patch in bz #109803. _________________________________________________________________ MSN Search, le moteur de recherche qui pense comme vous ! http://fr.ca.search.msn.com/ From dennis at ausil.us Wed Nov 12 04:06:21 2003 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 12 Nov 2003 14:06:21 +1000 Subject: Question regarding Fedora / PPC support In-Reply-To: <20031112015859.GG8280@kronos.net> References: <20031112015859.GG8280@kronos.net> Message-ID: <200311121406.21685.dennis@ausil.us> Once upon a time at band camp Wed, 12 Nov 2003 11:58 am, Christopher M. Smith wrote: > 1. What are people who are testing / developing for PPC based > hardware doing to bootstrap an installation of Fedora? > 2. Are there any documents out there right now that discuss this? > if not, I'd be more than happy to throw some together once I have > got this worked out. i have a mostly fedora machine on a Powerbook i started with a yellowdog 3 installand set yum to point to rawhide there is a few packages that you will need to keep the yellowdog versions of there was a discussion on this on the beta list do a google on it and it will help you on your way. Dennis From buildsys at porkchop.devel.redhat.com Wed Nov 12 11:39:49 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Wed, 12 Nov 2003 06:39:49 -0500 Subject: rawhide report: 20031112 changes Message-ID: <200311121139.hACBdnF27192@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1-0.20031112 ------------------------- s390utils-1.2.1-4.1 ------------------- * Wed Nov 12 2003 Phil Knirsch 2:1.2.1-4.1 - rebuilt * Wed Nov 12 2003 Phil Knirsch 2:1.2.1-4 - Another fix for the new automenu patch. Target was an optional parameter in old s390utils, provided compatibility behaviour. From pauln at truemesh.com Wed Nov 12 14:16:51 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 12 Nov 2003 14:16:51 +0000 Subject: Triage Day Message-ID: <20031112141650.GX4224@shitake.truemesh.com> Yes it's that time of the week to construct obscure bugzilla queries in a quest to help out those overworked developers. However my brain is tired and I'm struggling to think of a theme for this week http://www.fedora.us/wiki/FedoraTriage has lots of juicy titbits - feel free to add your own it's a wiki after all. It'd be nice to hear some feedback from people. I've just started playing with bugzuki so if anyone has any hints and tips on that would be great. As always people will be around in #fedora-bugs to discuss ideas, process and for opinons on bugs. Paul From jspaleta at princeton.edu Wed Nov 12 14:59:22 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 12 Nov 2003 09:59:22 -0500 Subject: Bug Day Volume 5 - The day the mailinglists stood still Message-ID: <1068649082.3816.63.camel@spatula.pppl.gov> I encourage everyone to stop reading email today. And instead do some valuable and needed bugzilla diving. Oh crap, I mean stop reading email right after you read this entire post. Err wait, you can read emails from bugzilla all day long too. Here's today's (Un)Official Fedora Bug Day Mystery Theme: Become involved in the fedora.us QA process and help QA packages that are waiting to be published in the fedora.us addon repo: http://www.fedora.us/QA Remember, until the full merge is completed and Fedora Extras and Alternatives is up and running...community packagers are being advised to use fedora.us's process: http://www.redhat.com/archives/fedora-devel-list/2003-November/msg00649.html How do you become involved in the fedora.us QA process? Easy, read: http://www.fedora.us/wiki/PackageSubmissionQAPolicy I think there are enough people in the freenode irc network's #fedora-bugs channel who are already part of the fedora.us QA wagon train to provide some guidance if you are new to the process (hint hint hint, that means if you ARE part of the fedora.us QA process right now, it might be in your best interests to sit in the channel and gingerly help new people getting started in this process as part of the bug day call to arms) -jef"do i need tequila or coffee right now..."spaleta From pauln at truemesh.com Wed Nov 12 16:45:58 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 12 Nov 2003 16:45:58 +0000 Subject: Self Introduction: Paul Nasrat Message-ID: <20031112164551.GY4224@shitake.truemesh.com> Name: Paul Nasrat Location: London, UK Profession: Package monkey/sysadmin/developer Company: undisclosed Goals: Working with Fedora to ensure quality packages, timely updates, etc. I'm intrested in build systems and automation. Packages I want to see published - synaptics driver which I will submit one of these days. Happy and have done some QA and also bug triaging at f.r.c Historical Qualifications: Developer on ELKS (particularly the SIBO port) JPackage Project member fedora ppc interests I potter with python, C and java. Why trust me - hopefully my track record helps, and I'm pretty enthusiastic and helpful, occasionally I have clue too. Ob GPG stuff: pub 1024D/831FFBCA 2003-02-21 Paul Nasrat Key fingerprint = 9693 1E2A 30A0 9E24 708E DC98 E618 76E8 831F FBCA sub 1024g/0653AAB4 2003-02-21 Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From atlhon at libero.it Wed Nov 12 21:57:23 2003 From: atlhon at libero.it (Giuseppe Cavallo) Date: Wed, 12 Nov 2003 22:57:23 +0100 Subject: ACPI IN KERNEL 2.4.22 INCOMPATIBLE WITH KDE??? Message-ID: <200311122257.23918.atlhon@libero.it> Hi All, RedHat 9.0 I installed the Linus' kernel (downloaded in kernel.org), after I recompilt it, when I wanted shoutdown my Laptop (Asus L8416K {L8400L serie}) the system don't shoutdown completely but on the monitor I watch the string "Power down" and I shutdown the computer with the power off button. This same problem I have had in Fedora Core 1 Kernel 2.4.22-1.2115.nptl. The thing curious is, that, if I don't login in KDE and I shoutdown my system by KDM or Terminal the system shoutdown normaly otherwhise when I login KDE I have that problem. I don't understand what I can resolve the problem. -- [--Saluti Giuseppe Cavallo--] From Mohammed_Khan at Dell.com Wed Nov 12 22:36:39 2003 From: Mohammed_Khan at Dell.com (Mohammed_Khan at Dell.com) Date: Wed, 12 Nov 2003 16:36:39 -0600 Subject: Fedora Core 1: X86-64 Failed compile package list Message-ID: <1D81B7B4A1FB0D48AEACB9C0B9D886D20111C388@ausx2kmps305.aus.amer.dell.com> Folks, I tried to cross-compile all the Fedora Core 1 (yarrow) SRPMS on an amd64 machine running the i386 version of Fedora Core 1 (yarrow). Out of 847 packages, a total of 89 packages failed to build (list attached as a.txt) 1. 77 packages failed because the "amd64-redhat" target was not recognized. 2. Another 12 failed for other reasons (list attached as b.txt). <> <> I have stdout,stderr logs on each SRPM rpmbuild... (should any of this be logged in bugzilla?) I have a couple ?s at this point: 1. Am I doing this right? or should I try to compile the SRPMS on a box running an amd64 linux environment....? But this is sort of a chicken and an egg problem with Fedora, either that or a rather painful one to solve as you would have to incrementally build your amd64 environment while building packages. I tried to workaround this by compiling using amd64 versions of other linux distributions but lots of packages fail to build w/o using the --nodeps flag... and lots more packages fail regardless... 2. How would one go about fixing packages exhibiting the first issue (unknown target: amd64)? Is it a matter of: 1. tweaking spec files 2. tweaking make files 3. tweaking source-code 4. combination of 1, 2, and 3? 5. ask/beg respective pacakage maintainers to fix? Thanks, MFK -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- amanda-2.4.4p1-1.src.rpm.log apr-0.9.4-2.src.rpm.log apr-util-0.9.4-2.src.rpm.log arts-1.1.4-3.src.rpm.log automake16-1.6.3-1.src.rpm.log beecrypt-3.0.1-0.20030630.1.src.rpm.log binutils-2.14.90.0.6-3.src.rpm.log bluez-utils-2.3-14.src.rpm.log brltty-3.2-3.src.rpm.log comps-1-0.20031103.src.rpm.log ddd-3.3.7-3.src.rpm.log dvdrtools-0.1.5-1.src.rpm.log emacs-21.3-7.src.rpm.log ethereal-0.9.13-4.1.src.rpm.log freeciv-1.14.0-2.src.rpm.log freetype-2.1.4-5.src.rpm.log gcc32-3.2.3-6.src.rpm.log gcc-3.3.2-1.src.rpm.log gdb-5.3.90-0.20030710.41.src.rpm.log glibc-2.3.2-101.src.rpm.log gmp-4.1.2-9.src.rpm.log gnomemeeting-0.98.5-1.src.rpm.log gnome-vfs2-extras-0.99.10-3.1.src.rpm.log gnome-vfs-extras-0.2.0-7.src.rpm.log gnucash-1.8.7-1.src.rpm.log gnupg-1.2.2-3.src.rpm.log gstreamer-0.6.3-1.src.rpm.log gstreamer-plugins-0.6.3-3.src.rpm.log Guppi-0.40.3-16.src.rpm.log ImageMagick-5.5.6-5.src.rpm.log iputils-20020927-9.1.src.rpm.log kdbg-1.2.9-1.src.rpm.log kdeaddons-3.1.4-2.src.rpm.log kdeadmin-3.1.4-1.src.rpm.log kdeartwork-3.1.4-1.src.rpm.log kdebase-3.1.4-6.src.rpm.log kdebindings-3.1.4-1.src.rpm.log kdeedu-3.1.4-1.src.rpm.log kdegames-3.1.4-2.src.rpm.log kdegraphics-3.1.4-1.src.rpm.log kdelibs-3.1.4-4.src.rpm.log kdemultimedia-3.1.4-1.src.rpm.log kdenetwork-3.1.4-1.src.rpm.log kdepim-3.1.4-1.src.rpm.log kdesdk-3.1.4-1.src.rpm.log kdetoys-3.1.4-1.src.rpm.log kdeutils-3.1.4-1.src.rpm.log kdevelop-2.1.5-13.src.rpm.log koffice-1.2.1-15.src.rpm.log libgcrypt-1.1.12-1.1.src.rpm.log libgtop-1.0.12-20.src.rpm.log libgtop2-2.0.3-1.src.rpm.log Maelstrom-3.0.6-1.src.rpm.log mod_perl-1.99_09-10.src.rpm.log modutils-2.4.25-13.src.rpm.log mtools-3.9.9-4.src.rpm.log mysql-3.23.58-4.src.rpm.log ncurses-5.3-9.src.rpm.log netatalk-1.5.5-9.src.rpm.log net-snmp-5.0.9-2.src.rpm.log nmap-3.48-1.src.rpm.log nss_ldap-207-3.src.rpm.log nut-1.4.0-3.src.rpm.log openobex-1.0.0-3.src.rpm.log openssl-0.9.7a-23.src.rpm.log ORBit-0.5.17-10.3.src.rpm.log perl-DateManip-5.40-30.src.rpm.log pilot-link-0.11.8-1.src.rpm.log pvm-3.4.4-14.src.rpm.log quanta-3.1.4-1.src.rpm.log radvd-0.7.2-5.src.rpm.log rpmdb-fedora-1-0.20031103.src.rpm.log rsync-2.5.6-19.src.rpm.log ruby-1.8.0-1.src.rpm.log samba-3.0.0-15.src.rpm.log scrollkeeper-0.3.12-2.src.rpm.log SDL_image-1.2.3-3.src.rpm.log SDL_mixer-1.2.4-9.src.rpm.log SDL_net-1.2.4-8.src.rpm.log sox-12.17.4-1.src.rpm.log splint-3.1.1-2.src.rpm.log star-1.5a18-2.src.rpm.log strace-4.5-1.src.rpm.log subversion-0.32.1-1.src.rpm.log switchdesk-3.9.8-18.src.rpm.log sylpheed-0.9.7-1.src.rpm.log traceroute-1.4a12-20.1.src.rpm.log w3c-libwww-5.4.0-7.src.rpm.log xinetd-2.3.12-4.10.0.src.rpm.log -------------- next part -------------- automake16-1.6.3-1.src.rpm.log comps-1-0.20031103.src.rpm.log emacs-21.3-7.src.rpm.log iputils-20020927-9.1.src.rpm.log mod_perl-1.99_09-10.src.rpm.log openssl-0.9.7a-23.src.rpm.log perl-DateManip-5.40-30.src.rpm.log pvm-3.4.4-14.src.rpm.log rpmdb-fedora-1-0.20031103.src.rpm.log star-1.5a18-2.src.rpm.log strace-4.5-1.src.rpm.log subversion-0.32.1-1.src.rpm.log From 64bit_fedora at comcast.net Wed Nov 12 22:51:28 2003 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Wed, 12 Nov 2003 16:51:28 -0600 (CST) Subject: Fedora Core 1: X86-64 Failed compile package list In-Reply-To: <1D81B7B4A1FB0D48AEACB9C0B9D886D20111C388@ausx2kmps305.aus.amer.dell.com> Message-ID: On Wed, 12 Nov 2003 Mohammed_Khan at Dell.com wrote: > Folks, > > I tried to cross-compile all the Fedora Core 1 (yarrow) SRPMS on an amd64 > machine running the i386 version of Fedora Core 1 (yarrow). > While certainly an interesting way to get to know the systems, cross compile environments are not always the cleanest. All of these packages except for kernel (and some hardware pieces not needed for AMD64 systems) are already built and available for x86_64. Kernel is an interesting beast, and currently being worked on. Target for AMD64 packages is generally recognized as x86_64 > > 2. How would one go about fixing packages exhibiting the first issue > (unknown target: amd64)? Is it a matter of: > 1. tweaking spec files > 2. tweaking make files > 3. tweaking source-code > 4. combination of 1, 2, and 3? > 5. ask/beg respective pacakage maintainers to fix? > > Thanks, > > MFK > 6. use --target=x86_64, or download existing builds if you would rather not eat up the CPU time. If there are any other issued you run across, please feel free to ping me on them, and I will look into them. Thanks, Justin From pauln at truemesh.com Wed Nov 12 09:15:53 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 12 Nov 2003 09:15:53 +0000 Subject: Question regarding Fedora / PPC support In-Reply-To: <20031112015859.GG8280@kronos.net> References: <20031112015859.GG8280@kronos.net> Message-ID: <20031112091552.GE4224@shitake.truemesh.com> On Tue, Nov 11, 2003 at 08:58:59PM -0500, Christopher M. Smith wrote: > 1. What are people who are testing / developing for PPC based > hardware doing to bootstrap an installation of Fedora? Currently there have been two different approaches - install YDL (3.0.1 iso's hitting mirrors) and yum up to rawhide. Or what I did which was to install fedora into a clean chroot from a minimal environment. There are a few gotchas to a full fedora tree working - mainly missing packages (mac specific stuff such as pdisk, pmac-utils), a broken depends (ppc64-utils for mkinitrd) and fedora-release. As Bill mentioned as far as an anaconda build goes the kernel is the big issue. I've built the boot.iso using anaconda, but not managed to test yet. Other main issue is a mozilla optimisation issue on ppc - needs to be built with -O0 - oneline spec change. There are also a set of OOo patches. Check through fedora-test-list and fedora-devel-list archives for ppc. > 2. Are there any documents out there right now that discuss this? > if not, I'd be more than happy to throw some together once I have > got this worked out. No there aren't. However Dan Burcaw from TerraSoft has a set of patches which he's going to publish - they probably will correspond to what I and others have done manually. Other than that all the work is already in anaconda and rawhide is built for ppc. The main other thing is configuration - ensuring redhat-config-xfree86 sets up correctly. Btw I'm using a g3 ibook2. Others have access to meatier equipment. I'd be intrested in looking at the 64/32 bit environment as I believe the amd64 people have found some intresting annoyances with hybrid environments so there is some clean up to do (should ppc64-utils requires 64 bit libc, etc). Dan has kindly setup a list which is quiet atm, but an attempt to collate those contributing rather than fragmented efforts: http://lists.ydl.net/mailman/listinfo/fedora-ppc Paul From mike at flyn.org Wed Nov 12 22:58:37 2003 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 12 Nov 2003 16:58:37 -0600 Subject: Anaconda and Linux kernel 2.6.0-test9 Message-ID: <20031112225837.GA1364@imp.flyn.org> Has anyone been able to compile anaconda 9.2 against 2.6.0-test9 kernel headers? I am running into kernel header-related problems. I've seen that other software projects are facing similar difficulty with 2.6. I imagine it has something to do with what code is protected by #ifdef __KERNEL__'s as the kernel itself compiles fine. I get the following errors: [mike at imp anaconda-9.2]$ make for d in isys loader2 po stubs textw utils scripts bootdisk installclasses iw pixmaps isomd5sum command-stubs fonts; do make -C $d; [ $? = 0 ] || exit 1; done make[1]: Entering directory `/home/mike/development/anaconda-9.2-cryptoroot/anaconda-9.2/isys' for d in gzlib; do make -C $d; done make[2]: Entering directory `/home/mike/development/anaconda-9.2-cryptoroot/anaconda-9.2/isys/gzlib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/mike/development/anaconda-9.2-cryptoroot/anaconda-9.2/isys/gzlib' cc -c -ffunction-sections -I/usr/include/python2.2 -I.. -Wall -Os -g -DHAVE_NFS -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -Werror -fPIC -o isys.lo isys.c In file included from /usr/include/linux/blockgroup_lock.h:8, from /usr/include/linux/ext2_fs_sb.h:19, from /usr/include/linux/ext2_fs.h:20, from isys.c:4: /usr/include/linux/spinlock.h: In function `bit_spin_lock': /usr/include/linux/spinlock.h:413: invalid type argument of `->' /usr/include/linux/spinlock.h: In function `bit_spin_trylock': /usr/include/linux/spinlock.h:436: invalid type argument of `->' /usr/include/linux/spinlock.h: In function `bit_spin_unlock': /usr/include/linux/spinlock.h:451: invalid type argument of `->' /usr/include/linux/spinlock.h:451: `TIF_NEED_RESCHED' undeclared (first use in this function) /usr/include/linux/spinlock.h:451: (Each undeclared identifier is reported only once /usr/include/linux/spinlock.h:451: for each function it appears in.) /usr/include/linux/spinlock.h: In function `bit_spin_is_locked': /usr/include/linux/spinlock.h:462: invalid type argument of `->' In file included from /usr/include/linux/ext2_fs_sb.h:20, from /usr/include/linux/ext2_fs.h:20, from isys.c:4: /usr/include/linux/percpu_counter.h: In function `percpu_counter_mod': /usr/include/linux/percpu_counter.h:75: invalid type argument of `->' /usr/include/linux/percpu_counter.h:77: invalid type argument of `->' /usr/include/linux/percpu_counter.h:77: `TIF_NEED_RESCHED' undeclared (first use in this function) In file included from /usr/include/linux/ext2_fs.h:20, from isys.c:4: /usr/include/linux/ext2_fs_sb.h: At top level: /usr/include/linux/ext2_fs_sb.h:40: parse error before "uid_t" /usr/include/linux/ext2_fs_sb.h:48: parse error before "s_next_generation" /usr/include/linux/ext2_fs_sb.h:50: parse error before '*' token /usr/include/linux/ext2_fs_sb.h:55: parse error before '}' token In file included from /usr/include/linux/ext3_fs.h:20, from isys.c:5: /usr/include/linux/ext3_fs_i.h:80: field `i_orphan' has incomplete type /usr/include/linux/ext3_fs_i.h:97: parse error before "loff_t" /usr/include/linux/ext3_fs_i.h:111: parse error before '}' token In file included from /usr/include/linux/ext3_fs.h:21, from isys.c:5: /usr/include/linux/ext3_fs_sb.h:44: parse error before "uid_t" /usr/include/linux/ext3_fs_sb.h:52: parse error before "s_next_generation" /usr/include/linux/ext3_fs_sb.h:53: parse error before "s_hash_seed" /usr/include/linux/ext3_fs_sb.h:55: parse error before '*' token /usr/include/linux/ext3_fs_sb.h:71: parse error before '}' token In file included from isys.c:5: /usr/include/linux/ext3_fs.h:618: parse error before "u32" /usr/include/linux/ext3_fs.h:621: parse error before '*' token /usr/include/linux/ext3_fs.h:622: parse error before '}' token In file included from /usr/include/linux/timer.h:5, from /usr/include/linux/workqueue.h:8, from /usr/include/linux/fb.h:5, from isys.c:38: /usr/include/linux/list.h:576:2: #warning "don't include kernel headers in userspace" In file included from /usr/include/linux/workqueue.h:8, from /usr/include/linux/fb.h:5, from isys.c:38: /usr/include/linux/timer.h:11: field `entry' has incomplete type /usr/include/linux/timer.h:21: confused by earlier errors, bailing out make[1]: *** [isys.lo] Error 1 make[1]: Leaving directory `/home/mike/development/anaconda-9.2-cryptoroot/anaconda-9.2/isys' make: *** [subdirs] Error 1 -- Mike :wq From walters at verbum.org Thu Nov 13 00:18:00 2003 From: walters at verbum.org (Colin Walters) Date: Wed, 12 Nov 2003 19:18:00 -0500 Subject: rhythmbox 0.6.0 rpms In-Reply-To: <1068603423.32071.10.camel@binkley> References: <1068603423.32071.10.camel@binkley> Message-ID: <1068682679.2468.8.camel@metropolis.verbum.private> On Tue, 2003-11-11 at 21:17, seth vidal wrote: > if anyone is interested: > > rhythmbox 0.6.0 rpms - they work nicely with fc1. > > http://linux.duke.edu/~skvidal/RPMS/rhythmbox/ Thanks, I've linked to this from the website now. -------------- 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 cmadams at hiwaay.net Wed Nov 12 21:18:01 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 12 Nov 2003 15:18:01 -0600 Subject: Installing from software RAID0? Message-ID: <20031112211801.GD1049932@hiwaay.net> I tried to install from local hard drives that are configured with software RAID0, and it didn't work. Should I bother to bugzilla this, or is this just too far into "don't do that" land? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From pauln at truemesh.com Wed Nov 12 11:46:36 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 12 Nov 2003 11:46:36 +0000 Subject: rawhide report: 20031112 changes In-Reply-To: <200311121139.hACBdnF27192@porkchop.devel.redhat.com> References: <200311121139.hACBdnF27192@porkchop.devel.redhat.com> Message-ID: <20031112114635.GK4224@shitake.truemesh.com> On Wed, Nov 12, 2003 at 06:39:49AM -0500, Build System wrote: > > > > Updated Packages: > > rpmdb-fedora-1-0.20031112 Hmm is this going to be rebuilt against each rawhide release? Paul From mrsam at courier-mta.com Thu Nov 13 00:52:56 2003 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 12 Nov 2003 19:52:56 -0500 Subject: Installing from software RAID0? References: <20031112211801.GD1049932@hiwaay.net> Message-ID: Chris Adams writes: > I tried to install from local hard drives that are configured with > software RAID0, and it didn't work. Should I bother to bugzilla this, > or is this just too far into "don't do that" land? I doubt that the stripped installer kernel includes RAID support, so this looks like a ?don't do that? deal to me. /me looks lovingly at the box with the Adaptec SCSI raid card, that's currently looking for a new home? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cmadams at hiwaay.net Thu Nov 13 01:06:32 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 12 Nov 2003 19:06:32 -0600 Subject: Installing from software RAID0? In-Reply-To: References: <20031112211801.GD1049932@hiwaay.net> Message-ID: <20031113010632.GA1416821@hiwaay.net> Once upon a time, Sam Varshavchik said: > Chris Adams writes: > >I tried to install from local hard drives that are configured with > >software RAID0, and it didn't work. Should I bother to bugzilla this, > >or is this just too far into "don't do that" land? > > I doubt that the stripped installer kernel includes RAID support, so this > looks like a ???don't do that??? deal to me. The installer kernel definately includes RAID support, since you can install to RAID (and have been able to for years). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Lovechild at foolclan.com Wed Nov 12 13:26:11 2003 From: Lovechild at foolclan.com (David Nielsen) Date: Wed, 12 Nov 2003 14:26:11 +0100 Subject: rhythmbox 0.6.0 rpms In-Reply-To: <1068603423.32071.10.camel@binkley> References: <1068603423.32071.10.camel@binkley> Message-ID: <1068643571.11740.4.camel@pilot.stavtrup-st.dk> Awesome, works like a charm. Now all we need is updated gstreamer rpms since rhythmbox really dislikes 0.6.3. Anyways, thanks for the rpm. - David Nielsen On Wed, 2003-11-12 at 03:17, seth vidal wrote: > if anyone is interested: > > rhythmbox 0.6.0 rpms - they work nicely with fc1. > > http://linux.duke.edu/~skvidal/RPMS/rhythmbox/ > > enjoy. > > -sv > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From Mohammed_Khan at Dell.com Thu Nov 13 02:07:00 2003 From: Mohammed_Khan at Dell.com (Mohammed_Khan at Dell.com) Date: Wed, 12 Nov 2003 20:07:00 -0600 Subject: Fedora Core 1: X86-64 Failed compile package list Message-ID: <1D81B7B4A1FB0D48AEACB9C0B9D886D20111C38B@ausx2kmps305.aus.amer.dell.com> Thanks for the tips Justin. I will keep you posted if I run across anything else. Thanks, MFK -----Original Message----- From: Justin M. Forbes [mailto:64bit_fedora at comcast.net] Sent: Wednesday, November 12, 2003 4:51 PM To: fedora-devel-list at redhat.com Subject: Re: Fedora Core 1: X86-64 Failed compile package list On Wed, 12 Nov 2003 Mohammed_Khan at Dell.com wrote: > Folks, > > I tried to cross-compile all the Fedora Core 1 (yarrow) SRPMS on an > amd64 machine running the i386 version of Fedora Core 1 (yarrow). > While certainly an interesting way to get to know the systems, cross compile environments are not always the cleanest. All of these packages except for kernel (and some hardware pieces not needed for AMD64 systems) are already built and available for x86_64. Kernel is an interesting beast, and currently being worked on. Target for AMD64 packages is generally recognized as x86_64 > > 2. How would one go about fixing packages exhibiting the first issue > (unknown target: amd64)? Is it a matter of: > 1. tweaking spec files > 2. tweaking make files > 3. tweaking source-code > 4. combination of 1, 2, and 3? > 5. ask/beg respective pacakage maintainers to fix? > > Thanks, > > MFK > 6. use --target=x86_64, or download existing builds if you would rather not eat up the CPU time. If there are any other issued you run across, please feel free to ping me on them, and I will look into them. Thanks, Justin -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list From bill at noreboots.com Wed Nov 12 13:43:45 2003 From: bill at noreboots.com (Bill Anderson) Date: 12 Nov 2003 06:43:45 -0700 Subject: TradeMarked Name --redhat-config- In-Reply-To: <20031109152732.GA3214@nsk.no-ip.org> References: <20031109152732.GA3214@nsk.no-ip.org> Message-ID: <1068644625.12212.44.camel@locutus> On Sun, 2003-11-09 at 08:27, Luciano Miguel Ferreira Rocha wrote: > PS: AINAL Am I Not A Lawyer? ;^) -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From diego.cibils at adinet.com.uy Wed Nov 12 14:46:23 2003 From: diego.cibils at adinet.com.uy (Diego Cibils) Date: Wed, 12 Nov 2003 11:46:23 -0300 Subject: exchange server alternatives Message-ID: Hi all, Does anyone knows, if there's any attemp out there to make a MS Exchange Server-compatible Mail/Groupware server ? I mean, something like (Open)Exchange Server, that implements the Exchange protocol. I guess it's a closed protocol, but perhaps, someone has tried to get into it ! Thanks, Diego. From jspaleta at princeton.edu Wed Nov 12 15:01:27 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 12 Nov 2003 10:01:27 -0500 Subject: Fedora Triage: where things are at. Message-ID: <1068649287.3816.71.camel@spatula.pppl.gov> On a completely different topic...the full (but tiny, and I'm going to start targeting people to create some useful information for the triage effort..soon) universe of Fedora Triage knowledge awaits you at: http://www.fedora.us/wiki/FedoraTriage To recap where things stand: There are about 56 'make cambridge not suck blockers' left https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=100643 We are experimenting with building public tracking bugs as a way the community can classify bugs so developers can run simple searches instead of trolling through open bugs. My current example is the EasyFix tracking bug. Which is an attempt to group the bug reports that have trivial fixes or have attached community provided patches. The hope is that when developers have a few minutes to work on low priority bugs...they have a way to quickly find the easily fixable ones so they don't waste their spare time trolling through the 'zilla. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109188 Another community tool we are experimenting with is the use of 'triage->reason' as a formatted comment string. Examples you can search for now are: triage->easyfix triage->close triage->duplicate #bugnumber triage->crack There are of course more variants on the 'triage->' theme but I'd like to come up with a reasonably short and more importantly consistantly used list, if developers find querying against 'triage->reason' useful. -jef"coffee it is"spaleta From warren at togami.com Thu Nov 13 03:16:38 2003 From: warren at togami.com (Warren Togami) Date: Wed, 12 Nov 2003 17:16:38 -1000 Subject: Fedora Core 1: X86-64 Failed compile package list In-Reply-To: <1D81B7B4A1FB0D48AEACB9C0B9D886D20111C38B@ausx2kmps305.aus.amer.dell.com> References: <1D81B7B4A1FB0D48AEACB9C0B9D886D20111C38B@ausx2kmps305.aus.amer.dell.com> Message-ID: <1068693398.4368.8.camel@laptop> Mr. Khan, Have you tried the x86_64 rawhide repository too? Almost everything should be very recent there, with the exception of the kernel. Warren From karlankayne at hotmail.com Thu Nov 13 03:18:31 2003 From: karlankayne at hotmail.com (Karlan Kayne) Date: Wed, 12 Nov 2003 19:18:31 -0800 Subject: redhat-config-network bug(and a small ethernet problem of my own) Message-ID: //////////////////////////////////////////////////////////////// Notes from Karlan: This happens when ever I try to activate my eth0 device(SiS 900-Based PCI Fast Ethernet Adapter), then press cancel after given this error: +------------------------------------------------+ | Determining IP information for eth0... | SIOCSIFFLAGS: Device or resource busy | SIOCSIFFLAGS: Device or resource busy +------------------------------------------------+ (Any help with this problem would be great, I can't get on the internet because it says this device is [always] busy. I used to be able to connect in RH9, but now RH9 install doesn't recognize it, mandrakes does(but can't use because of the same problem), NOTE: Device works just fine in Windows, so it is not a hardware failure(I believe) YET ANOTHER NOTE: Linux(any recent verion I believe) since this point(my troubles started) has always said it can't find OHCI drivers...blah) //////////////////////////////////////////////////////////////// Component: redhat-config-network Version: 1.3.10 Summary: TB3fbf821d GUI_functions.py:524:gui_run_dialog:OSError: [Errno 1] Operation not permitted Traceback (most recent call last): File "/usr/bin/redhat-control-network", line 184, in on_activateButton_clicked (ret, msg) = dev.activate() File "/usr/src/build/320592-noarch/install/usr/share/redhat-config-network/netconfpkg/NCDevice.py", line 385, in activate dialog = dialog) File "/usr/src/build/320592-noarch/install/usr/share/redhat-config-network/netconfpkg/NC_functions.py", line 512, in generic_run_dialog dialog = dialog) File "/usr/src/build/320592-noarch/install/usr/share/redhat-config-network/netconfpkg/gui/GUI_functions.py", line 524, in gui_run_dialog OSError: [Errno 1] Operation not permitted Local variables in innermost frame: fdin: [] swindow: string: okbutton: buffer: cancelbutton: command: /sbin/ifup argv: ['/sbin/ifup', 'eth0', 'up'] searchPath: 0 CancelException: netconfpkg.gui.GUI_functions.CancelException root: / label: Activating network device eth0, please wait... lbl: select: stdin: 0 xml: catchfd: (1, 2) fderr: [] dlg: errlabel: Cannot activate network device eth0! fdout: [] vadj: gtk: iter: mark: write: 4 read: 3 s: SIOCSIFFLAGS: Device or resource busy childpid: 24657 closefd: -1 dialog: None rc: Determining IP information for eth0...SIOCSIFFLAGS: Device or resource busy SIOCSIFFLAGS: Device or resource busy title: redhat-config-network: Network device activating... os: textview: _________________________________________________________________ Great deals on high-speed Internet access as low as $26.95. https://broadband.msn.com (Prices may vary by service area.) From eric at brouhaha.com Thu Nov 13 03:22:11 2003 From: eric at brouhaha.com (Eric Smith) Date: Wed, 12 Nov 2003 19:22:11 -0800 (PST) Subject: Anaconda LVM and file system size limitations Message-ID: <4979.4.20.168.241.1068693731.squirrel@ruckus.brouhaha.com> I just set up a system with a 1.4 TB RAID (on a 3Ware 7500-8), and have run into some limitations of Anaconda. It seems that it is not possible to set up an LVM physical volume or volume group larger than 1 TB, nor to create ext3 (or jfs) filesystems larger than 1 TB. These limits seem to be hardcoded in fsset.py, in multiple lines like aelf.maxSizeMB = 1024 * 1024 It's my undertanding that there are problems with filesystems larger than 2 TB, but it looks like it should be easy to change the Anaconda limits to a higher value, such as 1536 MB or 1920 MB. Is there any known problem with doing so? If I make these changes to Anaconda, how do I create a modified Fedora Core 1 binary CD-ROM 1? I can't even figure out from where on the CD-ROM Anaconda's Python files are being loaded during the install process. I expected them to either be in the base directory or the initrd, but I don't see them in either place. Is it actually getting them from the Anaconda RPM in Fedora/RPMS? I've tried creating the PV, VG, and LVs from the command line then installing Fedora Core 1, and Disk Druid does show them correctly. But after I tell it the mount points it gets an error to the effect that it couldn't tell the kernel about the sda3 partition (the PV). There's an option to ignore the error, but of course the install doesn't work after that. I'm hoping that increasing the fsset.py limits will solve this problem. Thanks! Eric From karlankayne at hotmail.com Thu Nov 13 03:51:20 2003 From: karlankayne at hotmail.com (Karlan Kayne) Date: Wed, 12 Nov 2003 19:51:20 -0800 Subject: Kudzu Message-ID: I was wondering if someone could help get started in maybe developing for this project, or would that not be feasible because of the fact I haven't done asm or device programming(I know c++ very well) _________________________________________________________________ Great deals on high-speed Internet access as low as $26.95. https://broadband.msn.com (Prices may vary by service area.) From hugo at devin.com.br Thu Nov 13 04:15:49 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Thu, 13 Nov 2003 01:15:49 -0300 Subject: Getting to work on i18n? Message-ID: <3FB30575.4000308@devin.com.br> Hi, 6 days ago I subscribed to this list and tried to subscribe on the i18n project to help Fedora Linux translating something to my language (Brazilian Portuguese). I received an e-mail telling me that my status was pending... I have to wait or can I work on something right now? I need some advice :) Thanks. []'s Hugo From notting at redhat.com Thu Nov 13 04:22:36 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Nov 2003 23:22:36 -0500 Subject: rawhide report: 20031112 changes In-Reply-To: <20031112114635.GK4224@shitake.truemesh.com>; from pauln@truemesh.com on Wed, Nov 12, 2003 at 11:46:36AM +0000 References: <200311121139.hACBdnF27192@porkchop.devel.redhat.com> <20031112114635.GK4224@shitake.truemesh.com> Message-ID: <20031112232236.D2888@devserv.devel.redhat.com> Paul Nasrat (pauln at truemesh.com) said: > > Updated Packages: > > > > rpmdb-fedora-1-0.20031112 > > Hmm is this going to be rebuilt against each rawhide release? Well, it's going that way now. Now that you bring it up, however, it could be disabled. It would certainly make the trees build faster. Bill From notting at redhat.com Thu Nov 13 04:33:28 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Nov 2003 23:33:28 -0500 Subject: Kudzu In-Reply-To: ; from karlankayne@hotmail.com on Wed, Nov 12, 2003 at 07:51:20PM -0800 References: Message-ID: <20031112233328.F2888@devserv.devel.redhat.com> Karlan Kayne (karlankayne at hotmail.com) said: > I was wondering if someone could help get started in maybe developing for > this project, or would that not be feasible because of the fact I haven't > done asm or device programming(I know c++ very well) What specific bits are you interested in? Note that aside from some minor bits in the ddc probing, it's all C with python bindings; there's not really any asm, and no driver stuff. Bill From aoliva at redhat.com Thu Nov 13 04:40:42 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 13 Nov 2003 02:40:42 -0200 Subject: Anaconda LVM and file system size limitations In-Reply-To: <4979.4.20.168.241.1068693731.squirrel@ruckus.brouhaha.com> References: <4979.4.20.168.241.1068693731.squirrel@ruckus.brouhaha.com> Message-ID: On Nov 13, 2003, "Eric Smith" wrote: > If I make these changes to Anaconda, how do I create a modified > Fedora Core 1 binary CD-ROM 1? Look for updates.img in /usr/share/doc/anaconda-9.2/install-methods.txt -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From warren at togami.com Thu Nov 13 05:03:58 2003 From: warren at togami.com (Warren Togami) Date: Wed, 12 Nov 2003 19:03:58 -1000 Subject: NEEDSWORK - How you can help Message-ID: <1068699838.4368.27.camel@laptop> http://www.fedora.us/NEEDSWORK These SRPM packages are in need of spec and/or source patching before being suitable for further QA testing at fedora.us. Some of the packages listed below are in need of new volunteers to take over as maintainer for future updates because the originating developers have very limited time. yum perl-Razor-Agent perl-File-Tail perl-Net-Netmask dovecot libsafe http://www.fedora.us/wiki/PackageSubmissionQAPolicy http://www.fedora.us/wiki/QAChecklist http://www.fedora.us/wiki/SelfIntroduction Please read these three pages to learn the process of contributing to the fedora.us project. fedora.us is acting as the semi-official interim community development project as we wait for fedora.redhat.com infrastructure to shape up. http://www.fedora.us/QA In addition to the NEEDSWORK queue, the QA queue has plenty of packages available for your testing. Again, please read the 3 links above to learn how you can effectively join the development effort. Warren From warren at togami.com Thu Nov 13 05:18:29 2003 From: warren at togami.com (Warren Togami) Date: Wed, 12 Nov 2003 19:18:29 -1000 Subject: NEEDSWORK - How you can help In-Reply-To: <1068699838.4368.27.camel@laptop> References: <1068699838.4368.27.camel@laptop> Message-ID: <1068700708.4368.30.camel@laptop> On Wed, 2003-11-12 at 19:03, Warren Togami wrote: > http://www.fedora.us/NEEDSWORK > > These SRPM packages are in need of spec and/or source patching before > being suitable for further QA testing at fedora.us. Some of the > packages listed below are in need of new volunteers to take over as > maintainer for future updates because the originating developers have > very limited time. > > yum One note that I should mention. This yum is specific for users of FC + fedora.us and not much different from FC's yum, differing mainly in default config file settings. After fedora.us merges fully with fedora.redhat.com a separate yum will no longer exist. Warren From michael at koziarski.com Thu Nov 13 05:48:19 2003 From: michael at koziarski.com (Michael A. Koziarski) Date: Thu, 13 Nov 2003 18:48:19 +1300 Subject: NEEDSWORK - How you can help In-Reply-To: <1068699838.4368.27.camel@laptop> References: <1068699838.4368.27.camel@laptop> Message-ID: <3FB31B23.8060101@koziarski.com> Warren Togami wrote: > http://www.fedora.us/NEEDSWORK > > These SRPM packages are in need of spec and/or source patching before > being suitable for further QA testing at fedora.us. Some of the > packages listed below are in need of new volunteers to take over as > maintainer for future updates because the originating developers have > very limited time. > > yum > perl-Razor-Agent > perl-File-Tail > perl-Net-Netmask > dovecot I'm a dovecot user, so if needs be I'd be willing to maintain this. However the RPM that I'm using comes straight from redhat. Is this the one that needs maintaining? or does fedora.us have its own (possibly redundant?) package? Cheers Koz From michael at koziarski.com Thu Nov 13 06:02:50 2003 From: michael at koziarski.com (Michael A. Koziarski) Date: Thu, 13 Nov 2003 19:02:50 +1300 Subject: Self Introduction; Michael Koziarski Message-ID: <3FB31E8A.1060507@koziarski.com> Full Legal Name: Michael Alan Koziarski Location: Wellington, New Zealand Profession: Software Engineer Company: A Retail bank My Goals in the Fedora Project: There are hundreds of excellent but lightly used libraries available for software development under linux. My goal is to package these libraries so that software developers, both commercial and open source, have a wide range of options available. The lower the barrier to entry is the more people can participate, the more people participating, the better. I'm not really a packaging expert, so while I'm willing to help with QA, I fear I may be more trouble than I'm worth. Historical Qualifications: I've helped out with the LyX document processor in the past, contributing the odd patch, I also ran their bugzilla installation for a while. I'm familiar with a variety of languages. Currently I'm paid to program Java, but I love using python and/or C++ Why should you trust me? .... Up to you really. (yes, this question may be a little blunt) GPG Key Fingerprint: 1024D/4743E9E9 2003-10-05 Michael A. Koziarski Key fingerprint = B77A 1053 C228 08D9 0866 5D60 39FF 0BD3 4743 E9E9 Cheers Koz From warren at togami.com Thu Nov 13 06:04:14 2003 From: warren at togami.com (Warren Togami) Date: Wed, 12 Nov 2003 20:04:14 -1000 Subject: NEEDSWORK - How you can help In-Reply-To: <3FB31B23.8060101@koziarski.com> References: <1068699838.4368.27.camel@laptop> <3FB31B23.8060101@koziarski.com> Message-ID: <3FB31EDE.5090609@togami.com> Michael A. Koziarski wrote: > > I'm a dovecot user, so if needs be I'd be willing to maintain this. > However the RPM that I'm using comes straight from redhat. Is this the > one that needs maintaining? or does fedora.us have its own (possibly > redundant?) package? fedora.us dovecot is only for RH9. If you use RH9 with dovecot I would highly encourage you to take over the package. Warren From satya at ttck.keio.ac.jp Thu Nov 13 15:10:28 2003 From: satya at ttck.keio.ac.jp (Satya Arjunan) Date: Fri, 14 Nov 2003 00:10:28 +0900 Subject: gcc-3.3.2 bug with boost-1.30.2 In-Reply-To: <1068699838.4368.27.camel@laptop> References: <1068699838.4368.27.camel@laptop> Message-ID: <3FB39EE4.4080508@ttck.keio.ac.jp> Hi all, I would like to report a bug of gcc-3.3.2 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10858) that appears when compiling with boost-1.30.2, both of which are standard packages in Fedora 1. In an attempt to enable compilation with the buggy gcc-3.3, the problem has been fixed with the current cvs version of boost. It would be helpful if Fedora can include the next release of boost in its next release. Thanks. From satya at ttck.keio.ac.jp Thu Nov 13 15:14:20 2003 From: satya at ttck.keio.ac.jp (Satya Arjunan) Date: Fri, 14 Nov 2003 00:14:20 +0900 Subject: gcc-3.3.2 bug with boost-1.30.2 In-Reply-To: <3FB31E8A.1060507@koziarski.com> References: <3FB31E8A.1060507@koziarski.com> Message-ID: <3FB39FCC.5020907@ttck.keio.ac.jp> Hi all, I would like to report a bug of gcc-3.3.2 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10858) that appears when compiling with boost-1.30.2, both of which are standard packages in Fedora 1. In an attempt to enable compilation with the buggy gcc-3.3, the problem has been fixed with the current cvs version of boost. It would be helpful if Fedora can include the next release of boost in its next release. Thanks. -- Satya Nanda Vel Arjunan Institute for Advanced Biosciences Keio University http://satya.host.sk/ From maxka at myrealbox.com Thu Nov 13 06:32:51 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Wed, 12 Nov 2003 22:32:51 -0800 Subject: exchange server alternatives In-Reply-To: References: Message-ID: <1068705171.5989.7.camel@max.localdomain> On Wed, 2003-11-12 at 06:46, Diego Cibils wrote: > Hi all, > > Does anyone knows, if there's any attemp out there to make a MS Exchange Server-compatible Mail/Groupware server ? > I mean, something like (Open)Exchange Server, that implements the Exchange protocol. > > I guess it's a closed protocol, but perhaps, someone has tried to get into it! I know of proprietary solutions, I believe. I'm not sure as far as Open Source goes. -M From ebpeele2 at pams.ncsu.edu Thu Nov 13 06:50:34 2003 From: ebpeele2 at pams.ncsu.edu (Elliot Peele) Date: Thu, 13 Nov 2003 01:50:34 -0500 Subject: exchange server alternatives In-Reply-To: References: Message-ID: <1068706234.10344.7.camel@localhost.localdomain> Theres open groupware: http://opengroupware.org/ Not sure how well it scales, never tried it, buts its an idea. You could also get all the functionality you need by using open source products to handle imap, an mta, and a directory service for an address book. The only thing that you can't implement in that way is calendaring afaik. Elliot On Wed, 2003-11-12 at 09:46, Diego Cibils wrote: > Hi all, > > Does anyone knows, if there's any attemp out there to make a MS Exchange Server-compatible Mail/Groupware server ? > I mean, something like (Open)Exchange Server, that implements the Exchange protocol. > > I guess it's a closed protocol, but perhaps, someone has tried to get into it ! > > Thanks, > Diego. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- 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 kwade at redhat.com Wed Nov 12 20:01:25 2003 From: kwade at redhat.com (Karsten Wade) Date: 12 Nov 2003 12:01:25 -0800 Subject: Participe In-Reply-To: <20031107222541.36040397D@sitemail.everyone.net> References: <20031107222541.36040397D@sitemail.everyone.net> Message-ID: <1068667285.2866.862.camel@erato.phig.org> On Fri, 2003-11-07 at 14:25, Miguel Vazquez Gocobachi wrote: > Hello. > > I'm Miguel Vazquez from Mexico, I interestering in a Fedora Project, > so I can translate language the site and others documents to Spanish. > What I need? You want to join fedora-docs-list. We're still working on the details of how translation will work, ongoing discussions on that list. - Karsten -- Karsten Wade : Tech Writer, RHCE : o: +1.831.466.9664 kwade at redhat.com : http://rhea.redhat.com/ : c: +1.831.818.9995 Red Hat Enterprise Applications : WAF, CMS, Portal Server -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- From tmus at get2net.dk Thu Nov 13 06:57:47 2003 From: tmus at get2net.dk (Thomas Munck Steenholdt) Date: Thu, 13 Nov 2003 07:57:47 +0100 (CET) Subject: exchange server alternatives In-Reply-To: <1068705171.5989.7.camel@max.localdomain> References: <1068705171.5989.7.camel@max.localdomain> Message-ID: <39387.80.163.254.90.1068706667.squirrel@www.tmus.dk> > On Wed, 2003-11-12 at 06:46, Diego Cibils wrote: >> Hi all, >> >> Does anyone knows, if there's any attemp out there to make a MS >> Exchange Server-compatible Mail/Groupware server ? I mean, something >> like (Open)Exchange Server, that implements the Exchange protocol. >> >> I guess it's a closed protocol, but perhaps, someone has tried to get >> into it! > > I know of proprietary solutions, I believe. I'm not sure as far as Open > Source goes. > > -M Try OpenGroupware.org - i believe that's that kind of thing, but I never tried it personally! Thomas From hugo at devin.com.br Wed Nov 12 20:13:31 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Wed, 12 Nov 2003 17:13:31 -0300 Subject: Getting to work on i18n? Message-ID: <3FB2946B.5060400@devin.com.br> Hi, 6 days ago I subscribed to this list and tried to subscribe on the i18n project to help Fedora Linux translating something to my language (Brazilian Portuguese). I received an e-mail telling me that my status was pending... I have to wait or can I work on something right now? I need some advice :) Thanks. []'s Hugo From matt at tasonline.com Thu Nov 13 07:10:44 2003 From: matt at tasonline.com (Matt Jarjoura) Date: Thu, 13 Nov 2003 02:10:44 -0500 (EST) Subject: PPC gcc3.3 Message-ID: <32922.172.155.89.66.1068707444.squirrel@tasonline.com> Hmmm... I know Apple has done a lot with gcc optimizations on the PPC platform. Is anyone bringing those changes over to the YellowDog/Fedora PPC? -Matt From sr at stephenreindl.de Thu Nov 13 07:24:13 2003 From: sr at stephenreindl.de (Stephen Reindl) Date: Thu, 13 Nov 2003 08:24:13 +0100 (CET) Subject: exchange server alternatives In-Reply-To: <39387.80.163.254.90.1068706667.squirrel@www.tmus.dk> References: <1068705171.5989.7.camel@max.localdomain> <39387.80.163.254.90.1068706667.squirrel@www.tmus.dk> Message-ID: <62447.195.233.250.7.1068708253.squirrel@sreindl.dyndns.org> But the Outlook connection (i.e. IMAP...) is extra, see http://www.skyrix.de/en/products/6_pricelist/index.html for details. Regards -- ------------------- Stephen Reindl sr at stephenreindl.de Thomas Munck Steenholdt sagte: >> On Wed, 2003-11-12 at 06:46, Diego Cibils wrote: >>> Hi all, >>> >>> Does anyone knows, if there's any attemp out there to make a MS >>> Exchange Server-compatible Mail/Groupware server ? I mean, something >>> like (Open)Exchange Server, that implements the Exchange protocol. >>> >>> I guess it's a closed protocol, but perhaps, someone has tried to get >>> into it! >> >> I know of proprietary solutions, I believe. I'm not sure as far as Open >> Source goes. >> >> -M > > Try OpenGroupware.org - i believe that's that kind of thing, but I never > tried it personally! > > Thomas > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From warren at togami.com Thu Nov 13 07:48:15 2003 From: warren at togami.com (Warren Togami) Date: Wed, 12 Nov 2003 21:48:15 -1000 Subject: Proposals for the Updates Testing Procedure Message-ID: <3FB3373F.3080303@togami.com> I am glad to see many test updates being announced on fedora-test-list, but may I please suggest some improvements to this mechanism. We also need to discuss the eventual creation of policy for the update approval process. Along with each announced test update, I believe it would be crucial to include a link to a corresponding Bugzilla report. While longer discussions pertaining to packages can remain on fedora-test-list, all pertinent information should be posted in one place within that test update's Bugzilla report. Why? * Otherwise it is likely that other Bugzilla reports and important information related to an update could easily be lost in the mailing list noise. * All pending updates can easily be found by a single Bugzilla database query. * Each report would become a one-stop-shop for information regarding that update. More responsible sysadmins with proper testing procedures can read that report to help in their decision to update. Discussion of the Update Approval Process ========================================= We also have not yet discussed the fedora.redhat.com update approval process. I suggest the following to begin the necessary discussion. Some of the below are similar in concept to the procedures currently being used successfully at fedora.us as described in this document: http://www.fedora.us/wiki/PackageSubmissionQAPolicy * Backport Patches v. Upgrade Version Most libraries, core system and server packages should always have backport patches. End-user applications where other packages do not depend on them can possibly be upgraded in version after sufficient testing in updates-testing. There are always possible exceptions to the rule, although the determination of backport verses upgrade version will need to be decided on a case-by-case basis based upon how intrusive the change would be. (Yeah this description sucks. Reply with a better and expanded proposal if you care about this.) * Time-limit to publish where no negative comments are posted within the Bugzilla report. Senior developers reserve the right to hold an update if a good technical reason can be stated. (Insert more details here.) * GPG clearsigned messages of approval For the test update approval process, a sizable number of people who matter (this needs further discussion) should post GPG clearsigned messages of approval to the Bugzilla report for the pending update currently in testing. Such messages should be posted if they technically agree with the patch/upgrade, and they have fully tested the functionality of the updated binary RPM and are satisfied that it is better than the previous package. Otherwise dissenting messages about functionality brokenness or suggestions for further package improvement are posted. http://www.fedora.us/wiki/QAChecklist There should be a checklist similar to this one used at fedora.us that contributors must go through and say "Passes all checklist items." within their report. This checklist idea has successfully prevented many common problems from being published in fedora.us. Depending on the criticalness of the update, the release managers decide when it is the appropriate time to publish based upon proper & signed contributor feedback. Before judging the above to be too an "onerous waste of time" as is the reaction that many people have, do know that this type of process has worked well at fedora.us during this year. This fedora.us report below is a great example of this type of process in action: https://bugzilla.fedora.us/show_bug.cgi?id=669 Well... something like this report, except a Fedora Core update would have fewer package updates during the approval process, and far more users saying "gcc-3.3.2-2 works for me". (It is important that clearsigned messages contain unique identifiers like the full package name-version-release because messages like "works for me" alone can be abused through a replay attack.) Why GPG? Wouldn't that be slow and a waste of time? ==================================================== No. The GPG clearsigned messages over time that collect within many reports and mailing list posts help to build a mass of "historical evidence" about the reliability and trustability of the advice given by a contributor. Over time this actually improves the efficiency of communication in a massively distributed project like one we are trying to create because of the following reasons. 1. Developers and users have a way to quickly search a history of a contributor's posts and contributions. That person may then quickly form an opinion about the skill level or reliability of the advice giver. 2. GPG signatures make it a lot more likely that the message came from the signer... the actual user holding the key. If that key is ever stolen, it would likely be discovered soon enough by other developers or the key owner if fraudulent messages are being posted. 3. Documented HOWTO procedure documents in GPG usage and proper use of messages give new contributors (developers, testers, etc.) a structured way to begin to build credibility and ease their way into the project. 4. The corpus of good GPG signed technical advice builds relationships of trust between developers and users. This could potentially form the basis of a developer certification and nomination of community leaders in the future. In order for GPG to become a standard for the project, we must have improved documentation with many examples of usage so newbies can quickly understand how it works. Perhaps better tools that interact with the X clipboard would help to improve the speed and ease of use of GPG clearsigning of messages too. Can anybody recommend existing tools that may help in this? Warren Togami warren at togami.com From kdebisschop at alert.infoplease.com Thu Nov 13 07:54:34 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Thu, 13 Nov 2003 02:54:34 -0500 Subject: Self-Introduction: Karl DeBisschop Message-ID: <1068705708.26251.19.camel@miles.debisschop.net> 1. Full legal name Karl Brian DeBisschop 2. Country, City Quincy, MA, USA 3. Profession or Student status Director of Software Engineering and Development, Infoplease.com 4. Company or School Infoplease is a tiny little part of Pearson Education. The over-inflated title is a holdover from when we were a startup in those dot-com bubble days. But we are still here, so we probably didn't do everything wrong. 5. Your goals in the Fedora Project My immediate goal is to submit for consideration minor changes to diskcheck that cause inodes to be checked in addition to bytes free. I also would like to get nagios and the nagios plugins into Fedora, but that would come later. I wouldn't mind doing some QA, but I've having a hard time figuring out all the policies and how Fedora works right now, so that too would probably best be later, I think. 6. Historical qualifications I have been the lead developer for the nagios plugins (nagiosplug.sourceforge.net) since the time the plugins were separated from the main nagios project, maybe about 3 years ago. I have from time to time worked with Lamar Owen in developing and debugging the RPMs for postgresql. Over the last several years I've been programming in perl and php for my work, and C for the nagios plugins. Before that I did a fair amount of fortran work, but unless we start putting groundwater flow models into Fedora Core, that may be less useful. Why should you trust me? Good question... I'm still working to figure out all the project policies, and most of my programming skills are self taught. But I tend to be aware of my limitations, willing to lurk/search around for answers when time allows, and ask direct questions when it does not. And I think my experience with nagios plugins has been a fairly good education in open source coding. 7. GPG KEYID and fingerprint pub 1024D/CA2294A0 2003-11-12 Karl DeBisschop (Personal Key) Key fingerprint = 8D09 F9FB 0859 CA98 EDC5 0316 9B39 B0E7 CA22 94A0 sub 1024g/9C869B9C 2003-11-12 -- Karl DeBisschop From eric at brouhaha.com Thu Nov 13 10:05:30 2003 From: eric at brouhaha.com (Eric Smith) Date: Thu, 13 Nov 2003 02:05:30 -0800 (PST) Subject: tools or scripts for release engineering? Message-ID: <37681.64.169.63.74.1068717930.squirrel@ruckus.brouhaha.com> Are there any tools or scripts for Fedora Core release engineering? In other words, the stuff that takes a big collection of SRPMS, and results in the ISO images? Failing that, is there some documentation on how it is done? I'm sure that with enough trial and error I could eventually come close to duplicating the way it's done officially, but if there are tools and/or docs, it's obviously much easier. Thanks! Eric Smith From eric at brouhaha.com Thu Nov 13 10:56:35 2003 From: eric at brouhaha.com (Eric Smith) Date: Thu, 13 Nov 2003 02:56:35 -0800 (PST) Subject: Anaconda LVM and file system size limitations In-Reply-To: <4979.4.20.168.241.1068693731.squirrel@ruckus.brouhaha.com> References: <4979.4.20.168.241.1068693731.squirrel@ruckus.brouhaha.com> Message-ID: <37785.64.169.63.74.1068720995.squirrel@ruckus.brouhaha.com> I wrote: > I just set up a system with a 1.4 TB RAID (on a 3Ware 7500-8), and > have run into some limitations of Anaconda. It seems that it is > not possible to set up an LVM physical volume or volume group larger > than 1 TB, nor to create ext3 (or jfs) filesystems larger than 1 TB. > > These limits seem to be hardcoded in fsset.py, in multiple lines like > aelf.maxSizeMB = 1024 * 1024 > It's my undertanding that there are problems with filesystems larger > than 2 TB, but it looks like it should be easy to change the Anaconda > limits to a higher value, such as 1536 MB or 1920 MB. Is there any > known problem with doing so? Thanks to Alexandre Oliva's message pointing me to the Anaconda docs for how to use updates.img, I've increased these to 1920 MB (patch attached) and it seems to solve that problem. Probably this could be set as high as 2047 MB before causing trouble. At 2048 MB there might be problems with 32-bit numbers overflowing and going negative, though I haven't tried it. I'll open an enhancement request in Bugzilla proposing raising it. I also increased the default LVM physical extent size to 64MB, because the 4MB default is ridiculously small (max. 256GB logical volume), and have attached a second patch for that. > I've tried creating the PV, VG, and LVs from the command line then > installing Fedora Core 1, and Disk Druid does show them correctly. > But after I tell it the mount points it gets an error to the effect that > it couldn't tell the kernel about the sda3 partition (the PV). There's > an option to ignore the error, but of course the install doesn't work > after that. I'm hoping that increasing the fsset.py limits will solve > this problem. Unfortunately, changing the limits did NOT fix this problem. More specifically, the error is "Error informing the kernel about modifications to partition /dev/sda3 - Invalid arguments". sda3 is my LVM physical volume. This error happens after the message "moving (1) to step enablefilesystems" is written to vt 1. Note that this is the same error I was getting *before* I patched Anaconda, so it is not something I broke. I'm not sure how to go about debugging this, so suggestions would be very welcome. Thanks! Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: max_partition_size.patch Type: application/octet-stream Size: 2220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: default_lvm_pesize.patch Type: application/octet-stream Size: 437 bytes Desc: not available URL: From strange at nsk.no-ip.org Thu Nov 13 10:45:26 2003 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 13 Nov 2003 10:45:26 +0000 Subject: TradeMarked Name --redhat-config- In-Reply-To: <1068644625.12212.44.camel@locutus> References: <20031109152732.GA3214@nsk.no-ip.org> <1068644625.12212.44.camel@locutus> Message-ID: <20031113104526.GA4542@nsk.no-ip.org> On Wed, Nov 12, 2003 at 06:43:45AM -0700, Bill Anderson wrote: > On Sun, 2003-11-09 at 08:27, Luciano Miguel Ferreira Rocha wrote: > > > PS: AINAL > > Am I Not A Lawyer? ;^) Well, am I? :) Regards, Luciano Rocha From buildsys at porkchop.devel.redhat.com Thu Nov 13 11:24:35 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Thu, 13 Nov 2003 06:24:35 -0500 Subject: rawhide report: 20031113 changes Message-ID: <200311131124.hADBOZG29142@porkchop.devel.redhat.com> From lowen at pari.edu Thu Nov 13 11:27:38 2003 From: lowen at pari.edu (Lamar Owen) Date: Thu, 13 Nov 2003 06:27:38 -0500 Subject: Self-Introduction: Karl DeBisschop In-Reply-To: <1068705708.26251.19.camel@miles.debisschop.net> References: <1068705708.26251.19.camel@miles.debisschop.net> Message-ID: <200311130627.38985.lowen@pari.edu> On Thursday 13 November 2003 02:54 am, Karl DeBisschop wrote: > I have from time to time worked with Lamar Owen in developing and > debugging the RPMs for postgresql. FWIW I'll confirm Karl's significant contributions to the PostgreSQL RPM packaging. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From redhat at olen.net Thu Nov 13 15:27:35 2003 From: redhat at olen.net (Ola Thoresen) Date: Thu, 13 Nov 2003 16:27:35 +0100 Subject: IMAP and mbox Message-ID: <20031113152734.GA9069@powertech.no> RedHat removed support for ~/mbox in 7.0, and since then we have recompiled the source rpms as described in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=18375 It might just be me, but I really prefer mail to stay in $HOME, and mbx is unfortunately not an option as /home is mounted over NFS. Would it be possible to either have this re-added in the next build of imapd, or should we submit these rebuilt packages to fedora.us as 'imapd-with-mbox' (or some other obscure name) or is there any chance that someone else (who already maintains the imap-packages) will add these? Rgds. Ola Thoresen -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From 64bit_fedora at comcast.net Thu Nov 13 15:33:04 2003 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Thu, 13 Nov 2003 09:33:04 -0600 (CST) Subject: Fedora Core 1: X86-64 Failed compile package list In-Reply-To: <200311131022.09725.nbecker@hns.com> Message-ID: On Thu, 13 Nov 2003, Neal D. Becker wrote: > > > Where? There is no x86_64 dir here: > http://download.fedora.us/fedora/fedora/1/ > Look in what used to be Red Hat Rawhide, but is now Fedora Development, there is an x86_64 directory in there that has the packages. Any mirror should work. Justin M. Forbes From katzj at redhat.com Thu Nov 13 16:08:51 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Nov 2003 11:08:51 -0500 Subject: Anaconda and Linux kernel 2.6.0-test9 In-Reply-To: <20031112225837.GA1364@imp.flyn.org> References: <20031112225837.GA1364@imp.flyn.org> Message-ID: <1068739731.7225.72.camel@edoras.local.net> On Wed, 2003-11-12 at 17:58, W. Michael Petullo wrote: > Has anyone been able to compile anaconda 9.2 against 2.6.0-test9 > kernel headers? I am running into kernel header-related problems. > I've seen that other software projects are facing similar difficulty > with 2.6. I imagine it has something to do with what code is protected > by #ifdef __KERNEL__'s as the kernel itself compiles fine. I get the > following errors: /usr/include/linux should be the sanitized headers that are in the glibc-kernheaders package. Just using the ones from the kernel tree is likely to be a bad idea. And I guarantee that anaconda has a fair bit of work to go to work with 2.6... continuing to work on that some more later this afternoon I hope. Cheers, Jeremy From katzj at redhat.com Thu Nov 13 16:13:30 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Nov 2003 11:13:30 -0500 Subject: Installing from software RAID0? In-Reply-To: <20031112211801.GD1049932@hiwaay.net> References: <20031112211801.GD1049932@hiwaay.net> Message-ID: <1068740009.7225.74.camel@edoras.local.net> On Wed, 2003-11-12 at 16:18, Chris Adams wrote: > I tried to install from local hard drives that are configured with > software RAID0, and it didn't work. Should I bother to bugzilla this, > or is this just too far into "don't do that" land? Due to space limitations, you can only do hard drive installs from things that are simple (ie raw hard drives, ext[23] or vfat filesystems). Cheers, Jeremy From cmadams at hiwaay.net Thu Nov 13 16:21:13 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 13 Nov 2003 10:21:13 -0600 Subject: Installing from software RAID0? In-Reply-To: <1068740009.7225.74.camel@edoras.local.net> References: <20031112211801.GD1049932@hiwaay.net> <1068740009.7225.74.camel@edoras.local.net> Message-ID: <20031113162113.GA968812@hiwaay.net> Once upon a time, Jeremy Katz said: > Due to space limitations, you can only do hard drive installs from > things that are simple (ie raw hard drives, ext[23] or vfat > filesystems). I guess you mean space limitations in the first stage installer (since the second stage does know RAID and can scan them for existing installations)? It has been mentioned as a possiblity that floppy boot may go away because the kernel won't fit (due to ACPI). With a CD boot, the first stage could be larger (and presumably smarter); any chance of support for more complex hard drive installs then? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From katzj at redhat.com Thu Nov 13 16:32:55 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Nov 2003 11:32:55 -0500 Subject: Installing from software RAID0? In-Reply-To: <20031113162113.GA968812@hiwaay.net> References: <20031112211801.GD1049932@hiwaay.net> <1068740009.7225.74.camel@edoras.local.net> <20031113162113.GA968812@hiwaay.net> Message-ID: <1068741175.7225.78.camel@edoras.local.net> On Thu, 2003-11-13 at 11:21, Chris Adams wrote: > Once upon a time, Jeremy Katz said: > > Due to space limitations, you can only do hard drive installs from > > things that are simple (ie raw hard drives, ext[23] or vfat > > filesystems). > > I guess you mean space limitations in the first stage installer (since > the second stage does know RAID and can scan them for existing > installations)? Correct. > It has been mentioned as a possiblity that floppy boot may go away > because the kernel won't fit (due to ACPI). With a CD boot, the first > stage could be larger (and presumably smarter); any chance of support > for more complex hard drive installs then? Maybe. It's not high on my list of things to consider, though, as hard drive installs are very uncommon from all the data that I have. Cheers, Jeremy From jspaleta at princeton.edu Thu Nov 13 16:45:54 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Thu, 13 Nov 2003 11:45:54 -0500 Subject: Proposals for the Updates Testing Procedure Message-ID: <1068741954.6053.21.camel@spatula.pppl.gov> Warren Togami wrote: >* Time-limit to publish where no negative comments are posted >within the Bugzilla report. Senior developers reserve the right to >hold an update if a good technical reason can be stated. (Insert >more details here.) I'm not going to weigh in on whether or not a countdown for a move from testing to release is a good idea or not. But if a clock is started it would be nice to know if there will be a way for community testers to not only abort the countdown by finding regressions in the test packages but also a way to accelerate the timetable if the fix in testing is 'important' and community members want to do what is in their power to get the package out of testing as quickly as possible so it can be applied. Starting a clock...does not, on the face of things, encourage active testing by the community...since if people wait for the clock to expire, the testing package gets released if no regressions are found. No testing...no regressions. And of course not having a clock, could mean, that good packages will linger in testing even though they are reasonably well crafted updates. -jef"just give me a policy that i can beat people over the head with"spaleta From Bernd.Bartmann at sohanet.de Thu Nov 13 17:29:15 2003 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Thu, 13 Nov 2003 18:29:15 +0100 Subject: Fedora updates/errata overview web page Message-ID: <3FB3BF6B.8080803@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Might I suggest to setup an updates/errata web page for Fedora Core similar to http://www.redhat.com/apps/support/errata/ and https://rhn.redhat.com/errata/rh9-errata.html as a central place for such information. http://fedora.redhat.com/download/updates.html doesn't show the the announcement texts. Best wishes. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/s79rkQuIaHu84cIRAsOXAKCpJ/s7+twv2uqNghQ/KDN+3gJrggCdGbXn 6jPmsFzLaDRe8eE0SaeQpWQ= =+Pol -----END PGP SIGNATURE----- From cmadams at hiwaay.net Thu Nov 13 17:17:48 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 13 Nov 2003 11:17:48 -0600 Subject: Installing from software RAID0? In-Reply-To: <1068741175.7225.78.camel@edoras.local.net> References: <20031112211801.GD1049932@hiwaay.net> <1068740009.7225.74.camel@edoras.local.net> <20031113162113.GA968812@hiwaay.net> <1068741175.7225.78.camel@edoras.local.net> Message-ID: <20031113171748.GB968812@hiwaay.net> Once upon a time, Jeremy Katz said: > On Thu, 2003-11-13 at 11:21, Chris Adams wrote: > > It has been mentioned as a possiblity that floppy boot may go away > > because the kernel won't fit (due to ACPI). With a CD boot, the first > > stage could be larger (and presumably smarter); any chance of support > > for more complex hard drive installs then? > > Maybe. It's not high on my list of things to consider, though, as hard > drive installs are very uncommon from all the data that I have. But how am I supposed to upgrade my mirror? :-) I didn't think about the fact that the second stage hasn't (and obviously can't have) started at this point. That does make it harder for little gain. The NOC is a half mile from the office, and I had to go back down the street to burn CDs - it was a good thing I'd already copied FC1 to my workstation, as the mirror OS drive was dead (for anyone trying to use mirror.hiwaay.net, it'll go down again for a bit shortly - I've got a different set of drives to use for the OS, so I need to re-install, and it has a slooow CD-ROM drive). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mike at flyn.org Thu Nov 13 16:18:24 2003 From: mike at flyn.org (mike at flyn.org) Date: Thu, 13 Nov 2003 12:18:24 -0400 Subject: Anaconda and Linux kernel 2.6.0-test9 Message-ID: <20031113171824.2EB93315F1@neuromancer.voxel.net> >> Has anyone been able to compile anaconda 9.2 against 2.6.0-test9 >> kernel headers? I am running into kernel header-related problems. >> I've seen that other software projects are facing similar difficulty >> with 2.6. I imagine it has something to do with what code is protected >> by #ifdef __KERNEL__'s as the kernel itself compiles fine. I get the >> following errors: > > /usr/include/linux should be the sanitized headers that are in the > glibc-kernheaders package. Just using the ones from the kernel tree is > likely to be a bad idea. > > And I guarantee that anaconda has a fair bit of work to go to work with > 2.6... continuing to work on that some more later this afternoon I > hope. Is there a glibc-kernheaders package created from 2.6 yet? I can not find one. I understand that kernel developers have stated that use-space programs should not include kernel headers but I don't understand who sanitizes them for use in /usr/include/linux etc. Is this the work of the glibc team? Red Hat? From jeremyp at pobox.com Thu Nov 13 17:42:13 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: Thu, 13 Nov 2003 12:42:13 -0500 Subject: NEEDSWORK - How you can help In-Reply-To: <3FB31EDE.5090609@togami.com> References: <1068699838.4368.27.camel@laptop> <3FB31B23.8060101@koziarski.com> <3FB31EDE.5090609@togami.com> Message-ID: <1068745333.16187.31.camel@jeremy.dtcc.cc.nc.us> On Thu, 2003-11-13 at 01:04, Warren Togami wrote: > Michael A. Koziarski wrote: > > > > I'm a dovecot user, so if needs be I'd be willing to maintain this. > > However the RPM that I'm using comes straight from redhat. Is this the > > one that needs maintaining? or does fedora.us have its own (possibly > > redundant?) package? > > fedora.us dovecot is only for RH9. If you use RH9 with dovecot I would > highly encourage you to take over the package. > I am a user of dovecot for RH9, but I used the one from Fedora Core, rebuilt with --rebuild. Perhaps the fedora.us package could be changed to the Red Hat (Fedora Core) package, and then there would no longer be a necessity to maintain a separate package? --Jeremy -- /---------------------------------------------------------------------\ | Jeremy Portzer jeremyp at pobox.com trilug.org/~jeremy | | GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 | \---------------------------------------------------------------------/ -------------- 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 katzj at redhat.com Thu Nov 13 17:45:09 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Nov 2003 12:45:09 -0500 Subject: Anaconda LVM and file system size limitations In-Reply-To: <4979.4.20.168.241.1068693731.squirrel@ruckus.brouhaha.com> References: <4979.4.20.168.241.1068693731.squirrel@ruckus.brouhaha.com> Message-ID: <1068745509.5753.12.camel@mirkwood.devel.redhat.com> On Wed, 2003-11-12 at 22:22, Eric Smith wrote: > I just set up a system with a 1.4 TB RAID (on a 3Ware 7500-8), and > have run into some limitations of Anaconda. It seems that it is > not possible to set up an LVM physical volume or volume group larger > than 1 TB, nor to create ext3 (or jfs) filesystems larger than 1 TB. Problems have been reported with devices larger than a terabyte. Also, in general, most drivers are only safe up to a terabyte -- some can go to 2, but it's driver dependent in 2.4.x and so it was deemed better to err on the side of caution since I don't have hardware to investigate with. > These limits seem to be hardcoded in fsset.py, in multiple lines like > aelf.maxSizeMB = 1024 * 1024 > It's my undertanding that there are problems with filesystems larger > than2 TB, but it looks like it should be easy to change the Anaconda > limits to a higher value, such as 1536 MB or 1920 MB. Is there any > known problem with doing so? It wasn't working, that's why it's set to 1 TB. Cheers, Jeremy From rdieter at math.unl.edu Thu Nov 13 17:48:11 2003 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 13 Nov 2003 11:48:11 -0600 Subject: IMAP and mbox In-Reply-To: <20031113170011.12814.36908.Mailman@listman.back-rdu.redhat.com> References: <20031113170011.12814.36908.Mailman@listman.back-rdu.redhat.com> Message-ID: <3FB3C3DB.20706@math.unl.edu> Ola Thoresen wrote: > RedHat removed support for ~/mbox in 7.0, and since then we have > recompiled > >the source rpms as described in >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=18375 >It might just be me, but I really prefer mail to stay in $HOME, > Amen to that. That's what we've been doing ever since then too. -- Rex From johnsonm at redhat.com Thu Nov 13 18:21:53 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Thu, 13 Nov 2003 13:21:53 -0500 Subject: Proposals for the Updates Testing Procedure In-Reply-To: <3FB3373F.3080303@togami.com>; from warren@togami.com on Wed, Nov 12, 2003 at 09:48:15PM -1000 References: <3FB3373F.3080303@togami.com> Message-ID: <20031113132153.A22474@devserv.devel.redhat.com> On Wed, Nov 12, 2003 at 09:48:15PM -1000, Warren Togami wrote: > Along with each announced test update, I believe it would be crucial to > include a link to a corresponding Bugzilla report. While longer This is probably a good idea, even if we need to create an empty report for discussion. > * Backport Patches v. Upgrade Version > Most libraries, core system and server packages should always have > backport patches. End-user applications where other packages do not > depend on them can possibly be upgraded in version after sufficient > testing in updates-testing. There are always possible exceptions to the > rule, although the determination of backport verses upgrade version will > need to be decided on a case-by-case basis based upon how intrusive the > change would be. (Yeah this description sucks. Reply with a better and > expanded proposal if you care about this.) Here we have disagreement, at least in wording. As documented at http://fedora.redhat.com/about/objectives.html one of Red Hat's prerequisites for participation is: o Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages. This is the default; when there is a good reason to use a backport patch it is of course OK to do so. Here are examples of reasons: o It's a critical security fix and the changes to a new upstream package are so large that they cannot reasonably be tested in time. o Configuration file formats have changed. o Library ABIs have changed. Essentially, the one main reason that should not be used for doing a backport is "it's the rule". We do, however, recognize that the maintainer of the package has expertise in that package and so we expect to trust maintainers' judgement for when exceptions should be made. Practically speaking, I'm not sure how many real differences there will be between our approaches, since the exceptions on both sides are relatively complementary... > * Time-limit to publish where no negative comments are posted within the > Bugzilla report. Senior developers reserve the right to hold an update > if a good technical reason can be stated. (Insert more details here.) I'd like to have something a little different here. Let's step back and look at the goal, which is simple "plenty of testing without finding unexpected regressions". Time doesn't really tell us anything. I'd like us to be able to get some information on downloads, and then consider the time since some reasonable number of downloads have been done. The amount of testing that is going to be needed will depend on the package, and I'd think that the package maintainer is going to be a good judge of how much testing is needed. So I'd say we should come up with guidelines, but be flexible. We need to look into providing the data on which to base good decisions. Also, security updates are clearly going to need to be handled differently from bugfix updates, and new feature updates also differently. Security updates need the most expeditious handling; bugfix less so, and new feature updates will tend to need less-expeditious handling *and* a larger amount of testing. > Why GPG? Wouldn't that be slow and a waste of time? > ==================================================== > No. The GPG clearsigned messages over time that collect within many > reports and mailing list posts help to build a mass of "historical > evidence" about the reliability and trustability of the advice given by > a contributor. Well, I'd say that a bugzilla account does the same. I know that it is only password-protected, but someone could GPG-sign a message saying that they weren't responsible for obnoxious bugzilla messages posted from their account -- and ask that their bugzilla password be reset! That said, Red Hat is operating under the assumption that all developers, at least, will have GPG keys. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From aoliva at redhat.com Thu Nov 13 17:30:56 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 13 Nov 2003 15:30:56 -0200 Subject: Installing from software RAID0? In-Reply-To: <1068741175.7225.78.camel@edoras.local.net> References: <20031112211801.GD1049932@hiwaay.net> <1068740009.7225.74.camel@edoras.local.net> <20031113162113.GA968812@hiwaay.net> <1068741175.7225.78.camel@edoras.local.net> Message-ID: On Nov 13, 2003, Jeremy Katz wrote: > Maybe. It's not high on my list of things to consider, though, as hard > drive installs are very uncommon from all the data that I have. Perhaps this is in part caused by the inability to do it. I, for one, would do most of my installs from hard disk if it supported RAID and LVM. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From eric at brouhaha.com Thu Nov 13 18:48:37 2003 From: eric at brouhaha.com (Eric Smith) Date: Thu, 13 Nov 2003 10:48:37 -0800 (PST) Subject: Anaconda LVM and file system size limitations In-Reply-To: <1068745509.5753.12.camel@mirkwood.devel.redhat.com> References: <4979.4.20.168.241.1068693731.squirrel@ruckus.brouhaha.com> <1068745509.5753.12.camel@mirkwood.devel.redhat.com> Message-ID: <37971.64.169.63.74.1068749317.squirrel@ruckus.brouhaha.com> "Jeremy Katz" wrote: > Also, in general, most drivers are only safe up to a terabyte -- some can > go to 2, but it's driver dependent in 2.4.x and so it was deemed better to > err on the side of caution That might justify an "are you sure you want to do this" dialog, but it doesn't justify a hard limit (IMNSHO). I've used other 2.4.x based distributions with >1 TB without problems, so at least some drivers (such as 3ware) handle it fine. The 3ware card as a documented limit of 2 TB. I'm hoping that they release new firmware to eliminate that limit, but it won't help until we use a 2.6.x kernel. > It wasn't working, that's why it's set to 1 TB. I suppose that would be OK for Fedora, except that I can't imagine Red Hat Enterprise Server customers being happy about that (I wouldn't), and IINM Fedora is supposed to be the testing ground for Enterprise stuff. So far with the patched Anaconda it looks like the only problem is in the parted library, and that problem occurs even with unpatched Anaconda if there is a preexisting partition >1 TB. So even if you don't need the Anaconda to create such partitions, you won't be able to upgrade a machine that has them. I'm out of time for hacking on it this week, but next week I'll see if standalone parted has the same problem. If so, that should be much easier to debug. Best regards, Eric From warren at togami.com Thu Nov 13 18:48:48 2003 From: warren at togami.com (Warren Togami) Date: Thu, 13 Nov 2003 08:48:48 -1000 Subject: Proposals for the Updates Testing Procedure In-Reply-To: <20031113132153.A22474@devserv.devel.redhat.com> References: <3FB3373F.3080303@togami.com> <20031113132153.A22474@devserv.devel.redhat.com> Message-ID: <3FB3D210.7010402@togami.com> Michael K. Johnson wrote: > On Wed, Nov 12, 2003 at 09:48:15PM -1000, Warren Togami wrote: > >>Along with each announced test update, I believe it would be crucial to >>include a link to a corresponding Bugzilla report. While longer > > > This is probably a good idea, even if we need to create an > empty report for discussion. > Or fill out the empty report with content from a simple template. I'd say information about why an upgrade, and perhaps the patch, etc. >>* Time-limit to publish where no negative comments are posted within the >>Bugzilla report. Senior developers reserve the right to hold an update >> if a good technical reason can be stated. (Insert more details here.) > SNIP > > Time doesn't really tell us anything. I'd like us to be able to get > some information on downloads, and then consider the time since some > reasonable number of downloads have been done. The amount of testing > that is going to be needed will depend on the package, and I'd think > that the package maintainer is going to be a good judge of how much > testing is needed. So I'd say we should come up with guidelines, but > be flexible. We need to look into providing the data on which to > base good decisions. > > Also, security updates are clearly going to need to be handled differently > from bugfix updates, and new feature updates also differently. Security > updates need the most expeditious handling; bugfix less so, and new feature > updates will tend to need less-expeditious handling *and* a larger amount > of testing. I guess I was mainly concerned about update packages sitting forever in testing only because too few people care enough to test & comment on it. https://bugzilla.fedora.us/show_bug.cgi?id=35 I'd really hate to avoid cases like this... where we have a package sitting in limbo for almost 9 months. I'd say that 1-2 months would be a fair time limit for update testing. At some point, maybe a week before the expiration date, there should be warnings posted for a last call for testing. This would be an important safeguard for the community so updates cannot be snuck in by default easily. In most cases however packages would receive enough testing to make publication far quicker and never necessitate invoking the expiration date. Warren From oliverjohntibi at hotmail.com Thu Nov 13 18:51:47 2003 From: oliverjohntibi at hotmail.com (Oliver John Tibi) Date: Fri, 14 Nov 2003 02:51:47 +0800 Subject: Backgrounds (Wallpapers) Message-ID: hello! i wondered who's in charge of backgrounds, i'd like to contribute my sample artworks. thanks! _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From johnsonm at redhat.com Thu Nov 13 19:02:04 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Thu, 13 Nov 2003 14:02:04 -0500 Subject: Proposals for the Updates Testing Procedure In-Reply-To: <3FB3D210.7010402@togami.com>; from warren@togami.com on Thu, Nov 13, 2003 at 08:48:48AM -1000 References: <3FB3373F.3080303@togami.com> <20031113132153.A22474@devserv.devel.redhat.com> <3FB3D210.7010402@togami.com> Message-ID: <20031113140204.B22474@devserv.devel.redhat.com> On Thu, Nov 13, 2003 at 08:48:48AM -1000, Warren Togami wrote: > I guess I was mainly concerned about update packages sitting forever in > testing only because too few people care enough to test & comment on it. > https://bugzilla.fedora.us/show_bug.cgi?id=35 > I'd really hate to avoid cases like this... where we have a package > sitting in limbo for almost 9 months. If no one cares enough to test, is it important to make it final? In the scheme we're using, it's easily available, it's just not the default. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From Nicolas.Mailhot at laPoste.net Thu Nov 13 17:38:34 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 13 Nov 2003 18:38:34 +0100 Subject: IMAP and mbox In-Reply-To: <20031113152734.GA9069@powertech.no> References: <20031113152734.GA9069@powertech.no> Message-ID: <1068745114.1947.1.camel@m70.net81-64-235.noos.fr> Le jeu 13/11/2003 ? 16:27, Ola Thoresen a ?crit : > RedHat removed support for ~/mbox in 7.0, and since then we have recompiled > the source rpms as described in > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=18375 > It might just be me, but I really prefer mail to stay in $HOME, and mbx is > unfortunately not an option as /home is mounted over NFS. postfix+procmail+spamassassin+dovecot is your friend 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 aoliva at redhat.com Thu Nov 13 19:12:56 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 13 Nov 2003 17:12:56 -0200 Subject: Anaconda and Linux kernel 2.6.0-test9 In-Reply-To: <20031113171824.2EB93315F1@neuromancer.voxel.net> References: <20031113171824.2EB93315F1@neuromancer.voxel.net> Message-ID: On Nov 13, 2003, "mike at flyn.org" wrote: > Is there a glibc-kernheaders package created from 2.6 yet? This would only be necessary if there had been any kernel ABI changes. Do you know of any? BTW, glibc-kernheaders is actually a misnomer: it exposes the kernel ABI, and has nothing to do with glibc, other than the fact that glibc uses it. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From daly at rio.sci.ccny.cuny.edu Thu Nov 13 16:58:45 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Thu, 13 Nov 2003 11:58:45 -0500 Subject: NEEDSWORK - How you can help In-Reply-To: <1068699838.4368.27.camel@laptop> (message from Warren Togami on Wed, 12 Nov 2003 19:03:58 -1000) References: <1068699838.4368.27.camel@laptop> Message-ID: <200311131658.hADGwj804255@rio.sci.ccny.cuny.edu> Warren, The links: http://www.fedora.us/wiki/PackageSubmissionQAPolicy http://www.fedora.us/wiki/QAChecklist http://www.fedora.us/wiki/SelfIntroduction fail with a DB Error: connect failed. Tim Daly axiom at tenkan.org daly at idsi.net From Nicolas.Mailhot at laPoste.net Thu Nov 13 19:46:05 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 13 Nov 2003 20:46:05 +0100 Subject: Some fedora devel inconsistencies... Message-ID: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> Some fedora devel inconsistencies... Resolving dependencies .package redhat-artwork needs /usr/lib/qt-3.1 (not provided) package redhat-config-rootpassword needs /usr/bin/python2.2 (not provided) package redhat-config-keyboard needs /usr/bin/python2.2 (not provided) package redhat-config-language needs /usr/bin/python2.2 (not provided) package redhat-config-mouse needs /usr/bin/python2.2 (not provided) package redhat-config-soundcard needs /usr/bin/python2.2 (not provided) package redhat-config-securitylevel needs /usr/bin/python2.2 (not provided) package redhat-config-xfree86 needs /usr/bin/python2.2 (not provided) package redhat-config-date needs /usr/bin/python2.2 (not provided) package authconfig-gtk needs /usr/bin/python2.2 (not provided) package redhat-config-users needs /usr/bin/python2.2 (not provided) package redhat-config-network-tui needs /usr/bin/python2.2 (not provided) package kdebase needs libvcard.so.0 (not provided) 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 skvidal at phy.duke.edu Thu Nov 13 19:57:58 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 13 Nov 2003 14:57:58 -0500 Subject: Some fedora devel inconsistencies... In-Reply-To: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> Message-ID: <1068753478.5425.67.camel@opus> On Thu, 2003-11-13 at 14:46, Nicolas Mailhot wrote: > Some fedora devel inconsistencies... > > Resolving dependencies > .package redhat-artwork needs /usr/lib/qt-3.1 (not provided) > package redhat-config-rootpassword needs /usr/bin/python2.2 (not > provided) > package redhat-config-keyboard needs /usr/bin/python2.2 (not provided) > package redhat-config-language needs /usr/bin/python2.2 (not provided) > package redhat-config-mouse needs /usr/bin/python2.2 (not provided) > package redhat-config-soundcard needs /usr/bin/python2.2 (not provided) > package redhat-config-securitylevel needs /usr/bin/python2.2 (not > provided) > package redhat-config-xfree86 needs /usr/bin/python2.2 (not provided) > package redhat-config-date needs /usr/bin/python2.2 (not provided) > package authconfig-gtk needs /usr/bin/python2.2 (not provided) > package redhat-config-users needs /usr/bin/python2.2 (not provided) > package redhat-config-network-tui needs /usr/bin/python2.2 (not > provided) > package kdebase needs libvcard.so.0 (not provided) known as broked. -sv From Nicolas.Mailhot at laPoste.net Thu Nov 13 20:21:07 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 13 Nov 2003 21:21:07 +0100 Subject: Some fedora devel inconsistencies... In-Reply-To: <1068753478.5425.67.camel@opus> References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> <1068753478.5425.67.camel@opus> Message-ID: <1068754866.4291.6.camel@m70.net81-64-235.noos.fr> Le jeu 13/11/2003 ? 20:57, seth vidal a ?crit : > On Thu, 2003-11-13 at 14:46, Nicolas Mailhot wrote: > > Some fedora devel inconsistencies... > > > > Resolving dependencies > > .package redhat-artwork needs /usr/lib/qt-3.1 (not provided) > > package redhat-config-rootpassword needs /usr/bin/python2.2 (not > > provided) > > package redhat-config-keyboard needs /usr/bin/python2.2 (not provided) > > package redhat-config-language needs /usr/bin/python2.2 (not provided) > > package redhat-config-mouse needs /usr/bin/python2.2 (not provided) > > package redhat-config-soundcard needs /usr/bin/python2.2 (not provided) > > package redhat-config-securitylevel needs /usr/bin/python2.2 (not > > provided) > > package redhat-config-xfree86 needs /usr/bin/python2.2 (not provided) > > package redhat-config-date needs /usr/bin/python2.2 (not provided) > > package authconfig-gtk needs /usr/bin/python2.2 (not provided) > > package redhat-config-users needs /usr/bin/python2.2 (not provided) > > package redhat-config-network-tui needs /usr/bin/python2.2 (not > > provided) > > package kdebase needs libvcard.so.0 (not provided) > > known as broked. Well this was just a way of venting my frustration after going through a long list of available updates to remove the python bits so yum actually accepts to update the system (man do I feel restrained). The silly program won't update unrelated stuff like bash & vim just because of those errors (ok I'll say it - apt is smarter. I'd return to it except all the directory shuffling seems to have killed the apted rawhide mirrors I knew of before) -- 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 mike at flyn.org Thu Nov 13 19:28:26 2003 From: mike at flyn.org (mike at flyn.org) Date: Thu, 13 Nov 2003 15:28:26 -0400 Subject: Anaconda and Linux kernel 2.6.0-test9 Message-ID: <20031113202826.673CD315E9@neuromancer.voxel.net> >> Is there a glibc-kernheaders package created from 2.6 yet? > > This would only be necessary if there had been any kernel ABI > changes. Do you know of any? > > BTW, glibc-kernheaders is actually a misnomer: it exposes the kernel > ABI, and has nothing to do with glibc, other than the fact that glibc > uses it. Yes, I want to add encrypted root filesystem support to anaconda unsing loopback encryption. In order to do this, I need 2.6 (or kerneli.org's 2.4 patch) because loop.h has cryptoloop-related additions. I suppose I could just apply the relevant portions of the 2.4 cryptoloop patch to glibc-kernheaders. I would like to see this cryptoloop stuff upstream, though. Hopefully I'm on the right track now, thanks. -- Mike From garrett at redhat.com Thu Nov 13 20:22:06 2003 From: garrett at redhat.com (Garrett LeSage) Date: Thu, 13 Nov 2003 15:22:06 -0500 Subject: Backgrounds (Wallpapers) In-Reply-To: References: Message-ID: <3FB3E7EE.8050804@redhat.com> Oliver John Tibi wrote: > hello! i wondered who's in charge of backgrounds, i'd like to > contribute my sample artworks. Oliver, I'm in charge of the graphics for Fedora. Many people have already expressed interest in submitting backgrounds and other graphics. Thanks for considering submitting artwork to Fedora. If you're interested, please join fedora-desktop-list, as we discuss not only user interface ideas, but the way the desktop looks in general (including the backgrounds and all other artwork). You can sign up at the list using the following page: http://www.redhat.com/mailman/listinfo/fedora-desktop-list Garrett From embryo at superonline.com Thu Nov 13 20:35:03 2003 From: embryo at superonline.com (caghan ozbek) Date: Thu, 13 Nov 2003 22:35:03 +0200 Subject: Fedora Core 1 Add/Remove Application BUG FIX in method.py Message-ID: <1068755703.6282.59.camel@redEmbryo> hi, i did upgrade my red hat 9.0 to fedora core 1 and it does work perfect now. but exist a bug: Step to BUG: 1.open redhat->System Settings ->Add\Remove Applications 2.select new packages from the gui 3.Press Update button 4.appears Completed System Preparation frame then press Continue button. 5.Get Error mesage "There was an error installing packages." And cannot install packages then i fix that bug: file: /usr/share/redhat-config-packages/method.py bug line number 733: bug line : self.packagesDir = "Redhat/RPMS" fix line : self.packagesDir = "Fedora/RPMS" i hope you will fix that in the source. happy programming:o) -- caghan ozbek @Bilgi Computer Science From katzj at redhat.com Thu Nov 13 20:40:54 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Nov 2003 15:40:54 -0500 Subject: Some fedora devel inconsistencies... In-Reply-To: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> Message-ID: <1068756054.5753.186.camel@mirkwood.devel.redhat.com> On Thu, 2003-11-13 at 14:46, Nicolas Mailhot wrote: > Some fedora devel inconsistencies... Welcome to rawhide... this is normal for early in the development cycle. :) Jeremy From skvidal at phy.duke.edu Thu Nov 13 20:46:07 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 13 Nov 2003 15:46:07 -0500 Subject: Some fedora devel inconsistencies... In-Reply-To: <1068754866.4291.6.camel@m70.net81-64-235.noos.fr> References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> <1068753478.5425.67.camel@opus> <1068754866.4291.6.camel@m70.net81-64-235.noos.fr> Message-ID: <1068756367.7061.30.camel@opus> > > known as broked. > > Well this was just a way of venting my frustration after going through a > long list of available updates to remove the python bits so yum actually > accepts to update the system (man do I feel restrained). Then don't use yum. problem solved. > The silly program won't update unrelated stuff like bash & vim just > because of those errors (ok I'll say it - apt is smarter. I'd return to > it except all the directory shuffling seems to have killed the apted > rawhide mirrors I knew of before) You're right - if you specify 'yum update' and something fails, it won't run the update. That's behavior that, to me, protects the user from stupid stupid shite. I don't think holding back updates that have been requested b/c others fail is correct or safe behavior. Again, if you don't want to use yum, then don't. I have no problem with that. I think there are lots of people out there who know that I've been working quite hard to make sure that repositories are not bound up for any one updater or pkg management tool. -sv From notting at redhat.com Thu Nov 13 21:10:22 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 13 Nov 2003 16:10:22 -0500 Subject: Proposals for the Updates Testing Procedure In-Reply-To: <3FB3373F.3080303@togami.com>; from warren@togami.com on Wed, Nov 12, 2003 at 09:48:15PM -1000 References: <3FB3373F.3080303@togami.com> Message-ID: <20031113161022.C23789@devserv.devel.redhat.com> Warren Togami (warren at togami.com) said: > Along with each announced test update, I believe it would be crucial to > include a link to a corresponding Bugzilla report. While longer > discussions pertaining to packages can remain on fedora-test-list, all > pertinent information should be posted in one place within that test > update's Bugzilla report. Why? > > * Otherwise it is likely that other Bugzilla reports and important > information related to an update could easily be lost in the mailing > list noise. > * All pending updates can easily be found by a single Bugzilla database > query. > * Each report would become a one-stop-shop for information regarding > that update. More responsible sysadmins with proper testing procedures > can read that report to help in their decision to update. That could be useful. > Discussion of the Update Approval Process > ========================================= > We also have not yet discussed the fedora.redhat.com update approval > process. I suggest the following to begin the necessary discussion. > Some of the below are similar in concept to the procedures currently > being used successfully at fedora.us as described in this document: > http://www.fedora.us/wiki/PackageSubmissionQAPolicy Whoa, lots of policy. More than I envisioned, actually. > * Backport Patches v. Upgrade Version > Most libraries, core system and server packages should always have > backport patches. Ah, see, one of the things that was discussed most often is that we'd be rolling forward to new versions of packages to fix problems. Basically, the cases where we wouldn't would be: a) when compatibility is affected b) when it's easier to backport > * Time-limit to publish where no negative comments are posted within the > Bugzilla report. Senior developers reserve the right to hold an update > if a good technical reason can be stated. (Insert more details here.) Sure, say, 2 days. :) > http://www.fedora.us/wiki/QAChecklist > There should be a checklist similar to this one used at fedora.us that > contributors must go through and say "Passes all checklist items." > within their report. This checklist idea has successfully prevented > many common problems from being published in fedora.us. Depending on > the criticalness of the update, the release managers decide when it is > the appropriate time to publish based upon proper & signed contributor > feedback. Most of this is less relevant for updates. For initial inclusion it makes more sense, but changes that would fail this shouldn't be going out in updates, as all of this stuff will have been fixed beforehand. Bill From notting at redhat.com Thu Nov 13 21:13:33 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 13 Nov 2003 16:13:33 -0500 Subject: Proposals for the Updates Testing Procedure In-Reply-To: <3FB3D210.7010402@togami.com>; from warren@togami.com on Thu, Nov 13, 2003 at 08:48:48AM -1000 References: <3FB3373F.3080303@togami.com> <20031113132153.A22474@devserv.devel.redhat.com> <3FB3D210.7010402@togami.com> Message-ID: <20031113161333.D23789@devserv.devel.redhat.com> Warren Togami (warren at togami.com) said: > I'd say that 1-2 months would be a fair time limit for update testing. 1-2 *months*? I'd say weeks, tops. Bill From notting at redhat.com Thu Nov 13 21:17:05 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 13 Nov 2003 16:17:05 -0500 Subject: Fedora updates/errata overview web page In-Reply-To: <3FB3BF6B.8080803@sohanet.de>; from Bernd.Bartmann@sohanet.de on Thu, Nov 13, 2003 at 06:29:15PM +0100 References: <3FB3BF6B.8080803@sohanet.de> Message-ID: <20031113161705.G23789@devserv.devel.redhat.com> Bernd Bartmann (Bernd.Bartmann at sohanet.de) said: > Might I suggest to setup an updates/errata web page for Fedora Core > similar to http://www.redhat.com/apps/support/errata/ and > https://rhn.redhat.com/errata/rh9-errata.html as a central place for > such information. http://fedora.redhat.com/download/updates.html doesn't > show the the announcement texts. Yeah, that's in the plan. Requires some more infrastructure around the updates than what we currently have. Bill From aoliva at redhat.com Thu Nov 13 21:18:48 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 13 Nov 2003 19:18:48 -0200 Subject: Fedora Core 1 Add/Remove Application BUG FIX in method.py In-Reply-To: <1068755703.6282.59.camel@redEmbryo> References: <1068755703.6282.59.camel@redEmbryo> Message-ID: On Nov 13, 2003, caghan ozbek wrote: > i hope you will fix that in the source. There's already an update being tested for it. Enable updates-testing from your up2date sources and up2date -u redhat-config-packages. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From alan at redhat.com Thu Nov 13 21:31:54 2003 From: alan at redhat.com (Alan Cox) Date: Thu, 13 Nov 2003 16:31:54 -0500 (EST) Subject: Kudzu In-Reply-To: from "Karlan Kayne" at Tach 12, 2003 07:51:20 Message-ID: <200311132131.hADLVsB25733@devserv.devel.redhat.com> > I was wondering if someone could help get started in maybe developing for > this project, or would that not be feasible because of the fact I haven't > done asm or device programming(I know c++ very well) Device level stuff and assembler really only appear in the kernel and a few other packages, so if you've done C++ you should be well positioned to play with a lot of stuff - half the desktop is in C++ for example From Nicolas.Mailhot at laPoste.net Thu Nov 13 21:28:14 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 13 Nov 2003 22:28:14 +0100 Subject: Some fedora devel inconsistencies... In-Reply-To: <1068756367.7061.30.camel@opus> References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> <1068753478.5425.67.camel@opus> <1068754866.4291.6.camel@m70.net81-64-235.noos.fr> <1068756367.7061.30.camel@opus> Message-ID: <1068758893.4755.11.camel@m70.net81-64-235.noos.fr> Le jeu 13/11/2003 ? 21:46, seth vidal a ?crit : > > The silly program won't update unrelated stuff like bash & vim just > > because of those errors (ok I'll say it - apt is smarter. I'd return to > > it except all the directory shuffling seems to have killed the apted > > rawhide mirrors I knew of before) > > You're right - if you specify 'yum update' and something fails, it won't > run the update. That's behavior that, to me, protects the user from > stupid stupid shite. Well, on rawhide there is always something broken:( So no update ever ? Say you have an experimental repo in your setup, it only has to break to stop all security updates ? (even on a stupid error like the artwork one ?) > Again, if you don't want to use yum, then don't. I have no problem with > that. I think there are lots of people out there who know that I've been > working quite hard to make sure that repositories are not bound up for > any one updater or pkg management tool. Hey, I know and I respect that. Why do you think I'm spending a lot of *my* time to learn to use yet another update manager ? I knew yum wouldn't like rawhide, but yum is the single free update manager rawhide supports now, so... I don't expect yum to do miracles and update when dependencies are not satisfied. Blocking on unrelated packages dep errors OTOH is a bit excessive IMHO. But again, you are free to disagree:) -- 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 pmatilai at welho.com Thu Nov 13 21:56:21 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 13 Nov 2003 23:56:21 +0200 Subject: Some fedora devel inconsistencies... In-Reply-To: <1068758893.4755.11.camel@m70.net81-64-235.noos.fr> References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> <1068753478.5425.67.camel@opus> <1068754866.4291.6.camel@m70.net81-64-235.noos.fr> <1068756367.7061.30.camel@opus> <1068758893.4755.11.camel@m70.net81-64-235.noos.fr> Message-ID: <1068760581.13556.36.camel@cs148226.pp.htv.fi> On Thu, 2003-11-13 at 23:28, Nicolas Mailhot wrote: > Le jeu 13/11/2003 ? 21:46, seth vidal a ?crit : > > > > The silly program won't update unrelated stuff like bash & vim just > > > because of those errors (ok I'll say it - apt is smarter. I'd return to > > > it except all the directory shuffling seems to have killed the apted > > > rawhide mirrors I knew of before) > > > > You're right - if you specify 'yum update' and something fails, it won't > > run the update. That's behavior that, to me, protects the user from > > stupid stupid shite. > I don't expect yum to do miracles and update when dependencies are not > satisfied. Blocking on unrelated packages dep errors OTOH is a bit > excessive IMHO. OTOH apt occasionally gets pretty wild ideas how to "fix" something when all dependencies aren't met: someone on freshrpms list just complained about apt wanting to remove 330 packages from his system after (obviously partial) upgrade from RHL 7.3 to 9 - that's not particularly productive behavior either :) - Panu - From jakub at redhat.com Thu Nov 13 21:35:17 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 13 Nov 2003 16:35:17 -0500 Subject: Proposals for the Updates Testing Procedure In-Reply-To: <20031113161333.D23789@devserv.devel.redhat.com>; from notting@redhat.com on Thu, Nov 13, 2003 at 04:13:33PM -0500 References: <3FB3373F.3080303@togami.com> <20031113132153.A22474@devserv.devel.redhat.com> <3FB3D210.7010402@togami.com> <20031113161333.D23789@devserv.devel.redhat.com> Message-ID: <20031113163517.K8854@devserv.devel.redhat.com> On Thu, Nov 13, 2003 at 04:13:33PM -0500, Bill Nottingham wrote: > Warren Togami (warren at togami.com) said: > > I'd say that 1-2 months would be a fair time limit for update testing. > > 1-2 *months*? I'd say weeks, tops. Especially for security issues, it should IMHO be days, not weeks. It would be good to know how many people actually tested it though, if there are problems, they will likely show up in bugzilla, but if there are no reports, it is unclear if this is because nobody bothered to test or because it works for everybody. I don't think WWW/FTP/rsync statistics would be much useful, because mirrors will be downloading them and people on the other side could download from mirrors, not from d.f.r.c. Jakub From kdebisschop at alert.infoplease.com Thu Nov 13 22:21:43 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Thu, 13 Nov 2003 17:21:43 -0500 Subject: Proposals for the Updates Testing Procedure In-Reply-To: <20031113163517.K8854@devserv.devel.redhat.com> References: <3FB3373F.3080303@togami.com> <20031113132153.A22474@devserv.devel.redhat.com> <3FB3D210.7010402@togami.com> <20031113161333.D23789@devserv.devel.redhat.com> <20031113163517.K8854@devserv.devel.redhat.com> Message-ID: <1068762103.29398.19.camel@skilletinfopleasecom.nh.pearsoned.com> On Thu, 2003-11-13 at 16:35, Jakub Jelinek wrote: > On Thu, Nov 13, 2003 at 04:13:33PM -0500, Bill Nottingham wrote: > > Warren Togami (warren at togami.com) said: > > > I'd say that 1-2 months would be a fair time limit for update testing. > > > > 1-2 *months*? I'd say weeks, tops. > > Especially for security issues, it should IMHO be days, not weeks. > It would be good to know how many people actually tested it though, > if there are problems, they will likely show up in bugzilla, but > if there are no reports, it is unclear if this is because nobody > bothered to test or because it works for everybody. > I don't think WWW/FTP/rsync statistics would be much useful, because > mirrors will be downloading them and people on the other side could > download from mirrors, not from d.f.r.c. I've been trying to get my head around how testing/approval might work also. I'm not looking forward to the idea that a storm of emails might come on to the list all saying "it worked for me" Maybe there could be a link to a bugzilla "yes" vote in the testing notification. Then, assuming your browser handled the login reasonably well, you could have a one-click way to approve. Problems could be reported via the normal means, I suppose. I actually don't mind seeing real problem reports on the list becuase that blends into discussing the solution. But I quickly tire of "me too's", and I can't imagine anyone would want to have count them either. -- Karl DeBisschop Pearson Education/Information Please From Nicolas.Mailhot at laPoste.net Thu Nov 13 22:27:04 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 13 Nov 2003 23:27:04 +0100 Subject: Some fedora devel inconsistencies... In-Reply-To: <1068760581.13556.36.camel@cs148226.pp.htv.fi> References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> <1068753478.5425.67.camel@opus> <1068754866.4291.6.camel@m70.net81-64-235.noos.fr> <1068756367.7061.30.camel@opus> <1068758893.4755.11.camel@m70.net81-64-235.noos.fr> <1068760581.13556.36.camel@cs148226.pp.htv.fi> Message-ID: <1068762423.3141.3.camel@m70.net81-64-235.noos.fr> Le jeu 13/11/2003 ? 22:56, Panu Matilainen a ?crit : > On Thu, 2003-11-13 at 23:28, Nicolas Mailhot wrote: > > Le jeu 13/11/2003 ? 21:46, seth vidal a ?crit : > > > You're right - if you specify 'yum update' and something fails, it won't > > > run the update. That's behavior that, to me, protects the user from > > > stupid stupid shite. > > I don't expect yum to do miracles and update when dependencies are not > > satisfied. Blocking on unrelated packages dep errors OTOH is a bit > > excessive IMHO. > > OTOH apt occasionally gets pretty wild ideas how to "fix" something when > all dependencies aren't met: someone on freshrpms list just complained > about apt wanting to remove 330 packages from his system after > (obviously partial) upgrade from RHL 7.3 to 9 - that's not particularly > productive behavior either :) In this case I'd have been satisfied with yum just ignoring the packages it couldn't place in its dependency graph:). Not a single package removal needed;) (and yes apt can get wild - but if I understand well, yum will block every single time whereas I know from experience apt is right most of the times) 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 jspaleta at princeton.edu Thu Nov 13 22:38:48 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Thu, 13 Nov 2003 17:38:48 -0500 Subject: Some fedora devel inconsistencies... Message-ID: <1068763127.6053.36.camel@spatula.pppl.gov> Nicolas Mailhot wrote: (and yes apt can get wild - but if I understand well, yum will block every single time whereas I know from experience apt is right most of the times) 90% okay when 10% wrong can eat 330 packages accidently..can not be considered sanely better than 100% wrong, where wrong means you've stopped anything from happening. Its an issue of failure modes...and the risk those failure modes represent to the running system...not to the frustration level of the user. The most dangerous thing to a running system's health is the administrator. Tools that are 10% or 1% of the time going to flip out and want to uninstall large chunks of the system because it found an error are not being respectful of the fact that the person at the wheel might be drunk with power. -jef"stop drop and roll"spaleta From aoliva at redhat.com Thu Nov 13 22:56:22 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 13 Nov 2003 20:56:22 -0200 Subject: Some fedora devel inconsistencies... In-Reply-To: <1068758893.4755.11.camel@m70.net81-64-235.noos.fr> References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> <1068753478.5425.67.camel@opus> <1068754866.4291.6.camel@m70.net81-64-235.noos.fr> <1068756367.7061.30.camel@opus> <1068758893.4755.11.camel@m70.net81-64-235.noos.fr> Message-ID: On Nov 13, 2003, Nicolas Mailhot wrote: > yum is the single free update manager rawhide supports now, so... Err... up2date? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From jkeating at j2solutions.net Thu Nov 13 23:05:29 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 13 Nov 2003 15:05:29 -0800 Subject: Some fedora devel inconsistencies... In-Reply-To: References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> <1068758893.4755.11.camel@m70.net81-64-235.noos.fr> Message-ID: <200311131505.29845.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 13 November 2003 14:56, Alexandre Oliva wrote: > > yum is the single free update manager rawhide supports now, so... > > Err... up2date? I question the need for any tool that will AUTO update you to rawhide. Thats just asking for a broken box. Rawhide packages shouldn't be mass consumed. - -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/tA454v2HLvE71NURAoy7AKCZBiVM88zzbsIDVdaozZIM7fcsWQCgglQw PesN7j/LqRTj+7aZkbZRum0= =WpGk -----END PGP SIGNATURE----- From robert at it4texas.com Thu Nov 13 23:36:09 2003 From: robert at it4texas.com (Robert Trembath) Date: Thu, 13 Nov 2003 17:36:09 -0600 Subject: Problem with Flash plugin to Mozilla Message-ID: <3FB41569.8050405@it4texas.com> Is anyone else seeing this? I cannot get mozilla to see the flash plugin for some reason. I even installed the latest 1.5.1 rpm's from mozilla. Java works fine on both builds but the mplayer plugin works without sound and the flash plugin is installed but mozilla won't see it at all on either mozilla 1.4.1 and 1.5.1. I have Fedora Core 1 installed on a Dell Latitude C840 Intel P4 2.0m 256MB RAM 3com mini-card Wireless and 10/100 20 GB Hard Drive Gnome and KDE produce the same result. I've tried everything I know to fix it and it seems centered around fedora core as I don't have this issue on the same model laptop with RH9. Any ideas? -- _______________________________ Robert Trembath VP - Business & Technical Development e| robert at it4texas.com IT4Texas Houston, TX, USA p| 832.771.9094 From anvil at livna.org Thu Nov 13 23:42:23 2003 From: anvil at livna.org (Dams) Date: Fri, 14 Nov 2003 00:42:23 +0100 Subject: Proposals for the Updates Testing Procedure In-Reply-To: <20031113161333.D23789@devserv.devel.redhat.com> References: <3FB3373F.3080303@togami.com> <20031113132153.A22474@devserv.devel.redhat.com> <3FB3D210.7010402@togami.com> <20031113161333.D23789@devserv.devel.redhat.com> Message-ID: <1068766942.29144.140.camel@gruyere> Agreed. We're talking about 6-9 months long-lifed distro.. months is just to much. 2 weeks *must* be enough. D Le jeu 13/11/2003 ? 22:13, Bill Nottingham a ?crit : > Warren Togami (warren at togami.com) said: > > I'd say that 1-2 months would be a fair time limit for update testing. > 1-2 *months*? I'd say weeks, tops. > Bill -- Dams Nad? Anvil/Anvilou on irc.freenode.net : #Linux-Fr, #Fedora I am looking for a job : http://livna.org/~anvil/cv.php "Dona Nobis Pacem E Dona Eis Requiem". Noir. -------------- 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 lsdr at lsdr.net Fri Nov 14 03:30:28 2003 From: lsdr at lsdr.net (Luiz Rocha) Date: Fri, 14 Nov 2003 01:30:28 -0200 (BRST) Subject: Problem with Flash plugin to Mozilla In-Reply-To: <3FB41569.8050405@it4texas.com> References: <3FB41569.8050405@it4texas.com> Message-ID: <3136.200.100.239.111.1068780628.squirrel@www.lsdr.net> > I've tried everything I know to fix it and it seems centered around > fedora core as I don't have this issue on the same model laptop with > RH9. Any ideas? Try installing the compat-libstdc++ (you can yum it). It worked here in Moz 1.4.1 and 1.5, and Firebird 0.7+. -- Luiz Rocha From Nicolas.Mailhot at laPoste.net Fri Nov 14 08:08:29 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 14 Nov 2003 09:08:29 +0100 Subject: Some fedora devel inconsistencies... In-Reply-To: <200311131505.29845.jkeating@j2solutions.net> References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> <1068758893.4755.11.camel@m70.net81-64-235.noos.fr> <200311131505.29845.jkeating@j2solutions.net> Message-ID: <1068797309.6210.2.camel@m70.net81-64-235.noos.fr> Le ven 14/11/2003 ? 00:05, Jesse Keating a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday 13 November 2003 14:56, Alexandre Oliva wrote: > > > yum is the single free update manager rawhide supports now, so... > > > > Err... up2date? > > I question the need for any tool that will AUTO update you to rawhide. > Thats just asking for a broken box. Rawhide packages shouldn't be mass > consumed. Believe me if you want to test rawhide you need an automated tool. It changes too often and the changes are so inter-dependant one can not handle it manually. I'd rather keep my time to actually identify what's wrong and report it -- Nicolas Mailhot Happy Rawhide tester since the last millenium -------------- 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 pmatilai at welho.com Fri Nov 14 09:04:47 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 14 Nov 2003 11:04:47 +0200 (EET) Subject: Some fedora devel inconsistencies... In-Reply-To: <1068763127.6053.36.camel@spatula.pppl.gov> Message-ID: On Thu, 13 Nov 2003, Jef Spaleta wrote: > Nicolas Mailhot wrote: > (and yes apt can get wild - but if I understand well, yum will block > every single time whereas I know from experience apt is right most of > the times) > > > 90% okay when 10% wrong can eat 330 packages accidently..can not be > considered sanely better than 100% wrong, where wrong means you've > stopped anything from happening. > > Its an issue of failure modes...and the risk those failure modes > represent to the running system...not to the frustration level of the > user. The most dangerous thing to a running system's health is the > administrator. Tools that are 10% or 1% of the time going to flip out > and want to uninstall large chunks of the system because it found an > error are not being respectful of the fact that the person at the wheel > might be drunk with power. Apt does warn you if it wants to remove like 330 packages - you'll get a prompt like "You are about to do something potentially harmful. To continue type in the phrase ..." If at that point there are no bells ringing in your head .. well, I dunno :) However that works much more reliably in Debian where the packages themselves carry a priority, eg "this must never be removed" vs "this is just a silly optional screensaver, feel free to toss out" whereas on rpm-systems it needs to rely on a manually crafted rpmpriorities file, if any. Actually.. (hear a bell ringing.. looking up source...) you can easily enable yum-like safe-mode on apt as well: just specify "APT::Get::Remove=false" in apt.conf or as command line option and it'll stop right there if an operation would remove something. - Panu - From pmatilai at welho.com Fri Nov 14 09:06:36 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 14 Nov 2003 11:06:36 +0200 (EET) Subject: Some fedora devel inconsistencies... In-Reply-To: Message-ID: On Fri, 14 Nov 2003, Panu Matilainen wrote: > > Actually.. (hear a bell ringing.. looking up source...) you can easily > enable yum-like safe-mode on apt as well: just specify > "APT::Get::Remove=false" in apt.conf or as command line option and it'll > stop right there if an operation would remove something. In fact .. APT::Get::Remove=false in apt.conf or --no-remove on command line. - Panu - From Nicolas.Mailhot at laPoste.net Fri Nov 14 09:29:58 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 14 Nov 2003 10:29:58 +0100 Subject: Some fedora devel inconsistencies... In-Reply-To: References: Message-ID: <1068802198.4754.1.camel@ulysse.olympe.o2t> Le ven 14/11/2003 ? 10:06, Panu Matilainen a ?crit : > On Fri, 14 Nov 2003, Panu Matilainen wrote: > > > > Actually.. (hear a bell ringing.. looking up source...) you can easily > > enable yum-like safe-mode on apt as well: just specify > > "APT::Get::Remove=false" in apt.conf or as command line option and it'll > > stop right there if an operation would remove something. > > In fact .. APT::Get::Remove=false in apt.conf or --no-remove on command > line. Yum is worse than this. It will block if an unrelated dep is not satisfied - with --no-remove apt will block only if all the updates require a removal (I think - didn't test it) 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 lfarkas at bnap.hu Fri Nov 14 09:38:25 2003 From: lfarkas at bnap.hu (Farkas Levente) Date: Fri, 14 Nov 2003 10:38:25 +0100 Subject: php in fedora development Message-ID: <3FB4A291.7050108@bnap.hu> hi, could you add to the defualt php package the mhash and mcrypt support? it doesn't hurt anything sincs it's just and addition to the configure: --with-mcrypt=shared \ --with-mhash=shared \ plus you should create two more packages php-mcrypt and php-mhash this woule help for many people includein hore and lam users who wouldn't have to rebuild php packages all the time just for these modules. thanks. -- Levente "Si vis pacem para bellum!" From pmatilai at welho.com Fri Nov 14 10:18:26 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 14 Nov 2003 12:18:26 +0200 (EET) Subject: Some fedora devel inconsistencies... In-Reply-To: <1068802198.4754.1.camel@ulysse.olympe.o2t> Message-ID: On Fri, 14 Nov 2003, Nicolas Mailhot wrote: > Le ven 14/11/2003 ? 10:06, Panu Matilainen a ?crit : > > On Fri, 14 Nov 2003, Panu Matilainen wrote: > > > > > > Actually.. (hear a bell ringing.. looking up source...) you can easily > > > enable yum-like safe-mode on apt as well: just specify > > > "APT::Get::Remove=false" in apt.conf or as command line option and it'll > > > stop right there if an operation would remove something. > > > > In fact .. APT::Get::Remove=false in apt.conf or --no-remove on command > > line. > > Yum is worse than this. > It will block if an unrelated dep is not satisfied - with --no-remove > apt will block only if all the updates require a removal (I think - > didn't test it) Heh.. I think this is actually pretty amusing: apt will refuse to do anything if you have unrelated unsatisfied dep in your rpmdb (one of the top three complaints about apt and I agree there should be a switch to turn that off temporarily) but doesn't care about unsatisfied unrelated deps in repositories, with yum the situation is exactly the opposite :) - Panu - From buildsys at porkchop.devel.redhat.com Fri Nov 14 11:05:29 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Fri, 14 Nov 2003 06:05:29 -0500 Subject: rawhide report: 20031114 changes Message-ID: <200311141105.hAEB5Tk17312@porkchop.devel.redhat.com> Removed package yaboot Updated Packages: quagga-0.96.4-0 --------------- * Mon Nov 03 2003 Jay Fenlason 0.96.4-0 - New upstream version - include .h files in the -devel package. redhat-artwork-0.88-2 --------------------- * Thu Nov 13 2003 Than Ngo 0.88-2 - fix to build with qt 3.2.2 * Wed Oct 29 2003 Than Ngo 0.87-2 - rebuild with qt 3.2.2 - cleanup KDE Bluecurve Icon Theme * Tue Oct 28 2003 Owen Taylor 0.87-1 - New version with fixed gtk-2.0/iconrc file, symlinks instead of copies for icon aliases * Tue Oct 28 2003 Alexander Larsson 0.86-1 - Add Bluecurve-classic metacity theme - Add missing KDE icons - Add BerriesAndCream Gtk+ theme color * Wed Oct 22 2003 Bill Nottingham 0.85-2 - spec file tweaks * Wed Oct 15 2003 Alexander Larsson 0.85-1 - fix icons in gtk theme * Thu Oct 09 2003 Jonathan Blandford 0.84-1 - new greeter theme * Thu Oct 09 2003 Alexander Larsson 0.83-1 - added missing translations * Wed Oct 08 2003 Alexander Larsson 0.82-1 - Icon fixes * Thu Aug 28 2003 Alexander Larsson 0.81-1 - kwin fix - metacity theme changes - small menu icons again * Wed Aug 20 2003 Alexander Larsson 0.80-1 - kwin fix * Mon Aug 18 2003 Alexander Larsson 0.79-1 - fix qt theme and kwin theme * Fri Aug 08 2003 Alexander Larsson 0.78-1 - Fix gtk2 theme crash (#100507) - Add buildrequires (#90530, #83161) - Fix ogg static (#100918) - Add gtk theme color schemes (#81316) * Thu Jul 17 2003 Havoc Pennington 0.77-1 - 0.77 * Thu Jul 10 2003 Havoc Pennington 0.75-1 - 0.76 * Wed Jul 09 2003 Havoc Pennington 0.75-1 - 0.75 * Mon Jul 07 2003 Alexander Larsson 0.74-1 - 0.74, gtk+ theme optimization * Wed Jun 04 2003 Elliot Lee - rebuilt * Tue Jun 03 2003 Jeff Johnson - add explicit epoch's where needed. * Wed Feb 26 2003 Havoc Pennington 0.73-1 - 0.73 fixes 800x600 and theme thumbnail * Mon Feb 24 2003 Havoc Pennington 0.72-1 - 0.72 with new music * Mon Feb 24 2003 Havoc Pennington 0.71-1 - 0.71 tweaks * Mon Feb 24 2003 Havoc Pennington 0.70-1 - 0.70 hopefully closes the last few blockers and doesn't break anything... * Fri Feb 21 2003 Jonathan Blandford 0.69-1 - 0.69 fixes cursors and adds animated watch glass * Tue Feb 18 2003 Havoc Pennington 0.68-1 - 0.68 moves an image to redhat-logos * Mon Feb 17 2003 Havoc Pennington 0.67-1 - 0.67 * Sat Feb 15 2003 Than Ngo 0.66-1 - 0.66, fix several qt theme problems * Wed Feb 12 2003 Alexander Larsson 0.65-1 - 0.65, than fixed kde icon theme * Fri Feb 07 2003 Jonathan Blandford 0.64-1 - new version. New cursors * Thu Jan 30 2003 Alexander Larsson - 0.63, Qt theme updated * Mon Jan 27 2003 Havoc Pennington - 0.62 * Wed Jan 22 2003 Tim Powers - rebuilt * Tue Jan 21 2003 Havoc Pennington - 0.61, we needed to set LANG while making the distribution * Tue Jan 21 2003 Havoc Pennington - set LANG to an ISO-8859-1 locale so intltool won't get confused * Fri Jan 17 2003 Havoc Pennington - 0.60 with the cursors * Tue Jan 14 2003 Havoc Pennington - 0.59 * Fri Jan 10 2003 Havoc Pennington - 0.57 with stock icons - 0.58 with stock icons really * Thu Jan 09 2003 Alexander Larsson - 0.56 * Thu Jan 09 2003 Alexander Larsson - 0.55 * Wed Jan 08 2003 Havoc Pennington - 0.54 * Sat Jan 04 2003 Jeff Johnson 0.53-2 - use internal dep generator. * Fri Dec 20 2002 Than Ngo 0.53-1 - 0.53 * Wed Dec 18 2002 Than Ngo 0.50-1 - fix a bug in kwin plugin, crash on clicking menu button * Tue Dec 17 2002 Tim Powers 0.49-4 - rebuild - don't use rpm's internal dep gen * Mon Dec 09 2002 Tim Powers 0.49-3 - rebuild * Wed Dec 04 2002 Tim Powers 0.49-2 - rebuild * Tue Nov 19 2002 Than Ngo - 0.49, add search path for plugins, fix conflict with qt 3.1.0 * Tue Nov 12 2002 Havoc Pennington - install to qt-3.0.5 as temporary workaround * Fri Nov 08 2002 Jeremy Katz - rebuild for new gtk2 engine paths * Thu Sep 05 2002 Havoc Pennington - 0.47 with gdm translations restored * Thu Sep 05 2002 Havoc Pennington - 0.46 * Tue Sep 03 2002 Havoc Pennington - 0.45 (updates some icons, COPYING) * Tue Sep 03 2002 Havoc Pennington - 0.44 * Tue Sep 03 2002 Than Ngo - 0.42 with some new icons and XIMInputStyle fix for Qt * Fri Aug 30 2002 Havoc Pennington - 0.41 with new kwin, new logout/exit/etc. icons * Fri Aug 30 2002 Havoc Pennington - 0.40 with lots of new icons, splash, etc. * Mon Aug 19 2002 Havoc Pennington - 0.38 with new icons * Fri Aug 16 2002 Owen Taylor - 0.37, with UTF-8 fixes for bluecurve.xml * Fri Aug 16 2002 Havoc Pennington - 0.35 with more icons * Wed Aug 14 2002 Havoc Pennington - 0.33 with KDE trash and menu icon * Wed Aug 14 2002 Havoc Pennington - put missing icons in Makefile * Wed Aug 14 2002 Alexander Larsson - 0.31, greeter theme fixes, gtk+ fixes, icon changes * Tue Aug 13 2002 Alexander Larsson - 0.30, Fixed bad gkt+ theme memory and pixmap leak * Mon Aug 12 2002 Havoc Pennington - 0.29 with fixed gdm theme * Mon Aug 12 2002 Havoc Pennington - 0.28 with new gdm stuff and icons and so forth * Fri Aug 09 2002 Havoc Pennington - 0.26 with Bluecurve name - 0.27 with Bluecurve name (fixed) * Wed Aug 07 2002 Havoc Pennington - 0.24 with nautilus theme, placeholders for some app icons - 0.25 with aliases for home icon (bug 67791) and some new icons * Tue Aug 06 2002 Havoc Pennington - 0.23 move metacity themes * Sat Aug 03 2002 Havoc Pennington - 0.22 xmms theme * Thu Aug 01 2002 Havoc Pennington - 0.21 move ksplash stuff to right place - add QTDIR hack * Wed Jul 31 2002 Havoc Pennington - 0.20 * Tue Jul 23 2002 Havoc Pennington - 0.19, some assorted fixes from people * Fri Jul 19 2002 Alexander Larsson 0.17-1 - 0.17 moved gtkrc inside tarball. conflict with gtk-engines < 0.11-13 - Install default gtkrc files for gtk1 and gtk2 * Fri Jul 19 2002 Alexander Larsson 0.16-1 - Bump version. Has new gtk1 theme fixes. * Wed Jul 17 2002 Owen Taylor - Bump version number, tag, do a formal distcheck * Tue Jul 16 2002 Than Ngo 0.14-3 - don't remove qtrc - added conflict with qt < 3.0.4-11 * Tue Jul 16 2002 Havoc Pennington - adjust file list again, we want to err on the side of owning more directories. It doesn't hurt anything to do so, and you may install this package without installing kde or metacity first. There's no prereqs on those. Owning more dirs means we don't get orphaned directories. * Tue Jul 16 2002 Alexander Larsson 0.14-1 - New gtk+ theme changes * Tue Jul 16 2002 Than Ngo 0.13-1 - 0.13 - add qt resource into redhat-artwork * Wed Jul 03 2002 Than Ngo 0.12-1 - more fixes to qt theme - Wonderland kwin theme - fixup specfile * Mon Jul 01 2002 Than Ngo 0.11-1 - more fixes to qt theme - added Wonderland colorscheme for KDE * Fri Jun 28 2002 Alex Larsson - contractor - New version 0.10, further fixes to the gtk+ theme * Thu Jun 27 2002 Owen Taylor - Remove backwards-compat patch so it works with the current metacity in the tree * Tue Jun 25 2002 Owen Taylor - New version including GDM placeholder theme * Wed Jun 19 2002 Havoc Pennington - 0.7 * Mon Jun 17 2002 Havoc Pennington - remove empty AUTHORS and COPYING files * Thu Jun 13 2002 Havoc Pennington - rebuild in different environment * Thu Jun 13 2002 Havoc Pennington - prereq /usr/lib/qt3 * Thu Jun 13 2002 Havoc Pennington - autoreq 0 to avoid pointless dependencies - own directories again except not the qt3 symlink * Thu Jun 13 2002 Bernhard Rosenkraenzer 0.6-2 - tidy up URL, source list - don't include qtrc for now - don't own so many directories * Wed Jun 12 2002 Havoc Pennington - rebuild in different environment * Wed Jun 12 2002 Havoc Pennington - 0.6, with Qt theme * Tue Jun 11 2002 Havoc Pennington - rebuild in different environment * Tue Jun 11 2002 Havoc Pennington - 0.5 * Mon Jun 10 2002 Havoc Pennington - rebuild in different environment * Mon Jun 10 2002 Havoc Pennington - 0.4 - fix group * Mon Jun 03 2002 Havoc Pennington - fix gtkrc * Mon Jun 03 2002 Havoc Pennington - rebuild in different environment * Mon Jun 03 2002 Havoc Pennington - build requires gtk2-devel - include a gtkrc to set default theme to Wonderland * Mon Jun 03 2002 Havoc Pennington - rebuild in different environment * Mon Jun 03 2002 Havoc Pennington - 0.3 - no longer noarch * Thu May 23 2002 Tim Powers - automated rebuild * Fri May 10 2002 Havoc Pennington - rebuild in different environment * Fri May 10 2002 Havoc Pennington - fix gtk theme location * Fri May 10 2002 Havoc Pennington - rebuild in different environment * Thu May 09 2002 Havoc Pennington - initial build redhat-config-printer-0.6.81-1 ------------------------------ * Thu Nov 13 2003 Tim Waugh 0.6.81-1 - 0.6.81: - More sharing fixes (bug #109942). reiserfs-utils-3.6.11-1 ----------------------- * Thu Aug 28 2003 Florian La Roche - update to 3.6.11 rpmdb-fedora-1-0.20031114 ------------------------- strace-4.5.1-1 -------------- * Thu Nov 13 2003 Roland McGrath 4.5.1-1 - new upstream version, more fixes (#108012, #105366, #105359, #105358) * Tue Sep 30 2003 Roland McGrath 4.5-3 - revert bogus s390 fix * Thu Sep 25 2003 Roland McGrath 4.5-1.2.1AS - rebuilt for 2.1AS erratum * Wed Sep 24 2003 Roland McGrath 4.5-2 - rebuilt subversion-0.32.1-3 ------------------- * Thu Nov 13 2003 Joe Orton 0.32.1-3 - remove workarounds for #109268 and #109267 vim-6.2.154-1 ------------- * Thu Nov 13 2003 Karsten Hopp 1:6.2.154-1 - Patchlevel 154 - vim-minimal doesn't really require vim-common to run, removed dependency (#109819) xinetd-2.3.12-5 --------------- * Wed Nov 12 2003 Jay Fenlason 2.3.12-3 - build in HEAD for pre FC-2 - merge from xinetd-3E-branch to fix bugzilla #103009 also includes: New upstream version, which obsoletes most of my patches Remove /usr/share/man/man8/xconv.pl* fixing #90730 Remove the servers service, which was removed from 2.3.12 Change localization: instead of using en_US in /etc/rc.d/init.d/xinetd (overriding the system default and preventing any customization), /etc/sysconfig/xinetd sets XINETD_LANG, which is either a locale to use or the word "none", which causes all locale environment variables to be cleared before xinetd is started. This fixes #91403 include post 2.3.12 patch from upstream (originally by Matthias Andree ) to add a new "libwrap" parameter. This closes bugs (#91555,#91135,#77724) by making xinetd's behavior documented and user-configurable. Removed the old libwrap/TCP/wait patch. If anyone actually cares, they can add "flags = NOLIBWRAP" to the configuration of TCP/wait services to get the old behavior. Mark /etc/sysconfig/xinetd as a config file in xinetd.spec Add pie support * Tue Sep 23 2003 Florian La Roche - allow compiling without tcp_wrappers * Wed Jun 04 2003 Elliot Lee - rebuilt * Mon Feb 24 2003 Elliot Lee - rebuilt * Fri Feb 21 2003 Jay Fenlason 2.3.10-5 - Merge various patches from xinetd-CVS, since 2.3.11 won't be out in time for our Red Hat Linux release. One improves range checking on file descriptors. (A potential security problem.) Another fixes bugzilla #84840: tcpmux doesn't work at all. A third improves error checking on tcpmux service entries. The last improves error checking on service startup. * Tue Feb 11 2003 Nalin Dahyabhai 2.3.10-4 - rebuild * Mon Feb 10 2003 Nalin Dahyabhai 2.3.10-3 - rebuild * Wed Jan 22 2003 Tim Powers - rebuilt * Tue Jan 07 2003 Jay Fenlason 2.3.10-1 - Fix #81770, #80612, #79219, #79274: New upstream version - May also fix #79085, #78903, #78699, #77781, #77760, #76727 - ... #73805, #60049, #58881, #58855 - Fix #79999: remove xinetd-ipv6 executable - Fix #82021: changed preun to turn off the server - try to Fix #74198 by quoting "${NETWORKING}" in xinetd.init * Tue Dec 10 2002 Dan Walsh 2.3.7-6 - Fix Service startup script to check for id=0 * Tue Nov 19 2002 Bill Nottingham 2.3.7-5 - add new stream_wait patch (#74696) * Wed Nov 13 2002 Dan Walsh 2.3.7-4 - Fix Service Descriptions * Wed Nov 13 2002 Dan Walsh 2.3.7-3 - Fix #77710 Fix Service Descriptions * Thu Aug 15 2002 Trond Eivind Glomsr?d 2.3.7-2 - Fix #71506 (mixed internal services) * Mon Aug 12 2002 Trond Eivind Glomsr?d 2.3.7-1 - 2.3.7 - this fixes #70504 * Mon Aug 05 2002 Trond Eivind Glomsr?d 2.3.5-6 - Initscript fixes (#70730) * Wed Jul 17 2002 Trond Eivind Glomsr?d 2.3.5-5 - Add patch for improved cross compiling (#55927) * Wed Jul 03 2002 Trond Eivind Glomsr?d 2.3.5-4 - #67701 * Wed Jun 26 2002 Trond Eivind Glomsr?d 2.3.5=3 - Fix maks for access control (#65743) - some fixes for config file parsing * Fri Jun 21 2002 Tim Powers - automated rebuild * Thu May 30 2002 Trond Eivind Glomsr?d 2.3.5-1 - 2.3.5 * Thu May 23 2002 Tim Powers - automated rebuild * Mon Apr 22 2002 Trond Eivind Glomsr?d - 2.3.4 final (bah, never announced... has been out for 3 weeks) * Thu Apr 04 2002 Trond Eivind Glomsr?d 2.3.4-0.8 - Add a patch to avoid fam haunting the system * Tue Apr 02 2002 Trond Eivind Glomsr?d 2.3.4-0.7 - Add patch from Alex Larson in order not to use tcp_wrappers on tcp/wait - they'd always be 0.0.0.0 * Thu Mar 28 2002 Trond Eivind Glomsr?d 2.3.4-0.6 - 2002-03-26. 2.3.4 final RSN * Fri Mar 01 2002 Trond Eivind Glomsr?d 2.3.4-0.5 - 2002-02-28-1 * Sun Jan 06 2002 Trond Eivind Glomsr?d 2.3.4-0.4 - 2002-01-04 - Update URLs * Fri Dec 14 2001 Trond Eivind Glomsr?d 2.3.4-0.3 - 2001-12-13 * Mon Dec 03 2001 Trond Eivind Glomsr?d 2.3.4-0.2 - 2001-12-03 (fixes #57001, #55738) * Fri Nov 30 2001 Trond Eivind Glomsr?d 2.3.4-0.1 - 2001-11-29, which fixes #56487 - Add configuration files for the xinetd internal services listing current servers and services. It's off by default, and restricted to localhost when enabled (#52707) - Use SIGHUP for configuration reload (change in program) * Wed Aug 29 2001 Trond Eivind Glomsr?d 2.3.3-1 - 2.3.3 - parser patch now obsolete * Thu Aug 23 2001 Trond Eivind Glomsr?d 2.3.2-1 - 2.3.2, which contains the memory overwrite patch, the audit fixes, the conn_free patch and the filelog patch. - Fix handling of rpc_version with ranges (like "1-2") (#51737) * Wed Aug 15 2001 Trond Eivind Glomsr?d 2.3.0-7 - Don't apply the skipjunk patch anymore - xinetd now skips files with ".", which include .rpmsave etc. - fix memory overwrite bug in env.c:grow() * Mon Aug 13 2001 Trond Eivind Glomsr?d 2.3.0-6 - conn_free was called twice... - add cps = 25 30 to xinetd.conf. Thus, if a service has many connections (25 in a 1 second period), it will be disabled for 30 seconds. Without this, 10 connections to a service in a second would permanently disable the service (#49122) * Thu Aug 09 2001 Trond Eivind Glomsr?d 2.3.0-5 - add the patch from "Solar Designer"'s audit * Thu Aug 09 2001 Trond Eivind Glomsr?d 2.3.0-4 - Make it handle stop and status when IPv6 is enabled (#49621) * Mon Jul 23 2001 Trond Eivind Glomsr?d - Add IPv6 support - separate binary, invoked if NETWORKING_IPV6 is set (#49621) - Make inetdconvert handle the "/usr/sbin/in.telnetd in.telnetd" scenario of inetd (#46449) * Tue Jul 03 2001 Trond Eivind Glomsr?d - redo skipjunkfile patch * Fri Jun 29 2001 Trond Eivind Glomsr?d - 2.3.0 * Thu Jun 21 2001 Trond Eivind Glomsr?d - 2.1.8.9pre16 * Mon Jun 04 2001 Trond Eivind Glomsr?d - Remove explicit dependancy on initscripts version * Sun May 20 2001 Trond Eivind Glomsr?d - 2.1.8.9pre15, which should fix wait=yes with tcp (linuxconf is the only program I know of using this) - fix some problems with UDP internal services (#38669) - make /etc/xinetd.conf noreplace * Wed Apr 25 2001 Trond Eivind Glomsr?d - Add the tcp wait=yes patch from the xinetd version in a different tree * Wed Apr 04 2001 Trond Eivind Glomsr?d - Add /etc/sysconfig/xinetd so users can add extra options (#34321) * Tue Feb 27 2001 Preston Brown - noreplace the xinetd.d files * Mon Feb 05 2001 Preston Brown - built against newer tcp_wrappers that fixes name resolution problem (#16949) * Mon Feb 05 2001 Trond Eivind Glomsr?d - Patch from nalin at redhat.com for terminating the environment variables properly * Tue Jan 30 2001 Trond Eivind Glomsr?d - remove PID from log_on_failure flags (#22687) * Tue Jan 23 2001 Trond Eivind Glomsr?d - improve gettextization - add "UNLISTED" to the internal udp services (#24279) * Thu Jan 18 2001 Trond Eivind Glomsr?d - 2.1.8.9pre14 * Wed Jan 17 2001 Trond Eivind Glomsr?d - gettextize * Sat Dec 30 2000 Jeff Johnson - remove python dependency. * Tue Dec 26 2000 Trond Eivind Glomsr?d - remove RECORD from xinetd.conf for security reasons (no known holes, but better safe than sorry #22687) * Mon Dec 04 2000 Trond Eivind Glomsr?d - unset a couple of environment variables(HOME,MAIL) in the initscript. This should avoid problems like bug #21663 * Fri Dec 01 2000 Trond Eivind Glomsr?d - rebuild * Tue Nov 14 2000 Trond Eivind Glomsr?d - 2.1.8.9pre13, which should fix #19355 - changes to initscript - set all locale environment variables to en_US, as the server doesn't know what locale the client expects and error messages can otherwise be confusing (partially #20566) * Thu Nov 09 2000 Trond Eivind Glomsr?d - fix mismatch in documentation vs. reality, introduced when we changed the behaviour of the access control to use server names (#20567) * Tue Oct 31 2000 Trond Eivind Glomsr?d - obsolete netkit-base, which was inetd's home until 6.2 * Thu Oct 19 2000 Trond Eivind Glomsr?d - 2.1.8.9pre12, which has a new "-stayalive" option so xinetd stays alive even if no services are enabled. - use the above in the initscript (#18819) * Tue Oct 17 2000 Trond Eivind Glomsr?d - 2.1.8.9pre11, which includes the previous bugfixes. - don't convert the internal services, include such files with xinetd (#17331, #18899) * Mon Oct 09 2000 Trond Eivind Glomsr?d - Add patch to fix segfault problem (#18686) * Fri Oct 06 2000 Trond Eivind Glomsr?d - apply patch from nalin at redhat.com for handling tcp connections with wait=yes properly * Tue Sep 26 2000 Trond Eivind Glomsr?d - add explicit dependency on a modern version of initscripts (#17533) * Wed Aug 30 2000 Trond Eivind Glomsr?d - 2.1.8.9pre10 - remove tcpwrapper and pidfile patches, as they are now in. - change default startup position to 56, so it starts after bind (#17047) * Fri Aug 18 2000 Trond Eivind Glomsr?d - use the server name not the service name for libwrap checking (#16516). The new way was better, but this is sacrificed so old systems will continue to work and the documentation for tcp_wrappers can be correct. * Wed Aug 16 2000 Than Ngo - fix initscript, test network file before source it (Bug #16247) * Tue Aug 15 2000 Trond Eivind Glomsr?d - added support for "-pidfile" option (#15531) * Fri Aug 04 2000 Trond Eivind Glomsr?d - added patch to ignore .rpmsave, .rpmorig, .rpmnew, ~ suffixed files (#15304) * Thu Aug 03 2000 Trond Eivind Glomsr?d - 2.1.8.9pre9, old patches are now integrated. * Wed Aug 02 2000 Trond Eivind Glomsr?d - fix converting of "wait" argument (#13884) - remove tcpd and /usr/sbin/tcpd from inetd.conf services before converting - xinetd is linked against tcp_wrappers * Mon Jul 31 2000 Trond Eivind Glomsr?d - fix linuxconf restart problem (#14856) - fix conditional restart - mark /etc/xinetd.conf as a configuration file * Tue Jul 25 2000 Bill Nottingham - um, we *need* to prereq /etc/init.d * Mon Jul 24 2000 Bernhard Rosenkraenzer - Don't require /etc/init.d * Sat Jul 22 2000 Bill Nottingham - rebuild * Tue Jul 18 2000 Trond Eivind Glomsr?d - fix the sections of the man pages (#14244) * Tue Jul 18 2000 Trond Eivind Glomsr?d - remove itox, as it wouldn't do the right thing with our configuration - same with xconv.pl - some changes to the installation process * Mon Jul 17 2000 Trond Eivind Glomsr?d - move initscript back to /etc/rc.d/init.d * Fri Jul 14 2000 Trond Eivind Glomsr?d - change process name in init file * Thu Jul 13 2000 Prospector - automatic rebuild * Fri Jul 07 2000 Nalin Dahyabhai - start the daemon with the "-reuse" flag * Thu Jul 06 2000 Trond Eivind Glomsr?d - "Prereq:", not "Requires:" for /etc/init.d * Thu Jul 06 2000 Trond Eivind Glomsr?d - require /etc/init.d * Wed Jul 05 2000 Florian La Roche - upper the number of instances to 60 * Sun Jul 02 2000 Nalin Dahyabhai - fix a memory-allocation bug * Wed Jun 28 2000 Trond Eivind Glomsr?d - 2.1.8.9pre8 * Wed Jun 21 2000 Trond Eivind Glomsr?d - moved to /etc/init.d * Wed Jun 21 2000 Trond Eivind Glomsr?d - changed specfile and initfile to implement conditional restart * Sun Jun 18 2000 Trond Eivind Glomsr?d - 2.1.8.9pre7 - now obsoletes inetd - use %{_tmppath} * Sun Jun 04 2000 Trond Eivind Glomsr?d - 2.1.8.9pre6 - added converter script which can convert specified or remaing uncoverted services - use %{_mandir} - removed +x on xinetd.conf * Wed May 24 2000 Trond Eivind Glomsr?d - 2.1.8.9pre4 - authpriv patch no longer needed * Tue May 23 2000 Trond Eivind Glomsr?d - /etc/xinetd.d is now part of the filesystem package - more fixes to xinetd.init * Mon May 22 2000 Trond Eivind Glomsr?d - fixed some obvious bugs in xinetd.init - added a default xinetd.conf - patched xinetd to understand LOG_AUTHPRIV * Fri May 19 2000 Trond Eivind Glomsr?d - updated version - removed a define %ver (we already have 2.3.12) - removed some extra CFLAGS declarations - added configuration directory, /etc/xinetd.d * Mon Feb 21 2000 Tim Powers - fixed broken postun sections, should have been *preun* - fixed broken gzip of manpages * Wed Jan 19 2000 Bernhard Rosenkraenzer - 2.1.8.8p8 - Fix the init script (Bug #7277) - remove our patches (no longer required) * Tue Sep 21 1999 Bill Nottingham - add -lnsl * Tue Sep 07 1999 Tim Powers - modification top install routine * Mon Jul 26 1999 Tim Powers - updated source to 2.1.8.6b6 - built for 6.1 * Mon Apr 26 1999 Bill Nottingham - update to 2.1.8.6b5 - build for PowerTools * Sun Jan 10 1999 Bill Nottingham - update to 2.1.8.5p2 * Tue Dec 01 1998 Bill Nottingham - intial build From chabotc at 4-ice.com Fri Nov 14 12:31:58 2003 From: chabotc at 4-ice.com (Chris Chabot) Date: Fri, 14 Nov 2003 13:31:58 +0100 Subject: php in fedora development References: <3FB4A291.7050108@bnap.hu> Message-ID: <007501c3aaab$4bcd2150$0200a8c0@gandalf> Both the mhash and mcrypt modules for PHP require those libraries, so it's not just a configure switch.. Since those libs are not included in the fedora core (that i know off), it would mean including those too. Did you ever consider using the openssl checksum & crypto functionality? Anyways, just pointing out it's not as cut-dry-and-simple as you made it sound ----- Original Message ----- From: "Farkas Levente" To: "Joe Orton" ; Sent: Friday, November 14, 2003 10:38 Subject: php in fedora development > hi, > could you add to the defualt php package the mhash and mcrypt support? > it doesn't hurt anything sincs it's just and addition to the configure: > --with-mcrypt=shared \ > --with-mhash=shared \ > plus you should create two more packages > php-mcrypt and php-mhash > this woule help for many people includein hore and lam users who > wouldn't have to rebuild php packages all the time just for these modules. > thanks. > > -- > Levente "Si vis pacem para bellum!" > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From aoliva at redhat.com Fri Nov 14 13:03:18 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 14 Nov 2003 11:03:18 -0200 Subject: Some fedora devel inconsistencies... In-Reply-To: <200311131505.29845.jkeating@j2solutions.net> References: <1068752764.3868.1.camel@m70.net81-64-235.noos.fr> <1068758893.4755.11.camel@m70.net81-64-235.noos.fr> <200311131505.29845.jkeating@j2solutions.net> Message-ID: On Nov 13, 2003, Jesse Keating wrote: > On Thursday 13 November 2003 14:56, Alexandre Oliva wrote: >> > yum is the single free update manager rawhide supports now, so... >> >> Err... up2date? > I question the need for any tool that will AUTO update you to rawhide. Who talked about AUTO updating? up2date, just like yum and apt, will only run when you tell it to, unless you're using RHN and rhnsd is running, which is not the case for FC. up2date, just like yum and apt, will only use repositories you've configured it to use, and rawhide isn't the default in any of them. So, if you chose rawhide, and run up2date by hand, that's what you get. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From efocht at hpce.nec.com Fri Nov 14 09:41:59 2003 From: efocht at hpce.nec.com (Erich Focht) Date: Fri, 14 Nov 2003 10:41:59 +0100 Subject: ia64 kernel? Message-ID: <200311141041.59591.efocht@hpce.nec.com> Hi, does anybody care currently about the ia64 kernel? Why is the version so old (2.4.9)? I could contribute from time to time but who is managing this and what is the policy (features to include, testing, etc...). And: how can I build an installation DVD out of the base/ and RPMS/ directories? Thanks. Best regards, Erich Focht From rayers.list at rdasys.net Fri Nov 14 15:57:03 2003 From: rayers.list at rdasys.net (Ryan Ayers) Date: Fri, 14 Nov 2003 09:57:03 -0600 Subject: service mysqld start fails Message-ID: <1068825423.15084.32.camel@camserv.dividia.net> Upon fresh installation of FC1. service mysqld start returns a failure status when a root password is supplied. This is because in the file /etc/init.d/mysqld /usr/bin/mysqladmin ping fails when a root password is set. Is this what should happen ... or is there a better way to determine if mysql has been successfully started? Ryan From johnsonm at redhat.com Fri Nov 14 16:03:14 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 14 Nov 2003 11:03:14 -0500 Subject: ia64 kernel? In-Reply-To: <200311141041.59591.efocht@hpce.nec.com>; from efocht@hpce.nec.com on Fri, Nov 14, 2003 at 10:41:59AM +0100 References: <200311141041.59591.efocht@hpce.nec.com> Message-ID: <20031114110314.A10230@devserv.devel.redhat.com> On Fri, Nov 14, 2003 at 10:41:59AM +0100, Erich Focht wrote: > does anybody care currently about the ia64 kernel? Why is the version > so old (2.4.9)? I could contribute from time to time but who is > managing this and what is the policy (features to include, testing, > etc...). Which ia64 kernel are you talking about, precisely? We haven't put any work into an ia64 kernel for Fedora. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From 64bit_fedora at comcast.net Fri Nov 14 16:06:01 2003 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Fri, 14 Nov 2003 10:06:01 -0600 (CST) Subject: ia64 kernel? In-Reply-To: <200311141041.59591.efocht@hpce.nec.com> Message-ID: On Fri, 14 Nov 2003, Erich Focht wrote: > does anybody care currently about the ia64 kernel? Why is the version > so old (2.4.9)? I could contribute from time to time but who is > managing this and what is the policy (features to include, testing, > etc...). > Honestly, Itanium is not out there in large numbers, and most existing installations would not be Fedora candidates anyway, more suitable for RHEL. That said, if you are willing to do the work, I would test it on some test servers I have, as long as I have them. Grab the FC1 kernel SRPM and go from there. > And: how can I build an installation DVD out of the base/ and RPMS/ > directories? > > Thanks. > > Best regards, > Erich Focht > buildinstall and mkisofs will get your dvd iso made. Justin M. Forbes From alexander.dalloz at uni-bielefeld.de Fri Nov 14 16:19:56 2003 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Fri, 14 Nov 2003 17:19:56 +0100 Subject: service mysqld start fails In-Reply-To: <1068825423.15084.32.camel@camserv.dividia.net> References: <1068825423.15084.32.camel@camserv.dividia.net> Message-ID: <1068826796.3858.141.camel@sirendipity.dogma.lan> Am Fr, den 14.11.2003 schrieb Ryan Ayers um 16:57: > Upon fresh installation of FC1. service mysqld start returns a failure > status when a root password is supplied. This is because in the file > /etc/init.d/mysqld /usr/bin/mysqladmin ping fails when a root password > is set. > > Is this what should happen ... or is there a better way to determine if > mysql has been successfully started? > > Ryan Correct the init script: mysqladmin -u dummyuser ping There is a bugzilla entry about this and will be fixed in next package release. Alexander -- Alexander Dalloz | Enger, Germany PGP key valid: made 13.07.1999 PGP fingerprint: 2307 88FD 2D41 038E 7416 14CD E197 6E88 ED69 5653 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From notting at redhat.com Fri Nov 14 16:43:48 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 14 Nov 2003 11:43:48 -0500 Subject: ia64 kernel? In-Reply-To: <200311141041.59591.efocht@hpce.nec.com>; from efocht@hpce.nec.com on Fri, Nov 14, 2003 at 10:41:59AM +0100 References: <200311141041.59591.efocht@hpce.nec.com> Message-ID: <20031114114348.B4551@devserv.devel.redhat.com> Erich Focht (efocht at hpce.nec.com) said: > does anybody care currently about the ia64 kernel? Why is the version > so old (2.4.9)? rawhide has an inheritance system when we build trees; it pulls packages from the current tree, and then it goes back and finds any packages from earlier trees that should be included (i.e., if they haven't been built for the current tree.) That 2.4.9 ia64 kernel is the most recent one there (and it's *several* trees old... i.e., 7.2 timeframe.) > I could contribute from time to time but who is > managing this and what is the policy (features to include, testing, > etc...). Frankly, I'd expect ia64 to be more useful starting with the FC2 development cycle; we're trying to stick as close to upstream as possible with a single source base for all of our kernels; for ia64, that's *much* easier to accomplish with 2.6 than with 2.4. (At least, it was the last time I was dinking with the ia64 kernel.) Bill From ms-nospam-0306 at arcor.de Fri Nov 14 17:21:30 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 14 Nov 2003 18:21:30 +0100 Subject: Proposals for the Updates Testing Procedure In-Reply-To: <20031113163517.K8854@devserv.devel.redhat.com> References: <3FB3373F.3080303@togami.com> <20031113132153.A22474@devserv.devel.redhat.com> <3FB3D210.7010402@togami.com> <20031113161333.D23789@devserv.devel.redhat.com> <20031113163517.K8854@devserv.devel.redhat.com> Message-ID: <20031114182130.5c07dc18.ms-nospam-0306@arcor.de> On Thu, 13 Nov 2003 16:35:17 -0500, Jakub Jelinek wrote: > It would be good to know how many people actually tested it though, > if there are problems, they will likely show up in bugzilla, but > if there are no reports, it is unclear if this is because nobody > bothered to test or because it works for everybody. In Test Update announcements, would it be possible to give hints on what to test in particular or what features to check for changed behaviour? Else I assume that simply installing a test update is not of any help other than catching obvious regression. Because if I haven't been caught by a bug in the previous package revision, I'm unlikely to notice whether the test update fixes the bug. Or is the testing process solely a quantity based thing? -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Fri Nov 14 17:29:49 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 14 Nov 2003 09:29:49 -0800 Subject: Testing Updates RFC Message-ID: <200311140929.54455.jkeating@j2solutions.net> Jeff Spatula and I spoke on IRC last night, and brainstormed up an idea for these Testing Updates. We need to develop a System Verification Test Suite, that will do some generic tests to ensure functionality of some core components of the system. I do believe such tests exist for build verification. This framework can be used so that the developer of a given package errata(or update) can provide a smallish test case with the proposed update. These test cases should be scriptable, possibly attached to the bugzilla entry for the update. When the announcement is made that there is a new testing update, the end user could then install the update and run the test script which checks for functionality, and anti-regression. We felt that if test cases were provided, many more people would be willing to A) test the package, and B) provide releveant test data. The biggest part about testing an update is getting it on as many different hardware sets as possible. Anything to make this easier is a Good Thing(tm). Anyhow, I know this RFC is horribly structured, but I would like to get some feedback on this idea. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 jkeating at j2solutions.net Fri Nov 14 17:35:12 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 14 Nov 2003 09:35:12 -0800 Subject: Testing Updates RFC In-Reply-To: <200311140929.54455.jkeating@j2solutions.net> References: <200311140929.54455.jkeating@j2solutions.net> Message-ID: <200311140935.12129.jkeating@j2solutions.net> On Friday 14 November 2003 09:29, Jesse Keating wrote: > Jeff Spatula and I spoke on IRC last night, and brainstormed up an > idea for these Testing Updates. EEEK! Last time I use /whois on IRC to figure out a last name when I cant remember it... s/Spatula/Spaleta/ Deeply sorry there Jeff. -- Jesse Keating RHCE MCSE (geek.j2solutions.net) Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy) Mondo DevTeam (www.mondorescue.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 efocht at hpce.nec.com Fri Nov 14 17:44:57 2003 From: efocht at hpce.nec.com (Erich Focht) Date: Fri, 14 Nov 2003 18:44:57 +0100 Subject: ia64 kernel? In-Reply-To: References: Message-ID: <200311141844.57509.efocht@hpce.nec.com> Thanks for the replies. On Friday 14 November 2003 17:06, Justin M. Forbes wrote: > Honestly, Itanium is not out there in large numbers, and most existing > installations would not be Fedora candidates anyway, more suitable for > RHEL. I'd like to play with a modern distro (new glibc) on clusters without having to pay the RHEL price. I'm sure I'm not alone with this whish... For AMD64 I can take SUSE9, but for Itanium the only option besides Fedora is to recompile RHEL SRPMS, which is not really what I want to do. > buildinstall and mkisofs will get your dvd iso made. Thanks. Erich From efocht at hpce.nec.com Fri Nov 14 17:47:36 2003 From: efocht at hpce.nec.com (Erich Focht) Date: Fri, 14 Nov 2003 18:47:36 +0100 Subject: ia64 kernel? In-Reply-To: <20031114114348.B4551@devserv.devel.redhat.com> References: <200311141041.59591.efocht@hpce.nec.com> <20031114114348.B4551@devserv.devel.redhat.com> Message-ID: <200311141847.36786.efocht@hpce.nec.com> On Friday 14 November 2003 17:43, Bill Nottingham wrote: > Frankly, I'd expect ia64 to be more useful starting with the FC2 > development cycle; we're trying to stick as close to upstream as > possible with a single source base for all of our kernels; for ia64, > that's *much* easier to accomplish with 2.6 than with 2.4. (At least, > it was the last time I was dinking with the ia64 kernel.) I agree and I'll try 2.6 kernels on top of the current development distro. Thanks, Erich From xose at wanadoo.es Fri Nov 14 20:36:24 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Fri, 14 Nov 2003 21:36:24 +0100 Subject: Why is ide-scsi not provided in Arjan's 2.6 kernel? References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> Message-ID: <3FB53CC8.2000306@wanadoo.es> *moved to devel-list* Chris Adams wrote: > Once upon a time, Xose Vazquez Perez said: >>I hope to see a 2.4.x kernel in FC2 _too_. Otherwise it will be a lame >>distribution. > What would be lame about not including an old kernel? If 2.6 doesn't bring _all functional features_ that 2.4 has, it will be necessary a backup 2.4 kernel. Today must-fix.txt and should-fix.txt(PRI1) are big lists. > Including multiple kernel versions (especially from different major > release trains) greatly increases complexity for very little gain. Mandrake 9.2 and SuSE 9.0 bring 2.6 & 2.4 kernels. If they are able to do it, why not Fedora ? :-? -- HTML mails are going to trash automagically From cmadams at hiwaay.net Fri Nov 14 21:23:58 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 14 Nov 2003 15:23:58 -0600 Subject: Why is ide-scsi not provided in Arjan's 2.6 kernel? In-Reply-To: <3FB53CC8.2000306@wanadoo.es> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> Message-ID: <20031114212358.GG1019032@hiwaay.net> Once upon a time, Xose Vazquez Perez said: > Chris Adams wrote: > > Once upon a time, Xose Vazquez Perez said: > >>I hope to see a 2.4.x kernel in FC2 _too_. Otherwise it will be a lame > >>distribution. > > > What would be lame about not including an old kernel? > > If 2.6 doesn't bring _all functional features_ that 2.4 has, it will > be necessary a backup 2.4 kernel. Since new versions almost never have everything old versions had (some things do get lost because nobody cares enough to fix them), that requirement would hold things back forever. Heck, FC1 doesn't have some thing from RHL9; that doesn't mean FC1 won't replace RHL9. > Today must-fix.txt and should-fix.txt(PRI1) are big lists. And FC2 is around 5 months away; there's a lot of time to get things in shape. > > Including multiple kernel versions (especially from different major > > release trains) greatly increases complexity for very little gain. > > Mandrake 9.2 and SuSE 9.0 bring 2.6 & 2.4 kernels. If they are able to do it, > why not Fedora ? I don't know about SuSE, but I believe Mandrake runs 2.4 and then includes a "preview" 2.6 kernel, like RHL 7.0 ran 2.2 and included a 2.4 kernel in a preview directory. Having a new kernel as a "preview" is a far sight from having two major "supported" kernel releases. It might have been possible to have a 2.6 preview for FC1, but it wasn't really quite ready. By FC2, the general expectation will be 2.6. If someone wants to maintain a 2.4 kernel for FC2, they could do it as part of Fedora Alternatives or Extras. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jfm512 at free.fr Fri Nov 14 21:38:30 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 14 Nov 2003 22:38:30 +0100 Subject: Why is ide-scsi not provided in Arjan's 2.6 kernel? In-Reply-To: <3FB53CC8.2000306@wanadoo.es> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> Message-ID: <1068845910.1119.7.camel@agnes.fremen.dune> On Fri, 2003-11-14 at 21:36, Xose Vazquez Perez wrote: > *moved to devel-list* > > Chris Adams wrote: > > > Once upon a time, Xose Vazquez Perez said: > > >>I hope to see a 2.4.x kernel in FC2 _too_. Otherwise it will be a lame > >>distribution. > > > What would be lame about not including an old kernel? > > If 2.6 doesn't bring _all functional features_ that 2.4 has, it will > be necessary a backup 2.4 kernel. > Today must-fix.txt and should-fix.txt(PRI1) are big lists. > > > Including multiple kernel versions (especially from different major > > release trains) greatly increases complexity for very little gain. > > Mandrake 9.2 and SuSE 9.0 bring 2.6 & 2.4 kernels. If they are able to do it, > why not Fedora ? > Providing 2.6 kernels nowadays is demagogic and wrong: every stable kernel I have known (and I have know them since 1.0) has had teething problems in the first weeks or months of existence. And here it is worse since we are talking of a pre-release version. My criteria for a kernel being "distribution-ready" is if Linus has opened development for the next version. Until he has done that it means he thinks there are too many bugs waiting to be squashed for allowing people spending their time in a new kernel. -- Jean Francois Martinez From Nicolas.Mailhot at laPoste.net Fri Nov 14 21:50:51 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 14 Nov 2003 22:50:51 +0100 Subject: Why is ide-scsi not provided in Arjan's 2.6 kernel? In-Reply-To: <1068845910.1119.7.camel@agnes.fremen.dune> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> Message-ID: <1068846651.4848.1.camel@m70.net81-64-235.noos.fr> Le ven 14/11/2003 ? 22:38, Jean Francois Martinez a ?crit : > Providing 2.6 kernels nowadays is demagogic and wrong: every stable > kernel I have known (and I have know them since 1.0) has had teething > problems in the first weeks or months of existence. And here it is > worse since we are talking of a pre-release version. And we are talking about a pre-release distribution. So what's the problem ? 2.6.0 final will be out way before FC2. 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 xose at wanadoo.es Fri Nov 14 22:28:15 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Fri, 14 Nov 2003 23:28:15 +0100 Subject: FC2, 2.6 vs 2.4 References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> Message-ID: <3FB556FF.2090601@wanadoo.es> Jean Francois Martinez wrote: > My criteria for a kernel being "distribution-ready" is if Linus has > opened development for the next version. Until he has done that it > means he thinks there are too many bugs waiting to be squashed for > allowing people spending their time in a new kernel. 2.6.0-pre is a different story what was 2.4.0-pre. There is a lot of people working on it ( http://www.osdl.org/projects/26lnxstblztn/results/ ) The 2.6 _core_ will be stable, but it won't have _all_ features as 2.4 has today. I hope to be mistaken ;-) But -- HTML mails are going to trash automagically From warren at togami.com Sat Nov 15 06:36:01 2003 From: warren at togami.com (Warren Togami) Date: Fri, 14 Nov 2003 20:36:01 -1000 Subject: Proposals for the Updates Testing Procedure In-Reply-To: <20031113161022.C23789@devserv.devel.redhat.com> References: <3FB3373F.3080303@togami.com> <20031113161022.C23789@devserv.devel.redhat.com> Message-ID: <1068878161.4379.4.camel@laptop> On Thu, 2003-11-13 at 11:10, Bill Nottingham wrote: > Warren Togami (warren at togami.com) said: > > Along with each announced test update, I believe it would be crucial to > > include a link to a corresponding Bugzilla report. While longer > > discussions pertaining to packages can remain on fedora-test-list, all > > pertinent information should be posted in one place within that test > > update's Bugzilla report. Why? > > > > * Otherwise it is likely that other Bugzilla reports and important > > information related to an update could easily be lost in the mailing > > list noise. > > * All pending updates can easily be found by a single Bugzilla database > > query. > > * Each report would become a one-stop-shop for information regarding > > that update. More responsible sysadmins with proper testing procedures > > can read that report to help in their decision to update. > > That could be useful. Great! How soon can this be implemented? This is needed ASAP for the current batch of updates/testing packages IMHO. Warren From felipe_alfaro at linuxmail.org Sat Nov 15 10:42:50 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 15 Nov 2003 11:42:50 +0100 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <3FB556FF.2090601@wanadoo.es> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> <3FB556FF.2090601@wanadoo.es> Message-ID: <1068892970.2154.2.camel@teapot.felipe-alfaro.com> On Fri, 2003-11-14 at 23:28, Xose Vazquez Perez wrote: > Jean Francois Martinez wrote: > > > My criteria for a kernel being "distribution-ready" is if Linus has > > opened development for the next version. Until he has done that it > > means he thinks there are too many bugs waiting to be squashed for > > allowing people spending their time in a new kernel. > > 2.6.0-pre is a different story what was 2.4.0-pre. There is a lot of > people working on it ( http://www.osdl.org/projects/26lnxstblztn/results/ ) > The 2.6 _core_ will be stable, but it won't have _all_ features as 2.4 > has today. I hope to be mistaken ;-) You're not mistaken, but no so many features will be left out of 2.6. Some of them can be easily replaced by newer ones (for example, IDE-SCSI was used mainly for CD-Burning, but now you can use direct ATAPI CD-Burning), and some will be superseded by newer versions, like LVM2 or EVMS. For mainstream usage, I think 2.6 is ready for most of the people out there. From felipe_alfaro at linuxmail.org Sat Nov 15 12:08:09 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 15 Nov 2003 13:08:09 +0100 Subject: rhpl: full python 2.3 support Message-ID: <1068898088.2154.6.camel@teapot.felipe-alfaro.com> Attached is the patch needed to make rhpl-0.122.1 stop requiring /usr/bin/python2.2. Tested on FC1 with python-2.3.2-5. -------------- next part -------------- A non-text attachment was scrubbed... Name: rhpl-python23.patch Type: text/x-patch Size: 35104 bytes Desc: not available URL: From mike at netlyncs.com Sat Nov 15 13:49:41 2003 From: mike at netlyncs.com (Mike Chambers) Date: Sat, 15 Nov 2003 07:49:41 -0600 Subject: Some fedora devel inconsistencies... Message-ID: <1068904181.11704.2.camel@bart.netlyncs.com> Ok, now that this has been talked about for a bit... Sooo, what exactly is happening or going to happen with these python2.2 errors? Are we waiting for that package to be created and populated into rawhide so that the other packages can then be upgraded/installed onto Fedora systems or what? -- Mike Chambers Madisonville, KY "Do you hear me now?....GOOD!" From tcallawa at redhat.com Sat Nov 15 20:14:39 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 15 Nov 2003 14:14:39 -0600 Subject: python 2.3 fixed packages Message-ID: <1068927278.20598.47.camel@localhost.localdomain> Those annoying failed dependencies are annoying, aren't they? I took some time this morning and patched everything that was still broken when python 2.3 got merged into rawhide. I'm not promising I got all the bugs out, but it should help people get over the dependencies and back to testing. RPMs and SRPMs live here: http://people.redhat.com/tcallawa/python23/ It's even Yum-ified. :) I'm going to file the bugzilla entries with the patches this afternoon. ~spot --- Tom "spot" Callaway LCA, RHCE Red Hat Sales Engineer || Aurora SPARC Linux Project Leader "The author's mathematical treatment of the conception of purpose is novel and highly ingenious, but heretical and, so far as the present social order is concerned, dangerous and potentially subversive. Not to be published." -- Aldous Huxley's "Brave New World" From lukasz at wsisiz.edu.pl Sat Nov 15 21:42:28 2003 From: lukasz at wsisiz.edu.pl (Lukasz Trabinski) Date: Sat, 15 Nov 2003 22:42:28 +0100 (CET) Subject: Yum HTTP Error 404: Not Found Message-ID: Hello What is going on? lt:# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1 - i386 - Base retrygrab() failed for: http://fedora.redhat.com/releases/fedora-core-1/headers/header.info Executing failover method failover: out of servers to try Error getting file http://fedora.redhat.com/releases/fedora-core-1/headers/header.info [Errno 4] IOError: HTTP Error 404: Not Found -- *[ ?ukasz Tr?bi?ski ]* SysAdmin @wsisiz.edu.pl From skvidal at phy.duke.edu Sat Nov 15 21:44:22 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 15 Nov 2003 16:44:22 -0500 Subject: Yum HTTP Error 404: Not Found In-Reply-To: References: Message-ID: <1068932662.18758.64.camel@binkley> On Sat, 2003-11-15 at 16:42, Lukasz Trabinski wrote: > Hello > What is going on? > lt:# yum update > Gathering header information file(s) from server(s) > Server: Fedora Core 1 - i386 - Base > retrygrab() failed for: > http://fedora.redhat.com/releases/fedora-core-1/headers/header.info > Executing failover method > failover: out of servers to try > Error getting file > http://fedora.redhat.com/releases/fedora-core-1/headers/header.info > [Errno 4] IOError: HTTP Error 404: Not Found looks like your baseurl points to somewhere that doesn't exist. you got a 404 error - which is 'not found' -sv From sr at stephenreindl.de Sat Nov 15 22:01:59 2003 From: sr at stephenreindl.de (Stephen Reindl) Date: Sat, 15 Nov 2003 22:01:59 +0000 Subject: Yum HTTP Error 404: Not Found Message-ID: <20031115.m9a.49019700@sreindl.dyndns.org> That'fine but that's that path that was working now for days (weeks) ... Stephen seth vidal (skvidal at phy.duke.edu) schrieb: > >On Sat, 2003-11-15 at 16:42, Lukasz Trabinski wrote: >> Hello >> What is going on? >> lt:# yum update >> Gathering header information file(s) from server(s) >> Server: Fedora Core 1 - i386 - Base >> retrygrab() failed for: >> http://fedora.redhat.com/releases/fedora-core-1/headers/header.info >> Executing failover method >> failover: out of servers to try >> Error getting file >> http://fedora.redhat.com/releases/fedora-core-1/headers/header.info >> [Errno 4] IOError: HTTP Error 404: Not Found > >looks like your baseurl points to somewhere that doesn't exist. > >you got a 404 error - which is 'not found' > >-sv > > > > From skvidal at phy.duke.edu Sat Nov 15 21:58:58 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 15 Nov 2003 16:58:58 -0500 Subject: Yum HTTP Error 404: Not Found In-Reply-To: <20031115.m9a.49019700@sreindl.dyndns.org> References: <20031115.m9a.49019700@sreindl.dyndns.org> Message-ID: <1068933537.18758.68.camel@binkley> On Sat, 2003-11-15 at 17:01, Stephen Reindl wrote: > That'fine but that's that path that was working now for days (weeks) ... Sounds like red hat's reshuffle last night left some people out in the cold -sv From jonathanbearak at yahoo.com Sat Nov 15 23:21:24 2003 From: jonathanbearak at yahoo.com (Jonathan Marc Bearak) Date: Sat, 15 Nov 2003 18:21:24 -0500 Subject: Yum HTTP Error 404: Not Found In-Reply-To: References: Message-ID: <1068938484.4501.8.camel@jonathan.bearak> They seem to have changed the URLs. Here's what I'm using now: [base] name=Fedora Core $releasever - $basearch - Base baseurl=http://download.fedora.us/fedora/fedora/$releasever/$basearch/yum/os/ [updates-released] name=Fedora Core $releasever - $basearch - Released Updates baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/$basearch/ [updates-testing] name=Fedora Core $releasever - $basearch - Unreleased Updates baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/$releasever/$basearch/ On Sat, 2003-11-15 at 16:42, Lukasz Trabinski wrote: > Hello > What is going on? > lt:# yum update > Gathering header information file(s) from server(s) > Server: Fedora Core 1 - i386 - Base > retrygrab() failed for: > http://fedora.redhat.com/releases/fedora-core-1/headers/header.info > Executing failover method > failover: out of servers to try > Error getting file > http://fedora.redhat.com/releases/fedora-core-1/headers/header.info > [Errno 4] IOError: HTTP Error 404: Not Found > > From m.smith6 at ugrad.unimelb.edu.au Sun Nov 16 05:21:11 2003 From: m.smith6 at ugrad.unimelb.edu.au (m.smith6 at ugrad.unimelb.edu.au) Date: Sun, 16 Nov 2003 16:21:11 +1100 Subject: Self introduction: Malcolm Smith Message-ID: <200311160521.hAG5LCcf017831@cassius.its.unimelb.edu.au> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From maxka at myrealbox.com Sun Nov 16 06:50:44 2003 From: maxka at myrealbox.com (Maxwell Kanat-Alexander) Date: Sat, 15 Nov 2003 22:50:44 -0800 Subject: Yum HTTP Error 404: Not Found In-Reply-To: <1068933537.18758.68.camel@binkley> References: <20031115.m9a.49019700@sreindl.dyndns.org> <1068933537.18758.68.camel@binkley> Message-ID: <1068965444.11672.63.camel@max.localdomain> On Sat, 2003-11-15 at 13:58, seth vidal wrote: > On Sat, 2003-11-15 at 17:01, Stephen Reindl wrote: > > That'fine but that's that path that was working now for days (weeks) ... > > Sounds like red hat's reshuffle last night left some people out in the > cold IIRC, it left every Fedora user out in the cold, based on the yum.conf that shipped with FC1. I could be wrong, though. -M From pp at ee.oulu.fi Sun Nov 16 18:37:56 2003 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Sun, 16 Nov 2003 20:37:56 +0200 Subject: Vic^H^Holunteers needed for updated SATA code testing Message-ID: <20031116183756.GA21083@ee.oulu.fi> Hiya Due to popular demand on #fedora-devel, I merged the latest libata code to the FC1 kernel. This is basically identical to 2.4.22-bk53-libata1.patch.gz, except for two PCI id's added to sata_promise (0x3376 and 0x3378) and ¤t->sigmask_lock -> ¤t->sighand->siglock in libata-core.c. Pre-built RPMS + the patches I used (linux-2.4.22-libata.patch and linux-2.4.22-intel-esb-drivers.patch) can be found from http://www.ee.oulu.fi/~pp/fc1-libata (sorry, no yum support :-) ) Please test it out and if it works like it should, I'll file a RFE in bugzilla to get this merged. Open questions: - Did I break anything? (the amount of changes in header files I merged from 2.4.22-bk to fc1 like scsi.h were a bit worrying...) Promise 376 + athlon works ok, and it did compile, so I decided to ship it :-) - Is the Promise 378 PCI id 0x3378 and does the code work on one? - driver disk or boot.iso that would let people install FC1 on SATA-only boxes -- Pekka Pietikainen From jweiss1 at utk.edu Sun Nov 16 18:44:35 2003 From: jweiss1 at utk.edu (jweiss1) Date: Sun, 16 Nov 2003 13:44:35 -0500 Subject: External firewire disk curruption on reads under FC1... Message-ID: <3FBAC8DF@webmail.utk.edu> Well, I am not a developer, but I thought this is an appropriate question on this list. I was just wondering whether anybody had seen disk corruptions under FC1 with external firewire hard drives. I have tried it on three different machines now with the FC1 kernel and it happens every time after some heavy read operations on the drive. I did not see any corruption under the Red Hat 9 kernel on any of those machines. I can write data from the workstations to the firewire drive without a problem, but when I rsync back (particularly with large files) or if I try to install rpms from the firewire drive onto the workstation, I get massive disk corruption on the firewire drive, which totally trashes the drive, the ext3 filesystem journal is destroyed in the process and e2fsck reports massive errors on files where previous read operations occured. I would be willing to do some more testing if I get some instructions on how to diagnose it... Jochen ------------------------------------------- Jochen Weiss Assistant Professor, Food Biophysics 2605 River Road, Knoxville, TN 37996 From m.a.young at durham.ac.uk Sun Nov 16 19:53:43 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Sun, 16 Nov 2003 19:53:43 +0000 (GMT) Subject: UML project for Cambridge++ (update 3) Message-ID: I have been doing other things until recently, but here is another update. I have now (just) got an anaconda UML install of Fedora Core 1 working (with a 2.4 kernel), with only a small change using an updates.img file needed, see http://toast.debian.net/~may/umlproject/install.html for details. I am still having problems with 2.6 kernel crashes; it seems that exec-shield problems come back if you compile the (2.4 or 2.6) uml kernel on Fedora, and my (revised) patch fixes one problem, but the kernel will still crash soon after, at least some of the time, and always seems to crash when you try to shut it down. The tls problem is still there, and I hope to get back to looking at the missing thread system calls soon. Michael Young UML project site: http://toast.debian.net/~may/umlproject/ From memeyou at memeyou.net Mon Nov 17 02:57:10 2003 From: memeyou at memeyou.net (Tom Gordon) Date: Sun, 16 Nov 2003 16:57:10 -1000 Subject: External firewire disk curruption on reads under FC1... In-Reply-To: <3FBAC8DF@webmail.utk.edu> References: <3FBAC8DF@webmail.utk.edu> Message-ID: <3FB83906.1070308@memeyou.net> jweiss1 wrote: >I was just wondering whether anybody had seen disk corruptions under FC1 with >external firewire hard drives. I have tried it on three different machines now > > No problems here. [memeyou at Wolley memeyou]$ /sbin/lspci|grep 1394 00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire (IEEE 1394) Controller (rev a3) [memeyou at Wolley memeyou]$ cp /mnt/max/KNOPPIX_V3.3-2003-09-24-EN.iso KNOPPIX_V3.3-2003-09-24-EN.i so.fw [memeyou at Wolley memeyou]$ md5sum KNOPPIX_V3.3-2003-09-24-EN.iso.fw b41807dae6c61122f05363d8bfa7bfa0 KNOPPIX_V3.3-2003-09-24-EN.iso.fw Which is the appropriate md5, b41807dae6c61122f05363d8bfa7bfa0, as stated at http://source.rfc822.org/pub/mirror/knoppix/KNOPPIX_V3.3-2003-09-24-EN.iso.md5 Other information: [memeyou at Wolley memeyou]$ uname -a Linux Wolley 2.4.22-1.2115.nptl #1 Wed Oct 29 15:31:21 EST 2003 i686 athlon i386 GNU/Linux [memeyou at Wolley memeyou]$ df -a|grep max /dev/sda1 117189600 69657952 47531648 60% /mnt/max Dmesg: --SNIP-- ohci1394: $Rev: 1010 $ Ben Collins PCI: Setting latency timer of device 00:0d.0 to 64 ohci1394_0: OHCI-1394 1.1 (PCI): IRQ=[7] MMIO=[e8082000-e80827ff] Max Packet=[2048] ohci1394_0: SelfID received outside of bus reset sequence ieee1394: Node added: ID:BUS[0-00:1023] GUID[0010b92000d5b4ea] ieee1394: Host added: ID:BUS[0-01:1023] GUID[00e018000019b853] --SNIP-- --SNIP-- blk: queue dcae1a14, I/O limit 4095Mb (mask 0xffffffff) Vendor: Maxtor Model: 5000DV Rev: 0100 Type: Direct-Access ANSI SCSI revision: 06 blk: queue dcae1614, I/O limit 4095Mb (mask 0xffffffff) Attached scsi disk sda at scsi1, channel 0, id 0, lun 0 SCSI device sda: 240119808 512-byte hdwr sectors (122941 MB) sda: sda1 --SNIP-- Tom From pauln at truemesh.com Mon Nov 17 07:52:32 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Mon, 17 Nov 2003 07:52:32 +0000 Subject: PPC rawhide headers incomplete Message-ID: <20031117075231.GG14052@ensim.rackshack.net> http://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/headers/ Seems to be only upto kakasi :( Could someone check yum-arch -s on the tree manually in case it's barfing, else there may be some sort of failure in the push. Cheers Paul From rtomayko at naeblis.cx Mon Nov 17 07:56:41 2003 From: rtomayko at naeblis.cx (Ryan Tomayko) Date: Mon, 17 Nov 2003 02:56:41 -0500 Subject: Self-Introduction: Ryan Tomayko Message-ID: <1069055801.10763.161.camel@shadar.fade.naeblis.cx> Ryan D. Tomayko US, Columbus, OH Senior Software Developer (Professionally) / Hobbyist Sterling Commerce (Not related to/sponsoring fedora contributions) GOALS Q: Which packages do you want to see published? A: python libraries, rss/blogging software (gnome-blog,pyblosxom), MozillaFirebird themes/extensions, recent versions of rdesktop, fluxbox, autocutsel, ccxstream.. Q: Do you want to do QA? A: Not exclusively but sure I would be willing to pull packages from the QA queue on fedora.us and check against packaging guidelines. Q: Anything else special? A: I'm just hoping to contribute in anyway possible to the process/people in which I have already benefited beyond repay. HISTORICAL QUALIFICATIONS Q: What other projects have you worked on in the past? A: OSS/FS - pixi (XInclude processor in Java), misc patches here and there to other OSS/FS projects, Yum. Proprietary - Java B2B Messaging and EAI Apps that no one will care about. :/ Q: What computer languages and other skills do you know? A: C, C++, Python, Java, Perl, bash. X{ML,SLT,Path} Q: Why should we trust you? A: Eh.. I guess that's a tough one. I guess I'm hoping to build trust as described in the fedora.us /Package Submission QAPolicy/. Excerpt follows. Is this sufficient or is there some standard method of asserting one's trustworthiness that I'm not aware of? "GPG clearsigned messages that give good advice can all be traced back to your GPG key and accumulate over time. This process allows new developers to gain trust through technical correctness and hard work over a period of time, eventually being able to prove to the community that the developer can be trusted." GPG $ gpg --fingerprint 2096A276 pub 1024D/2096A276 2003-11-16 Ryan Tomayko Key fingerprint = 4D30 D735 D003 9AD6 1E9D E666 9D57 D6F0 2096 A276 sub 1024g/0BC45896 2003-11-16 Thanks, - Ryan -------------- 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 steve at silug.org Mon Nov 17 07:57:23 2003 From: steve at silug.org (Steven Pritchard) Date: Mon, 17 Nov 2003 01:57:23 -0600 Subject: Self-Introduction: Steven Pritchard Message-ID: <20031117075723.GA19585@osiris.silug.org> Name: Steven Pritchard Location: Fairview Heights, IL, US (St. Louis metro area) Profession: sysadmin, consultant, etc. Company: K&S Pritchard Enterprises, Inc. (http://www.kspei.com/) Goals: The main thing I'd like to do is clear out my personal apt repository. Currently I have around 50 packages, although admittedly some disturbing percentage of that is stuff from CPAN. :-) It looks like a few of the things I have packaged are already on fedora.us, and a few more are already in the QA queue, so I would imagine I could do some QA after I get another box or two upgraded. Some of the more interesting packages in my repository include amavis-ng, clamav, courier-imap, kernel-hostap-driver, perl-HTML-Mason, and perl-Tk. Historical qualifications: I'm competent in C, really good with Perl, and just scary with sh. ;) I like to think I'm pretty good at managing systems, and packaging software is one piece that I think is absolutely essential when managing a large number of systems. As far as the trust thing goes, I've been around for years. Various people probably know me either through the LUGs I started (SILUG in 1994 and LUCI in 1997), the Hardware HOWTO (which I've been "maintaining" for a couple of years now, but try not to hold that against me), or through my better half, Kara Pritchard (of LPI fame, previously with linux.com). GPG KEYID and fingerprint: pub 1024D/CF71A040 2002-05-27 Steven Pritchard Key fingerprint = CA1F 0151 E903 FB46 879E 35A7 AF50 B774 CF71 A040 uid Steven Pritchard sub 1024g/3CDC52F6 2002-05-27 pub 1024R/542382D9 1996-09-13 Steven Pritchard Key fingerprint = 98 B2 AE 48 32 D0 74 EF 7D 14 A4 C6 B1 BE A8 11 (The second key is my old PGP key that I no longer actively use.) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From bishop at platypus.bc.ca Mon Nov 17 08:53:49 2003 From: bishop at platypus.bc.ca (bishop) Date: Mon, 17 Nov 2003 00:53:49 -0800 Subject: tools or scripts for release engineering? In-Reply-To: <37681.64.169.63.74.1068717930.squirrel@ruckus.brouhaha.com> References: <37681.64.169.63.74.1068717930.squirrel@ruckus.brouhaha.com> Message-ID: <3FB88C9D.3060507@platypus.bc.ca> Eric, That's something I'm interesting in reading as well. In addition, I'm looking forward to replicating, at home, whichever auto-build-from-CVS strategy Fedora chooses. My own system is okay, but it's small-time, it's got a whack of limitations and the workaround for them aren't pretty at all. I'm not sure of the license on our RPM-CVS add-on tools are, so I've hesitated on suggesting that (who's a python guru here?) for the collective. I almost wish I could get my hands on the release engineering routine one we used to use for work, but I'm sure that work would clamp some serious legal ain't-gonna-happen docs on it. Ideally, I'd love to see changes CVS building Rawhide packages, as well as a valid, installable update CD, maybe weekly. It was a goal we had at work for the longest time, spearheaded by Mr Terpstra himself for a while, too, even, but it lost the race. Bummer. But yeah, put my name down for any private responses to Eric's question. I want to be on the CC list to that stuff. - bish Eric Smith wrote: > Are there any tools or scripts for Fedora Core release engineering? > In other words, the stuff that takes a big collection of SRPMS, and > results in the ISO images? > > Failing that, is there some documentation on how it is done? > > I'm sure that with enough trial and error I could eventually come close > to duplicating the way it's done officially, but if there are tools > and/or docs, it's obviously much easier. > > Thanks! > Eric Smith > -- it seems like a dark day when an American citizen regards reading as a threat, and downright pitch-black when the federal government agrees. http://atlanta.creativeloafing.com/2003-07-17/rant.html From warren at togami.com Mon Nov 17 09:00:09 2003 From: warren at togami.com (Warren Togami) Date: Sun, 16 Nov 2003 23:00:09 -1000 Subject: Self-Introduction: Steven Pritchard In-Reply-To: <20031117075723.GA19585@osiris.silug.org> References: <20031117075723.GA19585@osiris.silug.org> Message-ID: <3FB88E19.8050505@togami.com> To Steven and all others who wrote a Self-Introduction as described in the Package Submission and QA Policy: http://www.fedora.us/wiki/PackageSubmissionQAPolicy Welcome! Steven Pritchard wrote: > Goals: > > The main thing I'd like to do is clear out my personal apt repository. > Currently I have around 50 packages, although admittedly some > disturbing percentage of that is stuff from CPAN. :-) fedora.us QA queue is in need of qualified perl people in order to push through several existing packages. Your help would be greatly appreciated there. > > It looks like a few of the things I have packaged are already on > fedora.us, and a few more are already in the QA queue, so I would > imagine I could do some QA after I get another box or two upgraded. Anything that exists in both fedora.us or fedora.us QA and your personal apt repository, please file reports for each package about any improvements to the existing fedora.us submitted package. If you feel that your package is far superior in every way, then submit your package as a replacement for the existing package and state reasons. Thank you for your interest to do QA, since that is what we really need as we are approaching 300 packages in the QA queue. =| > > Some of the more interesting packages in my repository include > amavis-ng, clamav, courier-imap, kernel-hostap-driver, > perl-HTML-Mason, and perl-Tk. Is hostap for prism2 chips? If so I am very excited. clamav is currently in QA queue and we would really appreciate your suggestions on that package. Warren Togami warren at togami.com From mandreiana at rdslink.ro Mon Nov 17 10:46:30 2003 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Mon, 17 Nov 2003 12:46:30 +0200 Subject: openoffice.org missing .jar classes Message-ID: <1069065990.5335.28.camel@marte.biciclete.ro> Hi openoffice.org is missing /usr/lib/openoffice/program/classes with various .jars, included in standard ooo distribution. Why weren't these included in ooo 1.1 rpm? Also, how to setup java for openoffice.org? OO.o says one should run jvmsetup, but that binary is missing on FC1. Thanks -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From buildsys at porkchop.devel.redhat.com Mon Nov 17 10:41:03 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Mon, 17 Nov 2003 05:41:03 -0500 Subject: rawhide report: 20031115 changes Message-ID: <200311171041.hAHAf2502440@porkchop.devel.redhat.com> From buildsys at porkchop.devel.redhat.com Mon Nov 17 11:24:30 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Mon, 17 Nov 2003 06:24:30 -0500 Subject: rawhide report: 20031116 changes Message-ID: <200311171124.hAHBOUq17636@porkchop.devel.redhat.com> New package yaboot Linux bootloader for Power Macintosh "New World" computers. Updated Packages: coreutils-5.0-30.sel -------------------- * Fri Nov 14 2003 Tim Waugh 5.0-30.sel - Fixed useless acl dependencies (bug #106141). e2fsprogs-1.35-2 ---------------- * Fri Nov 14 2003 Phil Knirsch 1.35-2 - Updated s390 patch. It's not not arch dependant anymore but only changes the default blocksizes when necessary. redhat-config-printer-0.6.82-1 ------------------------------ * Fri Nov 14 2003 Tim Waugh 0.6.82-1 - 0.6.82: - Requires gnome-python2-canvas (bug #110116). reiserfs-utils-3.x.0f-1 ----------------------- * Mon Mar 05 2001 Bernhard Rosenkraenzer - Update to 3.x.0f, many important fixes in fsck - Add missing README (#30556) - Use -v2 by default in mkreiserfs (#30556) * Wed Feb 07 2001 Than Ngo - added Missing symlinks for mkfs and fsck commands (Bug #26359) * Tue Jan 23 2001 Bernhard Rosenkraenzer - initial RPM - changes from base package: - Fix a security problem (yet another tmp file issue) - Fix an fd leak - Get rid of the config.cache file, it contains broken settings - Install man pages - Fix locations of binaries, installing this stuff to "bin" is not really a good idea - Fix build on alpha and ia64 rhn-applet-2.1.4-1 ------------------ rhpl-0.122.2-1 -------------- * Fri Nov 14 2003 Jeremy Katz 0.122.2-1 - more python2.3 rpmdb-fedora-1-0.20031117 ------------------------- sudo-1.6.7p5-4.sel ------------------ * Thu Nov 13 2003 Dan Walsh 1.6.7p5-4.sel - Turn on SELinux support * Tue Jul 29 2003 Dan Walsh 1.6.7p5-3 - Add support for SELinux taipeifonts-1.2-24 ------------------ * Fri Nov 14 2003 Mike A. Harris 1.2-24 - Remove possible packabe build time security vulnerability in Buildroot specification by using _tmppath appropriately (#110102) vnc-4.0-0.beta4.6 ----------------- * Fri Nov 14 2003 Tim Waugh 4.0-0.beta4.6 - F8 fix (bug #109377). From buildsys at porkchop.devel.redhat.com Mon Nov 17 11:53:20 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Mon, 17 Nov 2003 06:53:20 -0500 Subject: rawhide report: 20031117 changes Message-ID: <200311171153.hAHBrK825217@porkchop.devel.redhat.com> Updated Packages: From gemi at bluewin.ch Mon Nov 17 12:54:55 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Mon, 17 Nov 2003 13:54:55 +0100 Subject: Executable memory: some apps that work on RH9 don't on FC1 Message-ID: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> Hi, Some software, among them clisp, scm and mit-scheme don't work anymore with FC1. One problem seems to be that on FC1 stack and malloced memory is no longer executable, at least not without using mprotect. Interpreters and compilers like the above commonly allocate a piece of memory and fill it with executable code. I am sure they can be adapted to work on FC1, but I would have preferred that the FC1 kernel would behave in the same way as the RH9 one. Is there any way to disable this behaviour. Trying to get the problem fixed by the upstream developers will probably take a long time, and it seems that other Linux distros don't show this problem... Regards, G?rard -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From jakub at redhat.com Mon Nov 17 13:03:59 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 17 Nov 2003 08:03:59 -0500 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> Message-ID: <20031117130359.GB6288@devserv.devel.redhat.com> On Mon, Nov 17, 2003 at 01:54:55PM +0100, Gerard Milmeister wrote: > Some software, among them clisp, scm and mit-scheme don't work anymore > with FC1. One problem seems to be that on FC1 stack and malloced memory > is no longer executable, at least not without using mprotect. > Interpreters and compilers like the above commonly allocate a piece of > memory and fill it with executable code. I am sure they can be adapted > to work on FC1, but I would have preferred that the FC1 kernel would > behave in the same way as the RH9 one. Is there any way to disable this > behaviour. Trying to get the problem fixed by the upstream developers > will probably take a long time, and it seems that other Linux distros > don't show this problem... If they need executable stack in a way which is not known to the compiler, the programmer has to tell it to the toolchain. If a program say takes address of a nested function, GCC knows it needs executable stack and arranges things automatically. Otherwise, either an object file can be marked as needing executable stack (with -Wa,--execstack; at least one such object will make the whole shared library or binary requiring executable stack), or during link time with -Wl,-z,execstack or after it using execstack(8) utility. The defaults are such that programs and/or libraries compiled/linked on <= RHL9 are always assumed to potentially require executable stack, but if you build a new program on FC1, you really need to tell the toolchain about it. Jakub From gemi at bluewin.ch Mon Nov 17 13:39:00 2003 From: gemi at bluewin.ch (gemi at bluewin.ch) Date: Mon, 17 Nov 2003 14:39:00 +0100 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <20031117130359.GB6288@devserv.devel.redhat.com> Message-ID: <3FB818BB000054D2@mssazhb-int.msg.bluewin.ch> >If they need executable stack in a way which is not known to the compiler, >the programmer has to tell it to the toolchain. >If a program say takes address of a nested function, GCC knows it needs >executable stack and arranges things automatically. >Otherwise, either an object file can be marked as needing executable >stack (with -Wa,--execstack; at least one such object will make the whole >shared library or binary requiring executable stack), or during link >time with -Wl,-z,execstack or after it using execstack(8) utility. >The defaults are such that programs and/or libraries compiled/linked >on <= RHL9 are always assumed to potentially require executable stack, >but if you build a new program on FC1, you really need to tell the toolchain >about it. > > Jakub > Thanks for the info. However this seems to be not the only problem. I tried the execstack method on the mentioned programs without any success. Or try to approach it in another way: The official binary of mit-scheme 7.7.1 (http://www.gnu.org/software/mit-scheme) segfaults if called with 'scheme -compiler'. In this case the scheme main program load a 'band' called compiler.com, which contains executable code. Could somebody investigate this issue? I am not that familiar with problems like this. From daly at rio.sci.ccny.cuny.edu Mon Nov 17 14:21:59 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Mon, 17 Nov 2003 09:21:59 -0500 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <3FB818BB000054D2@mssazhb-int.msg.bluewin.ch> (gemi@bluewin.ch) References: <3FB818BB000054D2@mssazhb-int.msg.bluewin.ch> Message-ID: <200311171421.hAHELx116056@rio.sci.ccny.cuny.edu> I'll look at the clisp memory issue. We plan to support Axiom on clisp in the future so it's in our interest. Tim Daly axiom at tenkan.org daly at idsi.net From dcbw at redhat.com Mon Nov 17 15:09:58 2003 From: dcbw at redhat.com (Dan Williams) Date: Mon, 17 Nov 2003 10:09:58 -0500 Subject: openoffice.org missing .jar classes In-Reply-To: <1069065990.5335.28.camel@marte.biciclete.ro> References: <1069065990.5335.28.camel@marte.biciclete.ro> Message-ID: <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> Hi, You don't :) Well, that's not completely true. First, the issue of missing Java. We do not build OOo with Java enabled, because we cannot distribute a JVM with Fedora. Therefore, Java support in OOo is disabled. Debian does the same thing, with the same patches. Things that use Java, for example the Report Wizard, will not function on the current Red Hat RPMs. What I'm looking at is a good way to perhaps _build_ with Java here, but allow OOo to run on non-Java-enabled systems and Java-enabled systems at the same time. That's not exactly easy though. For the time being, if you'd like to use Java, I'd suggest grabbing the SRPM and removing the "--disable-java" from the ./configure options, and also commenting out all the "handle-no-solar-java" patches. Dan On Mon, 2003-11-17 at 05:46, Marius Andreiana wrote: > Hi > > openoffice.org is missing > /usr/lib/openoffice/program/classes > with various .jars, included in standard ooo distribution. Why weren't > these included in ooo 1.1 rpm? > > Also, how to setup java for openoffice.org? OO.o says one should run > jvmsetup, but that binary is missing on FC1. > > Thanks From johnsonm at redhat.com Mon Nov 17 16:05:52 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 17 Nov 2003 11:05:52 -0500 Subject: Yum HTTP Error 404: Not Found In-Reply-To: <1068933537.18758.68.camel@binkley> References: <20031115.m9a.49019700@sreindl.dyndns.org> <1068933537.18758.68.camel@binkley> Message-ID: <20031117160552.GA31907@devserv.devel.redhat.com> On Sat, Nov 15, 2003 at 04:58:58PM -0500, seth vidal wrote: > On Sat, 2003-11-15 at 17:01, Stephen Reindl wrote: > > That'fine but that's that path that was working now for days (weeks) ... > > Sounds like red hat's reshuffle last night left some people out in the > cold Redirects were accidentally broken by a side effect of a software upgrade; they are now fixed. Sorry for the inconvenience. You can always use the direct URLs, too, FYI: http://download.fedora.redhat.com/pub/fedora/linux/core/1/i386/os/ http://download.fedora.redhat.com/pub/fedora/linux/core/updates/1/i386/os/ http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/1/i386/os/ michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From johnsonm at redhat.com Mon Nov 17 16:56:50 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 17 Nov 2003 11:56:50 -0500 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: References: <1068236427.12684.60.camel@laptop> Message-ID: <20031117165650.GA19426@devserv.devel.redhat.com> On Fri, Nov 07, 2003 at 11:49:39PM +0100, Aurelien Bompard wrote: > However, I have recently bumped into a package naming problem which doesn't > seem to be covered here. It's a program called K3B, a CD/DVD burning > frontend for KDE. > Here is their release numbers : 0.8 -> 0.9 -> 0.10 That's no problem, RPM compares those correctly. That's normal version numbering out there, and RPM has handled it since the beginning of (its) recorded history. > How should we set the RPM fields without using epochs in this type of > versionning ? Is is a case where epoch is necessary ? Definitely do NOT use epoch here. I have heard that somewhere there is a theory circulating that these cases require epoch, and they are like practical examples of the apocryphal stories of philosophers debating the number of teeth in a horse's mouth without once walking into the barn to check! michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From steve at silug.org Mon Nov 17 18:41:51 2003 From: steve at silug.org (Steven Pritchard) Date: Mon, 17 Nov 2003 12:41:51 -0600 Subject: Self-Introduction: Steven Pritchard In-Reply-To: <3FB88E19.8050505@togami.com> References: <20031117075723.GA19585@osiris.silug.org> <3FB88E19.8050505@togami.com> Message-ID: <20031117184151.GA21606@osiris.silug.org> On Sun, Nov 16, 2003 at 11:00:09PM -1000, Warren Togami wrote: > Is hostap for prism2 chips? If so I am very excited. That's it. (http://hostap.epitest.fi/) Let me know if you want the SRPM to try out. > clamav is currently in QA queue and we would really appreciate your > suggestions on that package. Ah, I hadn't noticed that. I'll definitely have to take a look. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From kdebisschop at alert.infoplease.com Mon Nov 17 19:06:49 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Mon, 17 Nov 2003 14:06:49 -0500 Subject: Self-Introduction: Steven Pritchard In-Reply-To: <20031117184151.GA21606@osiris.silug.org> References: <20031117075723.GA19585@osiris.silug.org> <3FB88E19.8050505@togami.com> <20031117184151.GA21606@osiris.silug.org> Message-ID: <1069096008.11764.59.camel@skilletinfopleasecom.nh.pearsoned.com> On Mon, 2003-11-17 at 13:41, Steven Pritchard wrote: > On Sun, Nov 16, 2003 at 11:00:09PM -1000, Warren Togami wrote: > > Is hostap for prism2 chips? If so I am very excited. > > That's it. (http://hostap.epitest.fi/) Let me know if you want the > SRPM to try out. > > > clamav is currently in QA queue and we would really appreciate your > > suggestions on that package. > I'd like to look at that as well, but being very new to Fedora I'm not finding the 'QA Queue' or any proposed clamav SRMS. Sorry for the newbie question, but can someone give me a link to where these are, or more generally how the QA process will work? -- Karl DeBisschop Pearson Education/Information Please From roland at redhat.com Mon Nov 17 19:12:02 2003 From: roland at redhat.com (Roland McGrath) Date: Mon, 17 Nov 2003 11:12:02 -0800 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: gemi@bluewin.ch's message of Monday, 17 November 2003 14:39:00 +0100 <3FB818BB000054D2@mssazhb-int.msg.bluewin.ch> Message-ID: <200311171912.hAHJC2Cg015459@magilla.sf.frob.com> > The official binary of mit-scheme 7.7.1 (http://www.gnu.org/software/mit-scheme) > segfaults if called with 'scheme -compiler'. In this case the scheme main > program load a 'band' called compiler.com, which contains executable code. > Could somebody investigate this issue? I am not that familiar with problems > like this. If this binary was created with old tools and has no PT_GNU_STACK marker, then it should get executable stack by default. More likely the issue is that it calls malloc and expects the memory returned to be executable. The Scheme runtime needs to be changed to use mmap when executability matters. From ted at cypress.com Mon Nov 17 19:14:31 2003 From: ted at cypress.com (Thomas Dodd) Date: Mon, 17 Nov 2003 13:14:31 -0600 Subject: openoffice.org missing .jar classes In-Reply-To: <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> References: <1069065990.5335.28.camel@marte.biciclete.ro> <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> Message-ID: <3FB91E17.1060001@cypress.com> Dan Williams wrote: > What I'm looking at is a good way to perhaps _build_ with Java here, but > allow OOo to run on non-Java-enabled systems and Java-enabled systems at > the same time. That's not exactly easy though. The OOo build require the jvm setup, but will work without java. This should be doable. > For the time being, if you'd like to use Java, I'd suggest grabbing the > SRPM and removing the "--disable-java" from the ./configure options, and > also commenting out all the "handle-no-solar-java" patches. This should be a rpm switch that pathes and add --disable-java to configure, or doesn't patch and leaves java enabled. Better still would be autodetection of the require java for building, and building correctly for a given system. Once a java capable build is there, post-install and or the OOo-setup, should check for JVM and configure it. This detection starts to get tricky, so perhaps use a system wide "default JVM" setting, say in /etc/sysconfig. Fo now though, building with java, and at least allowing users to run jvmsetup (renamed as ooo-jvm-setup?) would be a good start. Trying to get the OOo builds to integrate with the Red Hat builds is a mess. -Thomas From kdebisschop at alert.infoplease.com Mon Nov 17 19:17:59 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Mon, 17 Nov 2003 14:17:59 -0500 Subject: SRPM for revised diskcheck monitors inodes Message-ID: <1069096679.11764.61.camel@skilletinfopleasecom.nh.pearsoned.com> This SRPM is for a revision to diskcheck that monitors inodes in addition to bytes free: http://www.debisschop.net/src/fedora/diskcheck-1.5-1.noarch.rpm This RFE can be viewed at: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109972 -- Karl DeBisschop -------------- 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 daly at rio.sci.ccny.cuny.edu Mon Nov 17 18:39:17 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Mon, 17 Nov 2003 13:39:17 -0500 Subject: fedora and GCL Message-ID: <200311171839.hAHIdHf09455@rio.sci.ccny.cuny.edu> Camm, Memory is managed in a new way in Fedora (the new redhat) distro. For instance, you can't execute from stack allocated memory. GCL will not build on Fedora Core 1: Loading ../cmpnew/gcl_fasdmacros.lsp Finished loading ../cmpnew/gcl_fasdmacros.lsp Loading /root/axiom/lsp/gcl-2.6.1/unixport/../gcl-tk/tk-package.lsp Finished loading /root/axiom/lsp/gcl-2.6.1/unixport/../gcl-tk/tk-package.lsp Loading /root/axiom/lsp/gcl-2.6.1/unixport/../cmpnew/gcl_cmpmain.lsp Warning: COMPILE-FILE is being redefined. Warning: COMPILE is being redefined. Warning: DISASSEMBLE is being redefined. Finished loading /root/axiom/lsp/gcl-2.6.1/unixport/../cmpnew/gcl_cmpmain.lsp Loading /root/axiom/lsp/gcl-2.6.1/unixport/../cmpnew/gcl_lfun_list.lsp Finished loading /root/axiom/lsp/gcl-2.6.1/unixport/../cmpnew/gcl_lfun_list.lsp Loading /root/axiom/lsp/gcl-2.6.1/unixport/../cmpnew/gcl_cmpopt.lsp Finished loading /root/axiom/lsp/gcl-2.6.1/unixport/../cmpnew/gcl_cmpopt.lsp Loading /root/axiom/lsp/gcl-2.6.1/unixport/../lsp/gcl_auto_new.lsp Finished loading /root/axiom/lsp/gcl-2.6.1/unixport/../lsp/gcl_auto_new.lsp Warning: LISP-IMPLEMENTATION-VERSION is being redefined. T > #<"USER" package> > Unrecoverable error: Segmentation violation.. make[4]: *** [saved_pre_gcl] Error 134 rm init_pre_gcl.lsp raw_pre_gcl make[4]: Leaving directory `/root/axiom/lsp/gcl-2.6.1/unixport' make[3]: *** [unixport/saved_pre_gcl] Error 2 make[3]: Leaving directory `/root/axiom/lsp/gcl-2.6.1' cp: cannot stat `unixport/saved_gcl': No such file or directory make[2]: *** [gcldir] Error 1 make[2]: Leaving directory `/root/axiom/lsp' make[1]: *** [lspdir] Error 2 make[1]: Leaving directory `/root/axiom' make: *** [all] Error 2 [root at fedora1 axiom]# From daly at rio.sci.ccny.cuny.edu Mon Nov 17 18:47:04 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Mon, 17 Nov 2003 13:47:04 -0500 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <200311171912.hAHJC2Cg015459@magilla.sf.frob.com> (message from Roland McGrath on Mon, 17 Nov 2003 11:12:02 -0800) References: <200311171912.hAHJC2Cg015459@magilla.sf.frob.com> Message-ID: <200311171847.hAHIl4H09514@rio.sci.ccny.cuny.edu> Roland, I just built a machine with the latest Fedora and tried to build Axiom. Axiom depends on GCL, Gnu Common Lisp. It appears that all of the lisps are broken under the new memory model. Can you give me some pointers to any documentation or source code in Fedora that might give me a clue about how to fix this? I understand there might be a compiler switch but haven't found any documentation. Tim Daly axiom at tenkan.org daly at idsi.net ==================================================================== > The official binary of mit-scheme 7.7.1 (http://www.gnu.org/software/mit-scheme) > segfaults if called with 'scheme -compiler'. In this case the scheme main > program load a 'band' called compiler.com, which contains executable code. > Could somebody investigate this issue? I am not that familiar with problems > like this. If this binary was created with old tools and has no PT_GNU_STACK marker, then it should get executable stack by default. More likely the issue is that it calls malloc and expects the memory returned to be executable. The Scheme runtime needs to be changed to use mmap when executability matters. From pmatilai at welho.com Mon Nov 17 19:22:32 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 17 Nov 2003 21:22:32 +0200 Subject: Self-Introduction: Steven Pritchard In-Reply-To: <1069096008.11764.59.camel@skilletinfopleasecom.nh.pearsoned.com> References: <20031117075723.GA19585@osiris.silug.org> <3FB88E19.8050505@togami.com> <20031117184151.GA21606@osiris.silug.org> <1069096008.11764.59.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <1069096952.4736.33.camel@cs148226.pp.htv.fi> On Mon, 2003-11-17 at 21:06, Karl DeBisschop wrote: > On Mon, 2003-11-17 at 13:41, Steven Pritchard wrote: > > On Sun, Nov 16, 2003 at 11:00:09PM -1000, Warren Togami wrote: > > > Is hostap for prism2 chips? If so I am very excited. > > > > That's it. (http://hostap.epitest.fi/) Let me know if you want the > > SRPM to try out. > > > > > clamav is currently in QA queue and we would really appreciate your > > > suggestions on that package. > > > > I'd like to look at that as well, but being very new to Fedora I'm not > finding the 'QA Queue' or any proposed clamav SRMS. Sorry for the newbie > question, but can someone give me a link to where these are, or more > generally how the QA process will work? Currently this stuff exist at the old fedora.us site until the merger happens for real: the QA queue can be found at http://www.fedora.us/QA and package submission and QA policy at http://www.fedora.us/wiki/PackageSubmissionQAPolicy - Panu - From roland at redhat.com Mon Nov 17 19:34:15 2003 From: roland at redhat.com (Roland McGrath) Date: Mon, 17 Nov 2003 11:34:15 -0800 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: Gerard Milmeister's message of Monday, 17 November 2003 13:54:55 +0100 <1069073695.9836.5.camel@scriabin.tannenrauch.ch> Message-ID: <200311171934.hAHJYFSr015539@magilla.sf.frob.com> You can disable the exec-shield functionality globally with /proc/sys/kernel/exec-shield, but that doesn't do anything different for an older binary that is not marked or for a binary that is marked as requiring executable stack. exec-shield is always disabled for those execs. The issue you are having is probably that malloc does not use PROT_EXEC in its mmap-based allocations. Executability should be enabled in the brk area when exec-shield is disabled. Verify the situation by looking at /proc/PID/maps for the process in question. From ms-nospam-0306 at arcor.de Mon Nov 17 19:35:36 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 17 Nov 2003 20:35:36 +0100 Subject: Self-Introduction: Steven Pritchard In-Reply-To: <1069096008.11764.59.camel@skilletinfopleasecom.nh.pearsoned.com> References: <20031117075723.GA19585@osiris.silug.org> <3FB88E19.8050505@togami.com> <20031117184151.GA21606@osiris.silug.org> <1069096008.11764.59.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <20031117203536.06111bdc.ms-nospam-0306@arcor.de> On Mon, 17 Nov 2003 14:06:49 -0500, Karl DeBisschop wrote: > On Mon, 2003-11-17 at 13:41, Steven Pritchard wrote: > > On Sun, Nov 16, 2003 at 11:00:09PM -1000, Warren Togami wrote: > > > Is hostap for prism2 chips? If so I am very excited. > > > > That's it. (http://hostap.epitest.fi/) Let me know if you want the > > SRPM to try out. > > > > > clamav is currently in QA queue and we would really appreciate your > > > suggestions on that package. > > > > I'd like to look at that as well, but being very new to Fedora I'm not > finding the 'QA Queue' or any proposed clamav SRMS. Sorry for the newbie > question, but can someone give me a link to where these are, or more > generally how the QA process will work? http://fedora.us/QA => https://bugzilla.fedora.us/show_bug.cgi?id=268 Some documentation can be found at http://www.fedora.us/index-main.html at the right side in the Wiki. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pcompton at proteinmedia.com Mon Nov 17 19:39:40 2003 From: pcompton at proteinmedia.com (Phillip Compton) Date: Mon, 17 Nov 2003 14:39:40 -0500 Subject: Self-Introduction: Steven Pritchard In-Reply-To: <1069096008.11764.59.camel@skilletinfopleasecom.nh.pearsoned.com> References: <20031117075723.GA19585@osiris.silug.org> <3FB88E19.8050505@togami.com> <20031117184151.GA21606@osiris.silug.org> <1069096008.11764.59.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <1069097980.12389.13.camel@GreenTea> On Mon, 2003-11-17 at 14:06, Karl DeBisschop wrote: > I'd like to look at that as well, but being very new to Fedora I'm not > finding the 'QA Queue' or any proposed clamav SRMS. Sorry for the newbie > question, but can someone give me a link to where these are, or more > generally how the QA process will work? The QA Queue is here: http://www.fedora.us/QA And here is what you need to know to use it: http://www.fedora.us/wiki/PackageSubmissionQAPolicy Phil From mandreiana at rdslink.ro Mon Nov 17 19:47:45 2003 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Mon, 17 Nov 2003 21:47:45 +0200 Subject: openoffice.org missing .jar classes In-Reply-To: <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> References: <1069065990.5335.28.camel@marte.biciclete.ro> <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> Message-ID: <1069098464.5084.19.camel@marte.biciclete.ro> On Lu, 2003-11-17 at 17:09, Dan Williams wrote: > What I'm looking at is a good way to perhaps _build_ with Java here, but > allow OOo to run on non-Java-enabled systems and Java-enabled systems at > the same time. That's not exactly easy though. So there's no way now to run Report Wizard on FC1 without rebuilding modified srpm. Would be good to be able to install Sun java rpm and then specify in ooo somewhere that it has java and use it. > For the time being, if you'd like to use Java, I'd suggest grabbing the > SRPM and removing the "--disable-java" from the ./configure options, and > also commenting out all the "handle-no-solar-java" patches. ok I've got the missing .jars from a windows version of ooo. Will the above rebuilding also add jvmsetup? Now I'm able to use ooo SDK, but no Report Wizard. Thanks -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From otaylor at redhat.com Mon Nov 17 19:42:36 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 17 Nov 2003 14:42:36 -0500 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: <20031117165650.GA19426@devserv.devel.redhat.com> References: <1068236427.12684.60.camel@laptop> <20031117165650.GA19426@devserv.devel.redhat.com> Message-ID: <1069098156.2300.40.camel@dhcp64-216.boston.redhat.com> On Mon, 2003-11-17 at 11:56, Michael K. Johnson wrote: > > How should we set the RPM fields without using epochs in this type of > > versionning ? Is is a case where epoch is necessary ? > > Definitely do NOT use epoch here. I have heard that somewhere there is > a theory circulating that these cases require epoch, and they are like > practical examples of the apocryphal stories of philosophers debating > the number of teeth in a horse's mouth without once walking into the > barn to check! All experience with using Epoch leads to one conclusion: Never, never, never, use Epoch. It's better to use version numbers that have no relationship at all to the upstream version than to use an Epoch. That is, if someone can't be disuaded from calling their packages: foo-alpha foo-beta foo-gamma foo-delta Use versions 1alpha 2beta 3gamma 4delta. If you didn't see delta coming, then go with fedora1delta, fedora2epsilon, or something. It may be ugly, but at least you don't have hidden version information that people will use in some places and not others, resulting in Requires: foo >= epsilon that do absolutely nothing. Regards, Owen From katzj at redhat.com Mon Nov 17 19:56:05 2003 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 17 Nov 2003 14:56:05 -0500 Subject: rhpl: full python 2.3 support In-Reply-To: <1068898088.2154.6.camel@teapot.felipe-alfaro.com> References: <1068898088.2154.6.camel@teapot.felipe-alfaro.com> Message-ID: <1069098965.20316.0.camel@mirkwood.devel.redhat.com> On Sat, 2003-11-15 at 07:08, Felipe Alfaro Solana wrote: > Attached is the patch needed to make rhpl-0.122.1 stop requiring > /usr/bin/python2.2. Tested on FC1 with python-2.3.2-5. Already in rhpl-0.122.2 which should now be in rawhide Thanks, Jeremy From ms-nospam-0306 at arcor.de Mon Nov 17 20:03:00 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 17 Nov 2003 21:03:00 +0100 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <20031117130359.GB6288@devserv.devel.redhat.com> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> Message-ID: <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> On Mon, 17 Nov 2003 08:03:59 -0500, Jakub Jelinek wrote: > On Mon, Nov 17, 2003 at 01:54:55PM +0100, Gerard Milmeister wrote: > > Some software, among them clisp, scm and mit-scheme don't work anymore > > with FC1. One problem seems to be that on FC1 stack and malloced memory > > is no longer executable, at least not without using mprotect. > > Interpreters and compilers like the above commonly allocate a piece of > > memory and fill it with executable code. I am sure they can be adapted > > to work on FC1, but I would have preferred that the FC1 kernel would > > behave in the same way as the RH9 one. Is there any way to disable this > > behaviour. Trying to get the problem fixed by the upstream developers > > will probably take a long time, and it seems that other Linux distros > > don't show this problem... > > If they need executable stack in a way which is not known to the compiler, > the programmer has to tell it to the toolchain. > If a program say takes address of a nested function, GCC knows it needs > executable stack and arranges things automatically. > Otherwise, either an object file can be marked as needing executable > stack (with -Wa,--execstack; at least one such object will make the whole > shared library or binary requiring executable stack), or during link > time with -Wl,-z,execstack or after it using execstack(8) utility. Unfortunately: # execstack -c $(which scheme) execstack: /usr/bin/scheme: Reshuffling of objects to make room for program header entry only supported for shared libraries > The defaults are such that programs and/or libraries compiled/linked > on <= RHL9 are always assumed to potentially require executable stack, > but if you build a new program on FC1, you really need to tell the toolchain > about it. The problem is, these are binaries built on RHL9, but run on FC1. I haven't had the time to look at debug output yet, an strace fragment can be found here: https://bugzilla.fedora.us/show_bug.cgi?id=823 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gemi at bluewin.ch Mon Nov 17 20:28:42 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Mon, 17 Nov 2003 21:28:42 +0100 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <200311171912.hAHJC2Cg015459@magilla.sf.frob.com> References: <200311171912.hAHJC2Cg015459@magilla.sf.frob.com> Message-ID: <1069100922.20884.17.camel@scriabin.tannenrauch.ch> On Mon, 2003-11-17 at 20:12, Roland McGrath wrote: > > The official binary of mit-scheme 7.7.1 (http://www.gnu.org/software/mit-scheme) > > segfaults if called with 'scheme -compiler'. In this case the scheme main > > program load a 'band' called compiler.com, which contains executable code. > > Could somebody investigate this issue? I am not that familiar with problems > > like this. > > If this binary was created with old tools and has no PT_GNU_STACK marker, > then it should get executable stack by default. More likely the issue is > that it calls malloc and expects the memory returned to be executable. > The Scheme runtime needs to be changed to use mmap when executability matters. I further investigated problem using scheme-7.7.90 and found the following. When loading a band (the runtime image), the following is called: static void * mmap_heap_malloc_1 (unsigned long requested_length, int fixedp) { unsigned long ps = (UX_getpagesize ()); void * addr = (mmap (((void *) MMAP_BASE_ADDRESS), (((requested_length + (ps - 1)) / ps) * ps), (PROT_EXEC | PROT_READ | PROT_WRITE), (MAP_PRIVATE | MAP_ANONYMOUS | (fixedp ? MAP_FIXED : 0)), /* Ignored by GNU/Linux, required by FreeBSD and Solaris. */ (-1), 0)); return ((addr == MAP_FAILED) ? 0 : addr); } Now for the default runtime (runtime.com), requested_length == 5726028, and the function proceeds without fault. However when the "-compiler" switch is used to load the compiler, the all.com runtime is loaded and then requested_length == 18563072 (this image is much bigger) and the mmap call results in a segfault. ps is 4096, fixedp is 1 and MMAP_BASE_ADDRESS == 4096. Why does mmap segfault at all? Shouldn't it at worst return an error? Hope this helps... -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From roland at redhat.com Mon Nov 17 20:32:22 2003 From: roland at redhat.com (Roland McGrath) Date: Mon, 17 Nov 2003 12:32:22 -0800 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: Tim Daly's message of Monday, 17 November 2003 13:47:04 -0500 <200311171847.hAHIl4H09514@rio.sci.ccny.cuny.edu> Message-ID: <200311172032.hAHKWMBQ015679@magilla.sf.frob.com> > I just built a machine with the latest Fedora and tried to build Axiom. > Axiom depends on GCL, Gnu Common Lisp. It appears that all of the > lisps are broken under the new memory model. > > Can you give me some pointers to any documentation or source code in > Fedora that might give me a clue about how to fix this? I understand > there might be a compiler switch but haven't found any documentation. Unfortunately I don't think we've succeeded in getting proper documentation up to date in step with the implementation of the features. I have written this explanation up a couple of times, but AFAIK there is no good place to look for it. Documentation volunteers take note! :-) The important changes have to do with what memory will be executable (i.e. have the PROT_EXEC bit set on those pages). If you have an issue with memory layout that changed, other than the question of executability, then you almost surely have a bug in your application or have uncovered one in the system. I'd be glad to help you understand which of those it is and how to fix it. There is at least one known issue of this nature (brk address). Please try to determine if nonexecutability alone is what's breaking you, and if not, please post the details of your problem so we can determine what different problem there might be. The status quo ante was that the stack was executable, and the brk area (used by malloc for small allocations) was executable, and on x86 pages with PROT_READ set but PROT_EXEC did not have any enforcement of nonexecutability anyway. All of these things are either just as they were before, or different now, on a per-process granularity (changed by exec calls). System-wide, you can disable the exec-shield functionality with: echo 0 > /proc/sys/kernel/exec-shield If that doesn't make your binaries work, then you probably have a different problem. If it does, then the system-wide switch is a stop-gap you can use while getting your binaries fixed. We have also overloaded the inherited "personality" setting so you can disable it per-process: setarch i386 foobar That runs "foobar" with the "personality" bits set such that exec-shield is disabled for that process and its children (unless one of them uses setarch or is setuid or somesuch). Again, if that doesn't make your binaries work, then you probably have a different problem. If disabling exec-shield momentarily does work around your problem, then you want to figure out why you had to do that. The most common situation is that you were using executable stack in some way that you don't really need to, e.g. GCC nested function trampolines. You can avoid that by rewriting the code not to use trampolines (i.e. take the address of a nested function that uses its parent's local variables). Things like Lisp systems that produce executable code at run time should generally avoid using stack space for that. You also should not be using malloc or direct brk/sbrk calls to get memory that you need to be executable--you have never had a specified guarantee that malloc returns executable memory. For dynamic allocation of memory where you need to put executable code, use mmap with PROT_READ|PROT_WRITE|PROT_EXEC. It is also fine to mmap with different protections and then use mprotect with e.g. PROT_READ|PROT_EXEC later. It is not proper to call mprotect on memory returned by malloc, because when you free that memory later it may be reused in ways that don't require the executability. The same goes for the brk area. (It's also the case that no specification guarantees that mprotect is meaningful on malloc-returned space, though in fact it will also work as you expect on malloc and brk/sbrk space in Linux and probably all Unixoid systems.) If you have a genuine need for executable stack, you can put a marker in your binary to tell the system that's what you want. This marker goes in ELF executables (and DSOs) as the PT_GNU_STACK phdr entry, with p_flags containing PF_X to indicate need for executable stack and not containing PF_X to indicate no need for executable stack. I'll describe how to compile those markers in a little later. When a binary does not have any PT_GNU_STACK marker at all, as is the case with binaries produced by all older tool versions, it's treated as needing executable stack to be safe. That should retain compatibility with older systems. The story is the same for DSOs as for executable files. The difference is that while the kernel looks for the marker in executable files at exec time, the dynamic linker looks at the marker in DSOs when it's loading them. This is because an executable file that itself does not require an executable stack might load a DSO at runtime (either as a needed library or by using dlopen, e.g. for plug-in libraries) that does require executable stack. In this instance, the dynamic linker stops and makes all the stacks executable before completing the load of the DSO in question. Note that this support applies only to the stack--if a DSO dynamically allocates memory it needs to be executable and does that the wrong way, no marker will work around it, the code just has to be fixed. If you have an old DSO binary that it's not feasible for you to rebuild for some reason (e.g. 3rd-party plug-ins for your applications), you can try marking it using the `execstack' utility (part of the `prelink' rpm). execstack edits an existing ELF binary for you, either to add a PT_GNU_STACK phdr if it's missing or to set or clear the PF_X flag. `execstack -q FILE' will tell you the current status of that file: X for executable, - for not, and ? for an old binary with no marker at all. (You can also use readelf -l or objdump -p to see the phdrs.) Note that there should never really be a need to add a marker to an old executable file because of the compatibility default--a good thing, since execstack cannot move things around to make room for the phdr in an executable as it can in a DSO. Remember, the default when there is no marking is to assume executable stack is required for compatibility with older systems. Ergo, you don't need to add a marker if it would have PF_X set. The reason to add a marker is to avoid enabling executable stack at runtime when it's not really needed. When compiling from source with current tools (including those in FC1), you don't usually need to do anything special to get the right markers into your binaries. The way it works is that the linker produces the PT_GNU_STACK marker when there are special marker sections in the input object files, called ".note.GNU-stack". The flags of these sections determine the flags of the PT_GNU_STACK entry. Your object files (.o) will normally have these sections because GCC emits them in its assembler output. When GCC compiles nested function trampoline code, it emits a .note.GNU-stack section with the SHF_EXECINSTR flag set: .section .note.GNU-stack, "x", @progbits .previous When GCC compiles a module that does not contain any code requiring executable stack, it emits the complementary marker section with no SHF_EXECINSTR flag bit: .section .note.GNU-stack, "", @progbits .previous If you have assembly code of your own, then you need to add these markers. The best way is to amend the source code with one of the assembly directives above. If that is problematic for some reason, another thing you can do is tell the assembler directly what to emit on the command line using -Wa,--execstack or -Wa,--noexecstack. Finally, if you want to punt altogether on marking your .o files properly, you can tell the linker to ignore the marker sections and override its output setting directly on the command using -Wl,-z,execstack or -Wl,-z,noexecstack. Thanks, Roland From notting at redhat.com Mon Nov 17 20:44:07 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Nov 2003 15:44:07 -0500 Subject: PPC rawhide headers incomplete In-Reply-To: <20031117075231.GG14052@ensim.rackshack.net> References: <20031117075231.GG14052@ensim.rackshack.net> Message-ID: <20031117204407.GG794@devserv.devel.redhat.com> Paul Nasrat (pauln at truemesh.com) said: > http://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/headers/ > > Seems to be only upto kakasi :( > > Could someone check yum-arch -s on the tree manually in case > it's barfing, else there may be some sort of failure in the push. There was, it should sort itself out. We're tracking down a race in the build process. Bill From jaboutboul at speakeasy.net Mon Nov 17 21:04:06 2003 From: jaboutboul at speakeasy.net (Jack Aboutboul) Date: Mon, 17 Nov 2003 16:04:06 -0500 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> Message-ID: <1069103046.18050.1.camel@localhost.localdomain> Try doing this to disable exec-shield, which was a wise incorporation into the fedora kernel, imho. Do "echo 0 > /proc/sys/kernel/exec-shield" This was put in specifically to make stacks not executable. Hope it helps, Jack From sopwith at redhat.com Mon Nov 17 21:16:51 2003 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 17 Nov 2003 16:16:51 -0500 (EST) Subject: Possible Project: CVS account manager Message-ID: If there are any volunteers out there looking for a project, there's a need for a set of CVS account management scripts to be written. These scripts, and the accompanying database, would make it easy to do things such as the following: . Store information on contributors such as account name, real name, e-mail address, ssh key, gpg key, account status, comments, etc. . Allow anyone to submit new account requests . Allow authenticated contributors to change info such as their e-mail address. . Allow authenticated administrators to manage accounts, including approving pending accounts, disabling inactive ones, and viewing reports. . Update the CVS repository to reflect account database changes. If all this sounds complicated, it's not. Realistically, it's three scripts to handle user interface, admin interface, and repository maintenance. postgresql is likely to be the DB. An implementation in python would be optimal, but the first priority is something that works. The most important thing is to make this system useful for the Fedora CVS repository, but it should be generic enough to be used by other projects. The trick is making it nice and polished so that it will save a lot of work in the future. Of course, if anyone knows of a system that already does this type of stuff, I'd be glad to hear about it! -- Elliot From fs111 at web.de Mon Nov 17 21:25:59 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Mon, 17 Nov 2003 22:25:59 +0100 Subject: openoffice.org missing .jar classes In-Reply-To: <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> References: <1069065990.5335.28.camel@marte.biciclete.ro> <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> Message-ID: <1069104359.7951.7.camel@localhost> Am Mo, den 17.11.2003 schrieb Dan Williams um 16:09: > Hi, Hi! > You don't :) Well, that's not completely true. > > First, the issue of missing Java. We do not build OOo with Java > enabled, because we cannot distribute a JVM with Fedora. But isn't it possible to make it user selectable like the original OO-installer does? Or just put the Java-things into another package which is not installed by default an gives a warning that it needs an installed JVM or somthing like this. I understand that it isn't possible to have a JVM in fedora but I think many people are interested in the java-facilities of OO me included. > What I'm looking at is a good way to perhaps _build_ with Java here, but > allow OOo to run on non-Java-enabled systems and Java-enabled systems at > the same time. That's not exactly easy though. But doesn't the original-installer allow you to enable the Java-Support at installation-time and not at compiletime? > > For the time being, if you'd like to use Java, I'd suggest grabbing the > SRPM and removing the "--disable-java" from the ./configure options, and > also commenting out all the "handle-no-solar-java" patches. How long does it take and how much diskspace am I needing to build an OO that way? > Dan Andr? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From roland at redhat.com Mon Nov 17 20:50:11 2003 From: roland at redhat.com (Roland McGrath) Date: Mon, 17 Nov 2003 12:50:11 -0800 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: Gerard Milmeister's message of Monday, 17 November 2003 21:28:42 +0100 <1069100922.20884.17.camel@scriabin.tannenrauch.ch> Message-ID: <200311172050.hAHKoB9l015764@magilla.sf.frob.com> > static void * > mmap_heap_malloc_1 (unsigned long requested_length, int fixedp) > { > unsigned long ps = (UX_getpagesize ()); > void * addr > = (mmap (((void *) MMAP_BASE_ADDRESS), > (((requested_length + (ps - 1)) / ps) * ps), > (PROT_EXEC | PROT_READ | PROT_WRITE), > (MAP_PRIVATE | MAP_ANONYMOUS | (fixedp ? MAP_FIXED : 0)), > /* Ignored by GNU/Linux, required by FreeBSD and Solaris. */ > (-1), > 0)); > return ((addr == MAP_FAILED) ? 0 : addr); > } > > Now for the default runtime (runtime.com), requested_length == 5726028, > and the function proceeds without fault. However when the "-compiler" > switch is used to load the compiler, the all.com runtime is loaded and > then requested_length == 18563072 (this image is much bigger) and the > mmap call results in a segfault. ps is 4096, fixedp is 1 and > MMAP_BASE_ADDRESS == 4096. > Why does mmap segfault at all? Shouldn't it at worst return an error? When MAP_FIXED is passed (fixedp!=0), the mapping will overwrite any other mappings that exist. So if the address range overlaps some shared libraries or something like that, it will clobber that part of the address space and who knows what could happen. In older kernels, shared libraries would always end up in a high part of the address space, so assuming a huge low region was available worked. Now shared libraries (and any mmap region) are more likely to be located at random addresses that may be in the low part of the address space. It has never been safe or kosher to assume some large part of the address space would never be used for shared libraries. cscheme needs to change its plan for calling mmap. If you need a big contiguous region of address space into which you will place multiple separate mappings, then the only safe thing to do is to mmap a region of the whole needed size without MAP_FIXED (e.g. using PROT_NONE), and then overwrite portions of that mapping with MAP_FIXED mappings to get the layout you want. Thanks, Roland From aoliva at redhat.com Mon Nov 17 21:35:38 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 17 Nov 2003 19:35:38 -0200 Subject: Possible Project: CVS account manager In-Reply-To: References: Message-ID: On Nov 17, 2003, Elliot Lee wrote: > If there are any volunteers out there looking for a project, there's a > need for a set of CVS account management scripts to be written. > Of course, if anyone knows of a system that already does this type of > stuff, I'd be glad to hear about it! Talk to overseers at sources.redhat.com, I believe we already have this all in place there. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From tromey at redhat.com Mon Nov 17 21:47:09 2003 From: tromey at redhat.com (Tom Tromey) Date: 17 Nov 2003 14:47:09 -0700 Subject: Possible Project: CVS account manager In-Reply-To: References: Message-ID: <87brra1xcy.fsf@fleche.redhat.com> >>>>> "Alexandre" == Alexandre Oliva writes: >> If there are any volunteers out there looking for a project, there's a >> need for a set of CVS account management scripts to be written. Alexandre> Talk to overseers at sources.redhat.com, I believe we already Alexandre> have this all in place there. Not really. The code on sources is really primitive. I wouldn't recommend it. But doesn't SourceForge/gForge already do a lot of what is needed here? Tom From dcbw at redhat.com Mon Nov 17 22:10:32 2003 From: dcbw at redhat.com (Dan Williams) Date: Mon, 17 Nov 2003 17:10:32 -0500 Subject: openoffice.org missing .jar classes In-Reply-To: <1069104359.7951.7.camel@localhost> References: <1069065990.5335.28.camel@marte.biciclete.ro> <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> <1069104359.7951.7.camel@localhost> Message-ID: <1069107032.5196.11.camel@dhcp64-188.boston.redhat.com> On Mon, 2003-11-17 at 16:25, Andr?? Kelpe wrote: > But doesn't the original-installer allow you to enable the Java-Support > at installation-time and not at compiletime? No, it does not. If you do NOT compile with Java at compile-time, then you do not get any Java whatsoever. There are pieces of OOo that require Java to compile. All builds from OpenOffice.org _assume_ that you have installed Java. We cannot assume that Java is installed when building either, hence the possible usage of a Java-disabling switch in the specfile at build-time. Either you build with Java right now, and use it with Java, or you don't build with Java and you cannot expect Java. That's a limitation of OpenOffice.org at this time, NOT Fedora packages (I'd love to be proven wrong because that would make my job easier). If you build with Java and run on a non-Java system, I'm not quite sure what happens, but I'm looking into that and I'll have answers tomorrow. We may be linking against some stuff on Linux (like the berkeleydb libdb-java) that won't be available on a non-java system, and therefore segfaults OOo when it can't be found. > How long does it take and how much diskspace am I needing to build an OO > that way? Oh, about 6GB for all language packs, and about 4 hours on a dual Xeon 2.4Ghz with 1GB of RAM. Don't try this on a Celeron or anything less than a PII 400. Dan From memeyou at memeyou.net Mon Nov 17 22:10:36 2003 From: memeyou at memeyou.net (Thomas Ryan Gordon Sr) Date: Mon, 17 Nov 2003 12:10:36 -1000 Subject: Self-Introduction: Steven Pritchard In-Reply-To: <20031117075723.GA19585@osiris.silug.org> References: <20031117075723.GA19585@osiris.silug.org> Message-ID: <3FB9475C.6000209@memeyou.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven Pritchard wrote: | Some of the more interesting packages in my repository include | amavis-ng, clamav, courier-imap, kernel-hostap-driver, | perl-HTML-Mason, and perl-Tk. hostap support for fedora would be a big plus for my next mobile router. (Senao parts are in the mail!) Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/uUdcSM0VWiAMmtsRAh2FAJ415Yp9LThrDyMV6Az/2F4hzG6URwCeKnD+ AbSjhjzA6Z3qjidTD6VbhRM= =nBhJ -----END PGP SIGNATURE----- From Nicolas.Mailhot at laPoste.net Mon Nov 17 22:16:45 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 17 Nov 2003 23:16:45 +0100 Subject: openoffice.org missing .jar classes In-Reply-To: <1069104359.7951.7.camel@localhost> References: <1069065990.5335.28.camel@marte.biciclete.ro> <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> <1069104359.7951.7.camel@localhost> Message-ID: <1069107405.4584.1.camel@m70.net81-64-235.noos.fr> Le lun 17/11/2003 ? 22:25, Andr? Kelpe a ?crit : > But isn't it possible to make it user selectable like the original > OO-installer does? Or just put the Java-things into another package > which is not installed by default an gives a warning that it needs an > installed JVM or somthing like this. I understand that it isn't possible > to have a JVM in fedora but I think many people are interested in the > java-facilities of OO me included. > If you can split the java parts in a separate srpm/rpm pair JPackage will host it. 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 xose at wanadoo.es Mon Nov 17 22:26:10 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Mon, 17 Nov 2003 23:26:10 +0100 Subject: rawhide report: 20031116 changes References: <200311171124.hAHBOUq17636@porkchop.devel.redhat.com> Message-ID: <3FB94B02.1080406@wanadoo.es> Build System wrote: > reiserfs-utils-3.x.0f-1 > ----------------------- > * Mon Mar 05 2001 Bernhard Rosenkraenzer > > - Update to 3.x.0f, many important fixes in fsck > - Add missing README (#30556) > - Use -v2 by default in mkreiserfs (#30556) reiserfs-utils-3.x.0f-1 is obsolete, it can be delete. And I believe that libffi-20010609-1.src.rpm kernel-2.4.9-31.1.src.rpm too. -- HTML mails are going to trash automagically From warren at togami.com Mon Nov 17 23:20:02 2003 From: warren at togami.com (Warren Togami) Date: Mon, 17 Nov 2003 13:20:02 -1000 (HST) Subject: Self-Introduction: Steven Pritchard In-Reply-To: <3FB9475C.6000209@memeyou.net> References: <20031117075723.GA19585@osiris.silug.org> <3FB9475C.6000209@memeyou.net> Message-ID: <9168.128.171.123.60.1069111202.squirrel@togami.com> > hostap support for fedora would be a big plus for my next mobile > router. (Senao parts are in the mail!) > Do you folks know if the SMC2602 PCI adapter containing the SMC2632 prism2 based card is supported by hostap? Warren From notting at redhat.com Mon Nov 17 22:37:16 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Nov 2003 17:37:16 -0500 Subject: rawhide report: 20031116 changes In-Reply-To: <3FB94B02.1080406@wanadoo.es> References: <200311171124.hAHBOUq17636@porkchop.devel.redhat.com> <3FB94B02.1080406@wanadoo.es> Message-ID: <20031117223716.GA959@devserv.devel.redhat.com> Xose Vazquez Perez (xose at wanadoo.es) said: > Build System wrote: > > > reiserfs-utils-3.x.0f-1 > > ----------------------- > > * Mon Mar 05 2001 Bernhard Rosenkraenzer > > > > - Update to 3.x.0f, many important fixes in fsck > > - Add missing README (#30556) > > - Use -v2 by default in mkreiserfs (#30556) > > reiserfs-utils-3.x.0f-1 is obsolete, it can be delete. And I believe > that libffi-20010609-1.src.rpm kernel-2.4.9-31.1.src.rpm too. Those are most probably the latest versions of those packages for some architecture included in rawhide. Although, libffi can die. Bill From jaap at haitsma.org Mon Nov 17 22:59:08 2003 From: jaap at haitsma.org (Jaap A. Haitsma) Date: Mon, 17 Nov 2003 23:59:08 +0100 Subject: Possible Project: CVS account manager In-Reply-To: <87brra1xcy.fsf@fleche.redhat.com> References: <87brra1xcy.fsf@fleche.redhat.com> Message-ID: <3FB952BC.2090907@haitsma.org> Tom Tromey wrote: >>>>>>"Alexandre" == Alexandre Oliva writes: > > >>>If there are any volunteers out there looking for a project, there's a >>>need for a set of CVS account management scripts to be written. > > > Alexandre> Talk to overseers at sources.redhat.com, I believe we already > Alexandre> have this all in place there. > > Not really. The code on sources is really primitive. I wouldn't > recommend it. > > But doesn't SourceForge/gForge already do a lot of what is needed > here? > You guys probably know this, but just in case. You could use the savannah software (a further development of an older open source version of sourceforge) if you want to host everything yourself. See: http://savannah.gnu.org/projects/savannah/ Jaap From xose at wanadoo.es Mon Nov 17 23:28:11 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Tue, 18 Nov 2003 00:28:11 +0100 Subject: rawhide report: 20031116 changes References: <200311171124.hAHBOUq17636@porkchop.devel.redhat.com> <3FB94B02.1080406@wanadoo.es> Message-ID: <3FB9598B.2050409@wanadoo.es> Xose Vazquez Perez wrote: > reiserfs-utils-3.x.0f-1 is obsolete, it can be delete. And I believe > that libffi-20010609-1.src.rpm kernel-2.4.9-31.1.src.rpm too. one more, sndconfig-0.70-1.src.rpm is obsolete. -- HTML mails are going to trash automagically From ms-nospam-0306 at arcor.de Mon Nov 17 23:31:50 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 18 Nov 2003 00:31:50 +0100 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <1069103046.18050.1.camel@localhost.localdomain> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> Message-ID: <20031118003150.1362efb1.ms-nospam-0306@arcor.de> On Mon, 17 Nov 2003 16:04:06 -0500, Jack Aboutboul wrote: > Try doing this to disable exec-shield, which was a wise incorporation > into the fedora kernel, imho. > > Do "echo 0 > /proc/sys/kernel/exec-shield" > > This was put in specifically to make stacks not executable. > > Hope it helps, As pointed out in the corresponding fedora.us package request bug, disabling exec-shield is not enough. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamesaharrisonuk at yahoo.co.uk Mon Nov 17 23:46:50 2003 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Mon, 17 Nov 2003 15:46:50 -0800 (PST) Subject: redhat-config-xfree86 Spanning Desktops not working Message-ID: <20031117234650.55696.qmail@web25107.mail.ukl.yahoo.com> Hi all, Ive just had to do something to get the multi-head video card to work properly on my system. I was trying to get the Spanning Desktops working from the GUI tool but couldnt. This is part of the /etc/X11/XF86Config after I changed it: Section "Device" Identifier "Videocard1" Driver "mga" VendorName "Videocard Vendor" BoardName "Matrox Millennium G550" BusID "PCI:1:0:0" Screen 1 EndSection I had to add the "Screen 1" part and then I had a spanning desktop. Im not sure if this is a bug or something Im not doing right. My hardware setup: x2 Sony Sony CPD-G400. Matrox Millennium G550 XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42) Athlon CPU 1G RAM ASUS A7V266E Motherboard Thanks, James Harrison ===== James Harrison __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree From jamesaharrisonuk at yahoo.co.uk Mon Nov 17 23:46:39 2003 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Mon, 17 Nov 2003 15:46:39 -0800 (PST) Subject: Fwd: redhat-config-xfree86 Spanning Desktops not working Message-ID: <20031117234639.48814.qmail@web25101.mail.ukl.yahoo.com> Hi all, Ive just had to do something to get the multi-head video card to work properly on my system. I was trying to get the Spanning Desktops working from the GUI tool but couldnt. This is part of the /etc/X11/XF86Config after I changed it: Section "Device" Identifier "Videocard1" Driver "mga" VendorName "Videocard Vendor" BoardName "Matrox Millennium G550" BusID "PCI:1:0:0" Screen 1 EndSection I had to add the "Screen 1" part and then I had a spanning desktop. Im not sure if this is a bug or something Im not doing right. My hardware setup: x2 Sony Sony CPD-G400. Matrox Millennium G550 XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42) Athlon CPU 1G RAM ASUS A7V266E Motherboard Thanks, James Harrison ===== James Harrison __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree From smoogen at lanl.gov Tue Nov 18 00:12:33 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 17 Nov 2003 17:12:33 -0700 (MST) Subject: Possible Project: CVS account manager In-Reply-To: <3FB952BC.2090907@haitsma.org> Message-ID: I have been told we have a couple of groups that have either used savannah or the version that the original developer has been using. Both those groups have been happy with what they got, and it covers the items you listed. It is of course a lot more complicated than 3 scripts. On Mon, 17 Nov 2003, Jaap A. Haitsma wrote: >Tom Tromey wrote: > >>>>>>>"Alexandre" == Alexandre Oliva writes: >> >> >>>>If there are any volunteers out there looking for a project, there's a >>>>need for a set of CVS account management scripts to be written. >> >> >> Alexandre> Talk to overseers at sources.redhat.com, I believe we already >> Alexandre> have this all in place there. >> >> Not really. The code on sources is really primitive. I wouldn't >> recommend it. >> >> But doesn't SourceForge/gForge already do a lot of what is needed >> here? >> >You guys probably know this, but just in case. You could use the >savannah software (a further development of an older open source version >of sourceforge) if you want to host everything yourself. >See: >http://savannah.gnu.org/projects/savannah/ > >Jaap > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From enrico.scholz at informatik.tu-chemnitz.de Tue Nov 18 02:12:28 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 18 Nov 2003 03:12:28 +0100 Subject: Self-Introduction: Steven Pritchard In-Reply-To: <1069096008.11764.59.camel@skilletinfopleasecom.nh.pearsoned.com> (Karl DeBisschop's message of "Mon, 17 Nov 2003 14:06:49 -0500") References: <20031117075723.GA19585@osiris.silug.org> <3FB88E19.8050505@togami.com> <20031117184151.GA21606@osiris.silug.org> <1069096008.11764.59.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <87islifmr7.fsf@kosh.ultra.csn.tu-chemnitz.de> kdebisschop at alert.infoplease.com (Karl DeBisschop) writes: >> > clamav is currently in QA queue and we would really appreciate your >> > suggestions on that package. > > I'd like to look at that as well, but being very new to Fedora I'm not > finding the 'QA Queue' This can be found at http://fedora.us -> 'Enter (the old)...homepage' -> 'QA Priority Queue' (right side, under 'Package Development') > or any proposed clamav SRMS. https://bugzilla.fedora.us/show_bug.cgi?id=268 > Sorry for the newbie question, but can someone give me a link to where > these are, or more generally how the QA process will work? The fedora.us wiki should answer this question, interesting might by http://www.fedora.us/wiki/PackageSubmissionQAPolicy ("QA Testing Procedure"), and http://www.fedora.us/wiki/QAChecklist You can look at old bugreports also ("PUBLISH Queue"), to see examples of the QA process. Enrico From roland at redhat.com Tue Nov 18 03:35:20 2003 From: roland at redhat.com (Roland McGrath) Date: Mon, 17 Nov 2003 19:35:20 -0800 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: Chris Hanson's message of Monday, 17 November 2003 21:00:12 -0500 Message-ID: <200311180335.hAI3ZKsj017246@magilla.sf.frob.com> > I appear to be missing some of the context of this discussion. What > kernels have this behavior? I have run MIT/GNU Scheme on Debian > unstable using many different 2.4 and a handful of 2.6-test kernels, > and I haven't seen this problem. This is about Fedora Core 1 kernels (http://fedora.redhat.com), which have some changes to how mapping addresses are chosen. > That mapping code dates back to the days of libc5. At that time, if > you tried to map some space that overlapped a shared library, you got > an error. I can't speak to that vintage of Linux libc or Linux kernels. The specification of mmap has always been that MAP_FIXED overwrites other mmap mappings, and in no recent time have shared libraries been anything other than mmap mappings. > But the problem remains that this code doesn't do what it's supposed > to. Is there some way for me to probe the address space to find the > largest hole in a given region of the space? (Not using signal > handlers to catch SIGSEGV traps!) If you want a Linux-specific kludge, you can always see the complete memory map by looking at /proc/self/maps. If you want a portable programmatic solution correct for POSIX systems with mmap, the only kind of probing you can do is try large mmaps without MAP_FIXED and see where they fit. > [...] we need the largest possible block of space under 2^26 -- ideally > all of it. I see. > It's possible to modify the implementation to handle a block outside > of this space I don't think you should have to. Your address space is yours to control. You just haven't been exercising control in the specified proper ways. > Faced with this situation, I'll probably just statically link the > program. Support for static linking is severely limited in a variety of ways. If you make any but the most low-level use of system library facilities, static linking is almost certainly a recipe for future aggravation. > IMO it's a bug that the application doesn't have any control over its > address space. The application has complete control over its address space within the size limits provided by the kernel (3GB with most Linux kernels, 4GB-16MB with some FC1 kernels). Presumption of what addresses the kernel will use in cases where the specification says it may choose any address, is not an aspect of the control interface. > I should be able to tell the linker and loader that certain areas are > reserved. That's possible with the linker, but I'm not aware of any way > to control the loader. I'm not sure what level of control you have in mind when you distinguish what you can specify to the linker and to the loader, or whether by "the loader" you mean the kernel's loading of executable files, or the dynamic linker's loading of DSOs, or both. I don't see why it's not sufficient to specify the layout you want at link time. That you can do. If your executable contains PT_LOAD program header entries for each region you want reserved, it will be. You can use entries with none of PF_[RWX] set to get PROT_NONE mappings that you can overwrite later with MAP_FIXED mappings. > So why does the kernel care where shared libraries are mapped? Why is > the application working for the kernel instead of the other way around? You are misrepresenting reality. The kernel does not care. You specified that you did not care, and so the kernel is doing what it thinks might be best for you given the constraints you have specified. From daly at rio.sci.ccny.cuny.edu Tue Nov 18 01:41:55 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Mon, 17 Nov 2003 20:41:55 -0500 Subject: [ms-nospam-0306@arcor.de: Re: Executable memory: some apps that work on RH9 don't on FC1] Message-ID: <200311180141.UAA09006@springbok.sci.ccny.cuny.edu> Michael, Can you give me a URL where I can find the information you reference? Tim axiom at tenkan.org daly at idsi.net ------- Start of forwarded message ------- From: Michael Schwendt To: fedora-devel-list at redhat.com Subject: Re: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <1069103046.18050.1.camel at localhost.localdomain> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__18_Nov_2003_00_31_50_+0100_.PiWBcWWL0dSn_Ee" X-loop: fedora-devel-list at redhat.com Sender: fedora-devel-list-admin at redhat.com X-BeenThere: fedora-devel-list at redhat.com X-Mailman-Version: 2.0.13 Precedence: junk Reply-To: fedora-devel-list at redhat.com List-Help: List-Post: List-Subscribe: , List-Id: For developers, developers, developers List-Unsubscribe: , List-Archive: Date: Tue, 18 Nov 2003 00:31:50 +0100 - --Signature=_Tue__18_Nov_2003_00_31_50_+0100_.PiWBcWWL0dSn_Ee Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Mon, 17 Nov 2003 16:04:06 -0500, Jack Aboutboul wrote: > Try doing this to disable exec-shield, which was a wise incorporation > into the fedora kernel, imho. > > Do "echo 0 > /proc/sys/kernel/exec-shield" > > This was put in specifically to make stacks not executable. > > Hope it helps, As pointed out in the corresponding fedora.us package request bug, disabling exec-shield is not enough. - -- - --Signature=_Tue__18_Nov_2003_00_31_50_+0100_.PiWBcWWL0dSn_Ee Content-Type: application/pgp-signature - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/uVpr0iMVcrivHFQRAmBCAJ4nZbnSxswJsI5hr5yhH3QNeJ8/fgCeK0BE QzqJubgPuAD4lZUORsSjm+0= =OOzc - -----END PGP SIGNATURE----- - --Signature=_Tue__18_Nov_2003_00_31_50_+0100_.PiWBcWWL0dSn_Ee-- - -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list ------- End of forwarded message ------- From daly at rio.sci.ccny.cuny.edu Tue Nov 18 01:45:02 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Mon, 17 Nov 2003 20:45:02 -0500 Subject: rpm database bug Message-ID: <200311180145.UAA09014@springbok.sci.ccny.cuny.edu> (I tried to find a bug mailing list but failed) While trying to: rpm -i tetex-fonts-2.0.2-8.i386.rpm I got the following error message: rpmdb: page 1647: illegal page type or format rpmdb: PANIC: Invalid argument rpmdb: /var/lib/rpm/Packages: pgin failed for page 1647 rpmdb: fatal region error detected; run recovery rpmdb: fatal region error detected; run recovery rpmdb: db4 error(-30982) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: fatal region error detected; run recovery rpmdb: db4 error(-30982) from dbcursor->c_close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: fatal region error detected; run recovery rpmdb: db4 error(-30982) from db->cursor: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: fatal region error detected; run recovery rpmdb: db4 error(-30982) from db->get: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: fatal region error detected; run recovery rpmdb: db4 error(-30982) from db->open: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: fatal region error detected; run recovery rpmdb: db4 error(-30982) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery error: cannot get Providename index using db3 - (-30982) rpmdb: fatal region error detected; run recovery rpmdb: db4 error(-30982) from db->cursor: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: fatal region error detected; run recovery rpmdb: db4 error(-30982) from db->put: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: fatal region error detected; run recovery rpmdb: db4 error(-30982) from db->open: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: fatal region error detected; run recovery rpmdb: db4 error(-30982) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery Note that I'm running using: > System-wide, you can disable the exec-shield functionality with: > > echo 0 > /proc/sys/kernel/exec-shield as I'm trying to find a bug. I need to install latex and the rpm install process failed. I did: rpm --rebuilddb Now rpm seems to work but the database doesn't remember anything. If I do: rpm -i tetex-2.0.2-8-i386.rpm then do: rpm -i tetex-dvips-2.0.2-8.i386.rpm it complains that: error: Failed dependencies: tetex = 2.0.2 is needed by tetex-dvips-2.0.2-8 running: rpm -i tetex-2.0.2-8-i386.rpm tetex-dvips-2.0.2-8.i386.rpm seems to succeed. Tim Daly axiom at tenkan.org daly at idsi.net ------- End of forwarded message ------- From lockhart at jeans.ifa.hawaii.edu Tue Nov 18 03:56:43 2003 From: lockhart at jeans.ifa.hawaii.edu (Charles Lockhart) Date: Mon, 17 Nov 2003 17:56:43 -1000 Subject: pre-emptive kernel question Message-ID: <3FB9987B.7000501@irtf.ifa.hawaii.edu> While trying to generate a RH or FC1 kernel with the rml preemptive kernel patch applied (and failing), I was told that the patch might already be ported into one or both of those kernels (if so, most likely this would be a backport from the 2.5/2.6 kernel). But after looking through the kernel source, while there are places that kernel preemption and rml are mentioned (mostly in comments), I don't see a lot of the functionality that would be needed for kernel preemption via the rml patch. Can someon confirm or deny? Motivation behind this is that I get a substantial system response (ie. my system (which is defined for a specific set of tasks) meets performance requirements) with the patch, but not without it (ie. with the RH/FC1 cores installed). Unfortunately, the system randomly freezes (sometimes after hourse, sometimes after a day or two) with the vanilla kernel, so it doesn't meet requirements for stability. I've considered just waiting until the 2.6 kernel is available, but I have some very specific hardware in the machine, and I'd have to port the drivers myself, which could become quite the time sink (the company that makes the hardware said that they're planning to support the 2.6 kernel sometime around the end of 2004). Also, the primary obstacle to patching the FC1/RH kernels has been (I think) the O1 scheduler (or at least that's where I get the greatest number of failed hunks). Has anyone tried to port this in? There's a O1/preemptive kernel patch, but it's for the 2.4.18 kernel. Has anyone tried this? Would it be possible to port over to the FC1 core kernel? I was able to patch the vanilla 2.4.20 kernel with the preemptive kernel patch, and then step through pretty much all of the RH 2.4.20-8 patches and fix failures as I went, pretty much right up to the end when it was time to add the O1 back port and others, and at that point hit a brick wall. The system is a compaq/hp DL360 G3, dual Xeon P4's, 1GB ram. I've tried both RH9 and FC1, same results. Thank you for your time, -Charles From mike at flyn.org Tue Nov 18 04:00:14 2003 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 17 Nov 2003 22:00:14 -0600 Subject: Self-Introduction: Mike Petullo Message-ID: <20031118040013.GA1101@imp.flyn.org> Hello everyone. I'm Mike Petullo. I've been on this list for a while but am just getting around to attempting to submit packages. I'm from the U.S.A. and currently a resident of Park Ridge (just north of Chicago). I am currently transitioning out of the U.S. Army and hoping to get into a graduate program to earn a M.S. in computer science. I have a B.S. in computer science that I earned at Drake University. My goals in the Fedora Project revolve around the GNOME desktop and security. In the near future, I would like to see my pam_mount (http://www.flyn.org/projects/pam_mount) package included in Fedora. I'd also like to work on adding encrypted root filesystem support to anaconda for use on laptops. I also hope to contribute to GNOME usability. As more of a long-term project, I would like to see an intrusion detection system that is somewhat integrated into Fedora's package management system. I've contributed small patches to several free software projects in the past (see http://www.flyn.org if interested). I wrote the code that added QuickTime support to xawtv's command line video capture tool. I work mostly in C but also know python, scheme and some other languages. I really think XSLT is cool (but the syntax tends to be long-winded). I've been using Linux since 1997. You should trust me because I have a security clearance from the Department of Defense (or maybe that means you should /not/ trust me, depending on your politics!). Here is some of my GPG info: pub 1024D/AEE7BAAA 2003-11-18 W. Michael Petullo (flyn) Key fingerprint = C929 DE01 E466 3271 09EE F3B1 7CE5 4745 AEE7 BAAA sub 2048g/A31771FD 2003-11-18 [expires: 2004-05-16] Okay, enough about me, geez! -- Mike :wq From roland at redhat.com Tue Nov 18 04:47:35 2003 From: roland at redhat.com (Roland McGrath) Date: Mon, 17 Nov 2003 20:47:35 -0800 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: Chris Hanson's message of Monday, 17 November 2003 23:26:30 -0500 Message-ID: <200311180447.hAI4lZ1m017447@magilla.sf.frob.com> > OK, so this is the piece that I'm missing. Where can I learn more > about these header entries? I don't see anything in the libc > reference about this, even though PT_LOAD is defined by libc. libc provides elf.h, yes. The details are part of the ELF spec, available online from e.g. http://www.sco.com/developers/gabi/. Looking at the phdr entries in programs with readelf -l or objdump -p, their meaning is probably obvious. What you are probably interested in is how to control their generation by the linker. You will need to provide your own variant of the normal built-in link script used to link an executable, that uses the PHDRS directive explicitly lay out sections. Here is the usual script from `ld --verbose' for i386-*-linux-gnu hacked to add a leading load segment at 0 for the ".reserved" section. You'll have to give the linker an input section of that name, e.g. with: .section ".reserved","a", at nobits .space 0x4000000 .previous to set the size of the output segment. OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") OUTPUT_ARCH(i386) ENTRY(_start) SEARCH_DIR("/usr/local/i686-pc-linux-gnu/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib"); /* Do we need any of these for elf? __DYNAMIC = 0; */ PHDRS { headers PT_PHDR PHDRS ; interp PT_INTERP ; reserved PT_LOAD FLAGS(0) ; text PT_LOAD FILEHDR PHDRS ; data PT_LOAD ; dynamic PT_DYNAMIC ; } SECTIONS { .reserved 0 : { *(.reserved) } :reserved /* Read-only sections, merged into text segment: */ . = 0x08048000 + SIZEOF_HEADERS; .interp : { *(.interp) } :text :interp .hash : { *(.hash) } :text .dynsym : { *(.dynsym) } .dynstr : { *(.dynstr) } .gnu.version : { *(.gnu.version) } .gnu.version_d : { *(.gnu.version_d) } .gnu.version_r : { *(.gnu.version_r) } .rel.dyn : { *(.rel.init) *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) *(.rel.fini) *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*) *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*) *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*) *(.rel.ctors) *(.rel.dtors) *(.rel.got) *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*) } .rela.dyn : { *(.rela.init) *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) *(.rela.fini) *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*) *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*) *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*) *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*) *(.rela.ctors) *(.rela.dtors) *(.rela.got) *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*) } .rel.plt : { *(.rel.plt) } .rela.plt : { *(.rela.plt) } .init : { KEEP (*(.init)) } =0x90909090 .plt : { *(.plt) } .text : { *(.text .stub .text.* .gnu.linkonce.t.*) /* .gnu.warning sections are handled specially by elf32.em. */ *(.gnu.warning) } =0x90909090 .fini : { KEEP (*(.fini)) } =0x90909090 PROVIDE (__etext = .); PROVIDE (_etext = .); PROVIDE (etext = .); .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) } .rodata1 : { *(.rodata1) } .eh_frame_hdr : { *(.eh_frame_hdr) } /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. */ . = ALIGN (0x1000) - ((0x1000 - .) & (0x1000 - 1)); . = DATA_SEGMENT_ALIGN (0x1000, 0x1000); /* Ensure the __preinit_array_start label is properly aligned. We could instead move the label definition inside the section, but the linker would then create the section even if it turns out to be empty, which isn't pretty. */ . = ALIGN(32 / 8); PROVIDE (__preinit_array_start = .); .preinit_array : { *(.preinit_array) } PROVIDE (__preinit_array_end = .); PROVIDE (__init_array_start = .); .init_array : { *(.init_array) } PROVIDE (__init_array_end = .); PROVIDE (__fini_array_start = .); .fini_array : { *(.fini_array) } PROVIDE (__fini_array_end = .); .data : { *(.data .data.* .gnu.linkonce.d.*) SORT(CONSTRUCTORS) } :data .data1 : { *(.data1) } .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) } .tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) } .eh_frame : { KEEP (*(.eh_frame)) } .gcc_except_table : { *(.gcc_except_table) } .dynamic : { *(.dynamic) } :data :dynamic .ctors : { /* gcc uses crtbegin.o to find the start of the constructors, so we make sure it is first. Because this is a wildcard, it doesn't matter if the user does not actually link against crtbegin.o; the linker won't look for a file to match a wildcard. The wildcard also means that it doesn't matter which directory crtbegin.o is in. */ KEEP (*crtbegin*.o(.ctors)) /* We don't want to include the .ctor section from from the crtend.o file until after the sorted ctors. The .ctor section from the crtend file contains the end of ctors marker and it must be last */ KEEP (*(EXCLUDE_FILE (*crtend*.o ) .ctors)) KEEP (*(SORT(.ctors.*))) KEEP (*(.ctors)) } :data .dtors : { KEEP (*crtbegin*.o(.dtors)) KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors)) KEEP (*(SORT(.dtors.*))) KEEP (*(.dtors)) } .jcr : { KEEP (*(.jcr)) } .got : { *(.got.plt) *(.got) } _edata = .; PROVIDE (edata = .); __bss_start = .; .bss : { *(.dynbss) *(.bss .bss.* .gnu.linkonce.b.*) *(COMMON) /* Align here to ensure that the .bss section occupies space up to _end. Align after .bss to ensure correct alignment even if the .bss section disappears because there are no input sections. */ . = ALIGN(32 / 8); } . = ALIGN(32 / 8); _end = .; PROVIDE (end = .); . = DATA_SEGMENT_END (.); /* Stabs debugging sections. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) } /* DWARF debug sections. Symbols in the DWARF debugging sections are relative to the beginning of the section so we begin them at 0. */ /* DWARF 1 */ .debug 0 : { *(.debug) } .line 0 : { *(.line) } /* GNU DWARF 1 extensions */ .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } /* DWARF 1.1 and DWARF 2 */ .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } /* DWARF 2 */ .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } /* SGI/MIPS DWARF 2 extensions */ .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) } /DISCARD/ : { *(.note.GNU-stack) } } From daly at rio.sci.ccny.cuny.edu Tue Nov 18 03:29:41 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Mon, 17 Nov 2003 22:29:41 -0500 Subject: Executable memory: some apps that work on RH9 don't on FC1 Message-ID: <200311180329.WAA09228@springbok.sci.ccny.cuny.edu> If I do: echo 0 >/proc/sys/kernel/exec-shield the GCL build succeeds. If I do: echo 1 >/proc/sys/kernel/exec-shield the GCL build fails. Tim Daly axiom at tenkan.org daly at idsi.net From laurent at guerby.net Tue Nov 18 07:27:23 2003 From: laurent at guerby.net (Laurent GUERBY) Date: Tue, 18 Nov 2003 08:27:23 +0100 Subject: ATI radeon 9600 Pro / willing to test and report Message-ID: <1069140442.4011.25.camel@dell> Hi, I've just installed Fedora Core 1 on my new machine wich has an ATI Radeon 9600 Pro. All I've got is a 640x480 resolution with the vesa driver on my Hyundai Q17 LCD 17" (1280x1024) but it's working :). I tried the generic radeon, it gets the right resolution but it freezes the machine after a few seconds. I've run up2date to get a few packages, if some newer xfree fedora packages are available which supports my graphic card (2D is good enough for me), what should I do to access them? (I would be delighted to use a GUI for that, but editing config file is ok too :). Just a small note: most of GUI tools are unusable at 640x480 since you cannot access the buttons at the bottom of the window, sometimes even after a resize. I don't know if the GUI guidelines say something about supporting 640x480. Thanks in advance, Laurent Ps: I'm posting here because Mike Harris suggested this list in his message "Newer ATI Radeon, ATI FireGL, and Nvidia GeForce/Quadro hardware support" on Oct 21, sorry if this is the wrong list. -------------- next part -------------- A non-text attachment was scrubbed... Name: XFree86.0.log.gz Type: application/x-gzip Size: 7172 bytes Desc: not available URL: From kjb at dds.nl Tue Nov 18 08:49:40 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Tue, 18 Nov 2003 09:49:40 +0100 Subject: openoffice.org missing .jar classes In-Reply-To: <1069107032.5196.11.camel@dhcp64-188.boston.redhat.com> References: <1069065990.5335.28.camel@marte.biciclete.ro> <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> <1069104359.7951.7.camel@localhost> <1069107032.5196.11.camel@dhcp64-188.boston.redhat.com> Message-ID: <3FB9DD24.8020205@dds.nl> Dan Williams wrote: > >Either you build with Java right now, and use it with Java, >or you don't build with Java and you cannot expect Java. That's a >limitation of OpenOffice.org at this time, NOT Fedora packages (I'd love >to be proven wrong because that would make my job easier). > What about the openoffice.org builds? At install time it asks about the installed JRE location, but you can skip that step. Is the install broken then? Klaasjan From johnsonm at redhat.com Tue Nov 18 20:29:25 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 18 Nov 2003 15:29:25 -0500 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <200311180335.hAI3ZKsj017246@magilla.sf.frob.com> References: <200311180335.hAI3ZKsj017246@magilla.sf.frob.com> Message-ID: <20031118202925.GA22980@devserv.devel.redhat.com> On Mon, Nov 17, 2003 at 07:35:20PM -0800, Roland McGrath wrote: > The application has complete control over its address space within the size > limits provided by the kernel (3GB with most Linux kernels, 4GB-16MB with > some FC1 kernels). Presumption of what addresses the kernel will use in FYI: actually, the 4GB-16MB kernel is the "hugemem" kernel we ship in RHEL 3 but not in Fedora Core. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From czar at czarc.net Tue Nov 18 20:53:40 2003 From: czar at czarc.net (Gene C.) Date: Tue, 18 Nov 2003 15:53:40 -0500 Subject: gFTP 2.0.14 In-Reply-To: <1069183174.15738.1.camel@GreenTea> References: <3FB9B5A3.9040505@staticnull.org> <1069183174.15738.1.camel@GreenTea> Message-ID: <200311181553.40739.czar@czarc.net> On Tuesday 18 November 2003 14:19, Phillip Compton wrote: > On Tue, 2003-11-18 at 01:01, Jonathan C. Sitte wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Seems odd to me but gFTP 2.0.14 is crashing on me allot. Anyone else > > have this problem? Also when I use to upload images some of them do not > > upload entirely. Just wondering if it is just me. :) > > Have you tried 2.0.16 > > https://bugzilla.fedora.us/show_bug.cgi?id=677 > > 2.0.14 and 2.0.15 seemed to crash a fair amount on me, bu 2.0.16 has > been rock solid. I agree about gftp-2.0.16 being rock solid. In addition, it fixes handling of http so that it actually works correctly. However, I do not understand the posting of a gftp update to fedora.us. This package is part of Fedora Core 1. Shouldn't this update be part of the updates flowing out of the Red Hat errata process? While Red Hat updates do not always come out to "my" schedule (I want it "now" ;), how are users to differentiate between those available through http://download.fedora.redhat.com and those from http://download.fedora.us ? This duplication does not make sense to me. While making updated packages available through some "private" repository or server is OK with me, making them available through http://download.fedora.us is confusing since it carries some "official" status. I really do not like cross-posting but will CC the devel list on this since I believe it is an important issue and is more likely to be addressed there (with the lower email volume). I really empathize with the problem of needing an updated package and not being sure just when it will come from Red Hat since their limited resources are covering lots of areas and sometimes cannot address things like gftp as soon as some of us would like (yes, I had already built 2.0.16 packages for myself). Perhaps there is some middle ground where user (non Red Hat) updated packages of packages in the Core can be placed and it would be clear that these were user updates. It was/is my understanding that fedora.us focuses on "Extras" and "Legacy" rather than quick updates of packages in Fedora Core. I would really like to hear from some Red Hat folks on this. I would like to see some means of folks outside of Red Hat providing updated packages where Red at currently does not have to resources available to do them "right now". After all, the whole idea of the Fedora Project is to leverage (utilize) resources outside of Red Hat to deliver a better product that could be done using only Red Hat resources. Some of this may "shake out" over the next few months as the whole Fedora process develops. -- Gene From dcbw at redhat.com Tue Nov 18 21:14:39 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 18 Nov 2003 16:14:39 -0500 Subject: OpenOffice.org and Java in Fedora Message-ID: <1069190078.30461.3.camel@dhcp64-188.boston.redhat.com> Hi, After some thought and discussion, I've come to the following conclusion: Since Fedora does not include Java for licensing reasons, all Red Hat-built OpenOffice.org RPMs for Fedora will NOT include Java support, and will NOT be built with Java enabled. It's not good form to supply an RPM that cannot be built on the platform it is intended for. Therefore, when you install Fedora and OOo, anything that requires Java will not function. However, I will attempt to keep a "Java-enable" switch in the specfile that will allow Java-enabled building on Fedora, provided you have a JRE/JDK installed. I will attempt to keep Java-enabled building up-to-date and functional. In the future, I hope OOo will compile using gcj or other free Java environments. This is something we'll be working towards, and other shave this same goal in mind (Debian). When gcj is able to compile the Java bits of OOo, the Fedora RPMs will include those patches. Its going to mean some work though. So in summary, I'm not going to build Java-enabled RPMs of OOo for the time being. But if you'd like them, I'm happy to keep it possible (and will try to keep it building out-of-the-box with a specfile switch). If anyone would like to help out in getting OOo to work with gcj or other free Java environments, by all means contact me and I'll try to point you in the right direction. Cheers, Dan From ms-nospam-0306 at arcor.de Tue Nov 18 09:39:51 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 18 Nov 2003 10:39:51 +0100 Subject: rpm database bug In-Reply-To: <200311180145.UAA09014@springbok.sci.ccny.cuny.edu> References: <200311180145.UAA09014@springbok.sci.ccny.cuny.edu> Message-ID: <20031118103951.48a3547c.ms-nospam-0306@arcor.de> On Mon, 17 Nov 2003 20:45:02 -0500, Tim Daly wrote: > > (I tried to find a bug mailing list but failed) For discussion of bugs/problems prior to submission of a bug report: http://www.redhat.com/mailman/listinfo/fedora-list For bug reports: http://bugzilla.redhat.com > While trying to: > > rpm -i tetex-fonts-2.0.2-8.i386.rpm > > I got the following error message: > > rpmdb: page 1647: illegal page type or format > rpmdb: PANIC: Invalid argument > rpmdb: /var/lib/rpm/Packages: pgin failed for page 1647 > rpmdb: fatal region error detected; run recovery > rpmdb: fatal region error detected; run recovery > rpmdb: db4 error(-30982) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run database recovery The problem is not related to the tetex-fonts package. Something else has corrupted your RPM database. Whenever I see spontaneous data corruption, I'd recommend to check your RAM chips first with memtest86. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rms at 1407.org Tue Nov 18 09:40:54 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 18 Nov 2003 09:40:54 +0000 Subject: [Fwd: [Bug 23679] NTLM auth for HTTP] Message-ID: <1069148453.2888.13.camel@roque> Good news, mozilla >= 1.6 will probably support NTLM on all platforms. -----Forwarded Message----- From: bugzilla-daemon at mozilla.org To: rms at 1407.org Subject: [Bug 23679] NTLM auth for HTTP Date: Mon, 17 Nov 2003 19:13:56 -0800 http://bugzilla.mozilla.org/show_bug.cgi?id=23679 darin at meer.net changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |224653 Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From darin at meer.net 2003-11-17 19:12 ------- this bug is fixed. see bug 224653 for details. here's a quick summary: o starting with mozilla 1.6 beta, it should be possible to connect using NTLM authentication on all platforms. note: NTLM is currently only supported for HTTP or HTTPS. o it is not supported when FIPS mode is enabled (because it uses MD4). o the SSPI based WIN32 implementation has been dropped in favor of the new cross-platform implementation. we had too many bugs with SSPI crashing on older machines. if possible, i'd therefore like to avoid SSPI altogether. however, i'm willing to entertain the possibility of adding it back under certain conditions if it proves valuable. o the new implementation attempts to negotiate the preferred NTLM2 session key mode whenever the server supports it. this improves security. o as with the previous SSPI based implementation, mozilla does not automatically send username, password, and domain (based on the user's WINNT logon) since we feel that that is a security risk. in a future version we may eliminate this restriction for proxy authentication. -- + 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 rezso at rdsor.ro Mon Nov 17 23:48:02 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Mon, 17 Nov 2003 23:48:02 +0000 Subject: Naoko - gcj based goodies like tomcat ? Message-ID: <200311172348.02582.rezso@rdsor.ro> Any plans to ship this with fedora ? http://people.redhat.com/gbenson/naoko/ It works pretty well (for me), curios why cannot be shiped with fedora ? cristian From kreg at virtual1.net Tue Nov 18 22:01:15 2003 From: kreg at virtual1.net (Kreg Steppe) Date: Tue, 18 Nov 2003 17:01:15 -0500 Subject: [Fwd: [Bug 23679] NTLM auth for HTTP] In-Reply-To: <1069148453.2888.13.camel@roque> References: <1069148453.2888.13.camel@roque> Message-ID: <3FBA96AB.6040006@virtual1.net> Damn Straight! I am so ready for this. I run our Intranet, and I have IIS (yuk) running it, just so there is a transparent login for our users. I personaly dont care if it asks for my username and password, as long as I can be on one box and work. Rui Miguel Seabra wrote: >Good news, mozilla >= 1.6 will probably support NTLM on all platforms. > >-----Forwarded Message----- >From: bugzilla-daemon at mozilla.org >To: rms at 1407.org >Subject: [Bug 23679] NTLM auth for HTTP >Date: Mon, 17 Nov 2003 19:13:56 -0800 > >http://bugzilla.mozilla.org/show_bug.cgi?id=23679 > > >darin at meer.net changed: > > What |Removed |Added >---------------------------------------------------------------------------- > BugsThisDependsOn| |224653 > Status|ASSIGNED |RESOLVED > Resolution| |FIXED > > > > >------- Additional Comments From darin at meer.net 2003-11-17 19:12 ------- >this bug is fixed. see bug 224653 for details. here's a quick summary: > > o starting with mozilla 1.6 beta, it should be possible to connect using NTLM > authentication on all platforms. note: NTLM is currently only supported > for HTTP or HTTPS. > > o it is not supported when FIPS mode is enabled (because it uses MD4). > > o the SSPI based WIN32 implementation has been dropped in favor of the new > cross-platform implementation. we had too many bugs with SSPI crashing on > older machines. if possible, i'd therefore like to avoid SSPI altogether. > however, i'm willing to entertain the possibility of adding it back under > certain conditions if it proves valuable. > > o the new implementation attempts to negotiate the preferred NTLM2 session > key mode whenever the server supports it. this improves security. > > o as with the previous SSPI based implementation, mozilla does not > automatically send username, password, and domain (based on the user's > WINNT logon) since we feel that that is a security risk. in a future > version we may eliminate this restriction for proxy authentication. > > From alan at redhat.com Tue Nov 18 22:33:54 2003 From: alan at redhat.com (Alan Cox) Date: Tue, 18 Nov 2003 17:33:54 -0500 Subject: ATI radeon 9600 Pro / willing to test and report In-Reply-To: <1069140442.4011.25.camel@dell> References: <1069140442.4011.25.camel@dell> Message-ID: <20031118223354.GA32270@devserv.devel.redhat.com> On Tue, Nov 18, 2003 at 08:27:23AM +0100, Laurent GUERBY wrote: > Just a small note: most of GUI tools are unusable at 640x480 > since you cannot access the buttons at the bottom of the window, > sometimes even after a resize. I don't know if the GUI guidelines > say something about supporting 640x480. Most of them work fine if you replace metacity with a window manager thats a bit smarter about small screens and forcing sizing. Still not ideal though. From carwyn at carwyn.com Tue Nov 18 23:10:26 2003 From: carwyn at carwyn.com (Carwyn Edwards) Date: Tue, 18 Nov 2003 23:10:26 +0000 Subject: [Fwd: [Bug 23679] NTLM auth for HTTP] In-Reply-To: <3FBA96AB.6040006@virtual1.net> References: <1069148453.2888.13.camel@roque> <3FBA96AB.6040006@virtual1.net> Message-ID: <3FBAA6E2.7070306@carwyn.com> Kreg Steppe wrote: > Damn Straight! I am so ready for this. I run our Intranet, and I have > IIS (yuk) running it, just so there is a transparent login for our > users. I personaly dont care if it asks for my username and password, > as long as I can be on one box and work. The other option for single sign on is something like: http://www.citi.umich.edu/projects/kerb_pki/ We've deployed this into a kerberised infrastructure here with very few problems (works like a treat with bugzilla). No IIS in sight :-) Carwyn -- Carwyn Edwards Computing Officer School of Informatics University of Edinburgh From tromey at redhat.com Tue Nov 18 23:16:40 2003 From: tromey at redhat.com (Tom Tromey) Date: 18 Nov 2003 16:16:40 -0700 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <200311172348.02582.rezso@rdsor.ro> References: <200311172348.02582.rezso@rdsor.ro> Message-ID: <87islh9siv.fsf@fleche.redhat.com> >>>>> "Balint" == Balint Cristian writes: Balint> Any plans to ship this with fedora ? Balint> http://people.redhat.com/gbenson/naoko/ Balint> It works pretty well (for me), curios why cannot be shiped Balint> with fedora ? Right now there's a compiler versioning problem. The gcc-ssa that is (will be? I haven't been paying attention) in Fedora is more experimental than the one Gary has been using for Naoko. And /usr/bin/gcj is too old to compile Naoko. We'd have to import gcc 3.4 (-ish) to make this work. Maybe that will happen, though. We'll need the same thing if gcj-eclipse goes into Fedora. Tom From buildsys at porkchop.devel.redhat.com Tue Nov 18 13:18:19 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Tue, 18 Nov 2003 08:18:19 -0500 Subject: rawhide report: 20031118 changes Message-ID: <200311181318.hAIDIJX20119@porkchop.devel.redhat.com> Removed package libffi Updated Packages: PyXML-0.8.3-2 ------------- * Mon Nov 17 2003 Tim Waugh 0.8.3-2 - Rebuild for Python 2.3. aspell-0.50.3-17 ---------------- * Mon Nov 17 2003 Thomas Woerner 12:0.50.3-17 - fixed build: added make to %build to avoid rpath for build directory * Tue Oct 07 2003 Adrian Havill 12:0.50.3-16 - moved spell compat script from /usr/share/aspell to /usr/bin (#105921) * Tue Jul 01 2003 Adrian Havill 11:0.50.3-15 - moved ispell compat script from /usr/share/aspell to /usr/bin (#90907) * Tue Jun 24 2003 Adrian Havill 10:0.50.3-14 - removed emacs/xemacs el files which are already provided * Wed Jun 18 2003 Adrian Havill 9:0.50.3-13 - provide pspell-devel in addition to obsoleting it * Tue Jun 10 2003 Adrian Havill 8:0.50.3-12 - obsolete old dicts designed for previous aspell * Wed Jun 04 2003 Elliot Lee - rebuilt * Fri May 30 2003 Joe Orton 7:0.50.3-10 - rebuild again to fix libpspell deps * Fri May 30 2003 Joe Orton 7:0.50.3-9 - remove ExcludeArch * Thu May 22 2003 Jeremy Katz 7:0.50.3-8 - fix build with gcc 3.3 * Thu May 22 2003 Adrian Havill 0.50.3-7 - require aspell-en for upgrades * Sun May 11 2003 Jeremy Katz 6:0.50.3-6 - -devel should obsolete pspell-devel * Tue May 06 2003 Joe Orton 0.50.3-5 - include libpspell.so in devel package * Thu May 01 2003 Adrian Havill 0.50.3-4 - removed .la files * Wed Apr 16 2003 Adrian Havill 0.50.3-3 - Changed the header for provides, obsoletes, epoch - fixed config prefix in dirs.h * Wed Apr 16 2003 Adrian Havill 0.50.3-1 - upgrade to 0.50.3 * Wed Jan 22 2003 Tim Powers - rebuilt * Fri Nov 08 2002 Tim Powers - fix broken pspell epoch dep - create $RPM_BUILD_ROOT/usr/bin by hand - remove /usr/doc - fix hardcoding of /usr/lib so that we can build on x86_64 * Tue Aug 13 2002 Nalin Dahyabhai 0.33.7.1-16 - require pspell and pspell-devel using the proper epoch * Sat Aug 10 2002 Elliot Lee - rebuilt with gcc-3.2 (we hope) * Mon Jul 22 2002 Tim Powers 0.33.7.1-14 - rebuild using gcc-3.2-0.1 * Fri Jun 21 2002 Tim Powers 0.33.7.1-13 - automated rebuild * Thu Jun 13 2002 Trond Eivind Glomsr?d 0.33.7.1-12 - Rebuild to make it work again... #66708 * Thu May 23 2002 Tim Powers - automated rebuild * Mon May 13 2002 Trond Eivind Glomsr?d 0.33.7.1-10 - Rebuild * Thu Feb 21 2002 Trond Eivind Glomsr?d 0.33.7.1-9 - Disable evil patch * Mon Jan 28 2002 Trond Eivind Glomsr?d 0.33.7.1-8 - Build on more archs (doh) * Tue Jan 22 2002 Trond Eivind Glomsr?d 0.33.7.1-7 - Make it compile with new compiler (evil workaround) * Wed Jan 16 2002 Trond Eivind Glomsr?d 0.33.7.1-5 - Rebuild - Unexclude alpha * Fri Dec 14 2001 Trond Eivind Glomsr?d 0.33.7.1-3 - Rebuild - Don't build on alpha * Mon Oct 29 2001 Bernhard Rosenkraenzer 0.33.7.1-2 - "make it work with gcc 3.1" ;) * Tue Sep 18 2001 Trond Eivind Glomsr?d 0.33.7.1-1 - 0.33.7.1, which is a "make it work with gcc 3" release * Wed Sep 12 2001 Tim Powers - rebuild with new gcc and binutils * Thu Aug 09 2001 Trond Eivind Glomsr?d 0.33.7-1 - 0.33.7 bugfix release. Requested by the author, it fixes coredumps in sug-mode and when not using typo-analyses. It also contains code cleanups so it compiles with -ansi - should fix coredump on IA64 (#49746) * Wed Jul 11 2001 Trond Eivind Glomsr?d - Add the .la files in the main package - used for dynamic loading * Sun Jun 03 2001 Trond Eivind Glomsr?d - 0.33.6.3, which includes the fix made yesterday * Sat Jun 02 2001 Trond Eivind Glomsr?d - Make it search for directories in the correct location * Wed May 30 2001 Trond Eivind Glomsr?d - No more workarounds at the specfile level * Tue May 29 2001 Trond Eivind Glomsr?d - Use custom ltmain.sh to work around buggy bundled libtool * Sun May 20 2001 Trond Eivind Glomsr?d - 0.33.6 - use standard %configure macro - it works now. * Fri May 11 2001 Bernhard Rosenkraenzer 0.33.5-2 - Rebuild with new libltdl * Mon Apr 23 2001 Trond Eivind Glomsr?d - 0.33.5 * Thu Nov 30 2000 Trond Eivind Glomsr?d - use new emacs init scheme for Emacs and XEmacs * Wed Nov 22 2000 Trond Eivind Glomsr?d - .32.6 * Sat Aug 19 2000 Trond Eivind Glomsr?d - .32.5 bugfix release (also contains improved documentation), obsolete old patch - the compatibility scripts are now part of the package itself - clean up build procedure - remove manual.aux file from docs (#16424) * Sun Aug 06 2000 Trond Eivind Glomsr?d - .32.1 bugfix release, obsolete old patch - rename to 0.32.1 - add patch from author to change his email address - add spell and ispell compatibility scripts * Fri Aug 04 2000 Trond Eivind Glomsr?d - rebuild * Tue Aug 01 2000 Trond Eivind Glomsr?d - remember to obsolete ispell - build the Canadian and British dictionaries here now, as part of the main package. Same package names and descriptions. * Mon Jul 24 2000 Trond Eivind Glomsr?d - .32 - remove old patches, add a patch since namespace isn't polluted as much anymore (as opposed to older toolchain) * Wed Jul 19 2000 Trond Eivind Glomsr?d - rebuild * Wed Jul 12 2000 Prospector - automatic rebuild * Tue Jul 04 2000 Jakub Jelinek - Rebuild with new C++ * Fri Jun 30 2000 Trond Eivind Glomsr?d - use RPM_OPT_FLAGS, not just -O0 - dont include .la-files * Fri Jun 23 2000 Trond Eivind Glomsr?d - excludearch ia64 * Fri Jun 23 2000 Trond Eivind Glomsr?d - patch to work around compiler bug(?) wrt. inline functions - use CFLAGS and CXXFLAGS - set them to -O0 to work around YACB - copy libtool files for IA64 support * Sun Jun 18 2000 Trond Eivind Glomsr?d - update to .31.1. My patch was upstreamed and is no longer needed. - new patch added so DESTDIR works properly * Fri Jun 16 2000 Trond Eivind Glomsr?d - (this entry includes some old ones...) - update to .31 - added patch to make it compile with a pickier compiler - include /usr/share/pspell * Mon May 01 2000 Tim Powers - updated to .30.1 - used build fixes from Ryan Weaver's 0.30.1-1 package on sourceforge - updated URL, download/ftp location - removed redundant define's at top of spec file * Thu Jul 08 1999 Tim Powers - built for Powertools 6.1 - removed %serial definitions from spec file to make versioning consistant with the other packages we ship. - changed build root path - general spec file cleanups * Tue Mar 02 1999 Ryan Weaver [aspell-.27.2-2] - Changes from .27.1 to .27.2 (Mar 1, 1999) - Fixed a major bug that caused aspell to dump core when used without any arguments - Fixed another major bug that caused aspell to do nothing when used in interactive mode. - Added an option to exit in Aspell's interactive mode. - Removed some old documentation files from the distribution. - Minor changes on to the section on using Aspell with egcs. - Minor changes to remove -Wall warnings. glibc-2.3.2-101.1 ----------------- * Tue Nov 11 2003 Jakub Jelinek 2.3.2-101.1 - fix getifaddrs (CAN-2003-0859) - fix ftw fd leak - fix linuxthreads sigaction (#108634) - fix glibc 2.0 stdio compatibility - fix uselocale (LC_GLOBAL_LOCALE) - speed up stdio locking in non-threaded programs on IA-32 - try to maintain correct order of cleanups between those registered with __attribute__((cleanup)) and with LinuxThreads style pthread_cleanup_push/pop (#108631) - fix segfault in regex (#109606) - fix RE_ICASE multi-byte handling in regex - fix pthread_exit in libpthread.a (#109790) joe-2.9.8-6 ----------- * Tue Jun 17 2003 Lon Hohberger 2.9.8-6 - Rebuild for FC2 tree * Tue Jun 17 2003 Lon Hohberger 2.9.8-5 - Rebuilt kudzu-1.1.38-1 -------------- * Mon Nov 17 2003 Jeremy Katz 1.1.38-1 - fix scsi probing for 2.6 kernel rpmdb-fedora-1-0.20031118 ------------------------- tcltk-8.3.5-94 -------------- * Mon Nov 17 2003 Thomas Woerner 8.3.5-94 - fixed RPATH for expect and expectk: patch 121 unzip-5.50-36 ------------- * Mon Nov 17 2003 Lon Hohberger 5.50-36 - Rebuild for FC-next xemacs-sumo-20031113-1 ---------------------- * Tue Nov 18 2003 Jens Petersen - 20031113-1 - update to 2003-11-13 pre-release From d_bradsh at bellsouth.net Tue Nov 18 13:43:53 2003 From: d_bradsh at bellsouth.net (d_bradsh at bellsouth.net) Date: Tue, 18 Nov 2003 8:43:53 -0500 Subject: rekall Message-ID: <20031118134353.ETVC6276.imf19aec.mail.bellsouth.net@mail.bellsouth.net> Hi folks, most of you dont know me because I am new here. I learned via /. that Rekall has been gpl'd and was wanting to start a discussion on whether it would be useful to incorporate it into fedora, or at least make it available via Yum. I have not tried it yet, and really dont know if I have much need for a database manager..but feel a lot of businesses and organizations might. Of course we already have most of what we need, but Rekall is getting good buzz and that is important. Well thank you all for your time. http://thekompany.com/products/rekall/ From bill at noreboots.com Tue Nov 18 13:57:12 2003 From: bill at noreboots.com (Bill Anderson) Date: 18 Nov 2003 06:57:12 -0700 Subject: rawhide report: 20031113 changes In-Reply-To: <200311131124.hADBOZG29142@porkchop.devel.redhat.com> References: <200311131124.hADBOZG29142@porkchop.devel.redhat.com> Message-ID: <1069163832.792.22.camel@locutus> On Thu, 2003-11-13 at 04:24, Build System wrote: > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list Could whatever mails this out have a check added to avoid blank emails? :^) -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From johnsonm at redhat.com Wed Nov 19 00:41:56 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 18 Nov 2003 19:41:56 -0500 Subject: gFTP 2.0.14 In-Reply-To: <200311181553.40739.czar@czarc.net> References: <3FB9B5A3.9040505@staticnull.org> <1069183174.15738.1.camel@GreenTea> <200311181553.40739.czar@czarc.net> Message-ID: <20031119004156.GA2930@devserv.devel.redhat.com> On Tue, Nov 18, 2003 at 03:53:40PM -0500, Gene C. wrote: > However, I do not understand the posting of a gftp update to fedora.us. This > package is part of Fedora Core 1. Shouldn't this update be part of the > updates flowing out of the Red Hat errata process? While Red Hat updates do Yes, ideally. (FWIW, because the process is very different and we want to express that difference, we use "errata" for RHEL and "updates" for Fedora.) > I would really like to hear from some Red Hat folks on this. I would like to > see some means of folks outside of Red Hat providing updated packages where > Red at currently does not have to resources available to do them "right now". > After all, the whole idea of the Fedora Project is to leverage (utilize) > resources outside of Red Hat to deliver a better product that could be done > using only Red Hat resources. > > Some of this may "shake out" over the next few months as the whole Fedora > process develops. Exactly. The one key item is the external CVS server for packaging metadata -- even without external developers having commit access, a "cvs diff -u" of the package metadata takes a lot of the work out of doing an update. http://fedora.redhat.com/participate/ (see the "Soon" entry) michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From roland at redhat.com Wed Nov 19 00:46:02 2003 From: roland at redhat.com (Roland McGrath) Date: Tue, 18 Nov 2003 16:46:02 -0800 Subject: exec-shield mmap & brk randomization In-Reply-To: Camm Maguire's message of , 18 November 2003 10:57:39 -0500 <54d6bpsm8c.fsf@intech19.enhanced.com> Message-ID: <200311190046.hAJ0k2TQ020528@magilla.sf.frob.com> I kind of suspected that GCL's trouble might relate to brk randomization. I avoided getting into these details in my first long message because I wanted to post that write-up about the executability issues for general reference, and not make it any more complicated than it already was. > > System-wide, you can disable the exec-shield functionality with: > > > > echo 0 > /proc/sys/kernel/exec-shield > > Does this only effect PROT_EXEC settings on memory pages? Nope. This disables the "exec-shield mode" for all new execs (for those reading kernel sources at home, PF_RELOCEXEC in task_struct.flags). Using "setarch i386 foobar" disables the mode for the run of foobar and its children; otherwise ELF execs have the mode enabled or disabled according to the presence or absence of PT_GNU_STACK program headers as I've already described in detail. That mode enforces nonexecutability as I described previously. It also enables some other layout changes. I'll describe them after answering your other various questions about how to be sure what's what. > This at least could function as a work-around for now, if we can make > configure figure out when it is needed (cat > /proc/sys/kernel/exec-shield && [ -x setarch ] ?) If this is the > wisest solution, let me know and I'll protect the image creations with > this command. I would just check for setarch. You don't really need to check for /proc/sys/kernel/exec-shield existing, though I suppose it doesn't hurt since you shouldn't need to use setarch when exec-shield isn't there. > To my knowledge, we have no nested functions, nor rely on an > executable C stack. The failures are pretty obvious when that's the nature of the problem. i.e., you will get a SIGSEGV with the PC value set to some address, and you can look in /proc/PID/maps and see the region containing the PC is not executable, and voila, you're sure that's the problem (or isn't). > Are these utils in any (unstable) Debian packages? The `execstack' program is only available as part of the prelink package by Jakub Jelinek, in very recent versions of that package. Off hand I don't know what version of prelink, if any, is in Debian. readelf and objdump are part of binutils, and versions too old to know the PT_GNU_STACK magic number just show you the number instead of the name (match up with values), so you can still see what's going on. > So even with nested functions, code should compile and run from > source, right? With current tools on FC1, yes. You should always be able to tell by examining the binaries with readelf/objdump/execstack how the tools marked (or didn't mark) the binary. > We don't use any asm. In that case you can be pretty sure that executable stack per se is not the problem unless you are using GCC nested functions and we have some tools bugs. > We get all pages via sbrk, and redefine malloc to a call to a native > memory management system which in turn calls sbrk as needed. This is probably where your problem lies. See below. I mentioned layout changes enabled by the exec-shield mode. The first of these is randomization of the addresses returned by mmap when not using the MAP_FIXED flag bit and supplying 0 as the first argument rather than a specific hint address. It has always been the case that mmap is specified to return unpredictable addresses when not given MAP_FIXED, and the application cannot presume any particular choices will be made (the address given in the first argument to mmap is a nonbinding suggestion). In the past, Linux kernels have always returned a very predictable sequence of addresses. In Fedora Core kernels, for processes in exec-shield mode, mmap returns truly unpredictable addresses. This affects programs that presume what addresses their mmap calls will return, and those that presume what addressses no mmap call will ever return. Note that this includes the mmap calls made by the dynamic linker to load shared libraries before any library or application code gets control, and potentially even the kernel's mapping of the dynamic linker itself done at exec. So if you had your eye on some particular part of the address space not directly mapped by your executable, it might already be in use by the time you get a chance to look. Incidentally, the mmap randomization is what broke MIT Scheme. It presumed that the low 64MB of the address space would never be used at all, and did mmap with MAP_FIXED on addresses in that range that would overwrite other mappings such as those for the shared library containing the mmap function itself. That's a case of presuming what addresses "anywhere" mmap calls would rule out, when no such guarantee was ever part of the specification of the system interface. MIT Scheme really wants that particular part of the address space for its data due to its pointer tagging implementation (high tags). The mmaps for shared libraries done before the Scheme runtime gets control are now randomized and might very well impinge on the [0,0x4000000) range. The only proper way to reserve such a range is with a PT_LOAD program header in the ELF executable, which can request a PROT_NONE mapping to reserve the range (without consuming any disk or RAM) so that it has carte blanche to overwrite that range with MAP_FIXED mappings later. Unfortunately, getting that into your binary is a bit of a pain in the ass futzing with linker scripts and bits of magic dust. I posted some quick examples that demonstrated it adequately for the MIT Scheme maintainer, but that maintainer is rather more experienced than the average bear. If you need to make this happen, I'll be happy to help you figure out the magic. The second layout change is what I suspect broke GCL. It broke Emacs's unexec as well. Personally, I consider this change incorrect. However, we have not yet hashed out among the RH developers concerned with this area what the resolution will be. Moreover, I tend to think that anything broken by it probably ought to be doing things differently in the long run. Since the dawn of time, the "break area" in Unix has started immediately after the executable's writable segment (i.e. after its .bss section) and extended upward from there. By "the break area", I mean the region of memory starting at the address returned by sbrk the first time it's called after an exec. From the beginning of Unix until two weeks ago Wednesday, the first `sbrk (0)' returned &end, the end of your .bss; increasing the break with sbrk calls gave a contiguous region from your data segment through to the current address of the dynamically-extended break. In Fedora Core kernels, for processes in exec-shield mode, this is no longer the case. The starting address of the break area is randomized at exec time, in a fashion similar to the randomization of mmap addresses. The first call to `sbrk (0)' will tell you the lower bound of the region, which will not be lined up with the end of your executable's writable segment. As always, calls to sbrk to increase the size of the region will work as long as there is unused address space above the current break region (randomly placed mmaps will tend to be elsewhere, lower in the address space, and not impinge on break expansion). But the exact location of the region is now somewhat unpredictable, and you can always expect a hole between static data (your program's writable segment, i.e. .data+.bss) and the dynamically-extended break region. As I said, I personally don't like this change. That's because I consider starting at &end to have been part of the specification of the break functionality inherited from ancient Unix, and breaking such things is just plain wrong. Nonetheless it is at least for the moment the way things are in FC1 kernels. I don't want to engage in a discussion here about the merits of this change. I would like to help hash out how precisely it affects you and any possible ways to work around it there might be. (If figuring it all out turns out to lead you not to want to change anything and instead to complain heartily about the kernel behavior change, then that's as may be.) I said that anything broken by it probably ought to be doing things differently. The reason I say that is that I consider the brk interface obsolete. I can't really see any good reason to be using it in preference to the other options. It's inherently limited as an allocation interface in that it provides just one contiguous region; address space fragmentation from the mappings for the executable, shared libraries, thread stacks, etc, will mean that many smaller discontiguous holes are available, and using only the break region will mean the total limit on useful allocation in the process can be much lower than the true limit imposed by the configured resource limits, the system implementation, or available virtual memory resources. The other option to use mmap and be prepared to get discontiguous regions when requesting pages on separate occasions. If contiguity is required, you can use the mremap call when available (AFAIK only on Linux kernels) to extend a region and move it if a sufficient contiguous region is not free in the original location. If contiguity is only somewhat preferred but not strongly so, you can use a nonzero first argument to mmap (without using the MAP_FIXED flag), and you will ordinarily get the requested address or the next following address with a free region of the requested size. (But note that there is still no guarantee of getting the requested region without MAP_FIXED and the robust program must be prepared to handle discontiguous regions. FC1 kernels will in fact hand back predictable addresses, but future kernels might not always do so.) If you specifically rely on treating static data and the dynamic break region as a single contiguous region, something has to change. If you don't rely on that, but just on knowing the start and end of the contiguous break region itself, then you can make the simple and portable change of using sbrk (0) instead of &end to initialize your idea of the lower bound of the break region. In the long run, I would still recommend more drastic changes to avoid relying on a contiguous break region at all, for the reasons I gave in the previous paragraph. If you make those changes, you will not impose so low a limit on the total memory you can allocate in a process, a benefit you'll get in the same way on all modern Unix-like systems (at least the 32-bit ones, I guess 64-bit systems always have more unused address space after the break than you could possibly need). Please let me know if there is anything I clarify or anything I can do to help you figure out what changes to your program might be best. Thanks, Roland From johnsonm at redhat.com Wed Nov 19 00:50:16 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 18 Nov 2003 19:50:16 -0500 Subject: rekall In-Reply-To: <20031118134353.ETVC6276.imf19aec.mail.bellsouth.net@mail.bellsouth.net> References: <20031118134353.ETVC6276.imf19aec.mail.bellsouth.net@mail.bellsouth.net> Message-ID: <20031119005016.GB2930@devserv.devel.redhat.com> On Tue, Nov 18, 2003 at 08:43:53AM -0500, d_bradsh at bellsouth.net wrote: > Hi folks, most of you dont know me because I am new here. I learned > via /. that Rekall has been gpl'd and was wanting to start a discussion > on whether it would be useful to incorporate it into fedora, or at least > make it available via Yum. I have not tried it yet, and really dont know > if I have much need for a database manager..but feel a lot of businesses > and organizations might. Of course we already have most of what we need, > but Rekall is getting good buzz and that is important. Well thank you > all for your time. > > http://thekompany.com/products/rekall/ I'd say start by packaging it up for www.fedora.us so that it's in line as we merge the package sets together. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From elliott at wilcoxon.org Wed Nov 19 01:04:14 2003 From: elliott at wilcoxon.org (Elliott Wilcoxon) Date: Tue, 18 Nov 2003 19:04:14 -0600 Subject: rawhide report: 20031113 changes In-Reply-To: <1069163832.792.22.camel@locutus> References: <200311131124.hADBOZG29142@porkchop.devel.redhat.com> <1069163832.792.22.camel@locutus> Message-ID: <3FBAC18E.3010707@wilcoxon.org> Or at least have it insert "No changes" if they must be sent out. Elliott Wilcoxon Bill Anderson wrote: > On Thu, 2003-11-13 at 04:24, Build System wrote: > >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > Could whatever mails this out have a check added to avoid blank emails? > :^) > From djh at iinet.net.au Wed Nov 19 01:43:43 2003 From: djh at iinet.net.au (djh) Date: Wed, 19 Nov 2003 11:43:43 +1000 (EST) Subject: rekall In-Reply-To: <20031118134353.ETVC6276.imf19aec.mail.bellsouth.net@mail.bellsouth.net> Message-ID: On Tue, 18 Nov 2003 d_bradsh at bellsouth.net wrote: > I learned via /. that Rekall has been gpl'd and was wanting to start a > discussion on whether it would be useful to incorporate it into fedora, > or at least make it available via Yum. Check out bug #1012 at bugzilla.fedora.us. David. From ByteEnable at austin.rr.com Wed Nov 19 01:40:29 2003 From: ByteEnable at austin.rr.com (ByteEnable) Date: Tue, 18 Nov 2003 19:40:29 -0600 Subject: OpenOffice.org and Java in Fedora Message-ID: <1069206029.1545.8.camel@ByteEnable> >Hi, > >After some thought and discussion, I've come to the following >conclusion: > >Since Fedora does not include Java for licensing reasons, all Red >Hat-built OpenOffice.org RPMs for Fedora will NOT include Java support, >and will NOT be built with Java enabled. It's not good form to supply >an RPM that cannot be built on the platform it is intended for. >Therefore, when you install Fedora and OOo, anything that requires Java >will not function. > >However, I will attempt to keep a "Java-enable" switch in the specfile >that will allow Java-enabled building on Fedora, provided you have a >JRE/JDK installed. I will attempt to keep Java-enabled building >up-to-date and functional. > >In the future, I hope OOo will compile using gcj or other free Java >environments. This is something we'll be working towards, and other >shave this same goal in mind (Debian). When gcj is able to compile the >Java bits of OOo, the Fedora RPMs will include those patches. Its going >to mean some work though. > >So in summary, I'm not going to build Java-enabled RPMs of OOo for the >time being. But if you'd like them, I'm happy to keep it possible (and >will try to keep it building out-of-the-box with a specfile switch). If >anyone would like to help out in getting OOo to work with gcj or other >free Java environments, by all means contact me and I'll try to point >you in the right direction. > >Cheers, >Dan > Hi Dan, Could you also move the -mcpu override's in solenv/inc/ into the spec file using a variable? Thanks, Byte From kreg at virtual1.net Wed Nov 19 01:56:48 2003 From: kreg at virtual1.net (Kreg Steppe) Date: Tue, 18 Nov 2003 20:56:48 -0500 Subject: [Fwd: [Bug 23679] NTLM auth for HTTP] In-Reply-To: <3FBAA6E2.7070306@carwyn.com> References: <1069148453.2888.13.camel@roque> <3FBA96AB.6040006@virtual1.net> <3FBAA6E2.7070306@carwyn.com> Message-ID: <3FBACDE0.90204@virtual1.net> You know, I would like to roll out something like a kerb option. I do not actually have control over our network, I am a web developer. We have about 500+ employees and a network admin with a Microsoft Koolaid maker at his desk. Where are some good docs for setting up kerberos? Kreg Carwyn Edwards wrote: > Kreg Steppe wrote: > >> Damn Straight! I am so ready for this. I run our Intranet, and I have >> IIS (yuk) running it, just so there is a transparent login for our >> users. I personaly dont care if it asks for my username and password, >> as long as I can be on one box and work. > > > > The other option for single sign on is something like: > > http://www.citi.umich.edu/projects/kerb_pki/ > > We've deployed this into a kerberised infrastructure here with very few > problems (works like a treat with bugzilla). No IIS in sight :-) > > Carwyn > > -- > Carwyn Edwards > Computing Officer > School of Informatics > University of Edinburgh > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From dawson at fnal.gov Tue Nov 18 14:42:43 2003 From: dawson at fnal.gov (Troy Dawson) Date: Tue, 18 Nov 2003 08:42:43 -0600 Subject: changing Gnome panel buttons Message-ID: <3FBA2FE3.3080006@fnal.gov> Hello, Alot of my users keep complaining whenever they get a new account on a box that the first thing they do is add the terminal button to their panel. These complaints came from both KDE and Gnome users. I was able to change the default buttons on KDE by changing /usr/share/config/kickerrc But try as I might, I cannot find the file, or set of files, to change the default set of buttons that you get on the gnome-panel. So, in short, what file, or set of files, do you need to modify, to change the default gnome-panel buttons? By default I mean the buttons that a newly created user would see. Thanks Troy Dawson -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From ted at cypress.com Tue Nov 18 14:43:06 2003 From: ted at cypress.com (Thomas Dodd) Date: Tue, 18 Nov 2003 08:43:06 -0600 Subject: openoffice.org missing .jar classes In-Reply-To: <1069107032.5196.11.camel@dhcp64-188.boston.redhat.com> References: <1069065990.5335.28.camel@marte.biciclete.ro> <1069081798.26780.9.camel@dhcp64-188.boston.redhat.com> <1069104359.7951.7.camel@localhost> <1069107032.5196.11.camel@dhcp64-188.boston.redhat.com> Message-ID: <3FBA2FFA.6000400@cypress.com> Dan Williams wrote: > to be proven wrong because that would make my job easier). If you build > with Java and run on a non-Java system, I'm not quite sure what happens, > but I'm looking into that and I'll have answers tomorrow. We may be > linking against some stuff on Linux (like the berkeleydb libdb-java) > that won't be available on a non-java system, and therefore segfaults > OOo when it can't be found. If so it's a build bug. I've used the OOo builds on Solaris, HP-UX, and Linux without problems. None of them had Java setup for OOo. Until you tell OOo where the JRE is installled it cannot use it, evidenced best on the Solaris system where There are 3 different JRE's but non are in default locations. > Oh, about 6GB for all language packs, and about 4 hours on a dual Xeon > 2.4Ghz with 1GB of RAM. Don't try this on a Celeron or anything less > than a PII 400. And a huge amount of RAM. I tried it on a 256M, Athlon 800, and it took more than 8 hours. The 333 Ultra 10 took days. -Thomas From gemi at bluewin.ch Tue Nov 18 14:44:46 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Tue, 18 Nov 2003 15:44:46 +0100 Subject: Executable memory: some apps that work on RH9 don't on FC1 In-Reply-To: <1069100922.20884.17.camel@scriabin.tannenrauch.ch> References: <200311171912.hAHJC2Cg015459@magilla.sf.frob.com> <1069100922.20884.17.camel@scriabin.tannenrauch.ch> Message-ID: <1069166686.15262.1.camel@scriabin.tannenrauch.ch> To whoever it may concern: I just uploaded a patched mit-scheme 7.7.90. See http://bugzilla.fedora.us/show_bug.cgi?id=823 Regard, G?rard -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From petersen at redhat.com Wed Nov 19 03:12:38 2003 From: petersen at redhat.com (Jens Petersen) Date: Wed, 19 Nov 2003 12:12:38 +0900 Subject: automake-1.7d beta test rpm available Message-ID: I put a rpm of the 2nd Automake 1.8 beta test release up for anyone who would like to give it a spin to test: http://people.redhat.com/petersen/?M=D Jens From xose at wanadoo.es Wed Nov 19 03:19:01 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 19 Nov 2003 04:19:01 +0100 Subject: strip flag in rpm-build Message-ID: <3FBAE125.2040701@wanadoo.es> is there any reason to put '-g' instead of '-s' in ...? brp-strip: strip -g $f || : brp-strip-static-archive: strip -g $f what's about to replace it with eu-strip ? -- Software is like sex, it's better when it's bug free. From aoliva at redhat.com Wed Nov 19 03:34:20 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 19 Nov 2003 01:34:20 -0200 Subject: strip flag in rpm-build In-Reply-To: <3FBAE125.2040701@wanadoo.es> References: <3FBAE125.2040701@wanadoo.es> Message-ID: On Nov 19, 2003, Xose Vazquez Perez wrote: > is there any reason to put '-g' instead of '-s' in ...? > brp-strip: strip -g $f || : > brp-strip-static-archive: strip -g $f > what's about to replace it with eu-strip ? If you strip a library with -s, IIRC you won't be able to link (ld, not ld.so or dlopen) with it any more. Bad idea for -devel libs. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From roland at redhat.com Wed Nov 19 03:36:22 2003 From: roland at redhat.com (Roland McGrath) Date: Tue, 18 Nov 2003 19:36:22 -0800 Subject: exec-shield mmap & brk randomization In-Reply-To: root's message of Tuesday, 18 November 2003 21:07:08 -0500 <200311190207.hAJ278L29349@localhost.localdomain> Message-ID: <200311190336.hAJ3aMUJ020896@magilla.sf.frob.com> > Ummm, I've read this 3 times and I understand that lisp (in fact every > lisp I've ever worked on) will break in this model. Lisp systems depend > on managing memory. You are overreacting. You have quite a lot of control over your address space. It's just that "presume it will be like it usually has been" does not constitute control. You have to use the proper explicit mechanisms. > If I understand what you wrote it appears that in the worst case I > could get back a page at a time which could not be remapped into a > contiguous area! Please tell me that I'm wrong. I don't really know what you are referring to. Unless you have already loaded zillions of libraries or other randomized mmaps, most of your address space will be free. If you want a 1GB chunk, mmap a 1GB chunk first thing. You know that the address space is 3GB or more and you've decided that 1GB is enough because it makes it easier to only handle one contiguous and that's the size you can reasonably expect, then fine. If you want to be absolutely sure of a certain minimum size before any shared libraries are loaded, then you need to have a PT_LOAD program header in your executable requesting a specific mapping. This is equivalent to allocating a huge data area in the executable, but you can do it without making the region accessible before your explicit mappings, and without consuming any real RAM or disk for it. I explained this already. > Do you have a set of examples from the design to show me what expectations > will be violated? I read your text but it would be helpful to see actual > code that used to work and will no longer be guaranteed to work. Is there > a design document I can read to understand this better? There is a POSIX specification of what has been guaranteed and what has always unspecified implementation detail you should never have been relying on. You have never been able to presume the layout mmap will use, or how close to the break it might be. However, you can reasonably expect that any implementation of decent quality would endeavor make it possible to get contiguous mappings of both small and large sizes. The locations of small mappings such as those for the shared libraries are not predictable, but they do not create ludicrous amounts of fragmentation. From johnsonm at redhat.com Tue Nov 18 15:24:21 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 18 Nov 2003 10:24:21 -0500 Subject: Self-Introduction: Mike Petullo In-Reply-To: <20031118040013.GA1101@imp.flyn.org> References: <20031118040013.GA1101@imp.flyn.org> Message-ID: <20031118152421.GB21939@devserv.devel.redhat.com> On Mon, Nov 17, 2003 at 10:00:14PM -0600, W. Michael Petullo wrote: > in Fedora. I'd also like to work on adding encrypted root filesystem > support to anaconda for use on laptops. I also hope to contribute to Let me beat my drum: First item of work for any necessary kernel changes are getting those changes accepted upstream. :-) That said, it certainly sounds like a worthwhile area to work in. Thanks! michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From jf_balto at hotmail.com Tue Nov 18 15:24:46 2003 From: jf_balto at hotmail.com (Jean-Francois Veillette) Date: Tue, 18 Nov 2003 15:24:46 +0000 Subject: I believe symlink libart_lgpl_2.so is missing Message-ID: Hi On my system, >ls -l /usr/lib/libart_lgpl_2* >symlink libart_lgpl_2.so.2 -> symlink libart_lgpl_2.so.2.3.16 >symlink libart_lgpl_2.so.2.3.16 apps like rekall won't compile because of that, making the symlink fix the compile problem. search buzilla with ibart_lgpl_2 found nothing about that. Jean-Francois Veillette _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://messenger.fr.msn.ca/ From roland at redhat.com Wed Nov 19 03:58:04 2003 From: roland at redhat.com (Roland McGrath) Date: Tue, 18 Nov 2003 19:58:04 -0800 Subject: [Gcl-devel] exec-shield mmap & brk randomization In-Reply-To: Camm Maguire's message of , 18 November 2003 22:10:15 -0500 <54brr9hx48.fsf@intech19.enhanced.com> Message-ID: <200311190358.hAJ3w4s5021031@magilla.sf.frob.com> > Bingo. In fact, we use exactly emacs' unexec. I'm hoping your past > tense of the verb to break here indicates that a fix for unexec is > already at hand? Not exactly. I do plan to resolve the situation in the Fedora Core 2 development cycle, but exactly how is not yet clear. I'd like to understand GCL's constraints as well as Emacs's before deciding what to do. > Thankfully, GCL does not have to know precisely where its heap lower > bound is (apart from unexec) until the first call to sbrk(0) is made, > but we do absolutely need contiguity of this heap. As long as you > don't dump brk altogether, I may retain my head of hair. :-). Do you make many repeated sbrk calls to expand the heap? If you make just one big allocation and don't really care what the base address is, then mmap is just as good for you. However, it sounds like you want to choose the actual address range at compile time. Is that so? > Only in unexec. If emacs has a fix, we can use it directly. But, in the binary produced by unexec, do you rely on the _end/end and _edata/edata symbols beind adjusted to included brk data allocated by the loadup run before the unexec? (I haven't yet checked whether Emacs does.) That is, if what unexec did were to just restore some particular memory allocated in the first run, disjoint from the original data segment, would that make you happy? > I'm not really sure how much memory could be wasted, but this likely > seems a very small consideration compared to the complexity of > redesigning the garbage collector, etc. Sure. Contiguity is inherently limited in the ways I mentioned, but there are plenty of reasons to like it if those limitations aren't your primary concern. If you like contiguity, you just need to find the best ways to ask up front for all the contiguity you really need. > 2) come up with a configure time absolute lower bound to the first > sbrk after exec That is not something you ought to try to rely on in the current situation. It is in fact a known range at the moment, but if the brk randomization feature remains, you can't be sure the range will remain the same, or that a compile-time determination would apply correctly to running on slightly different kernels or different hardware configurations. > Else we must > > 3) use setarch This is certainly the right stop-gap solution if you are concerned about people building GCL on FC1 tomorrow. It's trivial to implement in the src rpm spec, and probably not worth putting in configure now since it likely won't be required for very long. Thanks, Roland From steve at silug.org Tue Nov 18 15:55:14 2003 From: steve at silug.org (Steven Pritchard) Date: Tue, 18 Nov 2003 09:55:14 -0600 Subject: hostap In-Reply-To: <9168.128.171.123.60.1069111202.squirrel@togami.com> References: <20031117075723.GA19585@osiris.silug.org> <3FB9475C.6000209@memeyou.net> <9168.128.171.123.60.1069111202.squirrel@togami.com> Message-ID: <20031118155514.GA23441@osiris.silug.org> On Mon, Nov 17, 2003 at 01:20:02PM -1000, Warren Togami wrote: > Do you folks know if the SMC2602 PCI adapter containing the SMC2632 prism2 > based card is supported by hostap? I don't know that particular card, but I'd be willing to bet that it will. I have my rpm building on FC1 now, so just let me know if you want to give it a try. (I'll try to review the naming guidelines and such today so I can properly submit the package.) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From mharris at redhat.com Tue Nov 18 17:04:42 2003 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 18 Nov 2003 12:04:42 -0500 (EST) Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: References: <1068236427.12684.60.camel@laptop> Message-ID: On Fri, 7 Nov 2003, Aurelien Bompard wrote: >These guidelines seem fine, thanks for the work. > >However, I have recently bumped into a package naming problem which doesn't >seem to be covered here. It's a program called K3B, a CD/DVD burning >frontend for KDE. >Here is their release numbers : 0.8 -> 0.9 -> 0.10 >How should we set the RPM fields without using epochs in this type of >versionning ? Is is a case where epoch is necessary ? Release: 0.8 Release: 0.9 Release: 0.10 What's the problem? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From jspaleta at princeton.edu Wed Nov 19 05:25:46 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 19 Nov 2003 00:25:46 -0500 Subject: Bug Day 6: Doin' the Configure Tool Cha-Cha Message-ID: <1069219546.8223.46.camel@goober.localdomain> Nov. 19, 2003 Bug Day Topic: Bug squashing for the redhat-config-* packages That's right...tomorrow is another bug day!!!!! But this time its official, bug days now get a passing mention at: http://fedora.redhat.com/participate/ Little birdies have told me, that certain people are agitating for a chance to get their hands dirty working with some of the config tools. So why not start by first trying to get a handle on all the open bugs that are sitting in bugzilla right now and close as many as possible. And if your lucky...there might even be a bug that you can dig into and submit a patch for. And, hopefully people will be standing by in #fedora-bugs on the Freenode.net irc network to help you if you have any questions on how to master bugzilla diving. Here's a pre-built query showing all the open bugs for the redhat-config-* tools: http://tinyurl.com/vmh2 A Note. Please try to use the formatted triage->reason syntax when annotating bug reports ( http://www.fedora.us/wiki/TriageComment ). Example if you find an old unresolved bug report that is clearly fixed in the current release, please add the comment "triage->currentrelease" If you are unsure which reason is most appropriate, stop into #fedora-bug irc channel and ask for assistance. A second note. Just as a reminder, it might be good to glance over the wiki for the Fedora Triage effort: http://www.fedora.us/wiki/FedoraTriage In other news..... Fedora.us is still in great need for community members to do QA. There are 280+ packages waiting for QA ( http://www.fedora.us/QA ). Please read http://www.fedora.us/wiki/PackageSubmissionQAPolicy and get involved in the community QA process on the community submitted packages. So please take a look over the list of packs in the QA list, and see if there are packages there you want to see published..pick one..and pitch in to the QA process for the package you love. In other, other news.... Paul Nasrat is working on hacking up some example code to interface with the xmlrpc interface to bugzilla. I'll let him fill you in on the details when he's ready to show off his mad skills. But i mention it here because, I hope his experimental tools are something that can become the basis for ease-of-use tools to work with bugzilla to do triage and fedora.us(or extras/alternatives) package submit/QA down the road. Since tomorrow(err i mean today) is config tool bughunt day...i thought it appropriately ironic to mention that I'm hoping for a config tool just to help do bughunting. -jef"it just wouldn't be right...if a can of whoopass cola..tasted good"spaleta -------------- 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 dcbw at redhat.com Tue Nov 18 18:19:50 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 18 Nov 2003 13:19:50 -0500 Subject: OpenOffice.org and Java in Fedora Message-ID: <1069179590.11832.8.camel@dhcp64-188.boston.redhat.com> Hi, After some thought and discussion, I've come to the following conclusion: Since Fedora does not include Java for licensing reasons, all Red Hat-built OpenOffice.org RPMs for Fedora will NOT include Java support, and will NOT be built with Java enabled. Its not good form to supply an RPM that cannot be built on the platform it is intended for. Therefore, when you install Fedora and OOo, anything that requires Java will not function. However, I will attempt to keep a "Java-enable" switch in the specfile that will allow Java-enbabled building on Fedora, provided you have a JRE/JDK installed. I will attempt to keep Java-enabled building up-to-date and functional. In the future, I hope OOo will compile using gcj or other free Java environments. This is something we'll be working towards, and others have this same goal in mind (Debian). When gcj is able to compile the Java bits of OOo, the Fedora RPMs will include those patches. Its going to mean some work though. So in summary, I'm not going to build Java-enabled RPMs of OOo for the time being. But if you'd like them, I'm happy to keep it possible (and will try to keep it building out-of-the-box with a specfile switch). If anyone would like to help out in getting OOo to work with gcj or other free Java environments, by all means contact me and I'll try to point you in the right direction. Cheers, Dan From blargg at budget.net Tue Nov 18 18:40:07 2003 From: blargg at budget.net (ben ford) Date: Tue, 18 Nov 2003 10:40:07 -0800 Subject: php in fedora development In-Reply-To: <007501c3aaab$4bcd2150$0200a8c0@gandalf> References: <3FB4A291.7050108@bnap.hu> <007501c3aaab$4bcd2150$0200a8c0@gandalf> Message-ID: <1069180807.5243.20.camel@mybox> On Fri, 2003-11-14 at 04:31, Chris Chabot wrote: > Both the mhash and mcrypt modules for PHP require those libraries, so it's > not just a configure switch.. Since those libs are not included in the > fedora core (that i know off), it would mean including those too. > > Did you ever consider using the openssl checksum & crypto functionality? > Anyways, just pointing out it's not as cut-dry-and-simple as you made it > sound > What would it take to get mcrypt and mhash libraries to be part of the Fedora Core? Could someone interested build the rpms? I need mcrypt modules for a php project here at work. I would *consider* doing this in the hopes that it would make life easier for others. I've never built or maintained an RPM so I might be overdoing myself here, but I am willing to learn. I have around 5 years linux experience and have yet to contribute directly. > ----- Original Message ----- > From: "Farkas Levente" > To: "Joe Orton" ; > Sent: Friday, November 14, 2003 10:38 > Subject: php in fedora development > > > > hi, > > could you add to the defualt php package the mhash and mcrypt support? > > it doesn't hurt anything sincs it's just and addition to the configure: > > --with-mcrypt=shared \ > > --with-mhash=shared \ > > plus you should create two more packages > > php-mcrypt and php-mhash > > this woule help for many people includein hore and lam users who > > wouldn't have to rebuild php packages all the time just for these modules. > > thanks. > > > > -- > > Levente "Si vis pacem para bellum!" > > > > > > From roli at israel-jugendtag.ch Wed Nov 19 09:27:40 2003 From: roli at israel-jugendtag.ch (=?ISO-8859-1?Q?Roland_K=E4ser?=) Date: Wed, 19 Nov 2003 10:27:40 +0100 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <1069206029.1545.8.camel@ByteEnable> References: <1069206029.1545.8.camel@ByteEnable> Message-ID: <3FBB378C.9020107@israel-jugendtag.ch> An HTML attachment was scrubbed... URL: From tony at tgds.net Wed Nov 19 09:41:56 2003 From: tony at tgds.net (tony) Date: Wed, 19 Nov 2003 10:41:56 +0100 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <3FBB378C.9020107@israel-jugendtag.ch> References: <1069206029.1545.8.camel@ByteEnable> <3FBB378C.9020107@israel-jugendtag.ch> Message-ID: <1069234916.8970.352.camel@localhost.localdomain> Le mer 19/11/2003 ? 10:27, Roland K?ser a ?crit : > Sorry that I now reactivating the Java discussion again, but I think > Java is one of the most important technolgies for the business > environment specially as a antipole against the whole .NET hype. Is > it not better to talk with sun about a version to ship with fedora. It > would also allow to ship tomcat and so many of java based web > applications for the business field. Is there a repository with JDK, Tomcat and NetBeans rpms? Could this be documented on the Fedora site? Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From pauln at truemesh.com Wed Nov 19 09:52:39 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 19 Nov 2003 09:52:39 +0000 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <3FBB378C.9020107@israel-jugendtag.ch> References: <1069206029.1545.8.camel@ByteEnable> <3FBB378C.9020107@israel-jugendtag.ch> Message-ID: <20031119095238.GC10042@ensim.rackshack.net> On Wed, Nov 19, 2003 at 10:27:40AM +0100, Roland K?ser wrote: First off please don't post in html. > Sorry that I now reactivating the Java discussion again, but I think Java is > one of the most important technolgies for the business environment specially as > a antipole against the whole .NET hype. Yest but the license agreements are non-trivial - trust me. Different components vary and if you aren't shipping an app or are making changes (eg fixing up stuff to detect nptl, fixing paths) you are most likely in breach of them. > Is it not better to talk with sun People have tried, as a community project it's quite hard. Some have been successfull but only with a limited scope - eg jboss distributing the j2ee apis, the license is non-transferable: " The licensee (JBoss Group) is granted the permission to distribute the Sun stuff for the sole purpose of running the application. And the license is non-transferable." Which means say if you write a junitee test or a mock object using j2ee apis then you could technically be in breach of the license. I suggest you dig through jpackage archives and debian-legal for more information about the intresting combinations of licensing there was a summary post on the various non-free components and the versions of the licenses but I don't have that to hand. > about a version to ship with fedora. It would also allow to ship tomcat and so > many of java based web applications for the business field. If you want to use tomcat on fedora (in a package managed fashion), you have a few choices: 1) use naoko - the natively compiled tomcat which will ship in FC2 if all goes well I believe. 2) Use JPackage and rebuild the non-free components your self - from the FAQ: What is with the non-free section? The non-free section contains some vital/interesting applications that can not be redistributed as binaries due to licensing restrictions. The JPackage Project has made every reasonable effort to contact the various vendors and see if an agreement could be made to distribute binaries, but at least for now, the no source RPMs (.nosrc.rpm) has been determined to be the only legal method available. There's something YOU can do about this: go vote for bug id 4680244 at Sun's bug parade. We don't want to stop you using java, just we'd rather not breach the license agreements, of course if you want to redistribute the JDK in a sane manner in breach of the sun license there is nothing stopping you from setting up a repository rebuilt from the JPackage nosrc.rpms, indeed for internal use in a company this is probably fine, but a public repositiory is not going to happen unless the licensing improves. It is not practical for a distribution to repackage stuff without patching or changing paths for FHS compatibility. Paul From pauln at truemesh.com Wed Nov 19 09:54:45 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 19 Nov 2003 09:54:45 +0000 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <1069234916.8970.352.camel@localhost.localdomain> References: <1069206029.1545.8.camel@ByteEnable> <3FBB378C.9020107@israel-jugendtag.ch> <1069234916.8970.352.camel@localhost.localdomain> Message-ID: <20031119095444.GD10042@ensim.rackshack.net> On Wed, Nov 19, 2003 at 10:41:56AM +0100, tony wrote: > Is there a repository with JDK, Tomcat and NetBeans rpms? Could this be > documented on the Fedora site? http://www.jpackage.org - it's been mentioned before. NetBeans is probably out of date but I believe some people were looking it - of course more volunteers are always welcome. Also is this really a development question? Paul From rms at 1407.org Wed Nov 19 09:56:22 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 19 Nov 2003 09:56:22 +0000 Subject: [Fwd: [Bug 23679] NTLM auth for HTTP] In-Reply-To: <3FBAA6E2.7070306@carwyn.com> References: <1069148453.2888.13.camel@roque> <3FBA96AB.6040006@virtual1.net> <3FBAA6E2.7070306@carwyn.com> Message-ID: <1069235781.2881.15.camel@roque> On Tue, 2003-11-18 at 23:10, Carwyn Edwards wrote: > > Damn Straight! I am so ready for this. I run our Intranet, and I have > > IIS (yuk) running it, just so there is a transparent login for our > > users. I personaly dont care if it asks for my username and password, > > as long as I can be on one box and work. > > The other option for single sign on is something like: > http://www.citi.umich.edu/projects/kerb_pki/ Yes. But those news are for people who, like me, don't run non-Free Software but have to co-exist in a network with too many non-Free Software programs running, some of them beyond their power to make a change. I've been having to use an ntlm proxy but it's definitely not perfect :| 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 tony at tgds.net Wed Nov 19 10:11:15 2003 From: tony at tgds.net (tony) Date: Wed, 19 Nov 2003 11:11:15 +0100 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <20031119095444.GD10042@ensim.rackshack.net> References: <1069206029.1545.8.camel@ByteEnable> <3FBB378C.9020107@israel-jugendtag.ch> <1069234916.8970.352.camel@localhost.localdomain> <20031119095444.GD10042@ensim.rackshack.net> Message-ID: <1069236674.8970.386.camel@localhost.localdomain> Le mer 19/11/2003 ? 10:54, Paul Nasrat a ?crit : > On Wed, Nov 19, 2003 at 10:41:56AM +0100, tony wrote: > > > Is there a repository with JDK, Tomcat and NetBeans rpms? Could this be > > documented on the Fedora site? > > http://www.jpackage.org - it's been mentioned before. NetBeans is probably out > of date but I believe some people were looking it - of course more volunteers > are always welcome. > > Also is this really a development question? I want to build a distribution based on Fedora that includes a JDK and Tomcat (for confidential distribution). So I guess it has something to do with development. I am aware that Fedora can't do what I need so I am attempting to roll my own. Cheers Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From zboszor at freemail.hu Wed Nov 19 10:38:02 2003 From: zboszor at freemail.hu (Boszormenyi Zoltan) Date: Wed, 19 Nov 2003 11:38:02 +0100 Subject: Fedora/x86_64 vs 32-bit user space Message-ID: <3FBB480A.6040208@freemail.hu> Hi, I am thinking about buying an Athlon64 machine and use Fedora. Is there a way to be able to use (and maybe compile) ia32 binaries with this setup? I have seen only /lib64 and /usr/lib64 in glibc-2.3.2-101.x86_64.rpm the are conflicts between glibc-*i[36]86.rpm and glibc-*x86_64.rpm I was thinking about dosemu and wine (games mostly) but I would like to use the increased performance of the 64-bit mode with e.g. PostgreSQL, etc. -- Best regards, Zolt?n B?sz?rm?nyi --------------------- What did Hussein say about his knife? One in Bush worth two in the hand. From pauln at truemesh.com Wed Nov 19 11:35:55 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 19 Nov 2003 11:35:55 +0000 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <1069236674.8970.386.camel@localhost.localdomain> References: <1069206029.1545.8.camel@ByteEnable> <3FBB378C.9020107@israel-jugendtag.ch> <1069234916.8970.352.camel@localhost.localdomain> <20031119095444.GD10042@ensim.rackshack.net> <1069236674.8970.386.camel@localhost.localdomain> Message-ID: <20031119113553.GF10042@ensim.rackshack.net> On Wed, Nov 19, 2003 at 11:11:15AM +0100, tony wrote: > I want to build a distribution based on Fedora that includes a JDK and > Tomcat (for confidential distribution). So I guess it has something to > do with development. I am aware that Fedora can't do what I need so I am > attempting to roll my own. You can rebuild the nosrc.rpm from jpackage, host the binaries privately in a repo or use anaconda to mung them in. You can grab all the free binaries from a mirror. Of course you might want to check with a lawyer but I think it's ok for internal use in a company (counts as individual?). Paul From ms-nospam-0306 at arcor.de Wed Nov 19 12:56:08 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 19 Nov 2003 13:56:08 +0100 Subject: I believe symlink libart_lgpl_2.so is missing In-Reply-To: References: Message-ID: <20031119135608.6fcbb73f.ms-nospam-0306@arcor.de> On Tue, 18 Nov 2003 15:24:46 +0000, Jean-Francois Veillette wrote: > Hi > > On my system, > >ls -l /usr/lib/libart_lgpl_2* > >symlink libart_lgpl_2.so.2 -> symlink libart_lgpl_2.so.2.3.16 > >symlink libart_lgpl_2.so.2.3.16 > > apps like rekall won't compile because of that, making the symlink fix the > compile problem. > search buzilla with ibart_lgpl_2 found nothing about that. $ rpm --redhatprovides /usr/lib/libart_lgpl_2.so.2 libart_lgpl-2.3.16-1 During compilation the following link is needed: $ rpm --redhatprovides /usr/lib/libart_lgpl_2.so libart_lgpl-devel-2.3.16-1 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From 64bit_fedora at comcast.net Wed Nov 19 13:00:26 2003 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Wed, 19 Nov 2003 07:00:26 -0600 Subject: Fedora/x86_64 vs 32-bit user space In-Reply-To: <3FBB480A.6040208@freemail.hu> References: <3FBB480A.6040208@freemail.hu> Message-ID: <20031119130026.GA15597@comcast.net> On Wed, Nov 19, 2003 at 11:38:02AM +0100, Boszormenyi Zoltan wrote: > > I am thinking about buying an Athlon64 machine and use Fedora. > Is there a way to be able to use (and maybe compile) ia32 binaries > with this setup? I have seen only /lib64 and /usr/lib64 in > glibc-2.3.2-101.x86_64.rpm the are conflicts between glibc-*i[36]86.rpm > and glibc-*x86_64.rpm It is sane to have both 32-bit and 64-bit libs installed, in fact it is required as a couple of packages still do not work in 64-bit. Open Office is one of these. > > I was thinking about dosemu and wine (games mostly) but I would like > to use the increased performance of the 64-bit mode with e.g. PostgreSQL, > etc. 32-bit games which require 3D performance might be a tricky one, For gaming, I think I would recommend a dual boot, 32-bit Fedora and 64-bit Fedora. Justin M. Forbes From ms-nospam-0306 at arcor.de Wed Nov 19 13:15:11 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 19 Nov 2003 14:15:11 +0100 Subject: Warren's Package Naming Proposal - Revision 2 In-Reply-To: References: <1068236427.12684.60.camel@laptop> Message-ID: <20031119141511.5cde634e.ms-nospam-0306@arcor.de> On Tue, 18 Nov 2003 12:04:42 -0500 (EST), Mike A. Harris wrote: > On Fri, 7 Nov 2003, Aurelien Bompard wrote: > > >These guidelines seem fine, thanks for the work. > > > >However, I have recently bumped into a package naming problem which doesn't > >seem to be covered here. It's a program called K3B, a CD/DVD burning > >frontend for KDE. > >Here is their release numbers : 0.8 -> 0.9 -> 0.10 > >How should we set the RPM fields without using epochs in this type of > >versionning ? Is is a case where epoch is necessary ? > > Release: 0.8 > Release: 0.9 > Release: 0.10 > > What's the problem? As a follow-up here (someone should have changed the subject line early!), the k3b maintainer has been so kind to delete the News section at k3b.org which asked packagers to increase the Epoch for the step from 0.9 to 0.10. It's too late, however, since all or some of the k3b rpms are shipped with Epoch 1. But at least one source of misinformation is gone. Some (or just one?) of the k3b.org packagers (no names known ;) have had the impression that RPM version comparison would not allow a normal upgrade from 0.9 to 0.10. No idea whether they had discussed it on some mailing-list. But apparently, internal communication had lead to a wrong news release that the step from 0.9 to 0.10 would require the Epoch to be increased. It's a common misconception that RPM versions are compared as floating-point numbers or strings. Probably there are wrong HOWTOs somewhere. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From shekhar.tiwatne at ensim.com Wed Nov 19 14:10:01 2003 From: shekhar.tiwatne at ensim.com (Shekhar) Date: 19 Nov 2003 19:40:01 +0530 Subject: mysql4 In-Reply-To: <20031119103457.5041.17231.Mailman@listman.back-rdu.redhat.com> References: <20031119103457.5041.17231.Mailman@listman.back-rdu.redhat.com> Message-ID: <1069251000.22858.83.camel@stiwatne.india.ensim.com> Hi, Any chances to see mysql4 in coming fedora relesaes? TIA, -- shekhar From rhl at reachone.com Wed Nov 19 16:54:23 2003 From: rhl at reachone.com (Adam Debus) Date: Wed, 19 Nov 2003 08:54:23 -0800 Subject: mysql4 References: <20031119103457.5041.17231.Mailman@listman.back-rdu.redhat.com> <1069251000.22858.83.camel@stiwatne.india.ensim.com> Message-ID: <00e301c3aebd$c8ef3e00$e2e8b1d8@adam12> Please check the archives, this question has been answered recently on both fedora-devel-list and fedora-list. Thanks, Adam Debus Network Engineer, ReachONE Internet adam at reachone.com ----- Original Message ----- From: "Shekhar" To: Sent: Wednesday, November 19, 2003 6:10 AM Subject: mysql4 > Hi, > Any chances to see mysql4 in coming fedora relesaes? > TIA, > -- > shekhar > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From hp at redhat.com Wed Nov 19 16:46:01 2003 From: hp at redhat.com (Havoc Pennington) Date: Wed, 19 Nov 2003 11:46:01 -0500 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <3FBB378C.9020107@israel-jugendtag.ch> References: <1069206029.1545.8.camel@ByteEnable> <3FBB378C.9020107@israel-jugendtag.ch> Message-ID: <1069260361.17309.8.camel@localhost.localdomain> On Wed, 2003-11-19 at 04:27, Roland K?ser wrote: > > Sorry that I now reactivating the Java discussion again, but I think > Java is one of the most important technolgies for the business > environment specially as a antipole against the whole .NET hype. Is > it not better to talk with sun about a version to ship with fedora. It > would also allow to ship tomcat and so many of java based web > applications for the business field. > Fedora doesn't have business deals around it or proprietary software in it, because those would interfere with the goals of the project. Havoc From xose at wanadoo.es Wed Nov 19 17:04:56 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 19 Nov 2003 18:04:56 +0100 Subject: strip flag in rpm-build References: <3FBAE125.2040701@wanadoo.es> Message-ID: <3FBBA2B8.5050308@wanadoo.es> Alexandre Oliva wrote: > On Nov 19, 2003, Xose Vazquez Perez wrote: >>brp-strip-static-archive: strip -g $f > If you strip a library with -s, IIRC you won't be able to link (ld, > not ld.so or dlopen) with it any more. Bad idea for -devel libs. You are right, I thought brp-strip-static-archive was for static bin files. But it's for 'static libraries'. However brp-strip is for only 'ELF binaries' and there is no problem, in theory, to replace '-g' with '-s'. -- HTML mails are going to trash automagically From xose at wanadoo.es Wed Nov 19 17:05:37 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 19 Nov 2003 18:05:37 +0100 Subject: FC2, 2.6 vs 2.4 References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> <3FB556FF.2090601@wanadoo.es> <1068892970.2154.2.camel@teapot.felipe-alfaro.com> Message-ID: <3FBBA2E1.4050001@wanadoo.es> Felipe Alfaro Solana wrote: > Some of them can be easily replaced by newer ones (for example, IDE-SCSI > was used mainly for CD-Burning, but now you can use direct ATAPI > CD-Burning), and some will be superseded by newer versions, like LVM2 or > EVMS. should-fix.txt: drivers/ide/ ~~~~~~~~~~~~ (Alan) o IDE PIO has occasional unexplained PIO disk eating reports PRI1 o IDE has multiple zillions of races/hangs in 2.5 still PRI1 o There are lots of other IDE bugs that wont go away until the taskfile stuff is included, the locking bugs that allow any user to hang the IDE layer in 2.5, and some other updates are forward ported. (esp. HPT372N). PRI1 [...] > For mainstream usage, I think 2.6 is ready for most of the people out > there. must-fix.txt: o alan: Forward port 2.4 fixes - Security fixes including execve holes, execve vs proc races o There are about 60 or 70 security related checks that need doing (copy_user etc) from Stanford tools. (badari is looking into this, and hollisb) o A couple of hundred real looking bugzilla bugs [...] Maybe in six months +/- it will be ok. -- HTML mails are going to trash automagically From xose at wanadoo.es Wed Nov 19 17:07:03 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 19 Nov 2003 18:07:03 +0100 Subject: FC2, 2.6 vs 2.4 References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <1068765241.5753.249.camel@mirkwood.devel.redhat.com> Message-ID: <3FBBA337.6060800@wanadoo.es> moving to devel Jeremy Katz wrote: > at this point ;-), it is impossible to take advantage of all of the > benefits that you get with 2.6 and still leave a 2.4.x kernel. Not to I understand RH wants to do a 2.6 distribution _soon_, because there are lot of new features necessary for enterprises, RHEL 4.But I would like to see a backup 2.4 kernel. Because it's certainly impossible that first 2.6.x releases brings all features/stability/security/... that 2.4 gets today. > mention the question of how do you present this to the user. It is not necessary a install option, it's enough to place the packages on a CD dir. > The right answer is to get 2.6.x to where it doesn't cause FC2 to be "a > lame distribution" by getting it tested and stabilized :-) lame distribution becase the kernel is lame. Today kernel TODO list is not very small. -- HTML mails are going to trash automagically From xose at wanadoo.es Wed Nov 19 17:14:10 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 19 Nov 2003 18:14:10 +0100 Subject: FC2, 2.6 vs 2.4 References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <20031114212358.GG1019032@hiwaay.net> Message-ID: <3FBBA4E2.7070703@wanadoo.es> Chris Adams wrote: > And FC2 is around 5 months away; there's a lot of time to get things in > shape. I don't expect a kernel for_all until ~ summer 2004. There is too much work to do, drivers mainly and lot of fixes. > Having a new kernel as a "preview" is a far sight from having two major To put 2.6 by default, and 2.4 as backup. What's the problem ? > If someone wants to maintain a 2.4 kernel for FC2, they could do it as > part of Fedora Alternatives or Extras. I hope that someone do it. -- HTML mails are going to trash automagically From Nicolas.Mailhot at laPoste.net Wed Nov 19 17:59:03 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 19 Nov 2003 18:59:03 +0100 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <3FBBA337.6060800@wanadoo.es> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <1068765241.5753.249.camel@mirkwood.devel.redhat.com> <3FBBA337.6060800@wanadoo.es> Message-ID: <1069264743.8821.3.camel@m70.net81-64-235.noos.fr> Le mer 19/11/2003 ? 18:07, Xose Vazquez Perez a ?crit : > > The right answer is to get 2.6.x to where it doesn't cause FC2 to be "a > > lame distribution" by getting it tested and stabilized :-) > > lame distribution becase the kernel is lame. Today kernel TODO list is not > very small. And there is a gazillon new hardware that will only work correctly with 2.6. So wich kernel is lamer ? Depends on your usage. Current 2.6 is more than good enough to end up in rawhide (speaking as someone who uses 2.4 and 2.6 systems everyday). There is no way it can get as good as you want it without further testing. (Remember, when most kernel developers will have switched to 2.7 it'll be way to late to complain. The window for polishing 2.6 is *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 alan at redhat.com Wed Nov 19 18:05:00 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Nov 2003 13:05:00 -0500 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <3FBBA2E1.4050001@wanadoo.es> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> <3FB556FF.2090601@wanadoo.es> <1068892970.2154.2.camel@teapot.felipe-alfaro.com> <3FBBA2E1.4050001@wanadoo.es> Message-ID: <20031119180500.GB18425@devserv.devel.redhat.com> > o IDE has multiple zillions of races/hangs in 2.5 still Bart has been working through these and Andrew Morton. This is the easy stuff btw because someone knows it needs doing. To quote the Apollo 13 astronaut prelaunch conference "What is the greatest danger you face" "The one we haven't thought of" > o alan: Forward port 2.4 fixes > - Security fixes including execve holes, execve vs proc races Going on big time right now. Again its the know stuff From pauln at truemesh.com Wed Nov 19 18:08:51 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 19 Nov 2003 18:08:51 +0000 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <3FBBA337.6060800@wanadoo.es> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <1068765241.5753.249.camel@mirkwood.devel.redhat.com> <3FBBA337.6060800@wanadoo.es> Message-ID: <20031119180850.GM10042@ensim.rackshack.net> On Wed, Nov 19, 2003 at 06:07:03PM +0100, Xose Vazquez Perez wrote: > moving to devel > > Jeremy Katz wrote: > > > at this point ;-), it is impossible to take advantage of all of the > > benefits that you get with 2.6 and still leave a 2.4.x kernel. Not to > > I understand RH wants to do a 2.6 distribution _soon_, because there are > lot of new features necessary for enterprises, RHEL 4.But I would like > to see a backup 2.4 kernel. Because it's certainly impossible > that first 2.6.x releases brings all features/stability/security/... > that 2.4 gets today. With Fedora - if you want to stick with 2.4 support Fedora Legacy and stick with FC 1 - no-one's forcing you to upgrade. However development will go on... Paul From xose at wanadoo.es Wed Nov 19 18:11:55 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 19 Nov 2003 19:11:55 +0100 Subject: FC2, 2.6 vs 2.4 References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <1068765241.5753.249.camel@mirkwood.devel.redhat.com> <3FBBA337.6060800@wanadoo.es> <1069264743.8821.3.camel@m70.net81-64-235.noos.fr> Message-ID: <3FBBB26B.6040408@wanadoo.es> Nicolas Mailhot wrote: > complain. The window for polishing 2.6 is *now*) Did you see latest mm patch ? try it: http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm4/ -- HTML mails are going to trash automagically From roozbeh at sharif.edu Wed Nov 19 19:19:58 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Wed, 19 Nov 2003 22:49:58 +0330 Subject: joe UTF-8 support Message-ID: <1069269598.4603.11.camel@guava.bamdad.org> I heard on the #fedora-devel one day that some people are trying to implement UTF-8 support in joe (or at least giving it a thought). I have an irc log of that, but that wasn't enough to identify people. So, let me ask again: is anyone working on or thinking seriously about adding UTF-8 support to joe the editor? roozbeh From xose at wanadoo.es Wed Nov 19 18:24:57 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 19 Nov 2003 19:24:57 +0100 Subject: FC2, 2.6 vs 2.4 References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <1068765241.5753.249.camel@mirkwood.devel.redhat.com> <3FBBA337.6060800@wanadoo.es> <20031119180850.GM10042@ensim.rackshack.net> Message-ID: <3FBBB579.20207@wanadoo.es> Paul Nasrat wrote: >>I understand RH wants to do a 2.6 distribution _soon_, because there are >>lot of new features necessary for enterprises, RHEL 4.But I would like >>to see a backup 2.4 kernel. Because it's certainly impossible ^^^^^^^^^^^^^^^^^ > With Fedora - if you want to stick with 2.4 support Fedora Legacy > and stick with FC 1 - no-one's forcing you to upgrade. However > development will go on... who did speak about to block development? -- HTML mails are going to trash automagically From laurent at guerby.net Wed Nov 19 20:38:17 2003 From: laurent at guerby.net (Laurent GUERBY) Date: Wed, 19 Nov 2003 21:38:17 +0100 Subject: ATI radeon 9600 Pro / willing to test and report In-Reply-To: <20031118223354.GA32270@devserv.devel.redhat.com> References: <1069140442.4011.25.camel@dell> <20031118223354.GA32270@devserv.devel.redhat.com> Message-ID: <1069274296.9940.7.camel@dell> On Tue, 2003-11-18 at 23:33, Alan Cox wrote: > On Tue, Nov 18, 2003 at 08:27:23AM +0100, Laurent GUERBY wrote: > > Just a small note: most of GUI tools are unusable at 640x480 > > since you cannot access the buttons at the bottom of the window, > > sometimes even after a resize. I don't know if the GUI guidelines > > say something about supporting 640x480. > > Most of them work fine if you replace metacity with a window manager > thats a bit smarter about small screens and forcing sizing. Still not > ideal though. I changed font sizes, that's already a bit better :). Still a few things have > 480 harcoded height (like redhat-config-nfs). On the original problem, looks like the XFree86 people are aware of it: http://bugs.xfree86.org/show_bug.cgi?id=798 I'll have to live with 640x480 for a while... Laurent From fs111 at web.de Wed Nov 19 20:34:38 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Wed, 19 Nov 2003 21:34:38 +0100 Subject: ATI radeon 9600 Pro / willing to test and report In-Reply-To: <1069140442.4011.25.camel@dell> References: <1069140442.4011.25.camel@dell> Message-ID: <1069274078.23132.8.camel@localhost> Am Di, den 18.11.2003 schrieb Laurent GUERBY um 08:27: Hi! > Hi, I've just installed Fedora Core 1 on my new machine wich has > an ATI Radeon 9600 Pro. All I've got is a 640x480 resolution > with the vesa driver on my Hyundai Q17 LCD 17" (1280x1024) but it's > working :). I tried the generic radeon, it gets the right > resolution but it freezes the machine after a few seconds. Why aren't you using those drivers from ati? OK, it is not GPL, but better than 640x480 IMHO. They are working fine (glxgears has more than 4000 frames). If you are interested I can send you the XF86Config the ati tool created on an box from a friend of me for a Sapphire Radeon 9600 Pro. > Thanks in advance, > > Laurent Andr? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From lhh at redhat.com Wed Nov 19 22:16:36 2003 From: lhh at redhat.com (Lon Hohberger) Date: Wed, 19 Nov 2003 17:16:36 -0500 Subject: joe UTF-8 support In-Reply-To: <1069269598.4603.11.camel@guava.bamdad.org> References: <1069269598.4603.11.camel@guava.bamdad.org> Message-ID: <1069280196.5258.10.camel@atlantis.boston.redhat.com> On Wed, 2003-11-19 at 14:19, Roozbeh Pournader wrote: > So, let me ask again: is anyone working on or thinking seriously about > adding UTF-8 support to joe the editor? I looked at it briefly, but I didn't get too far before more important things came up. On a side note, it's probably much easier to write a joe.elisp or joe.vim ... :) You might want to check: http://sf.net/projects/joe-editor -- Lon -- Lon Hohberger Red Hat, Inc. --> http://www.redhat.com My Public Key --> http://people.redhat.com/lhh/pubkey.txt -------------- 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 Wed Nov 19 22:22:22 2003 From: skvidal at phy.duke.edu (Seth Vidal) Date: 19 Nov 2003 17:22:22 -0500 Subject: joe UTF-8 support In-Reply-To: <1069280196.5258.10.camel@atlantis.boston.redhat.com> References: <1069269598.4603.11.camel@guava.bamdad.org> <1069280196.5258.10.camel@atlantis.boston.redhat.com> Message-ID: <1069280542.9958.0.camel@opus> On Wed, 2003-11-19 at 17:16, Lon Hohberger wrote: > On Wed, 2003-11-19 at 14:19, Roozbeh Pournader wrote: > > > So, let me ask again: is anyone working on or thinking seriously about > > adding UTF-8 support to joe the editor? > > I looked at it briefly, but I didn't get too far before more important > things came up. On a side note, it's probably much easier to write a > joe.elisp or joe.vim ... :) hmmmmmm a joe.vim. -sv From seyman at wanadoo.fr Thu Nov 20 00:13:10 2003 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Thu, 20 Nov 2003 01:13:10 +0100 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <3FBBB579.20207@wanadoo.es> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <1068765241.5753.249.camel@mirkwood.devel.redhat.com> <3FBBA337.6060800@wanadoo.es> <20031119180850.GM10042@ensim.rackshack.net> <3FBBB579.20207@wanadoo.es> Message-ID: <20031120001309.GA9658@orient.maison.moi> On Wed, Nov 19, 2003 at 07:24:57PM +0100, Xose Vazquez Perez wrote: > > >>to see a backup 2.4 kernel. Because it's certainly impossible > ^^^^^^^^^^^^^^^^^ [snip] > who did speak about to block development? A backup 2.4 kernel will block developement. There is too much code to write, too many conditions to adapt to, that having a backup 2.4 kernel will be an inconvenience more than a benefit. Emmanuel From kje_m at yahoo.no Thu Nov 20 06:53:46 2003 From: kje_m at yahoo.no (Kjetil Mikkelborg) Date: Thu, 20 Nov 2003 07:53:46 +0100 Subject: diskless Message-ID: <1069311226.2890.19.camel@localhost.localdomain> Hi I was pretty impressed with the new redhat-config-netboot configurator which was included with fedora, but when starting to create my diskless images, I could not stop thinking about how suboptimal it is to let anaconda optimize a installation for a spesific computer, and then use that installation as an image for other diskless clients! Would it be possible to let the anaconda guided install to make an generic install into a directory or something? By generic install i mean an install with no or little hw config set by kudzu per default, Xconfigurator part be run at firstboot instead of in the installation (hmm has it been moved to firstboot allready?, can't remember ;), and offcourse support kickstart install as of today, so an administrator can choose what he knows about the computer base, and what he (or the user) can/should do at the computer itself. I also noticed that when using an redhat-config-netboot setup image, there seems to be problems with things like running kudzu, and that /dev/ptr seems to be mounted several times and so on. Is this normal, or is this just my image which is screwed? (or is redhat-config-netboot actually very beta as of now?) Well anyway, I really thinks fedora has become a pretty nice distro, and a big thankyou to the peoples who has created redhat-config-netboot, kudzu, and the anaconda installer. It really makes my life alot easier! Thanks! Kjetil Mikkelborg. From buildsys at porkchop.devel.redhat.com Thu Nov 20 10:00:08 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Thu, 20 Nov 2003 05:00:08 -0500 Subject: rawhide report: 20031120 changes Message-ID: <200311201000.hAKA08028342@porkchop.devel.redhat.com> From stan at ccs.neu.edu Thu Nov 20 19:28:56 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Thu, 20 Nov 2003 14:28:56 -0500 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <20031120001309.GA9658@orient.maison.moi> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <1068765241.5753.249.camel@mirkwood.devel.redhat.com> <3FBBA337.6060800@wanadoo.es> <20031119180850.GM10042@ensim.rackshack.net> <3FBBB579.20207@wanadoo.es> <20031120001309.GA9658@orient.maison.moi> Message-ID: <1069356536.1274.188.camel@duergar> On Wed, 2003-11-19 at 19:13, Emmanuel Seyman wrote: > > who did speak about to block development? > > A backup 2.4 kernel will block developement. > There is too much code to write, too many conditions to adapt to, > that having a backup 2.4 kernel will be an inconvenience more > than a benefit. > I totally agree, mainly because supporting both is a huge problem because of things working differently, incompatible module types, init changes necessary etc... I'd like to see just 2.6 in FC2. -sb From gbenson at redhat.com Thu Nov 20 12:41:17 2003 From: gbenson at redhat.com (Gary Benson) Date: Thu, 20 Nov 2003 12:41:17 +0000 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <87islh9siv.fsf@fleche.redhat.com> References: <200311172348.02582.rezso@rdsor.ro> <87islh9siv.fsf@fleche.redhat.com> Message-ID: <20031120124115.GB3424@redhat.com> Tom Tromey wrote: > >>>>> "Balint" == Balint Cristian writes: > > Balint> Any plans to ship this with fedora ? Yes. As soon as possible! > Balint> http://people.redhat.com/gbenson/naoko/ > Balint> It works pretty well (for me), curios why cannot be shiped > Balint> with fedora ? > > Right now there's a compiler versioning problem. The gcc-ssa that > is (will be? I haven't been paying attention) in Fedora is more > experimental than the one Gary has been using for Naoko. And > /usr/bin/gcj is too old to compile Naoko. We'd have to import gcc > 3.4 (-ish) to make this work. Maybe that will happen, though. > We'll need the same thing if gcj-eclipse goes into Fedora. The only big patch that I can think of that Tomcat needs is the solib (gcjlib?) URL one. Tom, would it be possible to make this work with the system libgcj? Gary From stan at ccs.neu.edu Thu Nov 20 19:33:05 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Thu, 20 Nov 2003 14:33:05 -0500 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <3FBBA2E1.4050001@wanadoo.es> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> <3FB556FF.2090601@wanadoo.es> <1068892970.2154.2.camel@teapot.felipe-alfaro.com> <3FBBA2E1.4050001@wanadoo.es> Message-ID: <1069356784.1274.193.camel@duergar> On Wed, 2003-11-19 at 12:05, Xose Vazquez Perez wrote: > Maybe in six months +/- it will be ok. Maybe many of the show-stoppers for most people are fixed, and including 2.6 in Fedora Core 2 will help iron out the rest. The point of Fedora is to develop and stabilize Linux while jump-starting innovation right? I find 2.6 stable and much better for the desktop than 2.4 and would love for it to be included in FC2. -sb From buildsys at porkchop.devel.redhat.com Thu Nov 20 20:56:14 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Thu, 20 Nov 2003 15:56:14 -0500 Subject: rawhide report: 20031119 changes Message-ID: <200311202056.hAKKuE528842@porkchop.devel.redhat.com> Updated Packages: gnupg-1.2.3-1 ------------- * Mon Oct 27 2003 Nalin Dahyabhai 1.2.3-1 - use -fPIE instead of -fpie because some arches need it * Mon Oct 27 2003 Nalin Dahyabhai - build gnupg as a position-independent executable (Arjan van de Ven) * Mon Aug 25 2003 Nalin Dahyabhai - add Werner's key as a source file * Fri Aug 22 2003 Nalin Dahyabhai - update to 1.2.3 iputils-20020927-12 ------------------- * Thu Oct 02 2003 Phil Knirsch 20020927-12 - Fixed unaligned access problem on ia64 (#101417) * Wed Sep 10 2003 Phil Knirsch 20020927-11 - Don't use own headers, use glibc and kernheaders. * Thu Sep 04 2003 Bill Nottingham 20020927-10 - fix build with new glibc-kernheaders mgetty-1.1.30-5 --------------- * Tue Nov 18 2003 Nalin Dahyabhai 1.1.30-5 - fix paths given for faxq-helper in faxq and faxrm (#92090) mktemp-1.5-1 ------------ * Tue Nov 18 2003 Phil Knirsch 2:1.5-1 - Fix tarball name and use Epoch instead for versioning. mysql-3.23.58-5 --------------- * Tue Nov 18 2003 Kim Ho 3.23.58-5 - update mysql.init to use anonymous user (UNKNOWN_MYSQL_USER) for pinging mysql server (#108779) pvm-3.4.4-16 ------------ * Tue Nov 18 2003 Lon Hohberger 3.4.4-16 - Rebuild/tag to include patch. * Tue Nov 18 2003 Lon Hohberger 3.4.4-15 - Fix for bugzilla #110277. redhat-config-printer-0.6.83-1 ------------------------------ * Tue Nov 18 2003 Tim Waugh 0.6.83-1 - 0.6.83: - Allow remote queues to be the default (bug #103224). * Fri Nov 14 2003 Tim Waugh - Requires PyXML built for Python 2.3. rpmdb-fedora-1-0.20031119 ------------------------- xmlto-0.0.16-1 -------------- * Tue Nov 18 2003 Tim Waugh 0.0.16-1 - 0.0.16. From s.mako at gmx.net Thu Nov 20 14:40:42 2003 From: s.mako at gmx.net (s.mako at gmx.net) Date: Thu, 20 Nov 2003 15:40:42 +0100 (CET) Subject: new package Message-ID: Hi, As I understood reeding some information on Fedora that new programs/packages are also welcome in the project. I have been involved in translation and rpm packaging of a nice bibliographic program (working under gnome). A new stable release was out recently. It would be very nice to see the program in the list of fedora packages. Could anybody tell me how to go on with this idea?! Thanks Zoltan Kota From tromey at redhat.com Thu Nov 20 16:28:09 2003 From: tromey at redhat.com (Tom Tromey) Date: 20 Nov 2003 09:28:09 -0700 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <20031120124115.GB3424@redhat.com> References: <200311172348.02582.rezso@rdsor.ro> <87islh9siv.fsf@fleche.redhat.com> <20031120124115.GB3424@redhat.com> Message-ID: <87k75v2eee.fsf@fleche.redhat.com> >>>>> "Gary" == Gary Benson writes: Gary> The only big patch that I can think of that Tomcat needs is the Gary> solib (gcjlib?) URL one. Tom, would it be possible to make this Gary> work with the system libgcj? I think backporting the library to 3.3 would be pretty simple, really. We can just copy it into place, more or less. However, I think we'd need to pull in some front-end changes, too, which is where things get a little more complicated. I haven't been closely tracking what changed from 3.3->3.4 in gcc proper, the backport might not be trivial. Andrew might have a better idea about that, I CCd him. Tom From ms-nospam-0306 at arcor.de Fri Nov 21 01:13:52 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 21 Nov 2003 02:13:52 +0100 Subject: new package In-Reply-To: References: Message-ID: <20031121021352.538efda7.ms-nospam-0306@arcor.de> On Thu, 20 Nov 2003 15:40:42 +0100 (CET), s.mako at gmx.net wrote: > As I understood reeding some information on Fedora that new > programs/packages are also welcome in the project. > I have been involved in translation and rpm packaging of a nice > bibliographic program (working under gnome). A new stable release > was out recently. It would be very nice to see the program in the list of > fedora packages. > Could anybody tell me how to go on with this idea?! http://www.fedora.us/wiki/PackageSubmissionQAPolicy http://www.fedora.us/wiki/FedoraDocuments -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michael at koziarski.com Thu Nov 20 12:53:30 2003 From: michael at koziarski.com (Michael A. Koziarski) Date: Fri, 21 Nov 2003 01:53:30 +1300 (NZDT) Subject: Fedora.us QA Queue Message-ID: <1705.202.49.97.73.1069332810.squirrel@webmail.koziarski.net> Hey guys, The fedora.us QA queue is very full right now. This potentially could discourage potential packagers as their shiny new packages languish on the queue. While obviously the ideal solution is hundreds of skilled & qualified QA people, the reality is that the numbers are lacking here. I'd like to propose a modification to the package submission procedure. The current system is: 1) New package submitted 2) QA 3) PUBLISH 4) PENDING 5) VERIFIED 6) CLOSED With the QA step, naturally, taking the longest. In order to keep the QA queue relatively clean, I'd like to see some kind of pre-QA keyword. What I'm envisioning here is a step to rule out packages that: 1) Don't build/install cleanly on the supported distributions 2) Sources can't be verified against upstream 3) Crash, print warnings or don't work when they are installed 4) Are duplicates 6) etc. By ruling out such simple errors the talented QA people can focus on things like packaging standards, spec file errors and other such complicated things. Whereas the enthusiastic-but-not-quite-there people (myself included) can help with the simpler errors. Also, by staying in the bug's CC throughout its submission process, the pre-QA team will see the kind of errors that they're missing and will slowly but surely make the transition to Fully Fledged QA. Comments? Flames? Cheers Koz From ms-nospam-0306 at arcor.de Fri Nov 21 03:58:45 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 21 Nov 2003 04:58:45 +0100 Subject: Fedora.us QA Queue In-Reply-To: <1705.202.49.97.73.1069332810.squirrel@webmail.koziarski.net> References: <1705.202.49.97.73.1069332810.squirrel@webmail.koziarski.net> Message-ID: <20031121045845.4b67daba.ms-nospam-0306@arcor.de> On Fri, 21 Nov 2003 01:53:30 +1300 (NZDT), Michael A. Koziarski wrote: > I'd like to propose a modification to the package submission procedure. > > The current system is: > > 1) New package submitted > 2) QA > 3) PUBLISH > 4) PENDING > 5) VERIFIED > 6) CLOSED > > With the QA step, naturally, taking the longest. And sometimes the PENDING->VERIFIED step, because that's the step where the packager(s) or reviewer(s) must decide whether the built binary package is okay. I think, so far the fedora.us build system has produced working binaries always, if it hasn't failed completely due to missing build requirements. > In order to keep the QA > queue relatively clean, I'd like to see some kind of pre-QA keyword. > > What I'm envisioning here is a step to rule out packages that: > > 1) Don't build/install cleanly on the supported distributions > 2) Sources can't be verified against upstream > 3) Crash, print warnings or don't work when they are installed > 4) Are duplicates > 6) etc. > > By ruling out such simple errors the talented QA people can focus on > things like packaging standards, spec file errors and other such > complicated things. Whereas the enthusiastic-but-not-quite-there people > (myself included) can help with the simpler errors. > > Also, by staying in the bug's CC throughout its submission process, the > pre-QA team will see the kind of errors that they're missing and will > slowly but surely make the transition to Fully Fledged QA. > > > Comments? Flames? Useful suggestions. There's the NEEDSWORK keyword already, which, when replacing the QA keyword, moves a bug entry out of the QA queue (http://fedora.us/QA) and makes it appear in the http://fedora.us/NEEDSWORK queue only. Everyone should feel encouraged to evaluate package requests in the QA queue and help with comments on issues in the NEEDSWORK queue. This could also help in deciding which packages are popular and which are not and which should processed at a higher priority level. Else current reviewers decide on what they find interesting, what they are familiar with or where they think that common sense might suffice in order to produce something that works. Very helpful would be simple src.rpm rebuild attempts (and e.g. a look at "configure"'s output for missing features) to see whether a package builds and seems to work at least. Having users in the "Cc" field, who would signal "works for me / doesn't work for me" could speed up some approvals. There's also the UPDATE keyword which can be used to find package updates which usually are easier to review/approve than new submissions. [...] But also: many of the packages in the queue have a very special target group, such as several dozens of special purpose programming language packages or scientific applications. These would benefit from reviews by small teams of users who are really familiar with the software. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nos at utel.no Fri Nov 21 08:35:29 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Fri, 21 Nov 2003 09:35:29 +0100 Subject: Fedora.us QA Queue In-Reply-To: <2cc2767805054807d3@[192.168.170.10]> References: <2cc2767805054807d3@[192.168.170.10]> Message-ID: <2e3262cc05056507d3@[192.168.170.10]> On Fri, 2003-11-21 at 02:53, Michael A. Koziarski wrote: > Hey guys, > > The fedora.us QA queue is very full right now. This potentially could > discourage potential packagers as their shiny new packages languish on the > queue. While obviously the ideal solution is hundreds of skilled & > qualified QA people, the reality is that the numbers are lacking here. > > I'd like to propose a modification to the package submission procedure. > > The current system is: > > 1) New package submitted > 2) QA > 3) PUBLISH > 4) PENDING > 5) VERIFIED > 6) CLOSED > > With the QA step, naturally, taking the longest. In order to keep the QA > queue relatively clean, I'd like to see some kind of pre-QA keyword. > > What I'm envisioning here is a step to rule out packages that: > > 1) Don't build/install cleanly on the supported distributions > 2) Sources can't be verified against upstream > 3) Crash, print warnings or don't work when they are installed > 4) Are duplicates > 6) etc. > > By ruling out such simple errors the talented QA people can focus on > things like packaging standards, spec file errors and other such > complicated things. Whereas the enthusiastic-but-not-quite-there people > (myself included) can help with the simpler errors. > > Also, by staying in the bug's CC throughout its submission process, the > pre-QA team will see the kind of errors that they're missing and will > slowly but surely make the transition to Fully Fledged QA. > > > Comments? Flames? One thing I'd like is to have the packages in CVS or similar.. So I easily could change the spec files or similar when QA'ing. Often it's trivial or just some buildrequirements missing, and the round trip time between QA and fixing things gets long. But thats me.. And I guess ensuring the quality would be harder this way ... -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From didierbe at sps.nus.edu.sg Fri Nov 21 09:02:31 2003 From: didierbe at sps.nus.edu.sg (Didier Casse) Date: Fri, 21 Nov 2003 17:02:31 +0800 (SGT) Subject: upgrading RH 9 system->Fedora with iso files and apt only Message-ID: I have the yarrow's iso files on my HD in a RH9 system. Let's say I want to upgrade selected packages using an "apt-get install" pointing to my iso-mounted files, how do I do it? i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. Then what is the complete procedure to make my apt look into my own HD to upgrade packages. Can anybody redirect me to the correct resource or some literature hanging on the web? Thanks. Assume also that I do not wish to burn CDs! I do not want to use apt-cdrom. Thanks. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg From kjb at dds.nl Fri Nov 21 09:50:45 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Fri, 21 Nov 2003 10:50:45 +0100 Subject: upgrading RH 9 system->Fedora with iso files and apt only In-Reply-To: References: Message-ID: <1069408244.4047.15.camel@topicus6> On Fri, 2003-11-21 at 10:02, Didier Casse wrote: > I have the yarrow's iso files on my HD in a RH9 system. Let's say I want > to upgrade selected packages using an "apt-get install" pointing to my > iso-mounted files, how do I do it? > > i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. > > Then what is the complete procedure to make my apt look into my own HD to > upgrade packages. Can anybody redirect me to the correct > resource or some literature hanging on the web? Thanks. > > Assume also that I do not wish to burn CDs! I do not want to use > apt-cdrom. Thanks. I just updated a RH9 system to FC1 by writing the bootdisk image to a floppy and directing the installer to the hd partition containing the iso's. It's working fine now... I'm not sure, but maybe grub can boot those disk images as well? -- Klaasjan Brand From buildsys at porkchop.devel.redhat.com Fri Nov 21 10:01:53 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Fri, 21 Nov 2003 05:01:53 -0500 Subject: rawhide report: 20031121 changes Message-ID: <200311211001.hALA1rv09832@porkchop.devel.redhat.com> From rezso at rdsor.ro Fri Nov 21 12:42:37 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Fri, 21 Nov 2003 12:42:37 +0000 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <20031120124115.GB3424@redhat.com> References: <200311172348.02582.rezso@rdsor.ro> <87islh9siv.fsf@fleche.redhat.com> <20031120124115.GB3424@redhat.com> Message-ID: <200311211242.37408.rezso@rdsor.ro> On Thursday 20 November 2003 12:41, Gary Benson wrote: > Tom Tromey wrote: > > >>>>> "Balint" == Balint Cristian writes: > > > > Balint> Any plans to ship this with fedora ? > > Yes. As soon as possible! > > > Balint> http://people.redhat.com/gbenson/naoko/ > > Balint> It works pretty well (for me), curios why cannot be shiped > > Balint> with fedora ? > > > > Right now there's a compiler versioning problem. The gcc-ssa that > > is (will be? I haven't been paying attention) in Fedora is more > > experimental than the one Gary has been using for Naoko. And > > /usr/bin/gcj is too old to compile Naoko. We'd have to import gcc > > 3.4 (-ish) to make this work. Maybe that will happen, though. > > We'll need the same thing if gcj-eclipse goes into Fedora. > > The only big patch that I can think of that Tomcat needs is the solib > (gcjlib?) URL one. Tom, would it be possible to make this work with > the system libgcj? > > Gary Thanks Gary ! Sounds great, i think will be a huge tehnology improvement to add java based stuff in fedora/redhat, there will be great interest in it. Thank you, i wish lot of energy/time/joy to improve it. cristian > > > -- > fedora-list mailing list > fedora-list at redhat.com > To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list -- Life in itself has no meaning. Life is an opportunity to create meaning. \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ From jos at xos.nl Fri Nov 21 11:08:37 2003 From: jos at xos.nl (Jos Vos) Date: Fri, 21 Nov 2003 12:08:37 +0100 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <200311211242.37408.rezso@rdsor.ro>; from rezso@rdsor.ro on Fri, Nov 21, 2003 at 12:42:37PM +0000 References: <200311172348.02582.rezso@rdsor.ro> <87islh9siv.fsf@fleche.redhat.com> <20031120124115.GB3424@redhat.com> <200311211242.37408.rezso@rdsor.ro> Message-ID: <20031121120837.A14019@xos037.xos.nl> On Fri, Nov 21, 2003 at 12:42:37PM +0000, Balint Cristian wrote: > Sounds great, i think will be a huge tehnology improvement > to add java based stuff in fedora/redhat, there will be great interest in it. The problem is that you usually pretty soon face other incompatibilities and such, as soon as you start using additional packages. Last week we wanted to look at Chiba in combination with Tomcat, but that is incompatible with the current gcj, it seems, so you are forced to use Sun's (or IBM's, probably) JDK for the rest too, which is an awfull lot of work and/or you have to use third-party package that do or do not work out of the box and can or can not be regenerated without any problems (jpackage.org is not that bad, but still...). Just my personal frustration about looking a bit at Java stuff... ;-) -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From gbenson at redhat.com Fri Nov 21 11:50:59 2003 From: gbenson at redhat.com (Gary Benson) Date: Fri, 21 Nov 2003 11:50:59 +0000 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <20031121120837.A14019@xos037.xos.nl> References: <200311172348.02582.rezso@rdsor.ro> <87islh9siv.fsf@fleche.redhat.com> <20031120124115.GB3424@redhat.com> <200311211242.37408.rezso@rdsor.ro> <20031121120837.A14019@xos037.xos.nl> Message-ID: <20031121115058.GB12864@redhat.com> Jos Vos wrote: > Last week we wanted to look at Chiba in combination with Tomcat, but > that is incompatible with the current gcj Why so? From bishop at platypus.bc.ca Fri Nov 21 12:02:55 2003 From: bishop at platypus.bc.ca (bishop) Date: Fri, 21 Nov 2003 04:02:55 -0800 Subject: upgrading RH 9 system->Fedora with iso files and apt only In-Reply-To: <1069408244.4047.15.camel@topicus6> References: <1069408244.4047.15.camel@topicus6> Message-ID: <3FBDFEEF.6060405@platypus.bc.ca> Klaasjan, Do you have the time to write out a mini-howto on that? I have a feeling that your instruction can help a few people following in your footsteps, and who may not have the opportunity to figure out a working solution by themselves. Me, I need one that can reliably do it from 5000km away. It'll be loop-mounted ISOs, apt-get and similar craziness, I think. Or I need to book a flight. 8-) Either way, I'm not the target audience, but I'm close. ACME at cl says that CL can do it with just apt-get, and that's incredibly interesting. - bish Klaasjan Brand wrote: > On Fri, 2003-11-21 at 10:02, Didier Casse wrote: > >>I have the yarrow's iso files on my HD in a RH9 system. Let's say I want >>to upgrade selected packages using an "apt-get install" pointing to my >>iso-mounted files, how do I do it? >> >>i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. >> >>Then what is the complete procedure to make my apt look into my own HD to >>upgrade packages. Can anybody redirect me to the correct >>resource or some literature hanging on the web? Thanks. >> >>Assume also that I do not wish to burn CDs! I do not want to use >>apt-cdrom. Thanks. > > > I just updated a RH9 system to FC1 by writing the bootdisk image to a > floppy and directing the installer to the hd partition containing the > iso's. It's working fine now... > > I'm not sure, but maybe grub can boot those disk images as well? > -- "those who torment us for our own good will torment us without end, for they do so with the approval of their own conscience." http://quotes.telemanage.ca/quotes.nsf/quotes/7cfd6e1a41c2c42185256c840053e1e7 From jos at xos.nl Fri Nov 21 12:10:13 2003 From: jos at xos.nl (Jos Vos) Date: Fri, 21 Nov 2003 13:10:13 +0100 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <20031121115058.GB12864@redhat.com>; from gbenson@redhat.com on Fri, Nov 21, 2003 at 11:50:59AM +0000 References: <200311172348.02582.rezso@rdsor.ro> <87islh9siv.fsf@fleche.redhat.com> <20031120124115.GB3424@redhat.com> <200311211242.37408.rezso@rdsor.ro> <20031121120837.A14019@xos037.xos.nl> <20031121115058.GB12864@redhat.com> Message-ID: <20031121131013.A14251@xos037.xos.nl> On Fri, Nov 21, 2003 at 11:50:59AM +0000, Gary Benson wrote: > > Last week we wanted to look at Chiba in combination with Tomcat, but > > that is incompatible with the current gcj > > Why so? Because Chibah developers said their stuff "needs 1.4, while gcj is 1.2". (I just recall what I heart, I am not an expert in this.) -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From ms-nospam-0306 at arcor.de Fri Nov 21 12:30:21 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 21 Nov 2003 13:30:21 +0100 Subject: Fedora.us QA Queue In-Reply-To: <2e3262cc05056507d3@[192.168.170.10]> References: <2cc2767805054807d3@[192.168.170.10]> <2e3262cc05056507d3@[192.168.170.10]> Message-ID: <20031121133021.3b2ef098.ms-nospam-0306@arcor.de> On Fri, 21 Nov 2003 09:35:29 +0100, "Nils O." Sel?sdal wrote: > One thing I'd like is to have the packages in CVS or similar.. > So I easily could change the spec files or similar when QA'ing. > Often it's trivial or just some buildrequirements missing, and the > round trip time between QA and fixing things gets long. > But thats me.. And I guess ensuring the quality would be harder this > way ... CVS and automated build servers are in the works, but as long as no such infrastructure is publicly available or even open for everyone, repository development can continue with what's available. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bishop at platypus.bc.ca Fri Nov 21 12:30:48 2003 From: bishop at platypus.bc.ca (bishop) Date: Fri, 21 Nov 2003 04:30:48 -0800 Subject: Possible Project: CVS account manager In-Reply-To: <3FB952BC.2090907@haitsma.org> References: <87brra1xcy.fsf@fleche.redhat.com> <3FB952BC.2090907@haitsma.org> Message-ID: <3FBE0578.4010503@platypus.bc.ca> Jaap A. Haitsma wrote: > Tom Tromey wrote: >>>>>>> "Alexandre" == Alexandre Oliva writes: >>>> If there are any volunteers out there looking for a project, there's a >>>> need for a set of CVS account management scripts to be written. >> Alexandre> Talk to overseers at sources.redhat.com, I believe we already >> Alexandre> have this all in place there. >> >> Not really. The code on sources is really primitive. I wouldn't >> recommend it. >> >> But doesn't SourceForge/gForge already do a lot of what is needed >> here? >> > You guys probably know this, but just in case. You could use the > savannah software (a further development of an older open source version > of sourceforge) if you want to host everything yourself. > See: > http://savannah.gnu.org/projects/savannah/ Jaap, I'm sure the recommendation is appreciated, but I'm curious: what does savannah offer the gforge doesn't? I'm sure you know the difference, but folks who don't know one from the other may not, and could really benefit from a description. The research experience that led to your recommendation of Savannah could really be a great big help here. I hear, for instance, that gforge is maintained by a very recently ex-sourceforge developer, which says a lot to me about potential code quality and avoidance of pitfalls or some nasty code that may be lurking in the SF codebase that's been fixed in gforge. Potentially. - bish From pmatilai at welho.com Fri Nov 21 12:51:51 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 21 Nov 2003 14:51:51 +0200 (EET) Subject: upgrading RH 9 system->Fedora with iso files and apt only In-Reply-To: <3FBDFEEF.6060405@platypus.bc.ca> References: <1069408244.4047.15.camel@topicus6> <3FBDFEEF.6060405@platypus.bc.ca> Message-ID: On Fri, 21 Nov 2003, bishop wrote: > Klaasjan, > > Do you have the time to write out a mini-howto on that? I have a > feeling that your instruction can help a few people following in your > footsteps, and who may not have the opportunity to figure out a working > solution by themselves. > > Me, I need one that can reliably do it from 5000km away. It'll be > loop-mounted ISOs, apt-get and similar craziness, I think. Or I need to > book a flight. 8-) Either way, I'm not the target audience, but I'm > close. ACME at cl says that CL can do it with just apt-get, and that's > incredibly interesting. Ok, since you need a remote upgrade then apt/yum/up2date is needed. For apt you basically need to create a local repository of the RPMS. Suppose you have the iso's mounted in /mnt/yarrow1, /mnt/yarrow2 and /mnt/yarrow3, I'd probably do it somewhat like this (watch out for typos and thinkos, I wrote this from top of my head so not tested.. ): mkdir -p /var/tmp/fedora/RPMS.core cd /var/tmp/fedora/RPMS.core ln -s /mnt/yarrow1/Fedora/RPMS/* . ln -s /mnt/yarrow2/Fedora/RPMS/* . ln -s /mnt/yarrow3/Fedora/RPMS/* . genbasedir --bloat /var/tmp/fedora The add that to your sources.list: "file://var/tmp fedora core" Check that it works (no errors in output) by running "apt-get update" and then you should be ready to roll: apt-get install kernel (choose suitable one from the output) apt-get dist-upgrade ..and there it is, if all goes well. Note that there's a packaging issue which prevents a fully updated RHL 9 from being updated to FC 1 cleanly: Latest RH errata has these packages: perl-CGI 2:1.804-88.3 perl-CPAN 2:1.804-88.3 perl-DB_File 2:1.804-88.3 ..and FC1 has this: [pmatilai at chip]$ rpm -q --obsoletes perl perl-Digest-MD5 perl-MIME-Base64 perl-libnet perl-Storable perl-CGI <= 2:2.81-88 perl-CPAN <= 2:1.61-88 perl-DB_File <= 2:1.804-88 Meaning that those three packages don't get obsoleted by the new perl package although they should, otherwise there are file conflicts. To get around that do "rpm -e perl-CGI perl-CPAN perl-DB_File" before running dist-upgrade. Nothing *bad* will happen if you dont remove those first, you just wont be able to run the upgrade before you do. - Panu - From rezso at rdsor.ro Fri Nov 21 15:17:02 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Fri, 21 Nov 2003 15:17:02 +0000 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <20031121120837.A14019@xos037.xos.nl> References: <200311172348.02582.rezso@rdsor.ro> <200311211242.37408.rezso@rdsor.ro> <20031121120837.A14019@xos037.xos.nl> Message-ID: <200311211517.02852.rezso@rdsor.ro> On Friday 21 November 2003 11:08, Jos Vos wrote: > On Fri, Nov 21, 2003 at 12:42:37PM +0000, Balint Cristian wrote: > > Sounds great, i think will be a huge tehnology improvement > > to add java based stuff in fedora/redhat, there will be great interest in > > it. > > The problem is that you usually pretty soon face other incompatibilities > and such, as soon as you start using additional packages. > > Last week we wanted to look at Chiba in combination with Tomcat, but > that is incompatible with the current gcj, it seems, so you are forced > to use Sun's (or IBM's, probably) JDK for the rest too, which is an > awfull lot of work and/or you have to use third-party package that > do or do not work out of the box and can or can not be regenerated > without any problems (jpackage.org is not that bad, but still...). > > Just my personal frustration about looking a bit at Java stuff... ;-) You can write/develop your code for tomcat for 100% compatibility with gcj. Of couse a jdk/ibm one will be incompatible but if you chouse from the start gcj will be ok very ok in my opinion. And thats going on with other proprietary c/c++ versus gnu gcc always need a little workaraund to get it work from one to other, thats normal. cristian -- Life in itself has no meaning. Life is an opportunity to create meaning. \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ From rezso at rdsor.ro Fri Nov 21 15:19:06 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Fri, 21 Nov 2003 15:19:06 +0000 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <20031121115058.GB12864@redhat.com> References: <200311172348.02582.rezso@rdsor.ro> <20031121120837.A14019@xos037.xos.nl> <20031121115058.GB12864@redhat.com> Message-ID: <200311211519.06150.rezso@rdsor.ro> On Friday 21 November 2003 11:50, Gary Benson wrote: > Jos Vos wrote: > > Last week we wanted to look at Chiba in combination with Tomcat, but > > that is incompatible with the current gcj > > Why so? Probably they focus _only_ with Suns jdk ... Neead another effort to be gcj aware too the code. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Life in itself has no meaning. Life is an opportunity to create meaning. \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ From nos at utel.no Fri Nov 21 13:29:18 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Fri, 21 Nov 2003 14:29:18 +0100 Subject: Fedora.us QA Queue In-Reply-To: <2f002ae205059407d3@[192.168.170.10]> References: <2f002ae205059407d3@[192.168.170.10]> Message-ID: <2f3f49b40505ad07d3@[192.168.170.10]> On Fri, 2003-11-21 at 13:30, Michael Schwendt wrote: > On Fri, 21 Nov 2003 09:35:29 +0100, "Nils O." Selsdal wrote: > > > One thing I'd like is to have the packages in CVS or similar.. > > So I easily could change the spec files or similar when QA'ing. > > Often it's trivial or just some buildrequirements missing, and the > > round trip time between QA and fixing things gets long. > > But thats me.. And I guess ensuring the quality would be harder this > > way ... > > CVS and automated build servers are in the works, but as long as no such Ah. Didn't really know that. > infrastructure is publicly available or even open for everyone, > repository > development can continue with what's available. Ofcourse. -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s Tlf: 370 45 431 Mob: 943 01 380 w w w . u t e l s y s t e m s . c o m From nos at utel.no Fri Nov 21 13:29:19 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Fri, 21 Nov 2003 14:29:19 +0100 Subject: Fedora.us QA Queue In-Reply-To: <2f002ae205059407d3@[192.168.170.10]> References: <2f002ae205059407d3@[192.168.170.10]> Message-ID: <2f3f55710505ae07d3@[192.168.170.10]> On Fri, 2003-11-21 at 13:30, Michael Schwendt wrote: > On Fri, 21 Nov 2003 09:35:29 +0100, "Nils O." Selsdal wrote: > > > One thing I'd like is to have the packages in CVS or similar.. > > So I easily could change the spec files or similar when QA'ing. > > Often it's trivial or just some buildrequirements missing, and the > > round trip time between QA and fixing things gets long. > > But thats me.. And I guess ensuring the quality would be harder this > > way ... > > CVS and automated build servers are in the works, but as long as no such Ah. Didn't really know that. > infrastructure is publicly available or even open for everyone, > repository > development can continue with what's available. Ofcourse. -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s Tlf: 370 45 431 Mob: 943 01 380 w w w . u t e l s y s t e m s . c o m From gbenson at redhat.com Fri Nov 21 13:47:37 2003 From: gbenson at redhat.com (Gary Benson) Date: Fri, 21 Nov 2003 13:47:37 +0000 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <20031121131013.A14251@xos037.xos.nl> References: <200311172348.02582.rezso@rdsor.ro> <87islh9siv.fsf@fleche.redhat.com> <20031120124115.GB3424@redhat.com> <200311211242.37408.rezso@rdsor.ro> <20031121120837.A14019@xos037.xos.nl> <20031121115058.GB12864@redhat.com> <20031121131013.A14251@xos037.xos.nl> Message-ID: <20031121134735.GC12864@redhat.com> Jos Vos wrote: > On Fri, Nov 21, 2003 at 11:50:59AM +0000, Gary Benson wrote: > > > Last week we wanted to look at Chiba in combination with Tomcat, > > > but that is incompatible with the current gcj > > > > Why so? > > Because Chibah developers said their stuff "needs 1.4, while gcj is > 1.2". (I just recall what I heart, I am not an expert in this.) libgcj doesn't particularly conform to any specific Java version -- some bits are indeed 1.2, whereas others are bang up to date. Did you try running it? If so, what execptions was it throwing? It might be that it is missing something that is fairly simple to implement... Gary From kjb at dds.nl Fri Nov 21 14:13:49 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Fri, 21 Nov 2003 15:13:49 +0100 Subject: upgrading RH 9 system->Fedora with iso files and apt only In-Reply-To: <3FBDFEEF.6060405@platypus.bc.ca> References: <1069408244.4047.15.camel@topicus6> <3FBDFEEF.6060405@platypus.bc.ca> Message-ID: <1069424028.4047.83.camel@topicus6> On Fri, 2003-11-21 at 13:02, bishop wrote: > Klaasjan, > > Do you have the time to write out a mini-howto on that? I have a > feeling that your instruction can help a few people following in your > footsteps, and who may not have the opportunity to figure out a working > solution by themselves. I believe it's already documented in the RH installation guide. IMO it's not that hard to do: just use the boot floppy and select "hard drive" when asked for installation source. After that you can select a partition and enter the path where the ISO files are. > Me, I need one that can reliably do it from 5000km away. It'll be > loop-mounted ISOs, apt-get and similar craziness, I think. Or I need to > book a flight. 8-) Either way, I'm not the target audience, but I'm > close. ACME at cl says that CL can do it with just apt-get, and that's > incredibly interesting. Creating your own repository is documented all over the net: http://www.dragonsdawn.net/~gordon/red-hat-apt-repository-howto/ -- Klaasjan Brand From jos at xos.nl Fri Nov 21 14:15:38 2003 From: jos at xos.nl (Jos Vos) Date: Fri, 21 Nov 2003 15:15:38 +0100 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <20031121134735.GC12864@redhat.com>; from gbenson@redhat.com on Fri, Nov 21, 2003 at 01:47:37PM +0000 References: <200311172348.02582.rezso@rdsor.ro> <87islh9siv.fsf@fleche.redhat.com> <20031120124115.GB3424@redhat.com> <200311211242.37408.rezso@rdsor.ro> <20031121120837.A14019@xos037.xos.nl> <20031121115058.GB12864@redhat.com> <20031121131013.A14251@xos037.xos.nl> <20031121134735.GC12864@redhat.com> Message-ID: <20031121151538.A14721@xos037.xos.nl> On Fri, Nov 21, 2003 at 01:47:37PM +0000, Gary Benson wrote: > libgcj doesn't particularly conform to any specific Java version -- > some bits are indeed 1.2, whereas others are bang up to date. Did you > try running it? If so, what execptions was it throwing? It might be > that it is missing something that is fairly simple to implement... Yes, we did try it, and this was the result: java.lang.NoSuchMethodError: method java.io.File.toURI was not found And the Chiba people then did tell us that 1.4 story... -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From gbenson at redhat.com Fri Nov 21 14:52:16 2003 From: gbenson at redhat.com (Gary Benson) Date: Fri, 21 Nov 2003 14:52:16 +0000 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <20031121151538.A14721@xos037.xos.nl> References: <200311172348.02582.rezso@rdsor.ro> <87islh9siv.fsf@fleche.redhat.com> <20031120124115.GB3424@redhat.com> <200311211242.37408.rezso@rdsor.ro> <20031121120837.A14019@xos037.xos.nl> <20031121115058.GB12864@redhat.com> <20031121131013.A14251@xos037.xos.nl> <20031121134735.GC12864@redhat.com> <20031121151538.A14721@xos037.xos.nl> Message-ID: <20031121145213.GD12864@redhat.com> Jos Vos wrote: > On Fri, Nov 21, 2003 at 01:47:37PM +0000, Gary Benson wrote: > > > libgcj doesn't particularly conform to any specific Java version > > -- some bits are indeed 1.2, whereas others are bang up to date. > > Did you try running it? If so, what execptions was it throwing? > > It might be that it is missing something that is fairly simple to > > implement... > > Yes, we did try it, and this was the result: > > java.lang.NoSuchMethodError: method java.io.File.toURI was not found > > And the Chiba people then did tell us that 1.4 story... That sounds like a fairly simple addition, assuming of course that java.net.URI exists in libgcj... Gary From buildsys at porkchop.devel.redhat.com Fri Nov 21 16:55:26 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Fri, 21 Nov 2003 11:55:26 -0500 Subject: rawhide report: 20031121 changes Message-ID: <200311211655.hALGtQl31505@porkchop.devel.redhat.com> From tromey at redhat.com Fri Nov 21 16:50:42 2003 From: tromey at redhat.com (Tom Tromey) Date: 21 Nov 2003 09:50:42 -0700 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <20031121145213.GD12864@redhat.com> References: <200311172348.02582.rezso@rdsor.ro> <87islh9siv.fsf@fleche.redhat.com> <20031120124115.GB3424@redhat.com> <200311211242.37408.rezso@rdsor.ro> <20031121120837.A14019@xos037.xos.nl> <20031121115058.GB12864@redhat.com> <20031121131013.A14251@xos037.xos.nl> <20031121134735.GC12864@redhat.com> <20031121151538.A14721@xos037.xos.nl> <20031121145213.GD12864@redhat.com> Message-ID: <871xs1y8bh.fsf@fleche.redhat.com> >>>>> "Gary" == Gary Benson writes: Gary> That sounds like a fairly simple addition, assuming of course that Gary> java.net.URI exists in libgcj... It doesn't. The currently-available URI parser uses java.util.regex, which isn't available pending the copyright assignments for gnu.regexp. It's in progress, but the legal stuff is slow going. I hope to get this in 3.4. Tom From jerry at samba.org Fri Nov 21 17:53:39 2003 From: jerry at samba.org (Gerald (Jerry) Carter) Date: Fri, 21 Nov 2003 11:53:39 -0600 Subject: Self-Introduction: Gerald (Jerry) Carter Message-ID: <3FBE5123.5040108@samba.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Name: Gerald Carter (aka Jerry) Location: Dadeville, AL, USA Profession: Software Engineer Samba Developer Company: HP Goals: To promote Samba of course :-) Historical qualifications: Samba Team member since '98 Acting release manage for 2.2 and 3.0 releases. Why trust me? I control the key that signs the Samba releases :-) gpg fingerprint: pub 1024D/D83511F6 2001-06-26 Gerald W. Carter ~ fingerprint = 2E2B 0D60 EA94 223A DF37 0465 211E EA31 D835 11F6 sub 1024g/1FB5F197 2001-06-26 ok. Seriously, I'm assuming that someone is already doing packaging for Samba in Fedora but have not been able to find the right person to talk to. I'm very interested in build a working relationship with whomever is managing the Samba packaging now, or I can take it over. - -- cheers, jerry - ---------------------------------------------------------------------- Hewlett-Packard ------------------------- http://www.hp.com SAMBA Team ---------------------- http://www.samba.org GnuPG Key ---- http://www.plainjoe.org/gpg_public.asc "If we're adding to the noise, turn off this song" --Switchfoot (2003) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/vlEjIR7qMdg1EfYRAoPJAKCK2tw2haBavv5rNiX1vqzsWlCedwCcD+N/ MA80UJMKn7hpl0ZArAnosqA= =A88R -----END PGP SIGNATURE----- From gemi at bluewin.ch Fri Nov 21 18:09:02 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Fri, 21 Nov 2003 19:09:02 +0100 Subject: Executable memory: further programs that fail In-Reply-To: <1069103046.18050.1.camel@localhost.localdomain> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> Message-ID: <1069438142.14267.7.camel@scriabin.tannenrauch.ch> Some further programs that work only when /proc/sys/kernel/exec-shield is set to 0 or setarch i386 is used: chicken scm mjolner beta system and I expect quite a number of other programs. If a program works flawlessly on Debian, SUSE, Mandrake etc... but doesn't on Fedora, I would consider this an incompatibility or, some might even say, a bug. I propose to disable exec-shield by default, however the feature may otherwise be, and giving the user (via a GUI perhaps) the option to "harden" the system. Maybe when exec-shield is incorporated into the standard kernel, and other distributions use it, and thereby software developers are forced to adapt their programs, it could be switched on by default. Maybe some of you will say, that the failing programs are not widely used anyway or are old, or both, imagine someone wanting to use them and asking themselves why it does work on Debian, ... but not on Fedora, and coming to obvious conclusions. Regards, G?rard -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From lamont at gurulabs.com Fri Nov 21 18:43:21 2003 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 21 Nov 2003 11:43:21 -0700 Subject: Naoko - gcj based goodies like tomcat ? In-Reply-To: <200311211517.02852.rezso@rdsor.ro> References: <200311172348.02582.rezso@rdsor.ro> <200311211242.37408.rezso@rdsor.ro> <20031121120837.A14019@xos037.xos.nl> <200311211517.02852.rezso@rdsor.ro> Message-ID: <1069440200.2405.18.camel@wraith.advansoft.net> On Fri, 2003-11-21 at 08:17, Balint Cristian wrote: > You can write/develop your code for tomcat for 100% compatibility with gcj. > Of couse a jdk/ibm one will be incompatible but if you chouse from the start gcj will be ok > very ok in my opinion. > And thats going on with other proprietary c/c++ versus gnu gcc always need a little workaraund > to get it work from one to other, thats normal. Write once, rewrite/run everywhere, eh? -- Lamont Peterson Instructor Guru Labs -------------- 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 kdebisschop at alert.infoplease.com Fri Nov 21 19:33:06 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Fri, 21 Nov 2003 14:33:06 -0500 Subject: Executable memory: further programs that fail In-Reply-To: <1069438142.14267.7.camel@scriabin.tannenrauch.ch> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> Message-ID: <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> On Fri, 2003-11-21 at 13:09, Gerard Milmeister wrote: > and I expect quite a number of other programs. > If a program works flawlessly on Debian, SUSE, Mandrake etc... > but doesn't on Fedora, I would consider this an incompatibility or, some > might even say, a bug. I propose to disable exec-shield by default, > however the feature may otherwise be, and giving the user (via a GUI > perhaps) the option to "harden" the system. Maybe when exec-shield is > incorporated into the standard kernel, and other distributions use it, > and thereby software developers are forced to adapt their programs, it > could be switched on by default. Maybe some of you will say, that the > failing programs are not widely used anyway or are old, or both, imagine > someone wanting to use them and asking themselves why it does work on > Debian, ... but not on Fedora, and coming to obvious conclusions. I prefer to default to the more secure mode, as is currently the case. Not based on utility or quality of the failing programs - in fact I have some commercial programs I cannot get away from that almost to a certainty will require running without execshield. I just prefer to default to the more secure stance. Either way, I will need to change some settings. But I'd prefer to find at the start out because my app doesn't run, rather than at 3 in the AM when my server has become owned and is launching a DDOS at the other servers in the cluster. Just my $0.02 worth. -- Karl DeBisschop Pearson Education/Information Please From steve at silug.org Fri Nov 21 19:49:22 2003 From: steve at silug.org (Steven Pritchard) Date: Fri, 21 Nov 2003 13:49:22 -0600 Subject: reference init script? Message-ID: <20031121194922.GA11047@osiris.silug.org> Is there a "reference" init script somewhere, or should I just pick one and modify it appropriately (like I usually do :)? Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From nhruby at uga.edu Fri Nov 21 19:58:57 2003 From: nhruby at uga.edu (nathan r. hruby) Date: Fri, 21 Nov 2003 14:58:57 -0500 (EST) Subject: reference init script? In-Reply-To: <20031121194922.GA11047@osiris.silug.org> References: <20031121194922.GA11047@osiris.silug.org> Message-ID: On Fri, 21 Nov 2003, Steven Pritchard wrote: > Is there a "reference" init script somewhere, or should I just pick > one and modify it appropriately (like I usually do :)? > I don't think so (though I'd like to know a definitive answer as well); however. You can take a peek at the early bind 9 RPM's from RHL8 and compare the init script to the current one, there were a bunch of changes for "redhatification" which kinda show the progression. HTH, -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From alexander.dalloz at uni-bielefeld.de Fri Nov 21 20:23:56 2003 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Fri, 21 Nov 2003 21:23:56 +0100 Subject: reference init script? In-Reply-To: <20031121194922.GA11047@osiris.silug.org> References: <20031121194922.GA11047@osiris.silug.org> Message-ID: <1069446236.4286.67.camel@sirendipity.dogma.lan> Am Fr, den 21.11.2003 schrieb Steven Pritchard um 20:49: > Is there a "reference" init script somewhere, or should I just pick > one and modify it appropriately (like I usually do :)? > > Steve Have a look at /usr/share/doc/initscripts-7.42/sysvinitfiles There you find an example with additional comments. Alexander -- Alexander Dalloz | Enger, Germany PGP key valid: made 13.07.1999 PGP fingerprint: 2307 88FD 2D41 038E 7416 14CD E197 6E88 ED69 5653 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From nosp at xades.com Fri Nov 21 21:08:27 2003 From: nosp at xades.com (nosp) Date: Fri, 21 Nov 2003 21:08:27 +0000 Subject: Executable memory: further programs that fail In-Reply-To: <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <1069448907.18549.32.camel@earth.xades.com> On Fri, 2003-11-21 at 19:33, Karl DeBisschop wrote: > I prefer to default to the more secure mode, as is currently the case. +1 From jan at roehrich.info Sun Nov 23 23:01:50 2003 From: jan at roehrich.info (Jan =?ISO-8859-1?Q?R=F6hrich?=) Date: 24 Nov 2003 00:01:50 +0100 Subject: Vic^H^Holunteers needed for updated SATA code testing Message-ID: <1069628510.1568.0.camel@speed.home.roehrich.info> > Due to popular demand on #fedora-devel, I merged the latest libata code to > the FC1 kernel. This is basically identical to 2.4.22-bk53-libata1.patch.gz, > except for two PCI id's added to sata_promise (0x3376 and 0x3378) and > ¤t->sigmask_lock -> ¤t->sighand->siglock in libata-core.c. > > Pre-built RPMS + the patches I used (linux-2.4.22-libata.patch > and linux-2.4.22-intel-esb-drivers.patch) can be found from > http://www.ee.oulu.fi/~pp/fc1-libata (sorry, no yum support :-) ) > > Please test it out and if it works like it should, I'll file a RFE in > bugzilla to get this merged. I just saw that this libata patch contains the sata_via.c driver. I'm interested in it because I want to migrate from P-ATA to S-ATA. I'll test it during next week and give feedback. Greetings Jan From lowen at pari.edu Fri Nov 21 22:15:43 2003 From: lowen at pari.edu (Lamar Owen) Date: Fri, 21 Nov 2003 17:15:43 -0500 Subject: SMP i586? Message-ID: <200311211715.43696.lowen@pari.edu> Ok, I have an HP netserver 5/133 LS2 I like and use. Under RH8.0 it ran fine with the SMP kernel. Upgraded to Fedora Core 1 on it, and I no longer have SMP. Is there something not working with SMP on i586 with NPTL or something? I'm downloading the kernel SRPM now, and will be rebuilding the kernel for i586 smp overnight, unless somebody knows something about this. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From jspaleta at princeton.edu Fri Nov 21 22:21:29 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Fri, 21 Nov 2003 17:21:29 -0500 Subject: Executable memory: further programs that fail Message-ID: <1069453289.5858.41.camel@spatula.pppl.gov> Gerard Milmeister wrote: > I propose to disable exec-shield by default, > however the feature may otherwise be, and giving the user (via a GUI > perhaps) the option to "harden" the system. Maybe when exec-shield is > incorporated into the standard kernel, and other distributions use it, > and thereby software developers are forced to adapt their programs, it > could be switched on by default. Under that logic......you would wait till ALL distros had the feature available before the defaults on any distro went from off to on. I would suggest that this would not encourage developers of the programs that get bitten by exec-shield to look at the problems, until that absolutely HAD to..to get their program working with exec-shield. That's not very proactive development. And using your logic...even if ALL the distros had the exec-shield feature, you would STILL argue that the default should be off, to allow developers of the affected programs some time to work things out. This is not proactive development. I submit to you that developers of programs that are being effected by by exec-shield need a distro that defaults with exec-shield on asap, so they can use a widely tested exec-shield setup as a test-bed to help them re-code their applications. IF all the distros wait and wait and wait for everyone to have exec-shield available, that gives 'out of touch' developers more time to wait and wait and wait..before they have to really deal with the problem. And the longer developers wait to fix the application level problems that result when exec-shield is turned on...the messier its going to be when exec-shield gets turned on and left on..by default in ALL distros. -jef"mumbles something about something being a testbed..."spaleta From buildsys at porkchop.devel.redhat.com Fri Nov 21 23:45:29 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Fri, 21 Nov 2003 18:45:29 -0500 Subject: rawhide report: 20031121 changes Message-ID: <200311212345.hALNjTw13699@porkchop.devel.redhat.com> Updated Packages: From didierbe at sps.nus.edu.sg Sat Nov 22 03:58:57 2003 From: didierbe at sps.nus.edu.sg (Didier Casse) Date: Sat, 22 Nov 2003 11:58:57 +0800 (SGT) Subject: upgrading RH 9 system->Fedora with iso files and apt only In-Reply-To: Message-ID: On 21/11/03, at 14:51 +0200, Panu Matilainen babbled: > Ok, since you need a remote upgrade then apt/yum/up2date is needed. For > apt you basically need to create a local repository of the RPMS. Suppose > you have the iso's mounted in /mnt/yarrow1, /mnt/yarrow2 and /mnt/yarrow3, > I'd probably do it somewhat like this (watch out for typos and thinkos, I > wrote this from top of my head so not tested.. ): > mkdir -p /var/tmp/fedora/RPMS.core > cd /var/tmp/fedora/RPMS.core > ln -s /mnt/yarrow1/Fedora/RPMS/* . > ln -s /mnt/yarrow2/Fedora/RPMS/* . > ln -s /mnt/yarrow3/Fedora/RPMS/* . > genbasedir --bloat /var/tmp/fedora > > The add that to your sources.list: "file://var/tmp fedora core" > Check that it works (no errors in output) by running "apt-get update" > and then you should be ready to roll: > apt-get install kernel (choose suitable one from the output) > apt-get dist-upgrade This is exactly what I was looking for. Thanks Panu. ;-p With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg From didierbe at sps.nus.edu.sg Sat Nov 22 04:03:16 2003 From: didierbe at sps.nus.edu.sg (Didier Casse) Date: Sat, 22 Nov 2003 12:03:16 +0800 (SGT) Subject: upgrading RH 9 system->Fedora with iso files and apt only In-Reply-To: <1069424028.4047.83.camel@topicus6> Message-ID: On 21/11/03, at 15:13 +0100, Klaasjan Brand babbled: > Creating your own repository is documented all over the net: > http://www.dragonsdawn.net/~gordon/red-hat-apt-repository-howto/ > Close to it. This is the formal type usable by others. I wanted to create a more private one to upgrade specific packages in my distro. This gives some insights but Paul's reply is to the point. Thanks for the help Klaasjan. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg From daly at rio.sci.ccny.cuny.edu Sat Nov 22 03:54:32 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Fri, 21 Nov 2003 22:54:32 -0500 Subject: Executable memory: further programs that fail In-Reply-To: <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> (message from Karl DeBisschop on Fri, 21 Nov 2003 14:33:06 -0500) References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <200311220354.WAA18263@springbok.sci.ccny.cuny.edu> Can someone explain in detail why exec-shield makes the system more secure? I understand that making the stack non-executable by default might help. I understand why read-only code sections might help. I can't understand why brk needs to change. I can't understand why random dynamic library location helps. I'd really like to understand (a) what exec-shield changes (b) why these changes REALLY help (I can search memory to find the random dynamic library locations. Randomness doesn't hide things). (c) code fragments with before-and-after I believe that enabling security measures THAT HELP should be done by default. However, some of these changes are fundamental to the whole design of Unix. The changes seems to be based on a strict legal reading of API calls and use the assumption that if the rules don't specifically disallow the change then exec-shield can do what it wants. It's about like going to a football game and finding that some of the seats are actually scattered on the field. The rules don't disallow that behavior but everyone will have to work around the change. Tim Daly axiom at tenkan.org daly at idsi.net From buildsys at porkchop.devel.redhat.com Sat Nov 22 11:38:30 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sat, 22 Nov 2003 06:38:30 -0500 Subject: rawhide report: 20031122 changes Message-ID: <200311221138.hAMBcUv16264@porkchop.devel.redhat.com> Updated Packages: pciutils-2.1.11-2 ----------------- * Fri Nov 21 2003 Jeremy Katz 2.1.11-2 - build a diet libpci_loader.a on i386 - always assume pread exists, it does with diet and all vaguely recent glibc rpmdb-fedora-1.90-0.20031122 ---------------------------- tcsh-6.12-6 ----------- * Fri Nov 21 2003 Nalin Dahyabhai 6.12-6 - add missing buildprereqs on groff, libtermcap-devel (#110599) * Tue Jul 08 2003 Nalin Dahyabhai - update URL From ville.skytta at iki.fi Sat Nov 22 13:40:55 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 22 Nov 2003 15:40:55 +0200 Subject: reference init script? In-Reply-To: <20031121194922.GA11047@osiris.silug.org> References: <20031121194922.GA11047@osiris.silug.org> Message-ID: <1069508454.2439.380.camel@bobcat.mine.nu> On Fri, 2003-11-21 at 21:49, Steven Pritchard wrote: > Is there a "reference" init script somewhere, or should I just pick > one and modify it appropriately (like I usually do :)? One good example is in the fedora.us fedora-rpmdevtools package, /usr/share/fedora/template.init. From chuckw at quantumlinux.com Mon Nov 24 03:59:06 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sun, 23 Nov 2003 19:59:06 -0800 (PST) Subject: Executable memory: further programs that fail In-Reply-To: <1069453289.5858.41.camel@spatula.pppl.gov> Message-ID: > Under that logic......you would wait till ALL distros had the feature > available before the defaults on any distro went from off to on. Thank God that's not the case, otherwise the 2.6 kernel would never come out... (referring to the fact that a few changes to 2.5/2.6 broke nearly *ALL* loadable modules at one time) -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From gemi at bluewin.ch Sat Nov 22 17:08:39 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Sat, 22 Nov 2003 18:08:39 +0100 Subject: Executable memory: further programs that fail In-Reply-To: <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <1069520919.16328.3.camel@scriabin.tannenrauch.ch> On Fri, 2003-11-21 at 20:33, Karl DeBisschop wrote: > I prefer to default to the more secure mode, as is currently the case. > > Not based on utility or quality of the failing programs - in fact I have > some commercial programs I cannot get away from that almost to a > certainty will require running without execshield. I just prefer to > default to the more secure stance. > > Either way, I will need to change some settings. But I'd prefer to find > at the start out because my app doesn't run, rather than at 3 in the AM > when my server has become owned and is launching a DDOS at the other > servers in the cluster. > > Just my $0.02 worth. One more program: xsb prolog So is it alright to include in Fedora packages that require exec-shield to be turned off? Should there be a wrapper-script that calls the main executable with 'setarch'? What I want to say is, that requiring everyone with problematic programs to adapt to exec-shield is not possible, and including software that simply doesn't work on a default setup isn't either. Simply ignoring this software isn't going to boost Fedora's popularity. -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From jaap at haitsma.org Sat Nov 22 18:06:16 2003 From: jaap at haitsma.org (Jaap A. Haitsma) Date: Sat, 22 Nov 2003 19:06:16 +0100 Subject: Possible Project: CVS account manager In-Reply-To: <3FBE0578.4010503@platypus.bc.ca> References: <87brra1xcy.fsf@fleche.redhat.com> <3FB952BC.2090907@haitsma.org> <3FBE0578.4010503@platypus.bc.ca> Message-ID: <3FBFA598.9040306@haitsma.org> > > Jaap, > > I'm sure the recommendation is appreciated, but I'm curious: what does > savannah offer the gforge doesn't? I'm sure you know the difference, > but folks who don't know one from the other may not, and could really > benefit from a description. The research experience that led to your > recommendation of Savannah could really be a great big help here. > > I hear, for instance, that gforge is maintained by a very recently > ex-sourceforge developer, which says a lot to me about potential code > quality and avoidance of pitfalls or some nasty code that may be lurking > in the SF codebase that's been fixed in gforge. > > Potentially. > > - bish > Hi Bish, I didn't know of the existence of gforge, so I can't tell you the differences. It seems pretty cool this gforge stuff. Jaap From redhat-forums at genesis-x.nildram.co.uk Sat Nov 22 19:22:37 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sat, 22 Nov 2003 19:22:37 +0000 Subject: Tripwire news Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm currently working on Tripwire for Fedora. Proposed release: tripwire-2.3.1-18 (currently alpha) The status so far is: Currently implemented: tripwire-2.3.1-2 source (clean) rfc822 patch mkstemp patch Paul Herman's patch (<=GCC3.3, OpenSSL, STLport and others) Not implemented: fhs patch (broken, possibly obsolete, untested) jbj patch (broken, possibly obsolete, untested) gcc3 patch (obsolete) Build environment: FC1 (2.4.22-1.2115.nptl) GCC3.2.3 Build status: Built (target i386), installed, tested. All ok. 22-Nov-03. All that remains now is the packaging, something that I'm not particularly good at, however I'm working on it. To do: Post-install scripts for baseline configuration. Fix weirdness with wrong paths in install. (Currently I'm hard coding paths, rather than using variables) RPM packaging and testing. If anyone desperately needs this alpha copy now, please contact me, but be warned there is zero post install configuration, so you will need to do this manually. Sorry, but I won't have any time to help you with configuration. As you've probably guessed, I'm working from a clean source, rather than Red Hat's src.rpm. The difficulty is that Red Hat's specs and scripts are just way too heavily modified and complex for me to work with. As I said, I'm not great at packaging, so starting from scratch was just a lot easier. I've been working on this for precisely 3 hours, so don't expect a final release soon. Any help (scripts & packaging) would be greatly appreciated. - - Keith G. Robertson-Turner tripwire-devel at genesis-x.nildram.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/v6SW2XoLj+pGfn8RAgWOAJ9YMNLiqpRvw1/76EW4hghH2HXDfQCdHRfD xYYis9VeF7DkYTcRP8y61jQ= =C8Ws -----END PGP SIGNATURE----- From software at kkalice.com Sun Nov 23 02:56:27 2003 From: software at kkalice.com (Christians, Stefan Mr.) Date: Sun, 23 Nov 2003 11:56:27 +0900 Subject: dhcrelay and ipsec Message-ID: <1069556187.2924.12.camel@AhqOfcTrm001> To the developers maintaining the dhcp packages, Could you please keep following in mind when packaging dhcp for FC2, though we are not sure whether they will still be issues with the 2.6 kernel: We had two issues running dhcrelay on an IPSEC VPN-gateway (RHL8 with FreeS/wan): 1) We had to change the startup priority in dhcrelay's init script to 98. We do not remember exactly why we did that, but think the problem was that the ipsec interface was not up yet at the time of the default 66 startup priority. 2) We had to recompile with USE_SOCKETS defined in includes/sites.h for dhcrelay to work over a virtual ipsec interface. We would be very happy and pleased if dhcrelay through ipsec VPNs would work out-of-the-box in FC2 :) -- Sincerely, K.K. Alice S. Christians From anthonysaffer at safferconsulting.com Mon Nov 24 08:43:44 2003 From: anthonysaffer at safferconsulting.com (Anthony Saffer) Date: Mon, 24 Nov 2003 00:43:44 -0800 Subject: Question about Development Message-ID: <002a01c3b267$12545c40$42f4ac41@k4h8f5> Hello Everyone, As most of you know, I am a developer looking for a project. A few weeks ago, I had decided to sign up and do the GUI Cron scheduler. I was going to do it in Perl/Tk but was told (with good justification) that using Tk was really unacceptable for a number of reasons. Well, I've not given up on the cause! Would anyone have a problem with software being developed in wxPerl (Wx with Perl bindings)? If not, I'm going to sign up to do a project tonight. Anthony Saffer Miami, OK ======================================= SCS Consulting Services Professional Software and Website Development Affordable Webhosting also Available Visit: http://www.safferconsulting.com ======================================= From ckloiber at redhat.com Mon Nov 24 06:41:21 2003 From: ckloiber at redhat.com (Chris Kloiber) Date: Mon, 24 Nov 2003 14:41:21 +0800 Subject: dhcrelay and ipsec In-Reply-To: <1069556187.2924.12.camel@AhqOfcTrm001> References: <1069556187.2924.12.camel@AhqOfcTrm001> Message-ID: <1069656081.24446.11.camel@outhouse.rdu.redhat.com> On Sun, 2003-11-23 at 10:56, Christians, Stefan Mr. wrote: > To the developers maintaining the dhcp packages, > > Could you please keep following in mind when packaging dhcp for FC2, > though we are not sure whether they will still be issues with the 2.6 > kernel: > > We had two issues running dhcrelay on an IPSEC VPN-gateway (RHL8 with > FreeS/wan): > > 1) We had to change the startup priority in dhcrelay's init script to > 98. We do not remember exactly why we did that, but think the problem > was that the ipsec interface was not up yet at the time of the default > 66 startup priority. > > 2) We had to recompile with USE_SOCKETS defined in includes/sites.h for > dhcrelay to work over a virtual ipsec interface. > > We would be very happy and pleased if dhcrelay through ipsec VPNs would > work out-of-the-box in FC2 :) If you don't want these suggestions to fall off the face of the earth, you need to open a bugzilla against the package. http://bugzilla.redhat.com/bugzilla -- Chris Kloiber Red Hat, Inc. From mrchoke at opentle.org Sun Nov 23 10:19:12 2003 From: mrchoke at opentle.org (Supphachoke Suntiwichaya) Date: Sun, 23 Nov 2003 17:19:12 +0700 Subject: VNC can't stats binary! Message-ID: <3FC089A0.9090609@opentle.org> I download vnc-server-4.0-0.beta4.3.2.i386.rpm from update site. It seem incorrect. it norespond when # file /usr/bin/Xvnc ?? I rebuilded but it can't .. http://download.fedora.redhat.com/pub/fedora/linux/core/updates/1/i386/vnc-server-4.0-0.beta4.3.2.i386.rpm MrChoke -- Name : Supphachoke Suntiwichaya Email : MrChoke at opentle.org URL : http://jedi.links.nectec.or.th/mrchoke/ Distribution : Linux TLE 5.0 (Andaman) OS : Linux 2.4.22-6.ll_3tle #1 Mon Oct 13 11:34:49 ICT 2003 i686 GNU/Linux Uptime : 17:15:00 up 2 days, 7:22, 1 user, load average: 0.28, 0.09, 0.02 From jfm512 at free.fr Mon Nov 24 07:06:29 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 24 Nov 2003 08:06:29 +0100 Subject: Question about Development In-Reply-To: <002a01c3b267$12545c40$42f4ac41@k4h8f5> References: <002a01c3b267$12545c40$42f4ac41@k4h8f5> Message-ID: <1069657588.2419.7.camel@agnes.fremen.dune> There are several practical reasons to not do it in Wx (at least if you want it being used in Fedora) 1) Wx would have to be introduced in Fedora for that single purpose: ie it would introduce the not negligible overhead of packaging Wx and keeping a watch in its security holes 2) The gratuitous use of yet another toolkit means for one side a waste of resources (will not share memory with other applications) and confuse users who will find that such or such action does not work as in the rest of the desktop. Unless you have a very good technical reason for using Wx or you just want to have some fun without caring about use of your application I urge you to stick to mainstream toolkit On Mon, 2003-11-24 at 09:43, Anthony Saffer wrote: > Hello Everyone, > > As most of you know, I am a developer looking for a project. A few weeks > ago, I had decided to sign up and do the GUI Cron scheduler. I was going to > do it in Perl/Tk but was told (with good justification) that using Tk was > really unacceptable for a number of reasons. Well, I've not given up on the > cause! Would anyone have a problem with software being developed in wxPerl > (Wx with Perl bindings)? If not, I'm going to sign up to do a project > tonight. > > Anthony Saffer > Miami, OK > > ======================================= > SCS Consulting Services > Professional Software and Website Development > Affordable Webhosting also Available > Visit: http://www.safferconsulting.com > ======================================= > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jean Francois Martinez From didierbe at sps.nus.edu.sg Mon Nov 24 06:59:51 2003 From: didierbe at sps.nus.edu.sg (Didier Casse) Date: Mon, 24 Nov 2003 14:59:51 +0800 (SGT) Subject: upgrading RH 9 system->Fedora with iso files and apt only In-Reply-To: Message-ID: On 21/11/03, at 14:51 +0200, Panu Matilainen babbled: > On Fri, 21 Nov 2003, bishop wrote: > > > Klaasjan, > > > > Do you have the time to write out a mini-howto on that? I have a > > feeling that your instruction can help a few people following in your > > footsteps, and who may not have the opportunity to figure out a working > > solution by themselves. > > > > Me, I need one that can reliably do it from 5000km away. It'll be > > loop-mounted ISOs, apt-get and similar craziness, I think. Or I need to > > book a flight. 8-) Either way, I'm not the target audience, but I'm > > close. ACME at cl says that CL can do it with just apt-get, and that's > > incredibly interesting. > > Ok, since you need a remote upgrade then apt/yum/up2date is needed. For > apt you basically need to create a local repository of the RPMS. Suppose > you have the iso's mounted in /mnt/yarrow1, /mnt/yarrow2 and /mnt/yarrow3, > I'd probably do it somewhat like this (watch out for typos and thinkos, I > wrote this from top of my head so not tested.. ): > mkdir -p /var/tmp/fedora/RPMS.core > cd /var/tmp/fedora/RPMS.core > ln -s /mnt/yarrow1/Fedora/RPMS/* . > ln -s /mnt/yarrow2/Fedora/RPMS/* . > ln -s /mnt/yarrow3/Fedora/RPMS/* . > genbasedir --bloat /var/tmp/fedora > > The add that to your sources.list: "file://var/tmp fedora core" Must be a typo error from you. I think that the correct expression is: ----------------------------- rpm file:/var/tmp fedora core ----------------------------- With kind regards, Didier --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg From buildsys at porkchop.devel.redhat.com Sun Nov 23 11:31:28 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sun, 23 Nov 2003 06:31:28 -0500 Subject: rawhide report: 20031123 changes Message-ID: <200311231131.hANBVSk10179@porkchop.devel.redhat.com> Updated Packages: MySQL-python-0.9.1-10 --------------------- * Sat Nov 15 2003 Tom "spot" Callaway 0.9.1-9spot - bring us to python 2.3 comps-extras-9.2-1 ------------------ * Sun Nov 23 2003 Florian La Roche - change getnotincomps.py /usr/bin/python2.2 -> /usr/bin/python mx-2.0.5-1 ---------- * Sun Nov 23 2003 Florian La Roche - update to 2.0.5 - recompile with python 2.3 rpmdb-fedora-1.90-0.20031123 ---------------------------- From mike at netlyncs.com Sun Nov 23 13:17:42 2003 From: mike at netlyncs.com (Mike Chambers) Date: Sun, 23 Nov 2003 07:17:42 -0600 Subject: mktemp dependencies in rawhide Message-ID: <1069593461.10822.2.camel@bart.netlyncs.com> Have been getting this error with the last version or so of mktemp... Unresolvable chain of dependencies: man-1.5k-12 requires mktemp >= 1.5-2.1.5x mkinitrd-3.5.14-1 requires mktemp >= 1.5-5 -- Mike Chambers Madisonville, KY "Do you hear me now?....GOOD!" From anthonysaffer at safferconsulting.com Mon Nov 24 09:18:17 2003 From: anthonysaffer at safferconsulting.com (Anthony Saffer) Date: Mon, 24 Nov 2003 01:18:17 -0800 Subject: Question about Development References: <002a01c3b267$12545c40$42f4ac41@k4h8f5> <1069657588.2419.7.camel@agnes.fremen.dune> Message-ID: <003e01c3b26b$e6c01a60$42f4ac41@k4h8f5> > Unless you have a very good technical reason for using Wx or you just > want to have some fun without caring about use of your application I > urge you to stick to mainstream toolkit Could you define "mainstream toolkit" for me? Forgive my frustrated tone here but it seems that "mainstream" or "acceptable" toolkit seems to mean "PyGTK" or nothing at all. So, if I *can* use something other than PyGTK, what would that be? Thanks! Anthony From rezso at rdsor.ro Sun Nov 23 19:42:38 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Sun, 23 Nov 2003 19:42:38 +0000 Subject: insight gdb-gui on fedora ? Message-ID: <200311231942.38981.rezso@rdsor.ro> Hi ! Can expect to see http://sources.redhat.com/ml/insight/ in fedora soon ? What issues can be there to not include it ? I think is very usefull tool. Cristian From mhoneyfield at xtra.co.nz Mon Nov 24 07:35:46 2003 From: mhoneyfield at xtra.co.nz (Michael Honeyfield) Date: Mon, 24 Nov 2003 20:35:46 +1300 Subject: Question about Development In-Reply-To: <003e01c3b26b$e6c01a60$42f4ac41@k4h8f5> References: <002a01c3b267$12545c40$42f4ac41@k4h8f5> <1069657588.2419.7.camel@agnes.fremen.dune> <003e01c3b26b$e6c01a60$42f4ac41@k4h8f5> Message-ID: <1069659345.23358.14.camel@pingu.linux.lan> Could the use of Perl-gtk be allowed? Would stay with the gtk toolkit of preference and allow Perl monks to use a UI toolkit. Mike On Mon, 2003-11-24 at 22:18, Anthony Saffer wrote: > > > Unless you have a very good technical reason for using Wx or you just > > want to have some fun without caring about use of your application I > > urge you to stick to mainstream toolkit > > Could you define "mainstream toolkit" for me? Forgive my frustrated tone > here but it seems that "mainstream" or "acceptable" toolkit seems to mean > "PyGTK" or nothing at all. So, if I *can* use something other than PyGTK, > what would that be? > > Thanks! > Anthony > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From mandreiana at rdslink.ro Mon Nov 24 08:03:27 2003 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Mon, 24 Nov 2003 10:03:27 +0200 Subject: Tripwire news In-Reply-To: References: Message-ID: <1069661006.5021.4.camel@marte.biciclete.ro> On S?, 2003-11-22 at 21:22, Keith G. Robertson-Turner wrote: > To do: > Post-install scripts for baseline configuration. Will this make a filelist with only the existing files in the system? I've found tripwire's reports hard to use because of the warnings for non-existent files. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From kjb at dds.nl Mon Nov 24 08:07:42 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Mon, 24 Nov 2003 09:07:42 +0100 Subject: SMP i586? In-Reply-To: <200311211715.43696.lowen@pari.edu> References: <200311211715.43696.lowen@pari.edu> Message-ID: <1069661262.22934.1.camel@topicus6> On Fri, 2003-11-21 at 23:15, Lamar Owen wrote: > Ok, I have an HP netserver 5/133 LS2 I like and use. Under RH8.0 it ran fine > with the SMP kernel. Upgraded to Fedora Core 1 on it, and I no longer have > SMP. Is there something not working with SMP on i586 with NPTL or something? > I'm downloading the kernel SRPM now, and will be rebuilding the kernel for > i586 smp overnight, unless somebody knows something about this. Search the list archives; I believe SMP was dropped from RH9 or Fedora because it never was really popular for i586 (and didn't perform that well too). You can build an i586 SMP kernel yourself... -- Klaasjan Brand From nos at utel.no Mon Nov 24 08:36:40 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Mon, 24 Nov 2003 09:36:40 +0100 Subject: Red Carpet ? Message-ID: <3d9873790106da07d3@[192.168.170.10]> Ximian just released a new version of Red-Carpet. Would it be an idea to make RC channels of fedora.us(and Fedora for that matter) ? RedCarpet does in my opinion make software installation a no brainer for most people. http://www.ximian.com/products/redcarpet/ http://www.opencarpet.org/ -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From software at kkalice.com Mon Nov 24 08:56:09 2003 From: software at kkalice.com (Christians, Stefan Mr.) Date: Mon, 24 Nov 2003 17:56:09 +0900 Subject: dhcrelay and ipsec In-Reply-To: <1069656081.24446.11.camel@outhouse.rdu.redhat.com> References: <1069556187.2924.12.camel@AhqOfcTrm001> <1069656081.24446.11.camel@outhouse.rdu.redhat.com> Message-ID: <1069664168.2692.1.camel@RioMgmTrm001> On Mon, 2003-11-24 at 15:41, Chris Kloiber wrote: > If you don't want these suggestions to fall off the face of the earth, > you need to open a bugzilla against the package. > > http://bugzilla.redhat.com/bugzilla I just hesitated to file a bug report against something that does not even exist yet. But with your encouragement I will go ahead now. -- Sincerely, K.K. Alice S. Christians From mingo at redhat.com Mon Nov 24 10:09:06 2003 From: mingo at redhat.com (Ingo Molnar) Date: Mon, 24 Nov 2003 05:09:06 -0500 (EST) Subject: Executable memory: further programs that fail In-Reply-To: <200311220354.WAA18263@springbok.sci.ccny.cuny.edu> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> <200311220354.WAA18263@springbok.sci.ccny.cuny.edu> Message-ID: On Fri, 21 Nov 2003, Tim Daly wrote: > Can someone explain in detail why exec-shield makes the system more secure? a somewhat dated announcement, but it should give you the rough idea: http://people.redhat.com/mingo/exec-shield/ANNOUNCE-exec-shield Ingo From rms at 1407.org Mon Nov 24 10:16:07 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 24 Nov 2003 10:16:07 +0000 Subject: Tripwire news In-Reply-To: <1069661006.5021.4.camel@marte.biciclete.ro> References: <1069661006.5021.4.camel@marte.biciclete.ro> Message-ID: <1069668967.4656.7.camel@roque> On Mon, 2003-11-24 at 08:03, Marius Andreiana wrote: > On S?, 2003-11-22 at 21:22, Keith G. Robertson-Turner wrote: > > To do: > > Post-install scripts for baseline configuration. > Will this make a filelist with only the existing files in the system? > I've found tripwire's reports hard to use because of the warnings for > non-existent files. What, you don't filter them out? Here's a suggestion: 1 Run /usr/sbin/tripwire --init &> /tmp/tw.out 2 Edit twpol.txt and remove inexistent files alerted on /tmp/tw.out 3 Run /usr/sbin/tripwire --init again (and repeat 2 if you forgot something) 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 mingo at redhat.com Mon Nov 24 10:42:27 2003 From: mingo at redhat.com (Ingo Molnar) Date: Mon, 24 Nov 2003 05:42:27 -0500 (EST) Subject: Executable memory: further programs that fail In-Reply-To: <1069520919.16328.3.camel@scriabin.tannenrauch.ch> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> <1069520919.16328.3.camel@scriabin.tannenrauch.ch> Message-ID: On Sat, 22 Nov 2003, Gerard Milmeister wrote: > So is it alright to include in Fedora packages that require exec-shield > to be turned off? Should there be a wrapper-script that calls the main > executable with 'setarch'? all 'third party' apps will run with exec-shield disabled by default. _Iff_ a package is recompiled under Fedora (using Fedora's gcc and binutils) then you might end up with an app that has exec-shield enabled although the app itself for whatever reason has some executability assumption. In this case there are myriads of ways to make the app work again: - use 'setarch i386 ' [or rather, use the 'i386 ' shortcut] - add this gcc option to the CFLAGS in the Makefile: -Wa,--execstack - add the following oneliner anywhere in the app's source in an assembly file to disable exec-shield: .section .note.GNU-stack, "x", @progbits; .previous - disable exec-shield globally, put "kernel.exec-shield = 0" into /etc/sysctl.conf. - the preferred solution: fix the app itself to not assume executability of non-executable regions or not hardcode any VM properties such as 'mmaps start at 2 GB'. Both assumptions are illegal and these apps will likely break on 64-bit architectures too, so they should be fixed. Note that typically the changes needed are quite simple. in any case, please keep reporting apps that need an executable stack, we want to track them all down and fix them for good. Fortunately 99.9% of the 5000+ binaries in a full Fedora Core 1 install work out of box. note that there are also prelink related problems, which we want to know about and fix just as much, but which should not be confused with exec-shield problems. Sometimes these do get mixed up. (in any case, please also read the extensive description provided by Roland McGrath's "exec-shield mmap & brk randomization" email.) Ingo From ckloiber at redhat.com Mon Nov 24 10:53:45 2003 From: ckloiber at redhat.com (Chris Kloiber) Date: Mon, 24 Nov 2003 18:53:45 +0800 Subject: dhcrelay and ipsec In-Reply-To: <1069664168.2692.1.camel@RioMgmTrm001> References: <1069556187.2924.12.camel@AhqOfcTrm001> <1069656081.24446.11.camel@outhouse.rdu.redhat.com> <1069664168.2692.1.camel@RioMgmTrm001> Message-ID: <1069671224.25277.7.camel@outhouse.rdu.redhat.com> On Mon, 2003-11-24 at 16:56, Christians, Stefan Mr. wrote: > On Mon, 2003-11-24 at 15:41, Chris Kloiber wrote: > > > If you don't want these suggestions to fall off the face of the earth, > > you need to open a bugzilla against the package. > > > > http://bugzilla.redhat.com/bugzilla > > I just hesitated to file a bug report against something that does not > even exist yet. > But with your encouragement I will go ahead now. If the package doesn't exist yet, file it against the 'distribution' component. Thanks. -- Chris Kloiber Red Hat, Inc. From nos at utel.no Mon Nov 24 11:25:24 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Mon, 24 Nov 2003 12:25:24 +0100 Subject: insight gdb-gui on fedora ? In-Reply-To: <3d68b8430106d007d3@[192.168.170.10]> References: <3d68b8430106d007d3@[192.168.170.10]> Message-ID: <3e32ee560106fe07d3@[192.168.170.10]> On Sun, 2003-11-23 at 20:42, Balint Cristian wrote: > Hi ! > > Can expect to see http://sources.redhat.com/ml/insight/ in fedora soon ? > > What issues can be there to not include it ? > > I think is very usefull tool. Maybe someone will package it for fedora.us ? In the meantime, try ddd , a neat GUI frontend to gdb already included in Fedora. -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From de_lupus at pandora.be Mon Nov 24 11:32:34 2003 From: de_lupus at pandora.be (lupus) Date: Mon, 24 Nov 2003 12:32:34 +0100 Subject: little patch for kallsyms (kernel2.6) (package : initscripts) Message-ID: <1069673554.1808.11.camel@D57729F0.kabel.telenet.be> #kallsyms is used in kernel 2.6 instead of ksyms #should the logs off kallsyms be written to /var/log/ksyms.$i or to /var/log/kallsyms.$i or maybe even both #to keep compatibility with programs that read these files?! Kristof Vansant (Belgium) -------------- next part -------------- A non-text attachment was scrubbed... Name: kallsyms.patch Type: text/x-patch Size: 1719 bytes Desc: not available URL: From buildsys at porkchop.devel.redhat.com Mon Nov 24 11:37:57 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Mon, 24 Nov 2003 06:37:57 -0500 Subject: rawhide report: 20031124 changes Message-ID: <200311241137.hAOBbvK03844@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.90-0.20031124 ---------------------------- sane-backends-1.0.13-1 ---------------------- * Sun Nov 23 2003 Tim Waugh 1.0.13-1 - 1.0.13. - No longer need autoload, gt68xx patches. From ms-nospam-0306 at arcor.de Mon Nov 24 12:09:02 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 24 Nov 2003 13:09:02 +0100 Subject: Tripwire news In-Reply-To: <1069661006.5021.4.camel@marte.biciclete.ro> References: <1069661006.5021.4.camel@marte.biciclete.ro> Message-ID: <20031124130902.0daaff15.ms-nospam-0306@arcor.de> On Mon, 24 Nov 2003 10:03:27 +0200, Marius Andreiana wrote: > On S?, 2003-11-22 at 21:22, Keith G. Robertson-Turner wrote: > > To do: > > Post-install scripts for baseline configuration. > > Will this make a filelist with only the existing files in the system? > I've found tripwire's reports hard to use because of the warnings for > non-existent files. You are expected to tune the default configuration and drop all non-existant files to get rid of those warnings. There are small helper scripts (posted in various places) that take a Tripwire report and modify the policy file automatically. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From spamfrommailing at freax.org Mon Nov 24 12:14:35 2003 From: spamfrommailing at freax.org (Philip Van Hoof) Date: Mon, 24 Nov 2003 13:14:35 +0100 Subject: little patch for kallsyms (kernel2.6) (package : initscripts) In-Reply-To: <1069673554.1808.11.camel@D57729F0.kabel.telenet.be> References: <1069673554.1808.11.camel@D57729F0.kabel.telenet.be> Message-ID: <1069676074.4346.84.camel@localhost.localdomain> > #kallsyms is used in kernel 2.6 instead of ksyms > #should the logs off kallsyms be written to /var/log/ksyms.$i or to > /var/log/kallsyms.$i or maybe even both > #to keep compatibility with programs that read these files?! Supporting multiple kernels is a very nobel thing to do indeed. However, I am not sure whether or not maintaining such scripts when they have inline if-then-else constructs like this will be easy. My proposal would be to create kernel-dependant parts of the scripts in folders like /etc/initscripts/kernel/2.4/ /etc/initscripts/kernel/2.6/ /etc/initscripts/kernel/2.5/ and then make calls to the scripts using KERNEL_BRANCH=`/bin/uname -r | /bin/cut -c -3` /etc/initscripts/$KERNEL_BRANCH/script_to_do_this.sh /etc/initscripts/$KERNEL_BRANCH/script_to_do_that.sh A check for the directory /etc/initscripts/$KERNEL_BRANCH/ could tell the user whether or not the kernel is support, and if not could ask the user to try starting the system using initscript for a different kernel, or the nearest kernel initscripts available. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org work: Philip dot VanHoof at cronos dot be http://www.freax.be, http://www.freax.eu.org From de_lupus at pandora.be Mon Nov 24 12:25:29 2003 From: de_lupus at pandora.be (lupus) Date: Mon, 24 Nov 2003 13:25:29 +0100 Subject: to filesystem-*.rpm should /sys (kernel 2.6) Message-ID: <1069676729.2993.8.camel@D57729F0.kabel.telenet.be> it's used by kernel 2.6 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: iostats.txt URL: From aoliva at redhat.com Mon Nov 24 13:06:57 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Nov 2003 11:06:57 -0200 Subject: little patch for kallsyms (kernel2.6) (package : initscripts) In-Reply-To: <1069676074.4346.84.camel@localhost.localdomain> References: <1069673554.1808.11.camel@D57729F0.kabel.telenet.be> <1069676074.4346.84.camel@localhost.localdomain> Message-ID: On Nov 24, 2003, Philip Van Hoof wrote: > My proposal would be to create kernel-dependant parts of the scripts in > folders like I doubt this would scale. case `uname -r` in 2.4.* | 2.5.[0-9]-* | 2.5.[1-2][0-9]-* | 2.5.3[0-4]-*) do something ;; 2.5.* | 2.6.*) do something else ;; esac seems to give far more flexibility in case changes are introduced in minor versions, which is quite common in unstable releases, and not entirely unheard-of in a stable series. So, this solution looks far more workable to me. Version numbers above are entirely random; no implication whatsoever is to be derived from them. I don't even know whether the 2.5 series got as far as 35 :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From jspaleta at princeton.edu Mon Nov 24 13:18:00 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Mon, 24 Nov 2003 08:18:00 -0500 Subject: Executable memory: further programs that fail Message-ID: <1069679880.20093.6.camel@goober.localdomain> Chuck Wolber: > Thank God that's not the case, otherwise the 2.6 kernel would never > come out... (referring to the fact that a few changes to 2.5/2.6 broke > nearly *ALL* loadable modules at one time) Comparing a kernel feature that doesn't work for nearly all modules to a kernel feature that maybe affects 1% of binary applications( which could be argued are doing technically 'illegal' tricks with regard to the memory space ) .... is a bit of a stretch. -jef"if only i knew how to prevent shantytowns from appearing in lincity"spaleta -------------- 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 chuckw at quantumlinux.com Mon Nov 24 13:32:24 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 24 Nov 2003 05:32:24 -0800 (PST) Subject: Executable memory: further programs that fail In-Reply-To: <1069679880.20093.6.camel@goober.localdomain> Message-ID: > > Thank God that's not the case, otherwise the 2.6 kernel would never > > come out... (referring to the fact that a few changes to 2.5/2.6 broke > > nearly *ALL* loadable modules at one time) > > Comparing a kernel feature that doesn't work for nearly all modules to a > kernel feature that maybe affects 1% of binary applications( which could > be argued are doing technically 'illegal' tricks with regard to the > memory space ) .... is a bit of a stretch. Then I'd say you missed my point completely. The issue was wether or not to make a change if it affected existing code (and by extension end users) in an adverse way. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com "M stands for magic, mystery or matrix; according to taste." --Edward Witten From mike at flyn.org Mon Nov 24 15:01:42 2003 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 24 Nov 2003 09:01:42 -0600 Subject: Tripwire news In-Reply-To: <20031124130902.0daaff15.ms-nospam-0306@arcor.de> References: <1069661006.5021.4.camel@marte.biciclete.ro> <20031124130902.0daaff15.ms-nospam-0306@arcor.de> Message-ID: <20031124150142.GA1256@imp.flyn.org> > > > To do: > > > Post-install scripts for baseline configuration. > > Will this make a filelist with only the existing files in the system? > > I've found tripwire's reports hard to use because of the warnings for > > non-existent files. > You are expected to tune the default configuration and drop all > non-existant files to get rid of those warnings. There are small helper > scripts (posted in various places) that take a Tripwire report and modify > the policy file automatically. I've always thought it would be neat to tie tripwire into the package management system. There is a RFE in Red Hat's bugzilla about this: #76877. -- Mike :wq From redhat-forums at genesis-x.nildram.co.uk Mon Nov 24 15:05:33 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Mon, 24 Nov 2003 15:05:33 +0000 Subject: Tripwire news References: <1069661006.5021.4.camel@marte.biciclete.ro> <20031124130902.0daaff15.ms-nospam-0306@arcor.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 24 Nov 2003 13:09:02 +0100, Michael Schwendt wrote: > On Mon, 24 Nov 2003 10:03:27 +0200, Marius Andreiana wrote: > >> On S?, 2003-11-22 at 21:22, Keith G. Robertson-Turner wrote: >> > To do: >> > Post-install scripts for baseline configuration. >> >> Will this make a filelist with only the existing files in the system? >> I've found tripwire's reports hard to use because of the warnings for >> non-existent files. > > You are expected to tune the default configuration and drop all > non-existant files to get rid of those warnings. There are small helper > scripts (posted in various places) that take a Tripwire report and modify > the policy file automatically. If I get time (or someone volunteers) I may be able to include a script that "gawk's" out any non-existent entries in twpol.txt (preferably by comment rather than removal). Then it's just a matter of doing a "tripwire -m p /etc/tripwire/twpol.txt" (you may need to specify the "-Z low" flag too) on the new policy file, and you're all set. That's at least a week away though, as it's low priority. Volunteers? - - Keith G. Robertson-Turner tripwire-devel at genesis-x.nildram.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/wh312XoLj+pGfn8RAibSAJ9XCaYy7mbx2lglQ1Xs+EZgZO+logCcDZ0E PQ/h1A+7GwBmICJK9rm0M/Y= =mr/R -----END PGP SIGNATURE----- From steve at silug.org Mon Nov 24 15:07:18 2003 From: steve at silug.org (Steven Pritchard) Date: Mon, 24 Nov 2003 09:07:18 -0600 Subject: Question about Development In-Reply-To: <002a01c3b267$12545c40$42f4ac41@k4h8f5> References: <002a01c3b267$12545c40$42f4ac41@k4h8f5> Message-ID: <20031124150718.GA19872@osiris.silug.org> On Mon, Nov 24, 2003 at 12:43:44AM -0800, Anthony Saffer wrote: > I was going to do it in Perl/Tk but was told (with good justification) > that using Tk was really unacceptable for a number of reasons. perl-Tk is in my pile of packages that I'll be submitting... ;-) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From redhat-forums at genesis-x.nildram.co.uk Mon Nov 24 15:31:03 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Mon, 24 Nov 2003 15:31:03 +0000 Subject: Tripwire Update ... Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good news ... I've tracked down the installpath bug (some nasty hard coded references that blatantly ignored opts) so phase one is now complete. Phase two is post-install scripts for baseline configuration. ETA - one or two days depending on how much free time I've got. I'm estimating this whole project will be wrapped up in a week. - - Keith G. Robertson-Turner tripwire-devel at genesis-x.nildram.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/wiPm2XoLj+pGfn8RAk1gAJ93cfYKx0DDoLabn7e4G6BvRJO1AACeMRO8 7ERAAfhoCnbtIC0RK/C9FUM= =TIyq -----END PGP SIGNATURE----- From zaitcev at redhat.com Tue Nov 18 07:02:28 2003 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 18 Nov 2003 02:02:28 -0500 Subject: FC2, 2.6 vs 2.4 In-Reply-To: References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> <3FB556FF.2090601@wanadoo.es> Message-ID: <200311180702.hAI72STS021128@devserv.devel.redhat.com> >> 2.6.0-pre is a different story what was 2.4.0-pre. There is a lot of >> people working on it ( http://www.osdl.org/projects/26lnxstblztn/results/ ) >> The 2.6 _core_ will be stable, but it won't have _all_ features as 2.4 >> has today. I hope to be mistaken ;-) > > You're not mistaken, but no so many features will be left out of 2.6. > Some of them can be easily replaced by newer ones (for example, IDE-SCSI > was used mainly for CD-Burning, but now you can use direct ATAPI > CD-Burning), and some will be superseded by newer versions, like LVM2 or > EVMS. The problem with ide-scsi is that it's needed for tapes. Burning is easy. -- Pete From smoogen at lanl.gov Mon Nov 24 16:26:23 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 24 Nov 2003 09:26:23 -0700 Subject: AIDE versus Tripwire Re: Tripwire news In-Reply-To: References: Message-ID: <1069691183.18185.5.camel@smoogen1.lanl.gov> I know that Tripwire was dropped from the distro due to the version that was shipped was no longer being maintained upstream.. Also at one point, AIDE was supposed to be the GNU replacement for it... does anyone know if AIDE is ready for primetime and better/worse than older tripwire? On Sat, 2003-11-22 at 12:22, Keith G. Robertson-Turner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm currently working on Tripwire for Fedora. -- 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 -- So shines a good deed in a weary world. = Willy Wonka -- From kdebisschop at alert.infoplease.com Mon Nov 24 16:49:37 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Mon, 24 Nov 2003 11:49:37 -0500 Subject: Tripwire Update ... In-Reply-To: References: Message-ID: <1069692577.19661.11.camel@skilletinfopleasecom.nh.pearsoned.com> I personally gave up tripwire in favor of aide some time ago. Not that choice is bad, but it seemed worth mentioning. I thought I'd read someplace that aide was slated to replace tripwire in FC, but maybe that was my imagination. -- Karl DeBisschop Pearson Education/Information Please From kdebisschop at alert.infoplease.com Mon Nov 24 16:54:53 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Mon, 24 Nov 2003 11:54:53 -0500 Subject: AIDE versus Tripwire Re: Tripwire news In-Reply-To: <1069691183.18185.5.camel@smoogen1.lanl.gov> References: <1069691183.18185.5.camel@smoogen1.lanl.gov> Message-ID: <1069692892.19661.16.camel@skilletinfopleasecom.nh.pearsoned.com> On Mon, 2003-11-24 at 11:26, Stephen Smoogen wrote: > I know that Tripwire was dropped from the distro due to the version that > was shipped was no longer being maintained upstream.. Also at one point, > AIDE was supposed to be the GNU replacement for it... does anyone know > if AIDE is ready for primetime and better/worse than older tripwire? I just commented on this, so I'll try not to be redundant. I do think it is ready for primetime, though last I checked the latest official release was stale. That's sort of an institutional issue that would need to be addressed. It's a valid issue, but as it is GPL, it is an issue that at worst could be addressed with a fork to new maintainer. And I have not needed to check for updates recently, so it may not even be a problem. I find it to be much easier to install and configure, and just ast secure. Once I switched, I had no thoughts of going back. -- Karl DeBisschop Pearson Education/Information Please From ms-nospam-0306 at arcor.de Mon Nov 24 17:04:22 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 24 Nov 2003 18:04:22 +0100 Subject: Tripwire news In-Reply-To: References: <1069661006.5021.4.camel@marte.biciclete.ro> <20031124130902.0daaff15.ms-nospam-0306@arcor.de> Message-ID: <20031124180422.74948252.ms-nospam-0306@arcor.de> On Mon, 24 Nov 2003 15:05:33 +0000, Keith G. Robertson-Turner wrote: > >> > Post-install scripts for baseline configuration. > >> > >> Will this make a filelist with only the existing files in the system? > >> I've found tripwire's reports hard to use because of the warnings for > >> non-existent files. > > > > You are expected to tune the default configuration and drop all > > non-existant files to get rid of those warnings. There are small helper > > scripts (posted in various places) that take a Tripwire report and modify > > the policy file automatically. > > If I get time (or someone volunteers) I may be able to include a script > that "gawk's" out any non-existent entries in twpol.txt (preferably by > comment rather than removal). > > Then it's just a matter of doing a "tripwire -m p /etc/tripwire/twpol.txt" > (you may need to specify the "-Z low" flag too) on the new policy file, > and you're all set. > > That's at least a week away though, as it's low priority. > > Volunteers? Find attached my old Perl script which I've used for Red Hat Linux so far (the included e-mail address is non-functional). Of course, if someone wants to customize a default Tripwire policy file in a %post scriplet, it needs much more work, such as querying the installed files (with "rpm -qf") or comparing the RPM database with what is included in the policy file. If integrity of RPM and the RPM database is ensured, one could use derivatives of "rpm -V" for verifying installed package files and use Tripwire or AIDE only for directories and files which don't belong to RPM packages. There are many possibilities... -- -------------- next part -------------- A non-text attachment was scrubbed... Name: tw_genpol.pl Type: application/octet-stream Size: 687 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ms-nospam-0306 at arcor.de Mon Nov 24 17:13:19 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 24 Nov 2003 18:13:19 +0100 Subject: AIDE versus Tripwire Re: Tripwire news In-Reply-To: <1069691183.18185.5.camel@smoogen1.lanl.gov> References: <1069691183.18185.5.camel@smoogen1.lanl.gov> Message-ID: <20031124181319.1e7f4b55.ms-nospam-0306@arcor.de> On Mon, 24 Nov 2003 09:26:23 -0700, Stephen Smoogen wrote: > I know that Tripwire was dropped from the distro due to the version that > was shipped was no longer being maintained upstream.. Also at one point, > AIDE was supposed to be the GNU replacement for it... does anyone know > if AIDE is ready for primetime and better/worse than older tripwire? Check it out in fedora.us "unstable". My personal opinion is I don't think it is ready yet due to memory leaks, bugs, non-functional features, missing password protection... and more which I don't remember right now. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From redhat-forums at genesis-x.nildram.co.uk Mon Nov 24 17:26:40 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Mon, 24 Nov 2003 17:26:40 +0000 Subject: Tripwire Update ... References: <1069692577.19661.11.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 24 Nov 2003 11:49:37 -0500, Karl DeBisschop wrote: > I personally gave up tripwire in favor of aide some time ago. > > Not that choice is bad, but it seemed worth mentioning. I thought I'd read > someplace that aide was slated to replace tripwire in FC, but maybe that > was my imagination. My trials of aide have shown that it occasionally segfaults, and is generally less reliable and stable than tripwire. I'd rather go with what I know and trust. Ultimately I am not entirely comfortable with the commercial/OSS split tripwire, and the fact that maintenance has faded away, but until I feel more confident about aide I will continue patching and building tripwire for current systems. I am hopeful that a fully GPL'ed system integrity verification tool (such as aide) will eventually replace tripwire. Meanwhile, my efforts are (at best) a quick fix-in-place solution to relatively minor incompatibilities that tripwire has with Fedora, and will suit many people's purposes for now. - - Keith G. Robertson-Turner tripwire-devel at genesis-x.nildram.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/wj6r2XoLj+pGfn8RAg5NAJ0frDpi2V+NKTBJLGwkRRmN/IAsiQCdEZIb MPKX0SOo8l/2LmpKYi7eNKM= =IPR5 -----END PGP SIGNATURE----- From kdebisschop at alert.infoplease.com Mon Nov 24 17:39:52 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Mon, 24 Nov 2003 12:39:52 -0500 Subject: Tripwire Update ... In-Reply-To: References: <1069692577.19661.11.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <1069695592.19661.23.camel@skilletinfopleasecom.nh.pearsoned.com> On Mon, 2003-11-24 at 12:26, Keith G. Robertson-Turner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Mon, 24 Nov 2003 11:49:37 -0500, Karl DeBisschop wrote: > > > I personally gave up tripwire in favor of aide some time ago. > > > > Not that choice is bad, but it seemed worth mentioning. I thought I'd read > > someplace that aide was slated to replace tripwire in FC, but maybe that > > was my imagination. > > My trials of aide have shown that it occasionally segfaults, and is > generally less reliable and stable than tripwire. Interesting. I did have some problems with 0.9, so I had to rebuild from CVS, much like the unstable version in Fedora US. Since then, I have not have any crashes or segfaults. Have you done anything to find where segfaults and crashes occur? I just checked out the CVS tree, and it looks like the last change was in January 2003. Maybe I'll contact the developer and see if it is still being maintained, or if he'd like to hand it off, or what. Not that I have any time either... > I am hopeful that a fully GPL'ed system integrity verification tool > (such as aide) will eventually replace tripwire. I share that hope. Maybe Fedora can help reach that goal. -- Karl DeBisschop Pearson Education/Information Please From kdebisschop at alert.infoplease.com Mon Nov 24 17:48:12 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Mon, 24 Nov 2003 12:48:12 -0500 Subject: Tripwire Update ... In-Reply-To: <1069695592.19661.23.camel@skilletinfopleasecom.nh.pearsoned.com> References: <1069692577.19661.11.camel@skilletinfopleasecom.nh.pearsoned.com> <1069695592.19661.23.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <1069696091.19661.28.camel@skilletinfopleasecom.nh.pearsoned.com> On Mon, 2003-11-24 at 12:39, Karl DeBisschop wrote: > I just checked out the CVS tree, and it looks like the last change was > in January 2003. Maybe I'll contact the developer and see if it is still > being maintained, or if he'd like to hand it off, or what. Not that I > have any time either... Sorry, that was incorrect. Development has moved off to sourceforge, but the homapage has not been updated. There is active work at: http://sourceforge.net/projects/aide/ Of course the project rates itself as beta, so it seems maybe the authors themselves feel it is not quite ready for primetime. -- Karl DeBisschop Pearson Education/Information Please From anthonysaffer at safferconsulting.com Mon Nov 24 20:23:07 2003 From: anthonysaffer at safferconsulting.com (Anthony Saffer) Date: Mon, 24 Nov 2003 12:23:07 -0800 Subject: Question about Development References: <002a01c3b267$12545c40$42f4ac41@k4h8f5> <20031124150718.GA19872@osiris.silug.org> Message-ID: <002a01c3b2c8$c6aaee00$bff4ac41@k4h8f5> > perl-Tk is in my pile of packages that I'll be submitting... ;-) Hi Steve, Please forgive my dumbness here but what does this mean? I mean, I understand what submitting packages is but how will this impact development in Perl-Tk in Fedora? Does this mean it might become part of the core installation?? Anthony ======================================= SCS Consulting Services Professional Software and Website Development Affordable Webhosting also Available Visit: http://www.safferconsulting.com ======================================= From steve at silug.org Mon Nov 24 18:33:40 2003 From: steve at silug.org (Steven Pritchard) Date: Mon, 24 Nov 2003 12:33:40 -0600 Subject: Question about Development In-Reply-To: <002a01c3b2c8$c6aaee00$bff4ac41@k4h8f5> References: <002a01c3b267$12545c40$42f4ac41@k4h8f5> <20031124150718.GA19872@osiris.silug.org> <002a01c3b2c8$c6aaee00$bff4ac41@k4h8f5> Message-ID: <20031124183340.GA21296@osiris.silug.org> On Mon, Nov 24, 2003 at 12:23:07PM -0800, Anthony Saffer wrote: > Please forgive my dumbness here but what does this mean? I mean, I > understand what submitting packages is but how will this impact development > in Perl-Tk in Fedora? Does this mean it might become part of the core > installation?? Highly unlikely, but I'm hoping it will end up in the fedora.us stable repository in the near future. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From davej at redhat.com Mon Nov 24 18:36:57 2003 From: davej at redhat.com (Dave Jones) Date: Mon, 24 Nov 2003 18:36:57 +0000 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <200311180702.hAI72STS021128@devserv.devel.redhat.com> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> <3FB556FF.2090601@wanadoo.es> <200311180702.hAI72STS021128@devserv.devel.redhat.com> Message-ID: <1069699017.2670.4.camel@delerium.codemonkey.org.uk> On Tue, 2003-11-18 at 07:02, Pete Zaitcev wrote: > The problem with ide-scsi is that it's needed for tapes. > Burning is easy. It's my current understanding that ide-tape is less broken than ide-scsi. (Although it too needs fixing iirc). Dave -- Dave Jones Red Hat From xose at wanadoo.es Mon Nov 24 19:14:37 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Mon, 24 Nov 2003 20:14:37 +0100 Subject: FC2, 2.6 vs 2.4 References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> <3FB556FF.2090601@wanadoo.es> <200311180702.hAI72STS021128@devserv.devel.redhat.com> <1069699017.2670.4.camel@delerium.codemonkey.org.uk> Message-ID: <3FC2589D.9080003@wanadoo.es> Dave Jones wrote: > It's my current understanding that ide-tape is less broken than > ide-scsi. (Although it too needs fixing iirc). anyway, 2.6 still needs a lot of work: http://marc.theaimsgroup.com/?l=linux-kernel&m=106623457024140&w=2 ;-) -- HTML mails are going to trash automagically From daly at rio.sci.ccny.cuny.edu Mon Nov 24 18:40:33 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Mon, 24 Nov 2003 13:40:33 -0500 Subject: Executable memory: further programs that fail In-Reply-To: (message from Ingo Molnar on Mon, 24 Nov 2003 05:09:06 -0500 (EST)) References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> <200311220354.WAA18263@springbok.sci.ccny.cuny.edu> Message-ID: <200311241840.hAOIeX931046@rio.sci.ccny.cuny.edu> Ingo, I've read your page and I understand the ascii-armor issue. There is an assumption, which is not true in general, that "code" and "data" are separate objects. In the trivial case the loader treats code as data. Lisp systems do this all the time. It might be more reasonable to apply exec-shield on a per-program or per-process basis. In particular, the normal exploits happen thru programs that access the net. Applying default security to net-enabled programs (e.g. anything that accesses a socket) might be more reasonable. My particular objection isn't really to the non-executable stack. I react to the notion that shared libraries can be placed "at random" in free space. Lisp systems, database systems, numeric systems (e.g. large matrix computations), all rely on large, contiguous blocks of storage. In fact the size of the problem they can handle depends on the size of contiguous storage. I don't understand why fragmenting free storage helps security. I certainly understand why it hurts certain applications. Tim Daly axiom at tenkan.org daly at idsi.net From dfarning at sbcglobal.net Mon Nov 24 20:25:31 2003 From: dfarning at sbcglobal.net (David Farning) Date: Mon, 24 Nov 2003 14:25:31 -0600 Subject: Package tree structure Message-ID: <1069705530.7468.90.camel@localhost.localdomain> I am currently working on a channel system for system-config-packages similar to the one used by red-carpet. As such, I would like verify the intended download.fedora.redhat.com hierarchy. The root level will contain the overall package sets. [core|extras|alternatives|3rd party|...] Each of these package sets will contain subsets of packages in different states of development. The numbered release will freeze at approximately 2-3 month intervals. Development and Testing are rolling releases. [1|2|...|development|test] Each of these Releases may be compiled for a number of archs. [i386|i386_64|...] Additionally, the numbered release will have updates and possibly legacy packages. Updates will continue for approximately 12 months and the legacy will continue as long as maintainers are interested [updates|legacy] This should result in a tree looking as such. fedora -core -1 -i386 -i386_64 -updates -i386 -legacy -i386 -2 -i386 -i386_64 -development -i386 -i386_64 -test -i386 - -extras -1 -i386 -2 -i386 There is already some deviance from this tree with -core -updates -1 -testing Because each numbered release will contain updates, updates should be a child of it's numbered parent. -updates/test either needs to merge into -test or -1/updates. I don't intended to too uptight, but setting standards will help make the tree more navigable for everyone. Thanks Dave Farning From marc.miller at amd.com Mon Nov 24 21:00:36 2003 From: marc.miller at amd.com (marc.miller at amd.com) Date: Mon, 24 Nov 2003 13:00:36 -0800 Subject: Package tree structure Message-ID: <858788618A93D111B45900805F85267A0998A6FD@caexmta3.amd.com> What is i386_64? Is that what the rest of the world is calling amd64 and x86_64? If so, why that name? -----Original Message----- From: David Farning [mailto:dfarning at sbcglobal.net] Sent: Monday, November 24, 2003 12:26 PM To: fedora-contacts Subject: Package tree structure I am currently working on a channel system for system-config-packages similar to the one used by red-carpet. As such, I would like verify the intended download.fedora.redhat.com hierarchy. The root level will contain the overall package sets. [core|extras|alternatives|3rd party|...] Each of these package sets will contain subsets of packages in different states of development. The numbered release will freeze at approximately 2-3 month intervals. Development and Testing are rolling releases. [1|2|...|development|test] Each of these Releases may be compiled for a number of archs. [i386|i386_64|...] Additionally, the numbered release will have updates and possibly legacy packages. Updates will continue for approximately 12 months and the legacy will continue as long as maintainers are interested [updates|legacy] This should result in a tree looking as such. fedora -core -1 -i386 -i386_64 -updates -i386 -legacy -i386 -2 -i386 -i386_64 -development -i386 -i386_64 -test -i386 - -extras -1 -i386 -2 -i386 There is already some deviance from this tree with -core -updates -1 -testing Because each numbered release will contain updates, updates should be a child of it's numbered parent. -updates/test either needs to merge into -test or -1/updates. I don't intended to too uptight, but setting standards will help make the tree more navigable for everyone. Thanks Dave Farning -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list From dfarning at sbcglobal.net Mon Nov 24 21:08:15 2003 From: dfarning at sbcglobal.net (David Farning) Date: Mon, 24 Nov 2003 15:08:15 -0600 Subject: Package tree structure In-Reply-To: <858788618A93D111B45900805F85267A0998A6FD@caexmta3.amd.com> References: <858788618A93D111B45900805F85267A0998A6FD@caexmta3.amd.com> Message-ID: <1069708095.7468.116.camel@localhost.localdomain> On Mon, 2003-11-24 at 15:00, marc.miller at amd.com wrote: > What is i386_64? Is that what the rest of the world is calling amd64 and x86_64? If so, why that name? > Sorry, a typo--I'm dyslexic. Without a compiler to catch my errors, stuff tends to come out a little weird. Thanks Dave Farning From davej at redhat.com Mon Nov 24 21:05:48 2003 From: davej at redhat.com (Dave Jones) Date: Mon, 24 Nov 2003 21:05:48 +0000 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <3FC2589D.9080003@wanadoo.es> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> <3FB556FF.2090601@wanadoo.es> <200311180702.hAI72STS021128@devserv.devel.redhat.com> <1069699017.2670.4.camel@delerium.codemonkey.org.uk> <3FC2589D.9080003@wanadoo.es> Message-ID: <1069707947.2670.9.camel@delerium.codemonkey.org.uk> On Mon, 2003-11-24 at 19:14, Xose Vazquez Perez wrote: > Dave Jones wrote: > > > It's my current understanding that ide-tape is less broken than > > ide-scsi. (Although it too needs fixing iirc). > > anyway, 2.6 still needs a lot of work: > http://marc.theaimsgroup.com/?l=linux-kernel&m=106623457024140&w=2 Bah, don't believe everything that guy says. Whilst there are a whole slew of changes that never made it forward, there's nothing really "stop ship" about those missing bits. Of the sorts of changes that haven't made it, the only ones to really worry about are the security related fixes, which is currently being sorted out. Driver fixes usually get brought forward 1 by 1 as they get updates (and after 2.6.0 goes gold we'll likely see a lot of driver updates from folks who don't follow the development branch) The rest is just fluff. Dave -- Dave Jones Red Hat From bdpepple at ameritech.net Mon Nov 24 22:16:47 2003 From: bdpepple at ameritech.net (Brian Pepple) Date: Mon, 24 Nov 2003 17:16:47 -0500 Subject: Self-Introduction: Brian Pepple Message-ID: <1069712206.29909.13.camel@hp.273piedmont.org> Name: Brian Pepple Home: Columbus, OH USA Profession: IT Company: None (In-between jobs) Goals: Help contribute to Fedora. I was working today on an rpm for the gkrellmms plugin, and figured I would share my work. Qualifications: Experience with C, Perl, Python. Previously worked at a Fortune 500 company. GPG Fingerprint: pub 1024D/810CC15E 2003-10-03 Brian Pepple Key fingerprint = BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E uid Brian Pepple sub 2048g/A55D2357 2003-10-03 [expires: 2008-10-01] Thanks, /B -- Brian Pepple -------------- 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 alan at redhat.com Mon Nov 24 22:14:36 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 24 Nov 2003 17:14:36 -0500 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <1069699017.2670.4.camel@delerium.codemonkey.org.uk> References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> <3FB556FF.2090601@wanadoo.es> <200311180702.hAI72STS021128@devserv.devel.redhat.com> <1069699017.2670.4.camel@delerium.codemonkey.org.uk> Message-ID: <20031124221436.GA8888@devserv.devel.redhat.com> > On Tue, 2003-11-18 at 07:02, Pete Zaitcev wrote: > > > The problem with ide-scsi is that it's needed for tapes. > > Burning is easy. > > It's my current understanding that ide-tape is less broken than > ide-scsi. (Although it too needs fixing iirc). ide-tape only handles some kinds of tape drive. You still need ide-scsi From dcbw at redhat.com Mon Nov 24 22:28:11 2003 From: dcbw at redhat.com (Dan Williams) Date: Mon, 24 Nov 2003 17:28:11 -0500 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <1069206029.1545.8.camel@ByteEnable> References: <1069206029.1545.8.camel@ByteEnable> Message-ID: <1069712891.25450.6.camel@dhcp64-188.boston.redhat.com> Hi, I've completed adding the required bits to the specfile. I hope to release a 1.1.0-7 fairly soon that includes the enable-java stuff and RH 9 build support for those of you wanting it. Unfortunately, Mozilla address book integration won't work on RH9 because the system mozilla is built with gcc 2.96 and OOo with 3.2.2... However, the rest should be fine (oh, minus startup-notification though). I also merged required enable-java stuff to gnome.org OOo (ie Ximianized OOo) so when I switch over to that you'll have it if you'd like it. If you do build with Java, the following things are true: 1) openoffice.org RPM will require libawt.so 2) RPMs will be named as such: openoffice.org-1.1.0-7.withjava.rpm openoffice.org-i18n-1.1.0-7.withjava.rpm openoffice.org-libs-1.1.0-7.withjava.rpm Still for the future, Red Hat won't be building and distributing Java-enabled builds of OOo for Fedora. This will change immediately when Java gets a license compatible with the license under which Fedora is distributed, or when gcj support gets into OOo. Cheers, Dan On Tue, 2003-11-18 at 20:40, ByteEnable wrote: > >Hi, > > > >After some thought and discussion, I've come to the following > >conclusion: > > > >Since Fedora does not include Java for licensing reasons, all Red > >Hat-built OpenOffice.org RPMs for Fedora will NOT include Java support, > >and will NOT be built with Java enabled. It's not good form to supply > >an RPM that cannot be built on the platform it is intended for. > >Therefore, when you install Fedora and OOo, anything that requires Java > >will not function. > > > >However, I will attempt to keep a "Java-enable" switch in the specfile > >that will allow Java-enabled building on Fedora, provided you have a > >JRE/JDK installed. I will attempt to keep Java-enabled building > >up-to-date and functional. > > > >In the future, I hope OOo will compile using gcj or other free Java > >environments. This is something we'll be working towards, and other > >shave this same goal in mind (Debian). When gcj is able to compile the > >Java bits of OOo, the Fedora RPMs will include those patches. Its > going > >to mean some work though. > > > >So in summary, I'm not going to build Java-enabled RPMs of OOo for the > >time being. But if you'd like them, I'm happy to keep it possible (and > >will try to keep it building out-of-the-box with a specfile switch). > If > >anyone would like to help out in getting OOo to work with gcj or other > >free Java environments, by all means contact me and I'll try to point > >you in the right direction. > > > >Cheers, > >Dan > > > > Hi Dan, > > Could you also move the -mcpu override's in solenv/inc/ into the spec > file using a variable? > > Thanks, > > Byte > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From stan at ccs.neu.edu Mon Nov 24 23:59:26 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Mon, 24 Nov 2003 18:59:26 -0500 Subject: Tripwire Update ... In-Reply-To: <1069696091.19661.28.camel@skilletinfopleasecom.nh.pearsoned.com> References: <1069692577.19661.11.camel@skilletinfopleasecom.nh.pearsoned.com> <1069695592.19661.23.camel@skilletinfopleasecom.nh.pearsoned.com> <1069696091.19661.28.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <1069718366.1269.159.camel@duergar> On Mon, 2003-11-24 at 12:48, Karl DeBisschop wrote: > Sorry, that was incorrect. Development has moved off to sourceforge, but > the homapage has not been updated. There is active work at: > > http://sourceforge.net/projects/aide/ > > Of course the project rates itself as beta, so it seems maybe the > authors themselves feel it is not quite ready for primetime. Yeah and for beta software, it hasn't had many updates in CVS either, the most recent changes from 2 weeks -> 2 months appear to simply be patches submitted by users for bugfixes and no actual features or other notable changes from 0.9 release. Call that speculation. Judging from CVS there appears to be only english and russian translations, this is something else that would have to be handled before it made it into Fedora I suspect. -sb -------------- 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 pri.rhl1 at iadonisi.to Tue Nov 25 00:08:11 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: Mon, 24 Nov 2003 19:08:11 -0500 Subject: VNC can't stats binary! In-Reply-To: <3FC089A0.9090609@opentle.org> References: <3FC089A0.9090609@opentle.org> Message-ID: <1069718890.20570.6.camel@va.local.linuxlobbyist.org> On Sun, 2003-11-23 at 05:19, Supphachoke Suntiwichaya wrote: > I download vnc-server-4.0-0.beta4.3.2.i386.rpm from update site. > It seem incorrect. > > it norespond when > > # file /usr/bin/Xvnc > > ?? > > I rebuilded but it can't .. I'm not sure what you mean by saying you couldn't rebuild it, but I don't think that's relevant, anyhow. The problem is likely with the 'file' command, not with Xvnc itself. Wanna see something even weirder? Try 'file /usr/bin/*' and you'll notice that it *doesn't* hang and even returns 'executable,' for Xvnc. Try any other file glob (/usr/bin/X*, /usr/bin/[x-z]*' that matches Xvnc, and it does hang. Something very strange is going on here. I even tried a for loop to loop through all the binaries in /usr/bin, /bin, /usr/sbin, /sbin, and /usr/X11R6/bin and Xvnc is the *only* binary that the file command hangs on. Running it with strace doesn't reveal anything very informative, at least not to me. Anybody else seeing this behavior? -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From ms-nospam-0306 at arcor.de Tue Nov 25 00:52:51 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 25 Nov 2003 01:52:51 +0100 Subject: yum tries to update gpgme03 with gpgme? Message-ID: <20031125015251.7ecc7c86.ms-nospam-0306@arcor.de> Following scenario: # rpm -e gpgme # rpm -qa 'gpgme*' gpgme03-0.3.15-0.fdr.2.1 # rpm -q --whatrequires gpgme03 sylpheed-gpg-0.9.7-0.fdr.1 # yum -y install gpgme [...] Resolving dependencies .package sylpheed-gpg needs libgpgme.so.6 (not provided) package sylpheed-gpg needs gpgme03 >= 0:0.3.10 (not provided) What did happen there? What does that error mean? Did Yum want to upgrade gpgme03 with gpgme? The following makes me think that might be true: # rpm -q --provides gpgme03 | grep ^gpg gpgme = 0:0.3.15-0.fdr.2.1 gpgme03 = 0:0.3.15-0.fdr.2.1 # rpm -q --provides gpgme | grep ^gpg gpgme = 0:0.4.3-0.fdr.2 When I let it install both packages at once, it succeeds: # rpm -e gpgme03 --nodeps # yum -y install gpgme03 gpgme [...] Resolving dependencies Dependencies resolved I will do the following: [install: gpgme 0.4.3-0.fdr.2.i386] [install: gpgme03 0.3.15-0.fdr.2.1.i386] Running test transaction: Test transaction complete, Success! gpgme03 100 % done 1/2 gpgme 100 % done 2/2 Installed: gpgme 0.4.3-0.fdr.2.i386 gpgme03 0.3.15-0.fdr.2.1.i386 Transaction(s) Complete -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roland at redhat.com Tue Nov 25 00:55:33 2003 From: roland at redhat.com (Roland McGrath) Date: Mon, 24 Nov 2003 16:55:33 -0800 Subject: Executable memory: further programs that fail In-Reply-To: Tim Daly's message of Monday, 24 November 2003 13:40:33 -0500 <200311241840.hAOIeX931046@rio.sci.ccny.cuny.edu> Message-ID: <200311250055.hAP0tXnr006289@magilla.sf.frob.com> > I react to the notion that shared libraries can be placed > "at random" in free space. Lisp systems, database systems, > numeric systems (e.g. large matrix computations), all rely on > large, contiguous blocks of storage. In fact the size of the > problem they can handle depends on the size of contiguous > storage. I don't understand why fragmenting free storage > helps security. I certainly understand why it hurts certain > applications. I've already explained how to reserve arbitrarily large portions of the address space ahead of time for the application's exclusive use. Is that not sufficient control for your needs? From de_lupus at pandora.be Tue Nov 25 01:01:28 2003 From: de_lupus at pandora.be (lupus) Date: Tue, 25 Nov 2003 02:01:28 +0100 Subject: kudzu won't update modprobe.conf Message-ID: <1069722088.3205.11.camel@D57729D5.kabel.telenet.be> kernel 2.6 uses /etc/modprobe.conf kernel 2.4 uses /etc/modules.conf I installed kernel 2.6-test9 next to my kernel 2.4.22 (fedora core 1), but when I boot kernel 2.6 Kudzu won't edit modprobe.conf because /etc/sysconfig/hwconf hasn't changed. Isn't it possible to use /etc/sysconfig/hwconf for 2.4.22 and /sysconf/hwconf26 for kernel2.6, then kudzu can correctly detect hardware and configure modprobe.conf and modules.conf depending on what kernel I boot? After I removed hwconf and booted with kernel 2.6 he configured modprobe.conf correctly. But still my bttv and audio don't work. Witch package/programme normally modprobes them? Kristof Vansant (Belgium) From wcooley at nakedape.cc Tue Nov 25 01:04:40 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Mon, 24 Nov 2003 17:04:40 -0800 Subject: Tripwire Update ... In-Reply-To: <1069692577.19661.11.camel@skilletinfopleasecom.nh.pearsoned.com> References: <1069692577.19661.11.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: <1069722280.31029.22.camel@denk.nakedape.priv> On Mon, 2003-11-24 at 08:49, Karl DeBisschop wrote: > I personally gave up tripwire in favor of aide some time ago. > > Not that choice is bad, but it seemed worth mentioning. I thought I'd > read someplace that aide was slated to replace tripwire in FC, but maybe > that was my imagination. Oh man, have you looked at the code for AIDE? I did a few years ago because I wanted it log via syslog and I thought it would be trivial to implement. The code was nightmare-ish; it looked like the stuff Stephen van den Berg produces (author of procmail). Maybe it has improved since then. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Tired of spam and viruses in your e-mail? Get the * * Naked Ape Mail Defender! http://nakedape.cc/r/maildefender * -------------- 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 behdad at cs.toronto.edu Tue Nov 25 01:10:17 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 24 Nov 2003 20:10:17 -0500 Subject: kudzu won't update modprobe.conf In-Reply-To: <1069722088.3205.11.camel@D57729D5.kabel.telenet.be> References: <1069722088.3205.11.camel@D57729D5.kabel.telenet.be> Message-ID: AFAIK 2.6 kernels are not supported yet. behdad On Mon, 24 Nov 2003, lupus wrote: > kernel 2.6 uses /etc/modprobe.conf > kernel 2.4 uses /etc/modules.conf > > I installed kernel 2.6-test9 next to my kernel 2.4.22 (fedora core 1), > but when I boot kernel 2.6 Kudzu won't edit modprobe.conf because > /etc/sysconfig/hwconf hasn't changed. > > Isn't it possible to use /etc/sysconfig/hwconf for 2.4.22 and > /sysconf/hwconf26 for kernel2.6, then kudzu can correctly detect > hardware and configure modprobe.conf and modules.conf depending on > what kernel I boot? > > After I removed hwconf and booted with kernel 2.6 he configured > modprobe.conf correctly. But still my bttv and audio don't work. > Witch package/programme normally modprobes them? > > > Kristof Vansant (Belgium) > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From yinyang at eburg.com Tue Nov 25 02:30:43 2003 From: yinyang at eburg.com (Gordon Messmer) Date: Mon, 24 Nov 2003 18:30:43 -0800 Subject: Executable memory: further programs that fail In-Reply-To: <200311241840.hAOIeX931046@rio.sci.ccny.cuny.edu> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> <200311220354.WAA18263@springbok.sci.ccny.cuny.edu> <200311241840.hAOIeX931046@rio.sci.ccny.cuny.edu> Message-ID: <3FC2BED3.7040906@eburg.com> Tim Daly wrote: > > I react to the notion that shared libraries can be placed > "at random" in free space. Lisp systems, database systems, > numeric systems (e.g. large matrix computations), all rely on > large, contiguous blocks of storage. In fact the size of the > problem they can handle depends on the size of contiguous > storage. I don't understand why fragmenting free storage > helps security. I'm not an assembly programmer, so someone may correct me: buffer overflow exploits rely on the ability to call a library function at a predictable address. If the libraries are loaded at random addresses, then buffer overflow attacks have a much more difficult time predicting the address of a block of code to jump to. From yinyang at eburg.com Tue Nov 25 03:14:29 2003 From: yinyang at eburg.com (Gordon Messmer) Date: Mon, 24 Nov 2003 19:14:29 -0800 Subject: Question about Development In-Reply-To: <003e01c3b26b$e6c01a60$42f4ac41@k4h8f5> References: <002a01c3b267$12545c40$42f4ac41@k4h8f5> <1069657588.2419.7.camel@agnes.fremen.dune> <003e01c3b26b$e6c01a60$42f4ac41@k4h8f5> Message-ID: <3FC2C915.8040807@eburg.com> Anthony Saffer wrote: > > >>Unless you have a very good technical reason for using Wx or you just >>want to have some fun without caring about use of your application I >>urge you to stick to mainstream toolkit > > > Could you define "mainstream toolkit" for me? Forgive my frustrated tone > here but it seems that "mainstream" or "acceptable" toolkit seems to mean > "PyGTK" or nothing at all. So, if I *can* use something other than PyGTK, > what would that be? Probably something that uses GTK (or maybe QT?) as its interface. Applications using GTK or QT have proper i18n facilities available, and their widgets behave like other widgets in the standard desktop. From notting at redhat.com Tue Nov 25 03:15:22 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 24 Nov 2003 22:15:22 -0500 Subject: kudzu won't update modprobe.conf In-Reply-To: <1069722088.3205.11.camel@D57729D5.kabel.telenet.be> References: <1069722088.3205.11.camel@D57729D5.kabel.telenet.be> Message-ID: <20031125031522.GA21828@devserv.devel.redhat.com> lupus (de_lupus at pandora.be) said: > kernel 2.6 uses /etc/modprobe.conf > kernel 2.4 uses /etc/modules.conf > > I installed kernel 2.6-test9 next to my kernel 2.4.22 (fedora core 1), > but when I boot kernel 2.6 Kudzu won't edit modprobe.conf because > /etc/sysconfig/hwconf hasn't changed. It only updates the one for the running kernel. > Isn't it possible to use /etc/sysconfig/hwconf for 2.4.22 and > /sysconf/hwconf26 for kernel2.6, then kudzu can correctly detect > hardware and configure modprobe.conf and modules.conf depending on > what kernel I boot? That really doesn't make sense. The hwconf file doesn't change depending on which kernel you boot. > After I removed hwconf and booted with kernel 2.6 he configured > modprobe.conf correctly. But still my bttv and audio don't work. > Witch package/programme normally modprobes them? Normally, they should be loaded by opening the proper v4l devices; i.e., there's an alias for char-major-81, and then whatever app opens the device will cause it to get loaded. Bill From skvidal at phy.duke.edu Tue Nov 25 03:22:01 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 24 Nov 2003 22:22:01 -0500 Subject: yum tries to update gpgme03 with gpgme? In-Reply-To: <20031125015251.7ecc7c86.ms-nospam-0306@arcor.de> References: <20031125015251.7ecc7c86.ms-nospam-0306@arcor.de> Message-ID: <1069730521.3559.15.camel@binkley> > # rpm -e gpgme > # rpm -qa 'gpgme*' > gpgme03-0.3.15-0.fdr.2.1 > # rpm -q --whatrequires gpgme03 > sylpheed-gpg-0.9.7-0.fdr.1 > > # yum -y install gpgme > [...] > Resolving dependencies > .package sylpheed-gpg needs libgpgme.so.6 (not provided) > package sylpheed-gpg needs gpgme03 >= 0:0.3.10 (not provided) > look at the dependencies of these two packages, I'll bet you find some sort of conflict. > What did happen there? What does that error mean? Did Yum want to upgrade > gpgme03 with gpgme? The following makes me think that might be true: > you might want to check for obsoletes b/t these two but yum doesn't not view gpgme03 as gpgme -sv From elliott at wilcoxon.org Tue Nov 25 05:10:46 2003 From: elliott at wilcoxon.org (Elliott Wilcoxon) Date: Mon, 24 Nov 2003 23:10:46 -0600 Subject: Red Carpet ? In-Reply-To: <3d9873790106da07d3@[192.168.170.10]> References: <3d9873790106da07d3@[192.168.170.10]> Message-ID: <3FC2E456.40900@wilcoxon.org> Is it just me, or does red carpet's use sound an awful lot like apt/yum/up2date? Does it offer something that's above and beyond their existing feature sets? Elliott Wilcoxon Nils O. Sel?sdal wrote: > Ximian just released a new version of Red-Carpet. Would it be an idea > to make RC channels of fedora.us(and Fedora for that matter) ? > RedCarpet does in my opinion make software installation a no brainer > for most people. > > http://www.ximian.com/products/redcarpet/ > http://www.opencarpet.org/ > From kdebisschop at alert.infoplease.com Tue Nov 25 06:01:00 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Tue, 25 Nov 2003 01:01:00 -0500 Subject: Tripwire Update ... In-Reply-To: <1069722280.31029.22.camel@denk.nakedape.priv> References: <1069692577.19661.11.camel@skilletinfopleasecom.nh.pearsoned.com> <1069722280.31029.22.camel@denk.nakedape.priv> Message-ID: <1069740060.22005.22.camel@miles.debisschop.net> On Mon, 2003-11-24 at 20:04, Wil Cooley wrote: > On Mon, 2003-11-24 at 08:49, Karl DeBisschop wrote: > > I personally gave up tripwire in favor of aide some time ago. > > > > Not that choice is bad, but it seemed worth mentioning. I thought I'd > > read someplace that aide was slated to replace tripwire in FC, but maybe > > that was my imagination. > > Oh man, have you looked at the code for AIDE? I haven't. It's worked for me out of the box, so I haven't needed to. But I'll accept your judgment that it should be cleaner. At the same time, I submit that the configuration of tripwire is too messy. My example: Since I run postgresql on several servers, files are routinely created and changed by DBMS users. In aide, a one line config switch excludes the DBMS data directory from the file scan. For tripwire, part of the discussion today was about creating add-on utilities that help the sysadmin exclude files that should not be checked. Tripwire may fit some needs, but since I to admin 20+ servers and desktops in something like 5 hours per week. With user-friendly tools like aide and logwatch, I can be a little proactive about security within those constraints. If I have to set up tripwire for each if those boxes, I don't think I can do it in that time frame. So I ask: 1) am I missing something that would make tripwire configurable for a basic setup in a 10-minute time frame? 2) If I am not, is there an alternative to both aide and tripwire that has clean code _and_ is more manageable than tripwire. 3) if there is no such alternative, what do you suggest Fedora _should_ use in this role? 4) If your answer to above is open-source tripwire plus some code changes and add-ons, can I assume that you have also audited the tripwire code and found it to be substantially cleaner than aide? (Reading the above, ISTM these questions are rather direct and could be antagonistic. That is not my intent - it just seems they are the questions that need to be answered to decide on an integrity-checking app for Fedora. So please don't read hostility into their directness - none is intended) -- Karl DeBisschop -------------- 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 Tue Nov 25 06:01:35 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Nov 2003 01:01:35 -0500 Subject: Tripwire Update ... In-Reply-To: <1069740060.22005.22.camel@miles.debisschop.net> References: <1069692577.19661.11.camel@skilletinfopleasecom.nh.pearsoned.com> <1069722280.31029.22.camel@denk.nakedape.priv> <1069740060.22005.22.camel@miles.debisschop.net> Message-ID: <1069740094.3559.39.camel@binkley> > Tripwire may fit some needs, but since I to admin 20+ servers and > desktops in something like 5 hours per week. With user-friendly tools > like aide and logwatch, I can be a little proactive about security > within those constraints. If I have to set up tripwire for each if those > boxes, I don't think I can do it in that time frame. This is off topic for this thread but: there is NOTHING clean or user-friendly about logwatch. look at http://linux.duke.edu/epylog/ That's clean and tidy and nice. -sv From kdebisschop at alert.infoplease.com Tue Nov 25 06:19:58 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Tue, 25 Nov 2003 01:19:58 -0500 Subject: logwatch (was: Tripwire Update ...) In-Reply-To: <1069740094.3559.39.camel@binkley> References: <1069692577.19661.11.camel@skilletinfopleasecom.nh.pearsoned.com> <1069722280.31029.22.camel@denk.nakedape.priv> <1069740060.22005.22.camel@miles.debisschop.net> <1069740094.3559.39.camel@binkley> Message-ID: <1069741198.22005.30.camel@miles.debisschop.net> On Tue, 2003-11-25 at 01:01, seth vidal wrote: > > Tripwire may fit some needs, but since I to admin 20+ servers and > > desktops in something like 5 hours per week. With user-friendly tools > > like aide and logwatch, I can be a little proactive about security > > within those constraints. If I have to set up tripwire for each if those > > boxes, I don't think I can do it in that time frame. > > This is off topic for this thread but: > > there is NOTHING clean or user-friendly about logwatch. some of that is in the eye of the beholder perhaps. And I submit that there is a degree of user-friendliness shown by the fact it has reduced some rather vast log files into something I can manage without extra configuration. For me it was a value add, because the alternative was to only look at the logs when something was going wrong. And in the few times I needed to change the default scanning engine, I read the docs and did the work in less than an hour. Could be better, but I'm OK with that. > look at http://linux.duke.edu/epylog/ Having stood up to the defense of logwatch, I also admit to always being on the lookout for a better tool. I will be clicking over to the like you gave right after I finish catching up on my mail. Thanks for the tip. -- Karl DeBisschop -------------- 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 nos at utel.no Tue Nov 25 08:39:56 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Tue, 25 Nov 2003 09:39:56 +0100 Subject: Red Carpet ? In-Reply-To: <4208c73202080007d3@[192.168.170.10]> References: <3d9873790106da07d3@[192.168.170.10]><4208c73202080007d3@[192.168.170.10]> Message-ID: <42c1d4bf02081807d3@[192.168.170.10]> On Tue, 2003-11-25 at 06:10, Elliott Wilcoxon wrote: > Is it just me, or does red carpet's use sound an awful lot like > apt/yum/up2date? Does it offer something that's above and beyond their > existing feature sets? A very nice GUI. Much more suitable for the common man for managing software. -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From elliott at wilcoxon.org Tue Nov 25 09:12:48 2003 From: elliott at wilcoxon.org (Elliott Wilcoxon) Date: Tue, 25 Nov 2003 03:12:48 -0600 Subject: Red Carpet ? In-Reply-To: <42c1d4bf02081807d3@[192.168.170.10]> References: <3d9873790106da07d3@[192.168.170.10]><4208c73202080007d3@[192.168.170.10]> <42c1d4bf02081807d3@[192.168.170.10]> Message-ID: <3FC31D10.5010703@wilcoxon.org> Ah, I see. Elliott Wilcoxon Nils O. Sel?sdal wrote: > On Tue, 2003-11-25 at 06:10, Elliott Wilcoxon wrote: > >>Is it just me, or does red carpet's use sound an awful lot like >>apt/yum/up2date? Does it offer something that's above and beyond their >>existing feature sets? > > A very nice GUI. Much more suitable for the common man for managing > software. > From roli at israel-jugendtag.ch Tue Nov 25 09:25:37 2003 From: roli at israel-jugendtag.ch (=?ISO-8859-1?Q?Roland_K=E4ser?=) Date: Tue, 25 Nov 2003 10:25:37 +0100 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <1069712891.25450.6.camel@dhcp64-188.boston.redhat.com> References: <1069206029.1545.8.camel@ByteEnable> <1069712891.25450.6.camel@dhcp64-188.boston.redhat.com> Message-ID: <3FC32011.90201@israel-jugendtag.ch> Hi Dan Can You exaclty describe whats the difficult therms in the Java licence? And why it hinders to integrate Java to the Fedora Core? Roland Dan Williams schrieb: >Hi, > >I've completed adding the required bits to the specfile. I hope to >release a 1.1.0-7 fairly soon that includes the enable-java stuff and RH >9 build support for those of you wanting it. Unfortunately, Mozilla >address book integration won't work on RH9 because the system mozilla is >built with gcc 2.96 and OOo with 3.2.2... However, the rest should be >fine (oh, minus startup-notification though). > >I also merged required enable-java stuff to gnome.org OOo (ie Ximianized >OOo) so when I switch over to that you'll have it if you'd like it. > >If you do build with Java, the following things are true: > >1) openoffice.org RPM will require libawt.so >2) RPMs will be named as such: >openoffice.org-1.1.0-7.withjava.rpm >openoffice.org-i18n-1.1.0-7.withjava.rpm >openoffice.org-libs-1.1.0-7.withjava.rpm > >Still for the future, Red Hat won't be building and distributing >Java-enabled builds of OOo for Fedora. This will change immediately >when Java gets a license compatible with the license under which Fedora >is distributed, or when gcj support gets into OOo. > >Cheers, >Dan > >On Tue, 2003-11-18 at 20:40, ByteEnable wrote: > > >>>Hi, >>> >>>After some thought and discussion, I've come to the following >>>conclusion: >>> >>>Since Fedora does not include Java for licensing reasons, all Red >>>Hat-built OpenOffice.org RPMs for Fedora will NOT include Java support, >>>and will NOT be built with Java enabled. It's not good form to supply >>>an RPM that cannot be built on the platform it is intended for. >>>Therefore, when you install Fedora and OOo, anything that requires Java >>>will not function. >>> >>>However, I will attempt to keep a "Java-enable" switch in the specfile >>>that will allow Java-enabled building on Fedora, provided you have a >>>JRE/JDK installed. I will attempt to keep Java-enabled building >>>up-to-date and functional. >>> >>>In the future, I hope OOo will compile using gcj or other free Java >>>environments. This is something we'll be working towards, and other >>>shave this same goal in mind (Debian). When gcj is able to compile the >>>Java bits of OOo, the Fedora RPMs will include those patches. Its >>> >>> >>going >> >> >>>to mean some work though. >>> >>>So in summary, I'm not going to build Java-enabled RPMs of OOo for the >>>time being. But if you'd like them, I'm happy to keep it possible (and >>>will try to keep it building out-of-the-box with a specfile switch). >>> >>> >>If >> >> >>>anyone would like to help out in getting OOo to work with gcj or other >>>free Java environments, by all means contact me and I'll try to point >>>you in the right direction. >>> >>>Cheers, >>>Dan >>> >>> >>> >>Hi Dan, >> >>Could you also move the -mcpu override's in solenv/inc/ into the spec >>file using a variable? >> >>Thanks, >> >>Byte >> >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Roland K?ser Bocksrietstr. 54 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch From Nicolas.Mailhot at laposte.net Tue Nov 25 09:36:50 2003 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 25 Nov 2003 10:36:50 +0100 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <3FC32011.90201@israel-jugendtag.ch> References: <1069206029.1545.8.camel@ByteEnable> <1069712891.25450.6.camel@dhcp64-188.boston.redhat.com> <3FC32011.90201@israel-jugendtag.ch> Message-ID: <1069753010.7825.1.camel@ulysse.olympe.o2t> Le mar 25/11/2003 ? 10:25, Roland K?ser a ?crit : > Hi Dan > > Can You exaclty describe whats the difficult therms in the Java licence? > And why it hinders to integrate Java to the Fedora Core? See the numerous jpackage-discuss threads on the subject http://www.jpackage.org/contacts.php -- 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 ms-nospam-0306 at arcor.de Tue Nov 25 09:38:23 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 25 Nov 2003 10:38:23 +0100 Subject: yum tries to update gpgme03 with gpgme? In-Reply-To: <1069730521.3559.15.camel@binkley> References: <20031125015251.7ecc7c86.ms-nospam-0306@arcor.de> <1069730521.3559.15.camel@binkley> Message-ID: <20031125103823.76abb452.ms-nospam-0306@arcor.de> On Mon, 24 Nov 2003 22:22:01 -0500, seth vidal wrote: > > # rpm -e gpgme > > # rpm -qa 'gpgme*' > > gpgme03-0.3.15-0.fdr.2.1 > > # rpm -q --whatrequires gpgme03 > > sylpheed-gpg-0.9.7-0.fdr.1 > > > > # yum -y install gpgme > > [...] > > Resolving dependencies > > .package sylpheed-gpg needs libgpgme.so.6 (not provided) > > package sylpheed-gpg needs gpgme03 >= 0:0.3.10 (not provided) > > > > look at the dependencies of these two packages, I'll bet you find some > sort of conflict. Well, I need assistance. Else I would have submitted a bug report straight away. What exactly should I search for? How is above error message to be interpreted correctly? If we agree on the same terminology when using the term "conflict", gpgme03, gpgme and sylpheed-gpg don't conflict. > > What did happen there? What does that error mean? Did Yum want to upgrade > > gpgme03 with gpgme? The following makes me think that might be true: > > > > you might want to check for obsoletes b/t these two but yum doesn't not > view gpgme03 as gpgme If we agree on the same terminology when using the term "obsoletes", gpgme03 and gpgme don't obsolete anything. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From de_lupus at pandora.be Tue Nov 25 12:41:23 2003 From: de_lupus at pandora.be (lupus) Date: Tue, 25 Nov 2003 13:41:23 +0100 Subject: kudzu won't update modprobe.conf In-Reply-To: <20031125031522.GA21828@devserv.devel.redhat.com> References: <1069722088.3205.11.camel@D57729D5.kabel.telenet.be> <20031125031522.GA21828@devserv.devel.redhat.com> Message-ID: <1069764083.2395.32.camel@D5E03FC5.kabel.telenet.be> I Quote man page kudzu: When started, kudzu detects the current hardware, and checks it against a database stored in /etc/sysconfig/hwconf, if one exists. Only when no previous database exists, kudzu attempts to determine what devices have already been configured, by looking at /etc/modules.conf, /etc/sysconfig/network-scripts/, and /etc/X11/XF86Config. I install fedora core 1 with kernel 2.4.22 kudzu will generate /etc/sysconfig/hwconf and find new hardware. Edits /etc/modules.conf. When I install kernel 2.6 and start fedora core 1 kudzu will compare hwconf against his probing and won't find new hardware. So /etc/modprobe.conf won't get edited. But kernel 2.6 uses /etc/modprobe.conf instead of /etc/modules.conf. So my proposal is to generate hwconf when booting 2.4 and hwconf26 with 2.6. So kudzu will chance /etc/modprobe.conf when hwconf26 has changed or does not exist. Kristof Vansant Op di 25-11-2003, om 04:15 schreef Bill Nottingham: > lupus (de_lupus at pandora.be) said: > > kernel 2.6 uses /etc/modprobe.conf > > kernel 2.4 uses /etc/modules.conf > > > > I installed kernel 2.6-test9 next to my kernel 2.4.22 (fedora core 1), > > but when I boot kernel 2.6 Kudzu won't edit modprobe.conf because > > /etc/sysconfig/hwconf hasn't changed. > > It only updates the one for the running kernel. > > > Isn't it possible to use /etc/sysconfig/hwconf for 2.4.22 and > > /sysconf/hwconf26 for kernel2.6, then kudzu can correctly detect > > hardware and configure modprobe.conf and modules.conf depending on > > what kernel I boot? > > That really doesn't make sense. The hwconf file doesn't > change depending on which kernel you boot. > > > After I removed hwconf and booted with kernel 2.6 he configured > > modprobe.conf correctly. But still my bttv and audio don't work. > > Witch package/programme normally modprobes them? > > Normally, they should be loaded by opening the proper v4l devices; > i.e., there's an alias for char-major-81, and then whatever app > opens the device will cause it to get loaded. > > Bill > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From buildsys at porkchop.devel.redhat.com Tue Nov 25 12:54:59 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Tue, 25 Nov 2003 07:54:59 -0500 Subject: rawhide report: 20031125 changes Message-ID: <200311251254.hAPCsxB13225@porkchop.devel.redhat.com> New package alsa-lib The Advanced Linux Sound Architecture (ALSA) library. Updated Packages: asp2php-0.76.18-1 ----------------- * Mon Nov 24 2003 Joe Orton 0.76.18-1 - update to 0.76.18; build against gtk2 - fix #110693 authconfig-4.4-1 ---------------- * Tue Nov 18 2003 Nalin Dahyabhai 4.4-1 - add options for toggling krb5's use of DNS * Mon Nov 17 2003 Nalin Dahyabhai - rework tui to include winbind options. there wasn't enough room in the old dialog to include the important options, so the whole thing's been reworked * Thu Nov 13 2003 Nalin Dahyabhai - conflict with older versions of samba which expect different configuration * Mon Nov 10 2003 Nalin Dahyabhai - initial support for configuring winbind * Tue Oct 28 2003 Nalin Dahyabhai - make pam_cracklib requisite instead of required in generated PAM configs dovecot-0.99.10.4-1 ------------------- * Mon Nov 24 2003 Jeremy Katz 0.99.10.4-1 - update to 0.99.10.4 * Mon Oct 06 2003 Jeremy Katz 0.99.10-7 - another patch from upstream to fix returning invalid data on partial BODY[part] fetches - patch to avoid confusion of draft/deleted in indexes firstboot-1.3.2-1 ----------------- * Mon Nov 24 2003 Brent Fox 1.3.2-1 - make changes for Python2.3 * Sun Nov 23 2003 Brent Fox 1.3.2-1 - update Requires for system-config name change - make changes for Python2.3 * Mon Oct 27 2003 Brent Fox 1.3.1-1 - fix initscript for text mode * Fri Oct 24 2003 Brent Fox 1.3.1-1 - bump version - use CVS head now for Fedora Core 2 - made firstboot-cambridge branch for Fedora Core 1 - first stab at text mode irda-utils-0.9.15-2 ------------------- * Mon Nov 24 2003 Karsten Hopp 0.9.15-2 - fix array usage (#110791) * Sun Oct 19 2003 Florian La Roche - add a %clean specfile target kdebase-3.1.93-0.3 ------------------ * Mon Nov 17 2003 Than Ngo 6:3.1.93-0.3 - disable kpersonalizer - fix konsole desktop file - get rid of some old workarounds in startkde, speedup startkde - get rid of theme, it's obsolete in 3.2 - add missing starthere icon - add missing kde-unknown.directory * Sun Nov 16 2003 Than Ngo 6:3.1.93-0.2 - start-here protocol - BlueCure Ksplash as default - fix menu issue in kicker/kcontrol * Tue Nov 04 2003 Than Ngo 6:3.1.93-0.1 - KDE 3.2 Beta 1 - remove many patch files, which are now in upstream - cleanup many patch files - cleanup startkde - cleanup rpm file list krb5-1.3.1-7 ------------ * Mon Nov 24 2003 Nalin Dahyabhai 1.3.1-7 - fix combination of --with-netlib and --enable-dns * Tue Nov 18 2003 Nalin Dahyabhai - remove libdefault ticket_lifetime option from the default krb5.conf, it is ignored by libkrb5 openssl-0.9.7a-25 ----------------- * Fri Oct 24 2003 Nalin Dahyabhai 0.9.7a-25 - add dependency on zlib-devel for the -devel package, which depends on zlib symbols because we enable zlib for libssl (#102962) * Fri Oct 24 2003 Phil Knirsch 0.9.7a-24 - Use /dev/urandom instead of PRNG for libica. - Apply libica-1.3.5 fix for /dev/urandom in icalinux.c - Use latest ICA engine patch from IBM. * Sat Oct 04 2003 Nalin Dahyabhai 0.9.7a-22.1 - rebuild * Wed Oct 01 2003 Nalin Dahyabhai 0.9.7a-22 - rebuild (22 wasn't actually built, fun eh?) python-2.3.2-6 -------------- * Mon Nov 24 2003 Mihai Ibanescu 2.3.2-6 - added a Provides: python-abi qt-3.2.3-0.1 ------------ * Fri Nov 14 2003 Than Ngo 1:3.2.3-0.1 - 3.2.3 release rpmdb-fedora-1.90-0.20031125 ---------------------------- system-config-users-1.2.6-1 --------------------------- * Mon Nov 24 2003 Brent Fox 1.2.6-1 - remove Red Hat reference in the window title From arubin at atl.lmco.com Tue Nov 25 13:25:18 2003 From: arubin at atl.lmco.com (Aron Rubin) Date: Tue, 25 Nov 2003 08:25:18 -0500 Subject: SiI3x12A Fedora Core Install Message-ID: <3FC3583E.6000501@atl.lmco.com> So I got this mondo hammer (athlon64) machine, but it has only a SATA drive. Prior to procuring said machine, I made sure I could find some sort of statement of support, some vague, for each component. Well poop, the Fedora Core install process does not recognize the SATA controller, which is a Silicon Image SiI 3x12. There does not seem to be a "legacy" emulation option in the bios. The vendor only supplies the driver compiled into a 2.4.18 binary distro and a promise for inclusion in 2.6. After much searching I came across: http://www.infowares.com/linux/ These drivers claim support for the SiI3x12A controller. Before I go and try to use them, can someone give me some direction as to how to do so with the install process. Any other *useful* info would be appreciated. Aron -- ssh aron at rubinium.org cat /dev/brain | grep ^work: Aron Rubin Member, Engineering Staff Lockheed Martin E-Mail: arubin at atl.lmco.com Advanced Technology Laboratories Phone: 856.792.9865 3 Executive Campus Fax: 856.792.9930 Cherry Hill, NJ USA 08002 Web: http://www.atl.lmco.com From lfarkas at bnap.hu Tue Nov 25 13:35:20 2003 From: lfarkas at bnap.hu (Farkas Levente) Date: Tue, 25 Nov 2003 14:35:20 +0100 Subject: ext2/3 acl in development Message-ID: <3FC35A98.4030401@bnap.hu> hi, michaelkjohnson wrote in oct: "the ACL patches no longer destabilize the system under load; we finally found and fixed that bug while working on RHEL3...ACLs will certainly be in FC2." can we can wait an updated kernel package for FC1 or a development package for FC2 in the near future? thanks. -- Levente "Si vis pacem para bellum!" From mudong at hotmail.com Tue Nov 25 13:48:49 2003 From: mudong at hotmail.com (Lu Mudong) Date: Tue, 25 Nov 2003 04:48:49 -0900 Subject: can't see any chinese characters at all, mozilla crashes all the time Message-ID: Could somebody please help? I am desperate. I upgraded from RH9 to Fedora days ago, since then, I can't read any chinese, mozilla crashes on chinese website or sometimes even by only typing "w", "x" in the address field, when open a chinese file, nothing is readable in it. I changed the locale to chinese, then when I restart X-window, all the letters(including english letters) become small rectangles, I don't know much about changing locale, it took me a while to find the configuation file and delete it. Could somebody please help? many many thanks. Mudong _________________________________________________________________ Need a shot of Hank Williams or Patsy Cline? The classic country stars are always singing on MSN Radio Plus. Try one month free! http://join.msn.com/?page=offers/premiumradio From mingo at redhat.com Tue Nov 25 14:04:01 2003 From: mingo at redhat.com (Ingo Molnar) Date: Tue, 25 Nov 2003 09:04:01 -0500 (EST) Subject: Executable memory: further programs that fail In-Reply-To: <200311241840.hAOIeX931046@rio.sci.ccny.cuny.edu> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> <200311220354.WAA18263@springbok.sci.ccny.cuny.edu> <200311241840.hAOIeX931046@rio.sci.ccny.cuny.edu> Message-ID: On Mon, 24 Nov 2003, Tim Daly wrote: > I react to the notion that shared libraries can be placed "at random" in > free space. [...] this is not how it works. It is random to a certain degree but it doesnt sacrifice free VM space! > [...] Lisp systems, database systems, numeric systems (e.g. large matrix > computations), all rely on large, contiguous blocks of storage. [...] yes, and the new VM rule that allocates anonymous mmap()s [ie. large matrix allocations] from below the stack helped a number of scientific projects around the globe to use more VM. (they use the exec-shield patch to get the benefit of the new VM layout.) > [...] I don't understand why fragmenting free storage helps security. > [...] we dont fragment free storage. We randomize _executable_ library addresses in a quite small, ~100 MB range, but normal program objects like matrices, etc. are still allocated in an as compact way as possible. In fact the new VM layout is better for scientific apps because the old way put the mmap base to 1 GB virtual, which made it impossible to use small malloc()s larger than ~900 MB. Now you can malloc up to 3 GB. (or 4 GB if using the 4G/4G kernel.) Also, the old VM layout only left 2 GB for mmap()s - now that has a maximum of 3 GB too. Ingo From redhat-forums at genesis-x.nildram.co.uk Tue Nov 25 14:05:32 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Tue, 25 Nov 2003 14:05:32 +0000 Subject: Tripwire 2.3.1-18.rhfc1 now available for QA Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message It's amazing what a good, strong cup of coffee can do :) (Note: can sombody please advise me how to submit this to QA? I tried the bugzilla interface, but because "tripwire" is not listed as an FC1 component, it was rejected.) Tripwire 2.3.1-18.rhfc1 is now ready, approximately 4 days ahead of schedule. Details: NAME: tripwire VERSION: 2.3.1 RELEASE: 18.rhfc1 SUMMARY: A system integrity assessment tool. DESCRIPTION: Tripwire is a very valuable security tool for Linux systems, if it is installed to a clean system. Tripwire should be installed right after the OS installation, and before you have connected your system to a network (before any possibility exists that someone could alter files on your system). CHANGELOG: * Tue Nov 25 2003 Keith G. Robertson-Turner 2.3.1-18.rhfc1 - Implemented Paul Herman's tw-20030919.patch - Removed the fhs gcc3 and jbj patches, which are now broken/obsoleted by the above - Both the mkstemp and rfc822 patches are still implemented - Build uses autoconf for now Download: http://www.genesis-x.nildram.co.uk/filez/tripwire-2.3.1-18.rhfc1.i386.rpm http://www.genesis-x.nildram.co.uk/filez/tripwire-2.3.1-18.rhfc1.i686.rpm http://www.genesis-x.nildram.co.uk/filez/tripwire-2.3.1-18.rhfc1.src.rpm Note, as the above has not yet passed QA, it should be treated as an unstable beta, however it WorksForMe?. Comments/Bug submissions: tripwire-devel at genesis-x.nildram.co.uk - Regards, Keith G. Robertson-Turner tripwire-devel at genesis-x.nildram.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/w2Fa2XoLj+pGfn8RAgxcAJ9/kx/I1VE6bmOT7MoenGmX5xeCAgCeJSt/ 3m51sdE5vuO+zmRPw+vwG1E= =Rsh5 -----END PGP SIGNATURE----- From behdad at cs.toronto.edu Tue Nov 25 14:43:46 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 25 Nov 2003 09:43:46 -0500 Subject: Red Carpet ? In-Reply-To: <3FC31D10.5010703@wilcoxon.org> References: <3d9873790106da07d3@[192.168.170.10]><4208c73202080007d3@[192.168.170.10]> <42c1d4bf02081807d3@[192.168.170.10]> <3FC31D10.5010703@wilcoxon.org> Message-ID: AFAICS it uses apt-rpm repos. Perhaps after yum/up2date/apt settle on a unified repo architecture, one can hack red carpet for that too. behdad On Tue, 25 Nov 2003, Elliott Wilcoxon wrote: > Ah, I see. > > Elliott Wilcoxon > > Nils O. Sel?sdal wrote: > > > On Tue, 2003-11-25 at 06:10, Elliott Wilcoxon wrote: > > > >>Is it just me, or does red carpet's use sound an awful lot like > >>apt/yum/up2date? Does it offer something that's above and beyond their > >>existing feature sets? > > > > A very nice GUI. Much more suitable for the common man for managing > > software. > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From daly at rio.sci.ccny.cuny.edu Tue Nov 25 14:10:55 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Tue, 25 Nov 2003 09:10:55 -0500 Subject: Executable memory: further programs that fail In-Reply-To: <200311250055.hAP0tXnr006289@magilla.sf.frob.com> (message from Roland McGrath on Mon, 24 Nov 2003 16:55:33 -0800) References: <200311250055.hAP0tXnr006289@magilla.sf.frob.com> Message-ID: <200311251410.hAPEAtn27388@rio.sci.ccny.cuny.edu> Roland, Yes, you've explained that there is a long-way-around method to tell the linker that I want free space reserved. Yes, that is sufficient for my needs. It is also painful to implement. I'm asking for the reason such an obscure method is needed in the first place. Clearly such a pervasive and intrusive change to the expected unix memory model has a strong justification based on improving security. I'm unclear what the justification could be and I haven't seen it explained. If I've found a way to take control of your machine by some exploit how does randomly placing shared libraries keep your computer secure? I'm unable to come up with a reason and I surely won't be able to explain it to my students. Tim From daly at rio.sci.ccny.cuny.edu Tue Nov 25 14:25:32 2003 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Tue, 25 Nov 2003 09:25:32 -0500 Subject: Executable memory: further programs that fail In-Reply-To: <3FC2BED3.7040906@eburg.com> (message from Gordon Messmer on Mon, 24 Nov 2003 18:30:43 -0800) References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> <200311220354.WAA18263@springbok.sci.ccny.cuny.edu> <200311241840.hAOIeX931046@rio.sci.ccny.cuny.edu> <3FC2BED3.7040906@eburg.com> Message-ID: <200311251425.hAPEPWY28013@rio.sci.ccny.cuny.edu> Gordon, The library code is shared. I can trivially search memory for a pattern that matches the routine I want to call. The memory can be read. The pattern is known beforehand since the binaries are widely distributed. The pattern match is a small loop. The typical buffer overflow, especially inline buffers, simply overwrites inline instructions. I've seen a buffer overflow in the several hundred K range of code. You can statically link the library code in the exploit given that much code in the overflow. Forcing code areas to be read-only would disallow inline buffers and require malloced buffers. I also understand the stack-execute issue. I can think of ways to exploit the system by stomping on return addresses in stack frames and even playing spaghetti-stack continuation games to leave my exploit around. All of these I can explain to my students. These are all good changes. I've just drawn a complete blank about how to explain fragmenting memory, especially after I've explained how and why segment registers exist. Tim From behdad at cs.toronto.edu Tue Nov 25 15:40:54 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 25 Nov 2003 10:40:54 -0500 Subject: Executable memory: further programs that fail In-Reply-To: <200311251425.hAPEPWY28013@rio.sci.ccny.cuny.edu> References: <1069073695.9836.5.camel@scriabin.tannenrauch.ch> <20031117130359.GB6288@devserv.devel.redhat.com> <20031117210300.15ce21c0.ms-nospam-0306@arcor.de> <1069103046.18050.1.camel@localhost.localdomain> <1069438142.14267.7.camel@scriabin.tannenrauch.ch> <1069443186.7723.47.camel@skilletinfopleasecom.nh.pearsoned.com> <200311220354.WAA18263@springbok.sci.ccny.cuny.edu> <200311241840.hAOIeX931046@rio.sci.ccny.cuny.edu> <3FC2BED3.7040906@eburg.com> <200311251425.hAPEPWY28013@rio.sci.ccny.cuny.edu> Message-ID: I can't completely understand what you are saying, if exec-shield is good, or not. BTW, that scanning that you say is easy to do, is not so easy for a couple of reasons: * You need to do that in an exploit code, which most of the time is limited in length, and should not have any null bytes. * Scanning through 4GB is not any fast. * What you are missing: Reading an invalid location in VM would cause a segfault. You most probably need your IP in your exploit. What people do is to write a few bytes of code somewhere in memory, and call the code, and pop IP from stack. With randomized VM, you don't know where to put your code. Even if you find one, with non-exec heap and non-write code segments, you can't both write your code somewhere, AND call it. If a hole is already in a library function, which you like to call, again more than the above reasons, the ascii shielded property prevents you. As the least, exec-shield stuff is very very useful to protect possible holes in suid binaries. behdad PS. I admit this thread is completely off-topic. Hope it's the last post. On Tue, 25 Nov 2003, Tim Daly wrote: > Gordon, > > The library code is shared. I can trivially search memory for a pattern > that matches the routine I want to call. The memory can be read. The > pattern is known beforehand since the binaries are widely distributed. > The pattern match is a small loop. > > The typical buffer overflow, especially inline buffers, simply overwrites > inline instructions. I've seen a buffer overflow in the several hundred K > range of code. You can statically link the library code in the exploit given > that much code in the overflow. Forcing code areas to be read-only would > disallow inline buffers and require malloced buffers. > > I also understand the stack-execute issue. I can think of ways to exploit > the system by stomping on return addresses in stack frames and even playing > spaghetti-stack continuation games to leave my exploit around. All of these > I can explain to my students. > > These are all good changes. I've just drawn a complete blank about how > to explain fragmenting memory, especially after I've explained how and why > segment registers exist. > > Tim From johnsonm at redhat.com Tue Nov 25 15:47:42 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 25 Nov 2003 10:47:42 -0500 Subject: SMP i586? In-Reply-To: <1069661262.22934.1.camel@topicus6> References: <200311211715.43696.lowen@pari.edu> <1069661262.22934.1.camel@topicus6> Message-ID: <20031125154742.GA1426@devserv.devel.redhat.com> On Mon, Nov 24, 2003 at 09:07:42AM +0100, Klaasjan Brand wrote: > Search the list archives; I believe SMP was dropped from RH9 or Fedora > because it never was really popular for i586 (and didn't perform that > well too). You can build an i586 SMP kernel yourself... That's correct. We don't have any functional i586 SMP hardware that I'm aware of either. If it's just for one machine, it's probably best for Lamar to just rebuild the kernel for his machine (sorry, Lamar!), but if there are really a significant number of people who will not only use after release, but *test before release* on i586 SMP, then it's at least worth discussion of whether or not to re-enable it. (Part of the downside being forcing everyone to download those bits when they get the ISOs, and then we get to also argue about what other bits are being traded off the ISOs...) michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From notting at redhat.com Tue Nov 25 15:50:19 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 25 Nov 2003 10:50:19 -0500 Subject: kudzu won't update modprobe.conf In-Reply-To: <1069764083.2395.32.camel@D5E03FC5.kabel.telenet.be> References: <1069722088.3205.11.camel@D57729D5.kabel.telenet.be> <20031125031522.GA21828@devserv.devel.redhat.com> <1069764083.2395.32.camel@D5E03FC5.kabel.telenet.be> Message-ID: <20031125155019.GC24851@devserv.devel.redhat.com> lupus (de_lupus at pandora.be) said: > So my proposal is to generate hwconf when booting 2.4 and hwconf26 with > 2.6. So kudzu will chance /etc/modprobe.conf when hwconf26 has changed > or does not exist. What probably makes more sense is to re-migrate modules.conf itself on boot of 2.6 if the modules.conf is newer than the modprobe.conf. Bill From czar at czarc.net Tue Nov 25 16:20:14 2003 From: czar at czarc.net (Gene C.) Date: Tue, 25 Nov 2003 11:20:14 -0500 Subject: development access from up2date Message-ID: <200311251120.14517.czar@czarc.net> Since development (formally rawhide) seems to be moving along and I have a system that I do not mind trashing (if necessary), I thought I would try and access development from up2date. I edited /etc/sysconfig/rhn/sources and added: yum development http://download.fedora.redhat.com:/pub/fedora/linux/core/development/ (all on one line). When I ran up2date, I selected only the development channel ... up2date "hung". When I re-ran up2date from the command line, I get lots of traceback when it goes to access/download the headers.info file. Should this work? Is it a bug I should report? -- Gene From johnsonm at redhat.com Tue Nov 25 16:33:38 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 25 Nov 2003 11:33:38 -0500 Subject: ext2/3 acl in development In-Reply-To: <3FC35A98.4030401@bnap.hu> References: <3FC35A98.4030401@bnap.hu> Message-ID: <20031125163338.GB1426@devserv.devel.redhat.com> On Tue, Nov 25, 2003 at 02:35:20PM +0100, Farkas Levente wrote: > can we can wait an updated kernel package for FC1 or a development > package for FC2 in the near future? "a development package for FC2" meaning what specifically? The 2.6 kernel already has acls, and we have included the user-space package changes needed to use ACLs for the final few releases of Red Hat Linux as well as in Fedora Core 1. There is also a chance to get an ACL-enabled kernel for Fedora Core 1 at some point, though we don't want to slow down development for Fedora Core 2. Don't hold your breath, in other words. :-) michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From johnsonm at redhat.com Tue Nov 25 16:41:02 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 25 Nov 2003 11:41:02 -0500 Subject: OpenOffice.org and Java in Fedora In-Reply-To: <3FC32011.90201@israel-jugendtag.ch> References: <1069206029.1545.8.camel@ByteEnable> <1069712891.25450.6.camel@dhcp64-188.boston.redhat.com> <3FC32011.90201@israel-jugendtag.ch> Message-ID: <20031125164102.GA32550@devserv.devel.redhat.com> On Tue, Nov 25, 2003 at 10:25:37AM +0100, Roland K?ser wrote: > Can You exaclty describe whats the difficult therms in the Java licence? > And why it hinders to integrate Java to the Fedora Core? http://fedora.redhat.com/about/ "The goal of The Fedora Project is to work with the Linux community to build a complete, general purpose operating system exclusively from open source software." http://fedora.redhat.com/about/objectives.html "Build the operating system exclusively from open source software." Hope that helps, michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From stan at ccs.neu.edu Tue Nov 25 17:38:34 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Tue, 25 Nov 2003 12:38:34 -0500 Subject: evolution problems (filters) Message-ID: <1069781913.1269.183.camel@duergar> Hey, I've been having numerous problems with evolutions mail filters, and I was wondering if anyone else has had any problems with them. A couple of examples. I post to large mailing lists often, and so I get a lot of returned mail sometimes. I setup a filter to put returned mail in a folder named return mail. The filter is setup like this: if any criteria are met: Sender -> sounds like -> MAILER-DAEMON Subject -> contains -> delivery failure Subject -> contains -> undeliverable Subject -> contains -> delivery status notification Move to Folder -> Returned Mail Seems simple enough right? It works like a charm except all mail from Dave Jones (davej at redhat.com) ends up in Returned Mail. This despite the fact the mail is coming from different mailing lists all of which rules are above returned mail in the filters list. This is very strange because I get hundreds of messages a day and his e-mails are the only ones that do it. There is nothing remotely like MAILER-DAEMON in his mail headers so this is odd. Another problem is duplicating messages. For example, I subscribe to the Linux Kernel Mailing list. I have two filters for it, one that just moves all mail with the Mailing-List header linux-kernel to a linux-kernel folder. I filter certain people to a folder called trusted (for instance messages from Linus and Andrew so I can see when new test kernels are released). Evolution thinks its funny, to often times not put people's messages who should be going into trusted into linux-kernel (the trusted rule is above linux-kernel in the filter list), and not only this but sometime it copies the persons message into BOTH folders, and I've checked and rechecked and even gone over my filters.xml with a fine tooth comb, there are no logic errors in the filtering setup, so these have to be evolution bugs, right? I want to make sure these are bugs in evolution and not my own logic before I put anything on Bugzilla. Any thoughts? -sb -------------- 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 lowen at pari.edu Tue Nov 25 18:40:53 2003 From: lowen at pari.edu (Lamar Owen) Date: Tue, 25 Nov 2003 13:40:53 -0500 Subject: SMP i586? In-Reply-To: <20031125154742.GA1426@devserv.devel.redhat.com> References: <200311211715.43696.lowen@pari.edu> <1069661262.22934.1.camel@topicus6> <20031125154742.GA1426@devserv.devel.redhat.com> Message-ID: <200311251340.53890.lowen@pari.edu> On Tuesday 25 November 2003 10:47 am, Michael K. Johnson wrote: > On Mon, Nov 24, 2003 at 09:07:42AM +0100, Klaasjan Brand wrote: > > Search the list archives; I believe SMP was dropped from RH9 or Fedora > > because it never was really popular for i586 (and didn't perform that > > well too). You can build an i586 SMP kernel yourself... > That's correct. We don't have any functional i586 SMP hardware that > I'm aware of either. > If it's just for one machine, it's probably best for Lamar to just > rebuild the kernel for his machine (sorry, Lamar!), but if there are > really a significant number of people who will not only use after > release, but *test before release* on i586 SMP, then it's at least > worth discussion of whether or not to re-enable it. I was just curious as to the why. The fact that Red Hat has no SMP i586 hardware is enough for me. As to performance, it is better than the UP i586 kernel on this box. At 133MHz, every little bit helps. As far as building kernels, that's the easy part. Edit the configs, edit the spec file, issue a rpmbuild --target=i586 -ba kernel-2.4.spec and go away for awhile during the build. Then install the fresh kernel RPM's (which has a special release tag, of course), which automatically updates things. Well, at least it's supposed to, but this box doesn't do grub, it does lilo (GRUB locks the box during boot, but LILO boots right up -- but that's probably due to /boot being on a RAID). I have found that this is the most reliable, least trouble way for me at least to build a custom kernel. But, then again, I have maintained various RPM's for over four years, so this cycle is a familiar one. > (Part of the > downside being forcing everyone to download those bits when they > get the ISOs, and then we get to also argue about what other bits > are being traded off the ISOs...) You ain't a kiddin'.... -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From alan at redhat.com Tue Nov 25 18:42:45 2003 From: alan at redhat.com (Alan Cox) Date: Tue, 25 Nov 2003 13:42:45 -0500 Subject: can't see any chinese characters at all, mozilla crashes all the time In-Reply-To: References: Message-ID: <20031125184245.GA24345@devserv.devel.redhat.com> On Tue, Nov 25, 2003 at 04:48:49AM -0900, Lu Mudong wrote: > Could somebody please help? I am desperate. > > I upgraded from RH9 to Fedora days ago, since then, I can't read any > chinese, mozilla crashes on chinese website or sometimes even by only > typing "w", "x" in the address field, when open a chinese file, nothing is > readable in it. I changed the locale to chinese, then when I restart > X-window, all the letters(including english letters) become small > rectangles, I don't know much about changing locale, it took me a while to > find the configuation file and delete it. What font packages do you have installed ? From alan at redhat.com Tue Nov 25 18:45:13 2003 From: alan at redhat.com (Alan Cox) Date: Tue, 25 Nov 2003 13:45:13 -0500 Subject: SMP i586? In-Reply-To: <20031125154742.GA1426@devserv.devel.redhat.com> References: <200311211715.43696.lowen@pari.edu> <1069661262.22934.1.camel@topicus6> <20031125154742.GA1426@devserv.devel.redhat.com> Message-ID: <20031125184513.GB24345@devserv.devel.redhat.com> > > because it never was really popular for i586 (and didn't perform that > > well too). You can build an i586 SMP kernel yourself... > > That's correct. We don't have any functional i586 SMP hardware that > I'm aware of either. Davej should even if RH doesnt ;) From snookertb at comcast.net Tue Nov 25 18:50:38 2003 From: snookertb at comcast.net (ftpuser) Date: Tue, 25 Nov 2003 13:50:38 -0500 Subject: fstab problem with mount Message-ID: <3FC3A47E.8040300@comcast.net> I made a new partition on a 60GB drive that was the 4th primary partition on that drive. Added this line to /etc/fstab /dev/hda4 /pub ext3 auto,user,dev,exec,rw,async 0 0 I checked /etc/rc.d/rc.sysinit and the command is there to use 'mount -a' to mount the dir at boot. But it fails to do so. mounting it manually does work and the dir is rw accessible to all users, as I wanted. The permissions are set correctly. As root command line 'mount -a' also fails to mount the dir. I added a line mount /pub to /etc/rc.d/rc.local and the mount point is properly brought up and dir is useable for all users. But why doesn't 'mount -a' work at boot in the rc.sysinit script as I assume it should? Wrong assumption? Bug? dumb user? bill From jamesaharrisonuk at yahoo.co.uk Tue Nov 25 19:16:56 2003 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Tue, 25 Nov 2003 11:16:56 -0800 (PST) Subject: fstab problem with mount In-Reply-To: <3FC3A47E.8040300@comcast.net> Message-ID: <20031125191656.3708.qmail@web25105.mail.ukl.yahoo.com> >>auto,user,dev,exec,rw,async Instead of this try /dev/hda4 /pub ext3 defaults 0 0 --- ftpuser wrote: > I made a new partition on a 60GB drive that was the 4th primary > partition on that drive. > > Added this line to /etc/fstab > /dev/hda4 /pub ext3 > auto,user,dev,exec,rw,async 0 0 > > I checked /etc/rc.d/rc.sysinit and the command is there to use 'mount > -a' to mount the > dir at boot. But it fails to do so. mounting it manually does work and > the dir is rw > accessible to all users, as I wanted. The permissions are set correctly. > > As root command line 'mount -a' also fails to mount the dir. > > I added a line mount /pub to /etc/rc.d/rc.local and > the mount point is properly > brought up and dir is useable for all users. > > But why doesn't 'mount -a' work at boot in the rc.sysinit script as I > assume it should? > > Wrong assumption? Bug? dumb user? > > bill > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list ===== James Harrison __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ From xspace at slackpkg.ath.cx Tue Nov 25 19:40:34 2003 From: xspace at slackpkg.ath.cx (xspace) Date: Tue, 25 Nov 2003 20:40:34 +0100 Subject: remove me from the list !!!! Message-ID: <1069789234.1047.3.camel@slack.ath.cx> !!!!!!!!!!!!!!!!!!!!!!!!!!!! From ms-nospam-0306 at arcor.de Tue Nov 25 19:34:25 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 25 Nov 2003 20:34:25 +0100 Subject: yum tries to update gpgme03 with gpgme? In-Reply-To: <1069730521.3559.15.camel@binkley> References: <20031125015251.7ecc7c86.ms-nospam-0306@arcor.de> <1069730521.3559.15.camel@binkley> Message-ID: <20031125203425.714c49c4.ms-nospam-0306@arcor.de> https://bugzilla.fedora.us/show_bug.cgi?id=1059 -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From johnsonm at redhat.com Tue Nov 25 19:47:04 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 25 Nov 2003 14:47:04 -0500 Subject: can't see any chinese characters at all, mozilla crashes all the time In-Reply-To: <20031125184245.GA24345@devserv.devel.redhat.com> References: <20031125184245.GA24345@devserv.devel.redhat.com> Message-ID: <20031125194704.GA26359@devserv.devel.redhat.com> First of all, this is not a development mail, and so fedora-devel-list isn't the place to ask. That said, the answer is at: http://www.redhat.com/archives/fedora-announce-list/2003-November/msg00006.html Hint to everyone: subscribe to fedora-announce-list! :-) On Tue, Nov 25, 2003 at 01:42:45PM -0500, Alan Cox wrote: > On Tue, Nov 25, 2003 at 04:48:49AM -0900, Lu Mudong wrote: > > Could somebody please help? I am desperate. > > > > I upgraded from RH9 to Fedora days ago, since then, I can't read any > > chinese, mozilla crashes on chinese website or sometimes even by only > > typing "w", "x" in the address field, when open a chinese file, nothing is > > readable in it. I changed the locale to chinese, then when I restart > > X-window, all the letters(including english letters) become small > > rectangles, I don't know much about changing locale, it took me a while to > > find the configuation file and delete it. > > What font packages do you have installed ? michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From mhoneyfield at xtra.co.nz Tue Nov 25 20:02:00 2003 From: mhoneyfield at xtra.co.nz (Michael Honeyfield) Date: Wed, 26 Nov 2003 9:02:00 +1300 Subject: remove me from the list !!!! Message-ID: <20031125200200.KIIO16412.web2-rme.xtra.co.nz@[127.0.0.1]> Perhaps you should look here: > http://www.redhat.com/mailman/listinfo/fedora-devel-list Mike From pros-n-cons at bak.rr.com Tue Nov 25 20:19:08 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Tue, 25 Nov 2003 12:19:08 -0800 Subject: remove me from the list !!!! In-Reply-To: <1069789234.1047.3.camel@slack.ath.cx> References: <1069789234.1047.3.camel@slack.ath.cx> Message-ID: <20031125121908.3b12f6ff.pros-n-cons@bak.rr.com> On Tue, 25 Nov 2003 20:40:34 +0100 xspace wrote: > !!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list You see that line right above my text? click it and read the bottom.... From snookertb at comcast.net Tue Nov 25 20:48:37 2003 From: snookertb at comcast.net (snookertb) Date: Tue, 25 Nov 2003 15:48:37 -0500 Subject: fstab problem with mount In-Reply-To: <20031125191656.3708.qmail@web25105.mail.ukl.yahoo.com> References: <20031125191656.3708.qmail@web25105.mail.ukl.yahoo.com> Message-ID: <3FC3C025.8030804@comcast.net> James Harrison wrote: >>>auto,user,dev,exec,rw,async > > Instead of this try > > /dev/hda4 /pub ext3 defaults 0 0 I tried that at the beginning. I re-ran the boot cycle with the changes you suggested. Still no joy. With the 'defaults' setting I log in from a user account as root # mount /pub ... the files are visable and usable by the user as normal. But boot still does not initialize the mount automatically. stumped, any more ideas??? tb From jamesaharrisonuk at yahoo.co.uk Tue Nov 25 21:08:33 2003 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Tue, 25 Nov 2003 13:08:33 -0800 (PST) Subject: fstab problem with mount In-Reply-To: <3FC3C025.8030804@comcast.net> Message-ID: <20031125210833.30794.qmail@web25103.mail.ukl.yahoo.com> /dev/hda4 /pub ext3 defaults 0 0 try: /dev/hda4 /pub ext3 defaults 1 2 see man fstab --- snookertb wrote: > James Harrison wrote: > >>>auto,user,dev,exec,rw,async > > > > Instead of this try > > > > /dev/hda4 /pub ext3 defaults 0 0 > > I tried that at the beginning. I re-ran the boot cycle with the > changes you suggested. Still no joy. > > With the 'defaults' setting I log in from a user account as root > > # mount /pub > > ... the files are visable and usable by the user as normal. > > But boot still does not initialize the mount automatically. > > stumped, any more ideas??? > > tb > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list ===== James Harrison __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ From snookertb at comcast.net Tue Nov 25 21:57:12 2003 From: snookertb at comcast.net (snookertb) Date: Tue, 25 Nov 2003 16:57:12 -0500 Subject: fstab problem with mount In-Reply-To: <20031125210833.30794.qmail@web25103.mail.ukl.yahoo.com> References: <20031125210833.30794.qmail@web25103.mail.ukl.yahoo.com> Message-ID: <3FC3D038.9060200@comcast.net> James Harrison wrote: > /dev/hda4 /pub ext3 defaults 0 0 > > try: > /dev/hda4 /pub ext3 defaults 1 2 > > see > man fstab Ok, I have been man fstab and man 8 fstab 'ing for a while now. Still no joy. Question... Can the way the original filesystem was made be causing the problem? I went back and remade the filesystem as extended, but it didn't change anything. I can't see how the setup of the filesystem could be causing the problem once it works properly. I am at a loss as to what is wrong. tb From behdad at cs.toronto.edu Tue Nov 25 22:02:29 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 25 Nov 2003 17:02:29 -0500 Subject: fstab problem with mount In-Reply-To: <3FC3D038.9060200@comcast.net> References: <20031125210833.30794.qmail@web25103.mail.ukl.yahoo.com> <3FC3D038.9060200@comcast.net> Message-ID: On Tue, 25 Nov 2003, snookertb wrote: > James Harrison wrote: > > > /dev/hda4 /pub ext3 defaults 0 0 > > > > try: > > /dev/hda4 /pub ext3 defaults 1 2 > > > > see > > man fstab > > Ok, I have been man fstab and man 8 fstab 'ing for a while now. > > Still no joy. > > Question... Can the way the original filesystem was made be causing the > problem? I went back and remade the filesystem as extended, but it > didn't change anything. I can't see how the setup of the filesystem > could be causing the problem once it works properly. > > I am at a loss as to what is wrong. > > tb Do you have any other ext3 partitions there? Anything in logs? be From mudong at hotmail.com Tue Nov 25 22:49:56 2003 From: mudong at hotmail.com (Lu Mudong) Date: Tue, 25 Nov 2003 13:49:56 -0900 Subject: can't see any chinese characters at all, mozilla crashes all the time Message-ID: Alan: Thanks for asking, I installed english, chinese font packages, I believe I have the right packages installed, it's just the system can't find them. Michael: I checked the announce list, it didn't help. I also searched all over the internet for several days, nothing helps. my problem is that I can't read chinese at all in KDE, not only mozilla's problem. So I figured that could be a development problem. Mudong >From: "Michael K. Johnson" >Reply-To: fedora-devel-list at redhat.com >To: fedora-devel-list at redhat.com >Subject: Re: can't see any chinese characters at all, mozilla crashes all >the time >Date: Tue, 25 Nov 2003 14:47:04 -0500 > >First of all, this is not a development mail, and so fedora-devel-list >isn't the place to ask. That said, the answer is at: >http://www.redhat.com/archives/fedora-announce-list/2003-November/msg00006.html > >Hint to everyone: subscribe to fedora-announce-list! :-) > >On Tue, Nov 25, 2003 at 01:42:45PM -0500, Alan Cox wrote: > > On Tue, Nov 25, 2003 at 04:48:49AM -0900, Lu Mudong wrote: > > > Could somebody please help? I am desperate. > > > > > > I upgraded from RH9 to Fedora days ago, since then, I can't read any > > > chinese, mozilla crashes on chinese website or sometimes even by only > > > typing "w", "x" in the address field, when open a chinese file, >nothing is > > > readable in it. I changed the locale to chinese, then when I restart > > > X-window, all the letters(including english letters) become small > > > rectangles, I don't know much about changing locale, it took me a >while to > > > find the configuation file and delete it. > > > > What font packages do you have installed ? > >michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list _________________________________________________________________ Need a shot of Hank Williams or Patsy Cline? The classic country stars are always singing on MSN Radio Plus. Try one month free! http://join.msn.com/?page=offers/premiumradio From roland at redhat.com Tue Nov 25 23:26:01 2003 From: roland at redhat.com (Roland McGrath) Date: Tue, 25 Nov 2003 15:26:01 -0800 Subject: Executable memory: further programs that fail In-Reply-To: Tim Daly's message of Tuesday, 25 November 2003 09:10:55 -0500 <200311251410.hAPEAtn27388@rio.sci.ccny.cuny.edu> Message-ID: <200311252326.hAPNQ1dp015952@magilla.sf.frob.com> > Yes, you've explained that there is a long-way-around method > to tell the linker that I want free space reserved. Yes, > that is sufficient for my needs. It is also painful to implement. Indeed it is somewhat of a nuisance to produce a PT_LOAD segment with no protection bits set so that you get the effect of a PROT_NONE mapping that you can overwrite later. However, it is trivial to just have a huge bss that you can remap later. The only difference is that before you do any mmap or mprotect calls to set up that area how you want it, you will have zero-fill pages if you touch there instead of faulting if you touch there, and that it will always be at the end of your data segment instead of being able to use disjoint parts of the address space. Since what you do now is to rely on large brk allocations, I imagine you won't mind those issues since preallocating huge amounts of bss is exactly equivalent to that. Also, as both Ingo and I have already said, you can reasonably expect quite large contiguous mmaps to work (in fact, larger than with traditional Linux layout when using shared libraries and a normal ELF executable). That is quite a different thing from presuming ahead of time exactly what addresses they might return. > Clearly such a pervasive and intrusive change to the expected unix memory > model has a strong justification based on improving security. The difficulty I'm having in trying to have a constructive discussion with you is the assumption embodied in this statement. If you are talking about the detached brk area, I've already said that I consider that a change in the specified Unix memory model--yet it's hardly "pervasive", it's exactly one thing. But I think you are in fact talking about the randomization of mmap address allocations. In that regard, there is absolutely zero change to the "expected Unix memory model"--as long as there has been mmap, the specification has been that you cannot rely on the addresses it will give you in any particular regard, and that the expectation of being able to mmap very large contiguous regions is an entirely reasonable demand on the quality of implementation but by no means accomplished through application presumption of address space layout. I have said all of this before, but you seem to have ignored it without even an attempt at refutation. > If I've found a way to take control of your machine by some exploit how > does randomly placing shared libraries keep your computer secure? That question is not germane--its antecedent removes it from the set of cases any of us has raised in discussion. In the context where some exploit has already succeeded in taking over a process, then obviously it is irrelevant what measures that process might earlier have taken to avoid an exploit succeeding in taking over. (Similarly, "A implies A" is a true statement.) Ingo has documented the kinds of exploits that the randomization of mapping addresses prevents. Noone suggests that it does much of anything for security other than to prevent these particular modes of exploit. If you have not found Ingo's write-ups or they have not adequately explained the exploit attempts thwarted by the exec-shield changes, then we will endeavor to better document the rationale. From yshao at redhat.com Wed Nov 26 00:19:02 2003 From: yshao at redhat.com (Yu Shao) Date: Wed, 26 Nov 2003 10:19:02 +1000 Subject: can't see any chinese characters at all, mozilla crashes all the time References: Message-ID: <3FC3F176.20602@redhat.com> Can you try this: #cd /usr/share/fonts/zh_CN/TrueType #rm fonts.cache-1 #fc-cache Or the latest mozilla-1.4.1-18 which is avaliable from here: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/1/ If you want to change locale, please use redhat-config-language. Yu Shao Lu Mudong wrote: > Alan: > > Thanks for asking, I installed english, chinese font packages, I > believe I have the right packages installed, it's just the system > can't find them. > > > Michael: > > I checked the announce list, it didn't help. I also searched all over > the internet for several days, nothing helps. my problem is that I > can't read chinese at all in KDE, not only mozilla's problem. So I > figured that could be a development problem. > > Mudong > > >> From: "Michael K. Johnson" >> Reply-To: fedora-devel-list at redhat.com >> To: fedora-devel-list at redhat.com >> Subject: Re: can't see any chinese characters at all, mozilla crashes >> all the time >> Date: Tue, 25 Nov 2003 14:47:04 -0500 >> >> First of all, this is not a development mail, and so fedora-devel-list >> isn't the place to ask. That said, the answer is at: >> http://www.redhat.com/archives/fedora-announce-list/2003-November/msg00006.html >> >> >> Hint to everyone: subscribe to fedora-announce-list! :-) >> >> On Tue, Nov 25, 2003 at 01:42:45PM -0500, Alan Cox wrote: >> > On Tue, Nov 25, 2003 at 04:48:49AM -0900, Lu Mudong wrote: >> > > Could somebody please help? I am desperate. >> > > >> > > I upgraded from RH9 to Fedora days ago, since then, I can't read any >> > > chinese, mozilla crashes on chinese website or sometimes even by >> only >> > > typing "w", "x" in the address field, when open a chinese file, >> nothing is >> > > readable in it. I changed the locale to chinese, then when I restart >> > > X-window, all the letters(including english letters) become small >> > > rectangles, I don't know much about changing locale, it took me a >> while to >> > > find the configuation file and delete it. >> > >> > What font packages do you have installed ? >> >> michaelkjohnson >> >> "He that composes himself is wiser than he that composes a book." >> Linux Application Development -- Ben Franklin >> http://people.redhat.com/johnsonm/lad/ >> >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > _________________________________________________________________ > Need a shot of Hank Williams or Patsy Cline? The classic country > stars are always singing on MSN Radio Plus. Try one month free! > http://join.msn.com/?page=offers/premiumradio > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From fedora-devel-list at cygnusx-1.org Wed Nov 26 04:23:36 2003 From: fedora-devel-list at cygnusx-1.org (Nathan G. Grennan) Date: Tue, 25 Nov 2003 20:23:36 -0800 Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm Message-ID: <1069820616.13740.10.camel@proton.cygnusx-1.org> I don't like the idea of adding the FC1 tag to future updates, and would love to see this update get replaced with an untagged version. Anyone have any information or comments on this? From redhat-forums at genesis-x.nildram.co.uk Wed Nov 26 05:27:30 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Wed, 26 Nov 2003 05:27:30 +0000 Subject: Tripwire - new release, new name (2.3.1-18.fdr.1) and bug fixes Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What's new: Fixed missing source file (Paul Herman's tw-20030919.patch). Fixed every (sensible) error revealed by rpmlint. Release name change to conform to Package Submission rules. Packages are really signed now ... honest. For more details, see https://bugzilla.fedora.us/show_bug.cgi?id=1058 New files now located at: http://www.genesis-x.nildram.co.uk/filez/tripwire-2.3.1-18.fdr.1.src.rpm http://www.genesis-x.nildram.co.uk/filez/tripwire-2.3.1-18.fdr.1.i386.rpm http://www.genesis-x.nildram.co.uk/filez/tripwire-2.3.1-18.fdr.1.i686.rpm http://www.genesis-x.nildram.co.uk/filez/md5sum http://www.genesis-x.nildram.co.uk/filez/GENESIS-RPM-KEY.asc Keith G. Robertson-Turner tripwire-devel at genesis-x.nildram.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/xDl02XoLj+pGfn8RAg3VAJ4lEIHYO7+2/OPkb7T5FrNbxD2rjQCdFRNV MPvYyg3LkWuquqSQ1g3fH0I= =xWxd -----END PGP SIGNATURE----- From tmus at get2net.dk Wed Nov 26 05:40:38 2003 From: tmus at get2net.dk (Thomas Munck Steenholdt) Date: Wed, 26 Nov 2003 06:40:38 +0100 (CET) Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm In-Reply-To: <1069820616.13740.10.camel@proton.cygnusx-1.org> References: <1069820616.13740.10.camel@proton.cygnusx-1.org> Message-ID: <51005.32.97.110.70.1069825238.squirrel@www.tmus.dk> > I don't like the idea of adding the FC1 tag to future updates, and > would love to see this update get replaced with an untagged version. > > Anyone have any information or comments on this? > I don't personally see the big deal here... And it makes sense to label binary packages, since there is a good chance it won't run on say RHL7.3... Not too much different from RHL packages being labeled with 9 and such... Anyways - Just my 5 cents worth of thoughts! Rgds Thomas From petersen at redhat.com Wed Nov 26 06:07:58 2003 From: petersen at redhat.com (Jens Petersen) Date: Wed, 26 Nov 2003 15:07:58 +0900 Subject: automake-1.7d beta test rpm available In-Reply-To: References: Message-ID: >>>>> "juhp" == Jens Petersen writes: juhp> I put a rpm of the 2nd Automake 1.8 beta test juhp> release up for anyone who would like to give it a juhp> spin to test: juhp> http://people.redhat.com/petersen/?M=D A package of the third beta ("rc1") automake-1.7f-0.1, is there now. Jens From sr at stephenreindl.de Wed Nov 26 07:18:08 2003 From: sr at stephenreindl.de (Stephen Reindl) Date: Wed, 26 Nov 2003 08:18:08 +0100 (CET) Subject: changelog display in up2date/yum Message-ID: <40204.195.233.250.7.1069831088.squirrel@sreindl.dyndns.org> Hi all, it would be a nice feature to see the changes in a package before the package is updated. A feature like this is available for Debian (but there you get a mail at the time you install the packages). My idea is to give the user the chance to decide by reading the changes of a package if the update is needed or not. Regards Stephen -- Stephen Reindl sr at stephenreindl.de From Axel.Thimm at physik.fu-berlin.de Wed Nov 26 07:44:37 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 26 Nov 2003 08:44:37 +0100 Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm In-Reply-To: <1069820616.13740.10.camel@proton.cygnusx-1.org> References: <1069820616.13740.10.camel@proton.cygnusx-1.org> Message-ID: <20031126074437.GD7622@puariko.nirvana> On Tue, Nov 25, 2003 at 08:23:36PM -0800, Nathan G. Grennan wrote: > I don't like the idea of adding the FC1 tag to future updates, and > would love to see this update get replaced with an untagged version. Tags are good for identification and enforcing upgrade paths for concurrent builds (e.g. the second build of ethereal 0.9.16 for both rh9, fc1, etc.). But tags need to be standardized, and there was a looong and mostly neglected thread (End. of Sep. - Beginning of Nov.) about disttags but finally coming up with the fine solution of rh7.3 < rh8.0 < rh9 < rhfc1 currently employed by many 3rd party repos with concurrent builds (drop the tag, if the package is really the same for all dists including the dependencies). > Anyone have any information or comments on this? Search the mentioned thread above ("retaining upgrade paths", "disttags") and weep ... -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nos at utel.no Wed Nov 26 08:33:18 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Wed, 26 Nov 2003 09:33:18 +0100 Subject: evolution problems (filters) In-Reply-To: <44b8697d02040f07d3@[192.168.170.10]> References: <44b8697d02040f07d3@[192.168.170.10]> Message-ID: <47f55aa703046007d3@[192.168.170.10]> On Tue, 2003-11-25 at 18:38, Stan Bubrouski wrote: > Another problem is duplicating messages. For example, I subscribe to > the Linux Kernel Mailing list. I have two filters for it, one that just > moves all mail with the Mailing-List header linux-kernel to a > linux-kernel folder. I filter certain people to a folder called trusted > (for instance messages from Linus and Andrew so I can see when new test > kernels are released). Evolution thinks its funny, to often times not > put people's messages who should be going into trusted into linux-kernel > (the trusted rule is above linux-kernel in the filter list), and not > only this but sometime it copies the persons message into BOTH folders, > and I've checked and rechecked and even gone over my filters.xml with a > fine tooth comb, there are no logic errors in the filtering setup, so > these have to be evolution bugs, right? Be sure you have a "Stop Processing" rule after your "Move Message to .." or similar. If you don't have that, the message will be matched against several rules, and potentionally copied for each match. -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From dag at wieers.com Wed Nov 26 08:59:43 2003 From: dag at wieers.com (Dag Wieers) Date: Wed, 26 Nov 2003 09:59:43 +0100 (CET) Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm In-Reply-To: <20031126074437.GD7622@puariko.nirvana> Message-ID: On Wed, 26 Nov 2003, Axel Thimm wrote: > On Tue, Nov 25, 2003 at 08:23:36PM -0800, Nathan G. Grennan wrote: > > I don't like the idea of adding the FC1 tag to future updates, and > > would love to see this update get replaced with an untagged version. > > Tags are good for identification and enforcing upgrade paths for > concurrent builds (e.g. the second build of ethereal 0.9.16 for both > rh9, fc1, etc.). Axel is right. If tags existed from the beginning (since RPM's inception) there wouldn't have been this 'DEB is better than RPM' or 'RPM is responsible for dependency problems' misconceptions. (Functionally there's really little difference between RPM and DEB) People would have sticked to packages build for their system and would have known/seen that using (tagged) SuSE packages on Red Hat would consistently show problems where proper packages wouldn't. Of course tags have little meaning if you're using apt. But still it is nice to do a rpm -qa | grep .rh9. | sort Just to see what left-over packages are installed. (You can't do this on a clean upgraded Red Hat system ! You have to look at build-dates to determine something and even then...) It would also be nice to have this information redundantly stored in an RPM header (Distribution-tag ?) in a standardized way. So that a package built to work for multiple distributions just has a list of these distro's inside. For the same reason repo-tags are important to know where to complain when you have problems. Of course this information is also inside the package, still it's nice to tell in advance or without having to look inside the package. (Similarly as for the architecture-tag and the version-tag ;-)) Remember when SuSE removed these tags from their packages. A nightmare ! -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dag at wieers.com Wed Nov 26 09:10:28 2003 From: dag at wieers.com (Dag Wieers) Date: Wed, 26 Nov 2003 10:10:28 +0100 (CET) Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm In-Reply-To: <20031126074437.GD7622@puariko.nirvana> Message-ID: On Wed, 26 Nov 2003, Axel Thimm wrote: > But tags need to be standardized, and there was a looong and mostly > neglected thread (End. of Sep. - Beginning of Nov.) about disttags > but finally coming up with the fine solution of > > rh7.3 < rh8.0 < rh9 < rhfc1 Or because of backward compatibility: rh73 < rh80 < rh90 < rhfc1 < rhfc1.1 < rhfc1.2 rh72 < rhas2.1 < rhel3 < rhel3.1 rh73 < rh80 < rh90 < rhel3 < rhel3.1 Depending on the situation. ;) Thanks Axel ! -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From tony at tgds.net Wed Nov 26 09:10:30 2003 From: tony at tgds.net (tony) Date: Wed, 26 Nov 2003 10:10:30 +0100 Subject: evolution problems (filters) In-Reply-To: <47f55aa703046007d3@[192.168.170.10]> References: <44b8697d02040f07d3@[192.168.170.10]> <47f55aa703046007d3@[192.168.170.10]> Message-ID: <1069837830.5086.38.camel@localhost.localdomain> Le mer 26/11/2003 ? 09:33, =?ISO-8859-1?Q? Nils O. Sel=E5sdal?= a ?crit : > Be sure you have a "Stop Processing" rule after your "Move Message to > .." or similar. If you don't have that, the message will be matched > against several rules, and potentionally copied for each match. Yes! I use spammassasin as a local filter and it wasn't working before I added that line. I am now a happy bunny with only about 2% of spam getting through and 1 false positive (Wired newsletter) in 5 days. I have found that if the filters don't work then it is I who have done something wrong. Cheers Tony Grant -- WWW.tgds.net | Logiciels de gestion de centre d'art | H?bergement de bases de donn?es en ligne | hush - ordinateurs silencieux pour biblioth?ques, documentations et bureaux From nos at utel.no Wed Nov 26 08:59:10 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Wed, 26 Nov 2003 09:59:10 +0100 Subject: evolution problems (filters) In-Reply-To: <480b040203046807d3@[192.168.170.10]> References: <44b8697d02040f07d3@[192.168.170.10]><47f55aa703046007d3@[192.168.170.10]> <480b040203046807d3@[192.168.170.10]> Message-ID: <480cfb8203046a07d3@[192.168.170.10]> On Wed, 2003-11-26 at 10:10, tony wrote: > Le mer 26/11/2003 ? 09:33, =?ISO-8859-1?Q? Nils O. Sel=E5sdal?= a > ?crit : > > > Be sure you have a "Stop Processing" rule after your "Move Message to > > .." or similar. If you don't have that, the message will be matched > > against several rules, and potentionally copied for each match. > > Yes! I use spammassasin as a local filter and it wasn't working before I > added that line. I am now a happy bunny with only about 2% of spam > getting through and 1 false positive (Wired newsletter) in 5 days. > You should have read http://utelsystems.dyndns.org/articles/evo-spam/evo-spamassassin.html ;-) Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From baldrick at terra.es Wed Nov 26 09:53:26 2003 From: baldrick at terra.es (Josep Puigdemont) Date: Wed, 26 Nov 2003 10:53:26 +0100 Subject: Translation project -- Catalan Message-ID: <1069840406.695.231.camel@deimos> Hi!! I have recently joined Fedora's translation project, and would like to start working on the translation to the Catalan language. I hope I am not posting to the wrong list (should I post at i18n at redhat.com?), if I do, please tell me and accept my apologies :) I have some questions: I've got CVS access, checked out "translate" module, and reviewed. Now, Catalan is a new language (there is no ca.po for any application), so to start with anaconda, for instance, I created it using msginit like this: $ msginit --locale=ca -i anaconda.pot Is that how you would normally do it? Then, once the file is translated, do I have rights to commit (and thus add a new file) into the repository, or is there someone coordinating the translation efforts that should do it? Shall I file a RFE requesting the addition of a new language, maybe? If it exists a FAQ or documentation about this, let me know! Thanks, Josep P.S.: If there are subscribers here that would like to help to translate Fedora into catalan, we're going to coordinate from http://www.softcatala.org/llistes/ (list "Fedora"). From mitr at volny.cz Wed Nov 26 10:03:32 2003 From: mitr at volny.cz (Miloslav Trmac) Date: Wed, 26 Nov 2003 11:03:32 +0100 Subject: Translation project -- Catalan In-Reply-To: <1069840406.695.231.camel@deimos> References: <1069840406.695.231.camel@deimos> Message-ID: <20031126100332.GB18366@popelka.ms.mff.cuni.cz> Hello, On Wed, Nov 26, 2003 at 10:53:26AM +0100, Josep Puigdemont wrote: > Then, once the file is translated, do I have rights to commit (and thus > add a new file) into the repository, or is there someone coordinating > the translation efforts that should do it? Shall I file a RFE requesting > the addition of a new language, maybe? You got the CVS access precisely so you could commit your work. Try it (: Mirek From hugo at devin.com.br Wed Nov 26 10:46:33 2003 From: hugo at devin.com.br (Hugo Cisneiros) Date: Wed, 26 Nov 2003 07:46:33 -0300 Subject: Translation project -- Catalan In-Reply-To: <1069840406.695.231.camel@deimos> References: <1069840406.695.231.camel@deimos> Message-ID: <3FC48489.3080205@devin.com.br> Josep Puigdemont wrote: > Hi!! > > I have recently joined Fedora's translation project, and would like to > start working on the translation to the Catalan language. > > I hope I am not posting to the wrong list (should I post at > i18n at redhat.com?), if I do, please tell me and accept my apologies :) Use the list fedora-docs for the translation too :) Many people who do translations are there. > Thanks, > Josep []'s Hugo From roli at israel-jugendtag.ch Wed Nov 26 11:18:08 2003 From: roli at israel-jugendtag.ch (=?ISO-8859-1?Q?Roland_K=E4ser?=) Date: Wed, 26 Nov 2003 12:18:08 +0100 Subject: FC2 and general LDAP Support Message-ID: <3FC48BF0.60005@israel-jugendtag.ch> Hi all What about moving the user database to LDAP for the FC2 release? It would be possible to integrate also the samba part of the user records directly to the LDAP directory. The only thing we need is a useful ldap administration frontend and the command line tools for creating and modifying the user records from the command line. The most of the command line tools are shipped with the samba source code. It it is desired, i can make a RPM for that. Greetings Roland -- Roland K?ser Bocksrietstr. 54 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch From ralph+fedora at strg-alt-entf.org Wed Nov 26 11:36:15 2003 From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt) Date: Wed, 26 Nov 2003 12:36:15 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <3FC48BF0.60005@israel-jugendtag.ch> References: <3FC48BF0.60005@israel-jugendtag.ch> Message-ID: <20031126113615.GN28476@localhorst.br.de> Roland K?ser wrote: > Hi all > > What about moving the user database to LDAP for the FC2 release? In general? Yikes! There's home users using Fedora, why throw LDAP unto them - there's another daemon which has to run and be secured. Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nos at utel.no Wed Nov 26 11:17:16 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Wed, 26 Nov 2003 12:17:16 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <487bd5ee03048b07d3@[192.168.170.10]> References: <487bd5ee03048b07d3@[192.168.170.10]> Message-ID: <488b6a5203048f07d3@[192.168.170.10]> On Wed, 2003-11-26 at 12:18, =?ISO-8859-1?Q?Roland K=E4ser?= wrote: > Hi all > > What about moving the user database to LDAP for the FC2 release? It > would be possible to integrate also the samba part of the user records > directly to the LDAP directory. The only thing we need is a useful ldap > administration frontend and the command line tools for creating and > modifying the user records from the command line. The most of the > command line tools are shipped with the samba source code. It it is > desired, i can make a RPM for that. While I'm all for LDAP(and kerberos for that matter) for authentication and user information , moving the standard user database to ldap would be very unneeded for the common home user. I'd very much like to see a fullu featured ldap administration console thoug, with specific tools for unix account management and similar. (gq is to general) -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From roli at israel-jugendtag.ch Wed Nov 26 12:23:04 2003 From: roli at israel-jugendtag.ch (=?ISO-8859-1?Q?Roland_K=E4ser?=) Date: Wed, 26 Nov 2003 13:23:04 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <20031126113615.GN28476@localhorst.br.de> References: <3FC48BF0.60005@israel-jugendtag.ch> <20031126113615.GN28476@localhorst.br.de> Message-ID: <3FC49B28.7020308@israel-jugendtag.ch> Hi Whats wrong with the home users? You can bind the ldap server only to the localhost device. And if all the command line tools are customized for that, it would not make any changes for the home users. They can just create, modify and delete users as the normal passwd database. But it would get many advantages for the professional users and the network administrators. Think about all the other "operating systems" which have user directory support. There are many other possibilities for future releases such as saving the bind (DNS) structure inside the ldap, hosting the printers information from cups in the ldap, mail routing information for postfix and courier etc. This main ldap infrastructure would be a big improvement to the distribution. And there are many other daemons which running on a "normal" system, one more whould doesn't matter. Roland Ralph Angenendt schrieb: >Roland K?ser wrote: > > >>Hi all >> >>What about moving the user database to LDAP for the FC2 release? >> >> > >In general? Yikes! There's home users using Fedora, why throw LDAP unto >them - there's another daemon which has to run and be secured. > >Ralph > > -- Roland K?ser Bocksrietstr. 54 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch From nos at utel.no Wed Nov 26 12:21:33 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Wed, 26 Nov 2003 13:21:33 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <48b840d20304a007d3@[192.168.170.10]> References: <3FC48BF0.60005@israel-jugendtag.ch><20031126113615.GN28476@localhorst.br.de><48b840d20304a007d3@[192.168.170.10]> Message-ID: <48c63b2b0304a307d3@[192.168.170.10]> On Wed, 2003-11-26 at 13:23, =?ISO-8859-1?Q?Roland K=E4ser?= wrote: > Hi > > Whats wrong with the home users? You can bind the ldap server only to > the localhost device. And if all the command line tools are customized > for that, it would not make any changes for the home users. They can > just create, modify and delete users as the normal passwd database. But > it would get many advantages for the professional users and the network > administrators. Think about all the other "operating systems" which have > user directory support. There are many other possibilities for future > releases such as saving the bind (DNS) structure inside the ldap, > hosting the printers information from cups in the ldap, mail routing > information for postfix and courier etc. This main ldap infrastructure > would be a big improvement to the distribution. And there are many other > daemons which running on a "normal" system, one more whould doesn't matter. Point is this is not needed and might complicates things for the majority of users. The name service switch makes it very easy for those that want to use ldap. What is perhaps needed is a gui for the ldap migration scripts, and ofcourse a good administration console. If you need to administrate a networked LDAP server, that is rather diffrent from managing local users/groups, though if one only wants user group management, it shouldn't be that hard making a unified administrator appliation based on e.g. libuser(if not already done..) -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From gauret at free.fr Wed Nov 26 13:08:51 2003 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 26 Nov 2003 14:08:51 +0100 Subject: FC2 and general LDAP Support References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> Message-ID: > I'd very much like to see a fullu featured ldap administration console > thoug, with specific tools for unix account management and similar. (gq > is to general) You might want to have a look at : https://bugzilla.fedora.us/show_bug.cgi?id=499 Bye, Aurelien -- http://gauret.free.fr From nos at utel.no Wed Nov 26 13:09:02 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Wed, 26 Nov 2003 14:09:02 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <48e20ffc0304ad07d3@[192.168.170.10]> References: <487bd5ee03048b07d3@[192.168.170.10]><488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> Message-ID: <48f1bc280304b207d3@[192.168.170.10]> On Wed, 2003-11-26 at 14:08, Aurelien Bompard wrote: > > I'd very much like to see a fullu featured ldap administration console > > thoug, with specific tools for unix account management and similar. (gq > > is to general) > > You might want to have a look at : > https://bugzilla.fedora.us/show_bug.cgi?id=499 ... which is to narrow again ;) Atleast the last time I tried it, it did only users and groups. A fully featured administrator app should do what gq does, but have specialized features, like e.g. the app in question here, initialization wizards for setting up the ldap server, etc. -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From roli at israel-jugendtag.ch Wed Nov 26 14:24:54 2003 From: roli at israel-jugendtag.ch (=?ISO-8859-1?Q?Roland_K=E4ser?=) Date: Wed, 26 Nov 2003 15:24:54 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <48f1bc280304b207d3@[192.168.170.10]> References: <487bd5ee03048b07d3@[192.168.170.10]><488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> Message-ID: <3FC4B7B6.8060800@israel-jugendtag.ch> Yeah but what i ment is that fc2 should come with a fully initialized ldap server. It's also possible that in a first step only the users and groups are saved in the ldap. As i said in the first mail, Samba ships command line tools for adding, modifying and deleting users from a bash shell. The only thing needed to change is to replace the "normal" useradd, usermod, userdel, groupadd, groupmod and groupdel by the ones shipped with samba. For the normal user it wouldn't make any changes in the "feeling" of the administration. From my point of view, a GUI admin tool doesn't needs to support all the complete ldap features, it should only be a easy to use administration interface - excuse this analogy - like the active directory frontend. Roland Nils O. Sel?sdal schrieb: >On Wed, 2003-11-26 at 14:08, Aurelien Bompard wrote: > > >>>I'd very much like to see a fullu featured ldap administration console >>>thoug, with specific tools for unix account management and similar. (gq >>>is to general) >>> >>> >>You might want to have a look at : >>https://bugzilla.fedora.us/show_bug.cgi?id=499 >> >> >... which is to narrow again ;) Atleast the last time I tried it, it >did only users and groups. >A fully featured administrator app should do what gq does, but have >specialized features, like e.g. the app in question here, initialization >wizards for setting up the ldap server, etc. > > > -- Roland K?ser Bocksrietstr. 54 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch From jspaleta at princeton.edu Wed Nov 26 14:25:16 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 26 Nov 2003 09:25:16 -0500 Subject: Bug Day 7: Nov 26,2003: -Imagine something clever relating Thanksgiving to bughunting here- Message-ID: <1069856716.28813.14.camel@spatula.pppl.gov> It's the day before Thanksgiving, what's a better way to work up an appetite for 40 lbs worthy of deep fried turkey meat than with some quality QA? Trick question...there is nothing better! For lack of something original and because the need is still as great as it was last time, I hereby deem today's bug day theme to be Fedora.us QA. Become involved in the fedora.us QA process and help QA packages that are waiting to be published in the fedora.us addon repo: http://www.fedora.us/QA. There are 279 packages sitting waiting for QA. That's 279 packages the Fedora community could be enjoying in the published fedora.us repository trees, once they have made it through the community QA process. Remember, until the full merge is completed and Fedora Extras and Alternatives is up and running...community packagers are being advised to use fedora.us's process: http://www.redhat.com/archives/fedora-devel-list/2003-November/msg00649.html How do you become involved in the fedora.us QA process? Easy, read: http://www.fedora.us/wiki/PackageSubmissionQAPolicy I think there are enough people in the freenode irc network's #fedora-bugs channel who are already part of the fedora.us QA wagon train to provide some guidance if you are new to the process (hint hint hint, that means if you ARE part of the fedora.us QA process right now, it might be in your best interests to sit in the channel and gingerly help new people getting started in this process as part of the bug day call to arms) -jef"yeah i know I need to send these emails out on mondays"spaleta From buildsys at porkchop.devel.redhat.com Wed Nov 26 14:37:44 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Wed, 26 Nov 2003 09:37:44 -0500 Subject: rawhide report: 20031126 changes Message-ID: <200311261437.hAQEbi620303@porkchop.devel.redhat.com> New package gcc-ssa Various compilers (C, C++, Objective-C, Java, ...) (GCC SSA snapshot) New package system-switch-mail The Mail Transport Agent Switcher Updated Packages: SDL-1.2.6-2 ----------- * Tue Nov 25 2003 Thomas Woerner 1.2.6-2 - removed rpath - using O3 instead of O2, now (SDL_RLEaccel.c compile error) - added BuildRequires for nasm * Tue Sep 02 2003 Thomas Woerner 1.2.6-1 - new version 1.2.6 arts-1.1.93-0.2 --------------- * Tue Nov 25 2003 Than Ngo 8:1.1.93-0.2 - enable support alsa cups-1.1.19-15 -------------- * Tue Nov 25 2003 Thomas Woerner 1:1.1.19-15 - no rpath in cups-config anymore ethereal-0.9.16-3 ----------------- * Tue Nov 25 2003 Phil Knirsch 0.9.16-3 - Added BuildRequires for elfutils-devel (#89466). - Fixed buggy desktop entry (#105704). - Fixed out of bound array access (#110749). kdeartwork-3.1.93-0.1 --------------------- * Wed Nov 12 2003 Than Ngo 3.1.93-0.1 - KDE 3.2 Beta1 - cleanup kdegames-3.1.93-0.1 ------------------- * Tue Nov 11 2003 Than Ngo 6:3.1.93-0.1 - KDE 3.2 Beta1 - cleanup specfile - remove some patch files, which are included in new upstream kdemultimedia-3.1.93-0.1 ------------------------ * Tue Nov 11 2003 Than Ngo 6:3.1.93-0.1 - 3.1.93 (KDE 3.2 Beta1) - cleanup rpm file list kdenetwork-3.1.93-0.2 --------------------- * Tue Nov 25 2003 Than Ngo 7:3.1.93-0.2 - fixed link problem with ssl * Mon Nov 10 2003 Than Ngo 7:3.1.93-0.1 - KDE 3.2 Beta1 - cleaned up rpm file list kdepim-3.1.93-0.1 ----------------- * Thu Nov 13 2003 Than Ngo 6:3.1.93-0.1 - KDE 3.2 Beta1 - cleanup kdetoys-3.1.93-0.1 ------------------ * Wed Nov 12 2003 Than Ngo 7:3.1.93-0.1 - KDE 3.2 Beta1 - cleanup specfile - remove some unneeded patch files kdeutils-3.1.93-0.1 ------------------- * Wed Nov 12 2003 Than Ngo 6:3.1.93-0.1 - KDE 3.2 Beta1 - cleanup specfile kdevelop-3.0.0b1-0.1 -------------------- * Thu Nov 13 2003 Than Ngo 8:3.0.0b1-0.1 - 3.0.0 Beta1 - po files moved in kde-i18n - cleanup * Tue Oct 21 2003 Florian La Roche - add a %clean specfile target lv-4.50-1 --------- * Tue Nov 25 2003 Akira TAGOH 4.50-1 - New upstream release. here is this release of note. - [4.49.5.a] - Added ISO-8859-10,11,13,14,15,16. - Changed coding system names for '=' key. - [4.49.5.b] - Updated KSX1001 <-> Unicode mapping table. - [4.49.5.c] - Input coding detection improved. - -D option now specifies default (fall-back) coding system, not default EUC coding system. - Output coding detection based on LC_CTYPE locale. - [4.49.5.d] - Checks $EDITOR and $VISUAL variables when invoking an editor. - [4.49.5.f] - Initialize file->used[] in FileAttach() in file.c to avoid segfault in lgrep. - [4.5.0] - added polling function for regular files with slightly modified patch from Pawel S. Veselov . - enabled itable cache. - Big5 to Unicode mapping didn't work at all (fixed offset of coding system table) (See http://lists.debian.or.jp/debian-devel/200311/msg00006.html) - fixed editor call not to return by SIGINT unexpectedly. pciutils-2.1.11-3 ----------------- * Tue Nov 25 2003 Bill Nottingham 2.1.11-3 - remove a few calls to ->error() in the sysfs code policycoreutils-1.2-9 --------------------- * Tue Nov 25 2003 Dan Walsh 1.2-9 - Change run_init.console to run as run_init_t quanta-3.1.93-0.2 ----------------- * Tue Nov 25 2003 Than Ngo 6:3.1.93-0.2 - add fix to build against new libxml2 >= 2.6 * Thu Nov 13 2003 Than Ngo 6:3.1.93-0.1 - KDE 3.2 Beta 1 - cleanup - add devel package rpmdb-fedora-1.90-0.20031126 ---------------------------- sane-backends-1.0.13-2 ---------------------- * Tue Nov 25 2003 Thomas Woerner 1.0.13-2 - no rpath in sane-config anymore usermode-1.69-3.sel ------------------- * Tue Nov 25 2003 Dan Walsh 1.69-3.sel - Fix handling of roles from console file * Fri Nov 14 2003 Nalin Dahyabhai - don't disable use of deprecated GLib and GTK+ APIs, reported by the mysterious Pierre-with-no-last-name vsftpd-1.2.1-1 -------------- * Mon Nov 24 2003 Karsten Hopp 1.2.1-1 - update to 1.2.1, which fixes #89765 and lot of other issues - remove manpage patch, it isn't required anymore - clean up init script - don't use script to find libs to link with (lib64 issues) From Nicolas.Mailhot at laposte.net Wed Nov 26 14:40:24 2003 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 26 Nov 2003 15:40:24 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <3FC4B7B6.8060800@israel-jugendtag.ch> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <3FC4B7B6.8060800@israel-jugendtag.ch> Message-ID: <1069857623.5949.7.camel@ulysse.olympe.o2t> While ldap is definitely heavier for single-box systems it might just be one of those things no one will make work in a satisfactory manner till it's the default (like UTF-8 was - lots of latin people do not need it but encoding problems were not solved till unicode was forced on everyone). And once basic ldap support is polished I can imagine quite a few wins even for home users - having your own directory server instead of saving contacts in dozens of incompatible formats being just one of them. So the question is - can openldap be trimmed enough to be acceptable for home users ? 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 nos at utel.no Wed Nov 26 14:20:42 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Wed, 26 Nov 2003 15:20:42 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <492ca0e40304c907d3@[192.168.170.10]> References: <487bd5ee03048b07d3@[192.168.170.10]><488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]><48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> Message-ID: <4933743f0304d107d3@[192.168.170.10]> On Wed, 2003-11-26 at 15:24, =?ISO-8859-1?Q?Roland K=E4ser?= wrote: > Yeah but what i ment is that fc2 should come with a fully initialized > ldap server. It's also possible that in a first step only the users and > groups are saved in the ldap. As i said in the first mail, Samba ships > command line tools for adding, modifying and deleting users from a bash > shell. The only thing needed to change is to replace the "normal" > useradd, usermod, userdel, groupadd, groupmod and groupdel by the ones > shipped with samba. For the normal user it wouldn't make any changes in > the "feeling" of the administration. From my point of view, a GUI admin > tool doesn't needs to support all the complete ldap features, it should > only be a easy to use administration interface - excuse this analogy - > like the active directory frontend. My point also. Though due to nss, it is not needed, it might complicate things, it's yet-another-really-not-needed-daemon, overkill for most users. Using something like libuser, it would be easy to have a unified userinterface for users/groups regarless of wether they are in text file or an ldap server. The question is ofcourse, _why_ should ldap be used as a backend for this, for _all_ users ? -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s Tlf: 370 45 431 Mob: 943 01 380 w w w . u t e l s y s t e m s . c o m From ms-nospam-0306 at arcor.de Wed Nov 26 15:04:12 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 26 Nov 2003 16:04:12 +0100 Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm In-Reply-To: <1069820616.13740.10.camel@proton.cygnusx-1.org> References: <1069820616.13740.10.camel@proton.cygnusx-1.org> Message-ID: <20031126160412.0c88d287.ms-nospam-0306@arcor.de> On Tue, 25 Nov 2003 20:23:36 -0800, Nathan G. Grennan wrote: > I don't like the idea of adding the FC1 tag to future updates, and > would love to see this update get replaced with an untagged version. > > Anyone have any information or comments on this? What I dislike about the FC1 tag is that it has come out of nowhere like a sudden strike. I mean, we've tried to discuss distribution tags several times before. It would have been nice if this someone, who has "invented" FC1, would have contributed to the disttag discussions. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roli at israel-jugendtag.ch Wed Nov 26 15:12:52 2003 From: roli at israel-jugendtag.ch (=?ISO-8859-1?Q?Roland_K=E4ser?=) Date: Wed, 26 Nov 2003 16:12:52 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <4933743f0304d107d3@[192.168.170.10]> References: <487bd5ee03048b07d3@[192.168.170.10]><488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]><48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> Message-ID: <3FC4C2F4.3030704@israel-jugendtag.ch> Look at the mail from Nicolas Mailhot. This is one of my points. Now, we have all the configuration stuff spread over a lot of configuration files. This structure is matured since the first version of Unix. But to maintain all this files become more worse over the time. Yet the KDE comes with a lot of new configuration files so on with every other application on the whole system. The redmond bill hat not that many good ideas but the one with the registry was a good one. If we wanna make linux become a more professional operating system and feels in a more homogeneous way. We need to replace all this fragments of configuration spread nearly over the whole file system by an more professional way of an configuration concept. It doesn't needs all to be changed by the next fedora release but I strongly think that to store all the configuration settings inside a centralized configuration store whould anymore enhance the release. And nicolas has right; if we are the first ones who forces this concept it probably becomes a standard in the linux distributions. And for an other benefit, think about the possibilities of hanging a centrailized configuration store for all workstations an servers on big network. All the workstation configurations are stored in one single place (with backup servers of corse) and needs only to be maintaind at this place. I can imagine the next TCO studies from all the business analysts for comparing windows with linux. The TCO of linux whould come extremly down by using a such concept. Was that enough arguments for establishing a ldap server for the user records. Roland Nils O. Sel?sdal schrieb: >On Wed, 2003-11-26 at 15:24, =?ISO-8859-1?Q?Roland K=E4ser?= wrote: > > >>Yeah but what i ment is that fc2 should come with a fully initialized >>ldap server. It's also possible that in a first step only the users and >>groups are saved in the ldap. As i said in the first mail, Samba ships >>command line tools for adding, modifying and deleting users from a bash >>shell. The only thing needed to change is to replace the "normal" >>useradd, usermod, userdel, groupadd, groupmod and groupdel by the ones >>shipped with samba. For the normal user it wouldn't make any changes in >>the "feeling" of the administration. From my point of view, a GUI admin >>tool doesn't needs to support all the complete ldap features, it should >>only be a easy to use administration interface - excuse this analogy - >>like the active directory frontend. >> >> >My point also. Though due to nss, it is not needed, it might complicate >things, it's yet-another-really-not-needed-daemon, overkill for most >users. >Using something like libuser, it would be easy to have a unified >userinterface for users/groups regarless of wether they are in text file >or an ldap server. > >The question is ofcourse, _why_ should ldap be used as a backend for >this, for _all_ users ? > > > -- Roland K?ser Bocksrietstr. 54 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch From snookertb at comcast.net Wed Nov 26 15:11:21 2003 From: snookertb at comcast.net (snookertb) Date: Wed, 26 Nov 2003 10:11:21 -0500 Subject: fstab problem with mount In-Reply-To: References: Message-ID: <3FC4C299.40201@comcast.net> I logged it with bugzilla number 111007 From alexander.dalloz at uni-bielefeld.de Wed Nov 26 15:17:54 2003 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Wed, 26 Nov 2003 16:17:54 +0100 Subject: feature request: assign additional IPs to an eth device without need of aliases Message-ID: <1069859874.4286.320.camel@sirendipity.dogma.lan> Hi everyone! Some time ago I already asked for a possibility to setup the network with additional IPs assigned to an eth device without using aliased devices. As the network scripts now for a long period uses iproute2 to setup devices instead of the older ifconfig it would be easier to address further IPs to a device than by aliasing. In addition iptables can't handle aliased device names. Did anyone made already efforts to develop scripts to handle this issue? Otherwise I would start by my own to integrate shell scripts into the Redhat/Fedora network scripts to assign additional IPs - as a list or as just a bunch of IPs - to an existing eth device. Alexander -- Alexander Dalloz | Enger, Germany PGP key valid: made 13.07.1999 PGP fingerprint: 2307 88FD 2D41 038E 7416 14CD E197 6E88 ED69 5653 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From gilh at technolog.ca Wed Nov 26 15:18:23 2003 From: gilh at technolog.ca (gilh at technolog.ca) Date: Wed, 26 Nov 2003 10:18:23 -0500 (EST) Subject: ISO build process and tools Message-ID: <57559.192.18.128.12.1069859903.squirrel@mail.technolog.ca> Hello, Can someone describe the build processes of Fedora, from source RPMs to ISO? Is there a document that describes this somewhere? Thanks, Gil From roli at israel-jugendtag.ch Wed Nov 26 15:38:21 2003 From: roli at israel-jugendtag.ch (=?ISO-8859-1?Q?Roland_K=E4ser?=) Date: Wed, 26 Nov 2003 16:38:21 +0100 Subject: fstab problem with mount In-Reply-To: References: <20031125210833.30794.qmail@web25103.mail.ukl.yahoo.com> <3FC3D038.9060200@comcast.net> Message-ID: <3FC4C8ED.2050507@israel-jugendtag.ch> I've got a similary problem with fstab mounts. Is it possible that You formated it with ext2 by mistake? Roland Behdad Esfahbod schrieb: >On Tue, 25 Nov 2003, snookertb wrote: > > > >>James Harrison wrote: >> >> >> >>>/dev/hda4 /pub ext3 defaults 0 0 >>> >>>try: >>>/dev/hda4 /pub ext3 defaults 1 2 >>> >>>see >>>man fstab >>> >>> >>Ok, I have been man fstab and man 8 fstab 'ing for a while now. >> >>Still no joy. >> >>Question... Can the way the original filesystem was made be causing the >>problem? I went back and remade the filesystem as extended, but it >>didn't change anything. I can't see how the setup of the filesystem >>could be causing the problem once it works properly. >> >>I am at a loss as to what is wrong. >> >>tb >> >> > >Do you have any other ext3 partitions there? Anything in logs? > >be > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Roland K?ser Bocksrietstr. 54 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch From nos at utel.no Wed Nov 26 15:41:42 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Wed, 26 Nov 2003 16:41:42 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <495585110304dc07d3@[192.168.170.10]> References: <487bd5ee03048b07d3@[192.168.170.10]><488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]><48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]><4933743f0304d107d3@[192.168.170.10]> <495585110304dc07d3@[192.168.170.10]> Message-ID: <496a60d10304e307d3@[192.168.170.10]> On Wed, 2003-11-26 at 16:12, =?ISO-8859-1?Q?Roland K=E4ser?= wrote: > Look at the mail from Nicolas Mailhot. This is one of my points. Now, we > have all the configuration stuff spread over a lot of configuration > files. This structure is matured since the first version of Unix. But to > maintain all this files become more worse over the time. Yet the KDE > comes with a lot of new configuration files so on with every other > application on the whole system. The redmond bill hat not that many good > ideas but the one with the registry was a good one. If we wanna make > linux become a more professional operating system and feels in a more > homogeneous way. We need to replace all this fragments of configuration > spread nearly over the whole file system by an more professional way of > an configuration concept. It doesn't needs all to be changed by the next > fedora release but I strongly think that to store all the configuration > settings inside a centralized configuration store whould anymore > enhance the release. And nicolas has right; if we are the first ones > who forces this concept it probably becomes a standard in the linux > distributions. > And for an other benefit, think about the possibilities of hanging a > centrailized configuration store for all workstations an servers on big > network. All the workstation configurations are stored in one single > place (with backup servers of corse) and needs only to be maintaind at > this place. I can imagine the next TCO studies from all the business > analysts for comparing windows with linux. The TCO of linux whould come > extremly down by using a such concept. > Was that enough arguments for establishing a ldap server for the user > records. Perhaps. On thing is missing though. Someone needs to implement this and prove it's "better". And since just about each project uses it's own config file parsing/format, all those need to be enhanced. Which is a lot of work, and chances are the changes will not get upstream atleast for a while. If not, all one adds is yet another config system. We also have gconf, which might be extended to this concept. -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From kdebisschop at alert.infoplease.com Wed Nov 26 15:36:14 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Wed, 26 Nov 2003 10:36:14 -0500 Subject: FC2 and general LDAP Support In-Reply-To: <3FC4C2F4.3030704@israel-jugendtag.ch> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> Message-ID: <1069860973.22984.44.camel@skilletinfopleasecom.nh.pearsoned.com> On Wed, 2003-11-26 at 10:12, Roland K?ser wrote: > Look at the mail from Nicolas Mailhot. This is one of my points. Now, we > have all the configuration stuff spread over a lot of configuration > files. This structure is matured since the first version of Unix. But to > maintain all this files become more worse over the time. Yet the KDE > comes with a lot of new configuration files so on with every other > application on the whole system. The redmond bill hat not that many good > ideas but the one with the registry was a good one. I could not disagree more. In my experience, the registry is a convoluted mess and a horrible single point of failure. It is so complex that if it gets screwed up, the general solution is to "reinstall windows" I'll give an example in contrast. On one of my installs of FC1, I noticed a periodic disk seek, and saw error in my log (It has since been found out that this was an up2date client from rh9 failing, but I had the problem before the issue surfaced on the mailing lists). In this case, I notice that the problem did not occur when my wife logged in, nor did it occur when I logged in via ssh). So I deleted my .gnome directory, logged in again, and all was fine. No reinstalls, not even of gnome - the total cost - 5 minutes to reconfigure my gnome preferences. I cannot imagine finding the fix so easily on a w2k registry, and I have no wish to see that concept brought into the linux world. LDAP has it's place. I use it and like it here at work. But I do not see creating a linux registry as a good thing. > If we wanna make > linux become a more professional operating system and feels in a more > homogeneous way. We need to replace all this fragments of configuration > spread nearly over the whole file system by an more professional way of > an configuration concept. The Linux FHS does not spread configuration files all over the place. It vary clearly puts all global configuration files in /etc, and personal configuration file in the user's home directory. I think X11 is the only app which once got a historical exception, and those are in /etc on fedora too. > It doesn't needs all to be changed by the next > fedora release but I strongly think that to store all the configuration > settings inside a centralized configuration store would anymore > enhance the release. And nicolas has right; if we are the first ones > who forces this concept it probably becomes a standard in the linux > distributions. > And for an other benefit, think about the possibilities of hanging a > centrailized configuration store for all workstations an servers on big > network. All the workstation configurations are stored in one single > place (with backup servers of corse) and needs only to be maintaind at > this place. I fully support the idea of making this an option, but I question its value to the home user. I will also point out that I do the same thing with CVS already. It works today, all you need to do is CVS the files that have changed from what is in the original RPM. > I can imagine the next TCO studies from all the business > analysts for comparing windows with linux. The TCO of linux whould come > extremly down by using a such concept. Again, this is a benefit in the enterprise, but could be a burden in the home. > Was that enough arguments for establishing a ldap server for the user > records. Sorry, in my mind it was not. -- Karl DeBisschop Pearson Education/Information Please From csm at redhat.com Wed Nov 26 16:06:01 2003 From: csm at redhat.com (Chuck Mead) Date: Wed, 26 Nov 2003 11:06:01 -0500 Subject: Self Introduction: Chuck Mead Message-ID: <3FC4CF69.9030500@redhat.com> 1. Charles S. Mead 2. Cary, North Carolina, USA 3. Instructor/Examiner 4. Red Hat, Inc., Global Learning Services 5. Goals: a. since Fedora is what RHEL will be and I have to teach RHEL I want to be involved in the development process as much as time permits. b. I am interested in init and related issues so I would like to do some things with init when needed. c. for starters I guess I will work on doing QA with the big pile of packages at fedora.us. 6. History: I started using Linux in 1993. Have been using Unix for almost 20 years now. I am the founder of MoonGroup.com (an independent consulting firm). Co-founder and past President of the Linux Professional Institute. Former CTO of LinuxMall (OTC: ebiz). Co-founder and leader of the Lunar Linux project (source based distro). Instructor/Examiner employed by Red Hat in the Global Learning Services group. [csm at dawg csm]$ gpg --fingerprint E1F9D56B pub 1024D/E1F9D56B 2003-02-24 Chuck Mead (Instructor, GLS) Key fingerprint = 662A 9CA3 6709 5538 3F73 0872 65FC B48E E1F9 D56B sub 1024g/E5600C57 2003-02-24 -- Chuck Mead Instructor II, GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" From gauret at free.fr Wed Nov 26 16:18:13 2003 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 26 Nov 2003 17:18:13 +0100 Subject: FC2 and general LDAP Support References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> <1069860973.22984.44.camel@skilletinfopleasecom.nh.pearsoned.com> Message-ID: > I could not disagree more. In my experience, the registry is a > convoluted mess and a horrible single point of failure. It is so complex > that if it gets screwed up, the general solution is to "reinstall > windows" I also don't like the idea of putting all the configuration into LDAP. I like how easy to script plain text files. Doing changes in LDAP is much more complicated (you have to create the LDIF file, and the LDIF format is rather strict). I really dissapprove putting the whole system configuration into a bunch of binary files by default. But LDAP is in my opinion something which sould be given a lot of attention. Just not use it by default, please. Bye Aurelien From Nicolas.Mailhot at laposte.net Wed Nov 26 16:31:09 2003 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 26 Nov 2003 17:31:09 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <496a60d10304e307d3@[192.168.170.10]> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <495585110304dc07d3@[192.168.170.10]> <496a60d10304e307d3@[192.168.170.10]> Message-ID: <1069864269.7138.10.camel@ulysse.olympe.o2t> Le mer 26/11/2003 ? 16:41, =?ISO-8859-1?Q? Nils O. Sel=E5sdal?= a ?crit : > On Wed, 2003-11-26 at 16:12, =?ISO-8859-1?Q?Roland K=E4ser?= wrote: > > Look at the mail from Nicolas Mailhot. This is one of my points. [...] > We need to replace all this fragments of configuration > > spread nearly over the whole file system by an more professional way of > > an configuration concept. Please do not read what I didn't put into my mail. I agree ldap has a place. I agree it's under-used. I agree there is some info like user descriptions, contacts... that should be moved into openldap if only because the current setup just does not cut it (the user system is inadequate for networks/samba, contact handling is a mess right now...). I also think we won't have a solid ldap setup till it's a Fedora default, and it's needed for lots of things *now*. However this won't happen if openldap is too heavy for single-box systems, and above all this is not an endorsement of "let's do a binary registry now".) There is a ton of cleanly defined hierarchical info that could be put into ldap now and improve user experience. There is also a ton of stuff that does not belong in there like Windows demonstrates every day. > We also have gconf, which might be extended to this concept. gconf might use a ldap backend someday (not sure it's a good idea). Switching to it now before ldap is solid/manageable would be a terrible mistake however. Let's do clearly understood stuff first. 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 Wed Nov 26 16:54:16 2003 From: davej at redhat.com (Dave Jones) Date: Wed, 26 Nov 2003 16:54:16 +0000 Subject: SMP i586? In-Reply-To: <20031125184513.GB24345@devserv.devel.redhat.com> References: <200311211715.43696.lowen@pari.edu> <1069661262.22934.1.camel@topicus6> <20031125154742.GA1426@devserv.devel.redhat.com> <20031125184513.GB24345@devserv.devel.redhat.com> Message-ID: <1069865656.7945.13.camel@delerium.codemonkey.org.uk> On Tue, 2003-11-25 at 18:45, Alan Cox wrote: > > > because it never was really popular for i586 (and didn't perform that > > > well too). You can build an i586 SMP kernel yourself... > > > > That's correct. We don't have any functional i586 SMP hardware that > > I'm aware of either. > > Davej should even if RH doesnt ;) It's actually pseudo-colo'd in the house of a local Debian bod right now (I was low on office space, and those folks seem to like such crazy hardware). For the curious, this is the dual P90 that Caldera[*] sent Alan for SMP development. It's incredibly clunky, weighs a ton, and in comparison to any of todays hardware, is almost painful to use for anything serious. It would be fun to get Fedora on that monster some time though. I thought we were actually churning out i586-smp kernels, but I just checked and spotted the exclusion in the spec file. I'll nuke that, and push one out sometime for folks to play with. Dave [*] The worm it turns... -- Dave Jones Red Hat From roli at israel-jugendtag.ch Wed Nov 26 17:13:30 2003 From: roli at israel-jugendtag.ch (=?ISO-8859-15?Q?Roland_K=E4ser?=) Date: Wed, 26 Nov 2003 18:13:30 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <1069864269.7138.10.camel@ulysse.olympe.o2t> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <495585110304dc07d3@[192.168.170.10]> <496a60d10304e307d3@[192.168.170.10]> <1069864269.7138.10.camel@ulysse.olympe.o2t> Message-ID: <3FC4DF3A.2030707@israel-jugendtag.ch> Nobody said that we should make a bad copy of the windows registry! Think beyond the bad implementation of the windows registry. It was never my opinion to bring the windows crap to linux. And its seriously not my idea to make linux configuration store that complex as it is on windows. Are we not more creative to just make a cheap copy of the registry? And to this idea that the file configuration is that easy can i only say that to work on a sendmail.cf and loosing it by an automatic configuration engine, such as yast, after it worked is also really horrorable. So, lets think about our own ideas to create a such configuration instance. The main goals from my point of view are only: 1: Centralized configuration and change management 2: Easy to extend the concept to network wide configuration store. Think also about the benefits of this idea. No more ssh nightmares to configure ten diffrent systems to support one single service. And specially the administration of useraccounts in a network with 10-50 servers is nearly impossible without ldap. And at least think that the success of linux specially the one of the fedora release is also based on the acceptance of the business. And from the business point of view, the TCO is an important factor. To edit a directory with config settings and user records is FASTER than edit a lot of files! That's important for the ones who maks the decision about windows or linux or even fedora. Roland Nicolas Mailhot schrieb: >Le mer 26/11/2003 ? 16:41, =?ISO-8859-1?Q? Nils O. Sel=E5sdal?= a >?crit : > > >>On Wed, 2003-11-26 at 16:12, =?ISO-8859-1?Q?Roland K=E4ser?= wrote: >> >> >>>Look at the mail from Nicolas Mailhot. This is one of my points. >>> >>> > >[...] > > > >>We need to replace all this fragments of configuration >> >> >>>spread nearly over the whole file system by an more professional way of >>>an configuration concept. >>> >>> > >Please do not read what I didn't put into my mail. > >I agree ldap has a place. I agree it's under-used. I agree there is some >info like user descriptions, contacts... that should be moved into >openldap if only because the current setup just does not cut it (the >user system is inadequate for networks/samba, contact handling is a mess >right now...). I also think we won't have a solid ldap setup till it's a >Fedora default, and it's needed for lots of things *now*. > >However this won't happen if openldap is too heavy for single-box >systems, and above all this is not an endorsement of "let's do a binary >registry now".) > >There is a ton of cleanly defined hierarchical info that could be put >into ldap now and improve user experience. There is also a ton of stuff >that does not belong in there like Windows demonstrates every day. > > > >>We also have gconf, which might be extended to this concept. >> >> > >gconf might use a ldap backend someday (not sure it's a good idea). >Switching to it now before ldap is solid/manageable would be a terrible >mistake however. Let's do clearly understood stuff first. > >Cheers, > > > -- Roland K?ser Bocksrietstr. 54 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch From csm at lunar-linux.org Wed Nov 26 17:41:28 2003 From: csm at lunar-linux.org (Chuck Mead) Date: Wed, 26 Nov 2003 12:41:28 -0500 Subject: Self Introduction: Chuck Mead In-Reply-To: <3FC4CF69.9030500@redhat.com> References: <3FC4CF69.9030500@redhat.com> Message-ID: <3FC4E5C8.6040405@lunar-linux.org> Chuck Mead wrote: > 1. Charles S. Mead > 2. Cary, North Carolina, USA > 3. Instructor/Examiner > 4. Red Hat, Inc., Global Learning Services > 5. Goals: > > a. since Fedora is what RHEL will be and I have to teach RHEL I > want to be involved in the development process as much as time permits. > b. I am interested in init and related issues so I would like to > do some things with init when needed. > c. for starters I guess I will work on doing QA with the big pile > of packages at fedora.us. > > 6. History: > > I started using Linux in 1993. Have been using Unix for almost 20 > years now. I am the founder of MoonGroup.com (an independent > consulting firm). Co-founder and past President of the Linux > Professional Institute. Former CTO of LinuxMall (OTC: ebiz). > Co-founder and leader of the Lunar Linux project (source based > distro). Instructor/Examiner employed by Red Hat in the Global > Learning Services group. > > [csm at dawg csm]$ gpg --fingerprint E1F9D56B > pub 1024D/E1F9D56B 2003-02-24 Chuck Mead (Instructor, GLS) > > Key fingerprint = 662A 9CA3 6709 5538 3F73 0872 65FC B48E E1F9 D56B > sub 1024g/E5600C57 2003-02-24 > > This is my other key which I like to use when I am at home! [csm at stealth srpms]$ gpg --fingerprint FE7E1807 pub 1024D/FE7E1807 2003-04-23 Chuck Mead Key fingerprint = 068F D928 F359 3BDC C74C 830E AB76 E7CB FE7E 1807 sub 1024g/EDD2E93D 2003-04-23 This one... my redhat one and one other are all cross signed iirc. -- csm Lunar Project Leader Disclaimer: "I am not a curmudgeon! No... really..." Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" From alan at redhat.com Wed Nov 26 17:59:18 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 26 Nov 2003 12:59:18 -0500 Subject: changelog display in up2date/yum In-Reply-To: <40204.195.233.250.7.1069831088.squirrel@sreindl.dyndns.org> References: <40204.195.233.250.7.1069831088.squirrel@sreindl.dyndns.org> Message-ID: <20031126175918.GA5695@devserv.devel.redhat.com> > it would be a nice feature to see the changes in a package before the > package is updated. A feature like this is available for Debian (but there > you get a mail at the time you install the packages). rpm -q -p --changelog From alan at redhat.com Wed Nov 26 18:11:31 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 26 Nov 2003 13:11:31 -0500 Subject: Translation project -- Catalan In-Reply-To: <1069840406.695.231.camel@deimos> References: <1069840406.695.231.camel@deimos> Message-ID: <20031126181131.GE5695@devserv.devel.redhat.com> > it using msginit like this: > > $ msginit --locale=ca -i anaconda.pot > > Is that how you would normally do it? Its one way yes. > Then, once the file is translated, do I have rights to commit (and thus > add a new file) into the repository, or is there someone coordinating Yes you do. You may need to bug the package author to get them to then do an update and include the changes. Some package owners are pretty snappy others (redhat-menus 8)) take a lot of kicking ;) You do need to co-ordinate with any other ca translators who turn up and you should also co-ordinate with active Gnome/KDE/etc translators because it is important that the configuration tools use the same words for things like "window" or "printer" as the desktop... From alan at redhat.com Wed Nov 26 18:13:26 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 26 Nov 2003 13:13:26 -0500 Subject: FC2 and general LDAP Support In-Reply-To: <3FC49B28.7020308@israel-jugendtag.ch> References: <3FC48BF0.60005@israel-jugendtag.ch> <20031126113615.GN28476@localhorst.br.de> <3FC49B28.7020308@israel-jugendtag.ch> Message-ID: <20031126181326.GF5695@devserv.devel.redhat.com> > hosting the printers information from cups in the ldap, mail routing > information for postfix and courier etc. This main ldap infrastructure > would be a big improvement to the distribution. And there are many other > daemons which running on a "normal" system, one more whould doesn't matter. "When all you have is a hammer everything looks like a nail" From johnsonm at redhat.com Wed Nov 26 18:20:28 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 26 Nov 2003 13:20:28 -0500 Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm In-Reply-To: <20031126074437.GD7622@puariko.nirvana> References: <1069820616.13740.10.camel@proton.cygnusx-1.org> <20031126074437.GD7622@puariko.nirvana> Message-ID: <20031126182028.GA13830@devserv.devel.redhat.com> On Wed, Nov 26, 2003 at 08:44:37AM +0100, Axel Thimm wrote: > But tags need to be standardized, and there was a looong and mostly No, they don't. Not necessarily. When the tag is there for the convenience of the packager, it's the packager's job (within reason) to select the tag. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From johnsonm at redhat.com Wed Nov 26 18:26:01 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 26 Nov 2003 13:26:01 -0500 Subject: FC2 and general LDAP Support In-Reply-To: <3FC4B7B6.8060800@israel-jugendtag.ch> References: <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <3FC4B7B6.8060800@israel-jugendtag.ch> Message-ID: <20031126182601.GB13830@devserv.devel.redhat.com> On Wed, Nov 26, 2003 at 03:24:54PM +0100, Roland K?ser wrote: > shell. The only thing needed to change is to replace the "normal" > useradd, usermod, userdel, groupadd, groupmod and groupdel by the ones > shipped with samba. That's too LDAP-centric. It's good to make LDAP work better, but don't do it at the expense of other, equally valid configurations. Tools that take the system configuration into account are what you really want. That will work with whatever configuration you have. And considering the amount of work in the user tools that come by default, I'd suggest modifying those rather than a wholesale switch as the best option. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From redhat-forums at genesis-x.nildram.co.uk Wed Nov 26 19:05:38 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Wed, 26 Nov 2003 19:05:38 +0000 Subject: REQ: Tripwire developers / testers Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tripwire development has stepped up a gear and gone beyond the "quick fix" stage. The current pre-release in the QA queue WorksForMe? and the binary distro looks good, but now there is a growing interest in backporting some other patches and cleaning up the code. The biggest fix promises to come in the form of cryptlib patches in the Deb patch, however this patch cannot be applied "as-is" since: 1) ... It's too Debian-centric, and 2) ... It clashes with Paul Herman's tw-20030919.patch I'm looking to merge competing patches and generally clean up. Paul has indicated that (time permitting) he will review his code and submit an overview of his patch, to be documented and included with the release. I feel this is important, given the scope of the changes. Meanwhile, I will begin work on the huge array of patches. I'm requesting help from anyone with even an hour or two two spare per week, to get development moving again. My current busy schedule (and my day job) would make progress painfully slow otherwise. Thanks in advance, Keith G. Robertson-Turner tripwire-devel at genesis-x.nildram.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/xPkK2XoLj+pGfn8RAln9AJkBgJxR7+9Zt6ZA19hV5oZ39GbCXgCeO5Zg jtGQ3Ar3cSny65HxWjd7Wh4= =Ic41 -----END PGP SIGNATURE----- From enrico.scholz at informatik.tu-chemnitz.de Wed Nov 26 19:11:18 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 26 Nov 2003 20:11:18 +0100 Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm In-Reply-To: <20031126182028.GA13830@devserv.devel.redhat.com> (Michael K. Johnson's message of "Wed, 26 Nov 2003 13:20:28 -0500") References: <1069820616.13740.10.camel@proton.cygnusx-1.org> <20031126074437.GD7622@puariko.nirvana> <20031126182028.GA13830@devserv.devel.redhat.com> Message-ID: <87smkbq71l.fsf@kosh.ultra.csn.tu-chemnitz.de> johnsonm at redhat.com ("Michael K. Johnson") writes: >> But tags need to be standardized, and there was a looong and mostly > > No, they don't. Not necessarily. When the tag is there for the > convenience of the packager, it's the packager's job (within reason) > to select the tag. Such non-standardized tags will cause conflicts with automatic buildsystems. For a clean update-path a disttag-change is needed for new releases. What do you think happens at mass-rebuilds (e.g. rh9* -> fc1 transition) when every packager chooses an own disttag-scheme? Either, the packager would have to resubmit a new version (inclusive the QA trail) or the buildmaster would have to change the tags manually. Both methods are not really an option, imo... Enrico From sr at stephenreindl.de Wed Nov 26 19:32:56 2003 From: sr at stephenreindl.de (Stephen Reindl) Date: Wed, 26 Nov 2003 20:32:56 +0100 Subject: changelog display in up2date/yum In-Reply-To: <20031126175918.GA5695@devserv.devel.redhat.com> References: <40204.195.233.250.7.1069831088.squirrel@sreindl.dyndns.org> <20031126175918.GA5695@devserv.devel.redhat.com> Message-ID: <1069875176.11100.3.camel@yedi> Am Mi, den 26.11.2003 schrieb Alan Cox um 18:59: > > it would be a nice feature to see the changes in a package before the > > package is updated. A feature like this is available for Debian (but there > > you get a mail at the time you install the packages). > > rpm -q -p --changelog This I know but it gives me the complete changelog of the package. If I use yum to update my distribution it would be nice to see the differences from the version that is currently installed. Stephen > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From johnsonm at redhat.com Wed Nov 26 19:44:13 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 26 Nov 2003 14:44:13 -0500 Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm In-Reply-To: <87smkbq71l.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1069820616.13740.10.camel@proton.cygnusx-1.org> <20031126074437.GD7622@puariko.nirvana> <20031126182028.GA13830@devserv.devel.redhat.com> <87smkbq71l.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20031126194413.GA9437@devserv.devel.redhat.com> On Wed, Nov 26, 2003 at 08:11:18PM +0100, Enrico Scholz wrote: > Such non-standardized tags will cause conflicts with automatic > buildsystems. For a clean update-path a disttag-change is needed for new > releases. What do you think happens at mass-rebuilds (e.g. rh9* -> fc1 > transition) when every packager chooses an own disttag-scheme? Either, > the packager would have to resubmit a new version (inclusive the QA > trail) or the buildmaster would have to change the tags manually. > > Both methods are not really an option, imo... Sorry, I think I was operating on insufficient context. I was stuck in the base distribution -- Fedora Core, not third party repositories. Please excuse that... Before I give any more pronouncements on this, I'd like to more carefully study the issues. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From jvdev at 3va.net Wed Nov 26 20:13:30 2003 From: jvdev at 3va.net (Jeroen van Drie) Date: Wed, 26 Nov 2003 21:13:30 +0100 Subject: fedora naming and google Message-ID: <200311262113.30339.jvdev@3va.net> This might seem trivial but might make a WORLD of difference Searching for things related to rh on google has always been difficult because the response could apply to 5.2, 7.1, 9.0, or any or all version(s). Searching for information about an OSX release is much easier because of the proliferation of the cat names (panther, jaguar, etc) so adding the cat name to the google query often returns the right answer. Since google is such an invaluable tool in maintaining a linux machine I would ask you all to consider and discuss using simple names for each fedora release, and to refer to the releases by those names and not by version numbers so that the practise becomes common enough to be a valuable google property. Names like fedora core fedora quark fedora proton (ie simple names from a cohesive list like physics.) I've installed fedora as my main desktop a few days ago; it's very nice and polished, very well done everyone! From notting at redhat.com Wed Nov 26 20:20:14 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 26 Nov 2003 15:20:14 -0500 Subject: fedora naming and google In-Reply-To: <200311262113.30339.jvdev@3va.net> References: <200311262113.30339.jvdev@3va.net> Message-ID: <20031126202014.GA24892@devserv.devel.redhat.com> Jeroen van Drie (jvdev at 3va.net) said: > Searching for things related to rh on google has always been difficult because > the response could apply to 5.2, 7.1, 9.0, or any or all version(s). All of those releases had names of one sort or another. http://fedora.redhat.com/about/history/ Bill From jvdev at 3va.net Wed Nov 26 20:41:50 2003 From: jvdev at 3va.net (Jeroen van Drie) Date: Wed, 26 Nov 2003 21:41:50 +0100 Subject: fedora naming and google In-Reply-To: <20031126202014.GA24892@devserv.devel.redhat.com> References: <200311262113.30339.jvdev@3va.net> <20031126202014.GA24892@devserv.devel.redhat.com> Message-ID: <200311262141.50877.jvdev@3va.net> > > Searching for things related to rh on google has always been difficult > > because the response could apply to 5.2, 7.1, 9.0, or any or all > > version(s). > > All of those releases had names of one sort or another. > > http://fedora.redhat.com/about/history/ Hello Bill, They did, but if you need information about 6.2 then adding zoot to your google query is not going to be helpful because people don't use the term zoot while describing problems, fixes or anything related to redhat 6.2 zoot. If the name had been redhat zoot without the 6.2 version number people would have been much more likely to use it and hence it would have become a google search property. From Bernd.Bartmann at sohanet.de Wed Nov 26 20:44:06 2003 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Wed, 26 Nov 2003 21:44:06 +0100 Subject: RFE: Common format for update/errata announcements Message-ID: <3FC51096.9000106@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Request for enhancement: Please use ONE common format for Fedora update/errata announcements. Until today we already got 4 different kinds of subject lines: [SECURITY] Fedora Core 1 Update: glibc-2.3.2-101.1 Fedora Core 1 Update: epic-1.0.1-16 Fedora Update Notification: Mozilla [1.4.1-18] Updated ethereal packages available I would propose to use the first format listed above with the extension to replace the prefix [SECURITY] with [BUGFIX] or [ENHANCEMENT] when appropriate. Every announcement should be GPG signed. Also I think it would be better to put the rpm names and the md5sums into the same line. This would increase readability alot. And as already requested before can we please get a central web page containing all update announcements something like https://rhn.redhat.com/errata/rh9-errata.html Shouldn't these announcements not also be posted at the Bugtraq and Full-Disclosure mailing-lists? Filed as RFE bug #111056. Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/xRCWkQuIaHu84cIRAr+lAJwLrUTJTzM9KgiUvgMDd3ZTtyIkEgCaAlmh gZrR/QY4Oi7iWmsEcptftTQ= =x2bH -----END PGP SIGNATURE----- From notting at redhat.com Wed Nov 26 20:50:03 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 26 Nov 2003 15:50:03 -0500 Subject: fedora naming and google In-Reply-To: <200311262141.50877.jvdev@3va.net> References: <200311262113.30339.jvdev@3va.net> <20031126202014.GA24892@devserv.devel.redhat.com> <200311262141.50877.jvdev@3va.net> Message-ID: <20031126205003.GB24069@devserv.devel.redhat.com> Jeroen van Drie (jvdev at 3va.net) said: > They did, but if you need information about 6.2 then adding zoot to your > google query is not going to be helpful because people don't use the term > zoot while describing problems, fixes or anything related to redhat 6.2 zoot. > If the name had been redhat zoot without the 6.2 version number people would > have been much more likely to use it and hence it would have become a google > search property. But if we did that, many more people than those that complain about this would complain about having to keep in their head which version is newer than which... Bill From anthonysaffer at safferconsulting.com Wed Nov 26 22:57:30 2003 From: anthonysaffer at safferconsulting.com (Anthony Saffer) Date: Wed, 26 Nov 2003 14:57:30 -0800 Subject: fedora naming and google References: <200311262113.30339.jvdev@3va.net> <20031126202014.GA24892@devserv.devel.redhat.com> <200311262141.50877.jvdev@3va.net> <20031126205003.GB24069@devserv.devel.redhat.com> Message-ID: <005f01c3b470$ad249ae0$15f4ac41@k4h8f5> > But if we did that, many more people than those that complain about > this would complain about having to keep in their head which version > is newer than which... I have to agree with Bill here. Using formal names instead of version/release numbers would just confuse the matter even further and make it a bit *harder* for people to find information they need. Think about the Microsoft Windows world. While each release has a codename they are eventually released as Windows 98, Windows 2000, Windows XP, etc. This is really no different than what Fedora is doing and it's not hard at all to find the information you need. Anthony Saffer From kreg at virtual1.net Wed Nov 26 20:59:13 2003 From: kreg at virtual1.net (Kreg Steppe) Date: Wed, 26 Nov 2003 15:59:13 -0500 Subject: fedora naming and google In-Reply-To: <20031126205003.GB24069@devserv.devel.redhat.com> References: <200311262113.30339.jvdev@3va.net> <20031126202014.GA24892@devserv.devel.redhat.com> <200311262141.50877.jvdev@3va.net> <20031126205003.GB24069@devserv.devel.redhat.com> Message-ID: <3FC51421.8040904@virtual1.net> Bill Nottingham wrote: > Jeroen van Drie (jvdev at 3va.net) said: > >>They did, but if you need information about 6.2 then adding zoot to your >>google query is not going to be helpful because people don't use the term >>zoot while describing problems, fixes or anything related to redhat 6.2 zoot. >>If the name had been redhat zoot without the 6.2 version number people would >>have been much more likely to use it and hence it would have become a google >>search property. > > > But if we did that, many more people than those that complain about > this would complain about having to keep in their head which version > is newer than which... > > Bill > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list I agree... look at all the questions that were asked about which was newer severn or yarrow. Stick with versions. Kreg From jvdev at 3va.net Wed Nov 26 21:12:17 2003 From: jvdev at 3va.net (Jeroen van Drie) Date: Wed, 26 Nov 2003 22:12:17 +0100 Subject: fedora naming and google In-Reply-To: <20031126205003.GB24069@devserv.devel.redhat.com> References: <200311262113.30339.jvdev@3va.net> <200311262141.50877.jvdev@3va.net> <20031126205003.GB24069@devserv.devel.redhat.com> Message-ID: <200311262212.17760.jvdev@3va.net> Ok thanks everyone for your time and consideration, you're definately right that a naming would make it loose serial cohesion and that is much more important than having an identifying label. Maybe it's possible to do both and try to place the version name/number in the awareness more. It's true that the jaguar/panther versioning does generate a lot of questions "which one is that exactly".... I guess I hadn't considered this from all sides equally :) From iamfezzik at hotmail.com Wed Nov 26 21:26:01 2003 From: iamfezzik at hotmail.com (Fezzik Giant) Date: Wed, 26 Nov 2003 21:26:01 +0000 Subject: I gotta ask this ... Message-ID: Hi everyone, I have seen several posts in the past where someone asks about building Fedora ISO images. I have yet to see a response. Surely _someone_ must know how this is done. Why is there never a response? Is this knowledge a 'secret sauce' that nobody wishes to share? F _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From Axel.Thimm at physik.fu-berlin.de Wed Nov 26 21:34:09 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 26 Nov 2003 22:34:09 +0100 Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm In-Reply-To: <20031126194413.GA9437@devserv.devel.redhat.com> <87smkbq71l.fsf@kosh.ultra.csn.tu-chemnitz.de> <20031126182028.GA13830@devserv.devel.redhat.com> References: <20031126182028.GA13830@devserv.devel.redhat.com> <87smkbq71l.fsf@kosh.ultra.csn.tu-chemnitz.de> <20031126194413.GA9437@devserv.devel.redhat.com> <1069820616.13740.10.camel@proton.cygnusx-1.org> <20031126074437.GD7622@puariko.nirvana> <20031126182028.GA13830@devserv.devel.redhat.com> <87smkbq71l.fsf@kosh.ultra.csn.tu-chemnitz.de> <1069820616.13740.10.camel@proton.cygnusx-1.org> <20031126074437.GD7622@puariko.nirvana> <20031126182028.GA13830@devserv.devel.redhat.com> Message-ID: <20031126213409.GB27249@puariko.nirvana> On Wed, Nov 26, 2003 at 01:20:28PM -0500, Michael K. Johnson wrote: > On Wed, Nov 26, 2003 at 08:44:37AM +0100, Axel Thimm wrote: > > But tags need to be standardized, and there was a looong and mostly > > No, they don't. Not necessarily. When the tag is there for the > convenience of the packager, it's the packager's job (within reason) > to select the tag. On Wed, Nov 26, 2003 at 08:11:18PM +0100, Enrico Scholz wrote: > Such non-standardized tags will cause conflicts with automatic > buildsystems. For a clean update-path a disttag-change is needed for new > releases. What do you think happens at mass-rebuilds (e.g. rh9* -> fc1 > transition) when every packager chooses an own disttag-scheme? Either, > the packager would have to resubmit a new version (inclusive the QA > trail) or the buildmaster would have to change the tags manually. I agree, and to give another picture, imagine some packager eventually finding his currently used scheme inadequate, but would only be able to depart from it with epoch bumps, resulting in more versioning desasters. > Both methods are not really an option, imo... On Wed, Nov 26, 2003 at 02:44:13PM -0500, Michael K. Johnson wrote: > Sorry, I think I was operating on insufficient context. I was > stuck in the base distribution -- Fedora Core, not third party > repositories. Please excuse that... Even within the Red Hat ecosystem a standardized way to tag concurrent versions for different distros would not hurt. Currently it is really up to the (redhat.com) packager to decide on versioning. This freedom is sometimes used like an artistic freedom (yes, packagers are artists ;) > Before I give any more pronouncements on this, I'd like to more > carefully study the issues. Versioning (including disttags, epoch avoidance etc) should be standardized in any context IMHO. Of course there is more demand for doing so, if one needs to do often concurrent builds, which is not the main component in RH's development models (only a few common errata need to be treat that way from RH' POV). Even if RH itself does not see great benefits in using disttags, they certainly do not hurt. And if the need for non-RH community content, like fedora-legacy or external repos is acknowledged, RH should be interested in having a common scheme, because - how do your marketing/sales folks say - it's important to have "one face to the customer" ;) -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roli at israel-jugendtag.ch Wed Nov 26 21:55:25 2003 From: roli at israel-jugendtag.ch (=?ISO-8859-1?Q?Roland_K=E4ser?=) Date: Wed, 26 Nov 2003 22:55:25 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <20031126181326.GF5695@devserv.devel.redhat.com> References: <3FC48BF0.60005@israel-jugendtag.ch> <20031126113615.GN28476@localhorst.br.de> <3FC49B28.7020308@israel-jugendtag.ch> <20031126181326.GF5695@devserv.devel.redhat.com> Message-ID: <3FC5214D.5070603@israel-jugendtag.ch> What you mean with that? Alan Cox schrieb: >>hosting the printers information from cups in the ldap, mail routing >>information for postfix and courier etc. This main ldap infrastructure >>would be a big improvement to the distribution. And there are many other >>daemons which running on a "normal" system, one more whould doesn't matter. >> >> > >"When all you have is a hammer everything looks like a nail" > > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Roland K?ser Bocksrietstr. 54 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch From wcooley at nakedape.cc Wed Nov 26 21:56:16 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Wed, 26 Nov 2003 13:56:16 -0800 Subject: FC2 and general LDAP Support In-Reply-To: <3FC48BF0.60005@israel-jugendtag.ch> References: <3FC48BF0.60005@israel-jugendtag.ch> Message-ID: <1069883776.3700.45.camel@denk.nakedape.priv> On Wed, 2003-11-26 at 03:18, Roland K?ser wrote: > What about moving the user database to LDAP for the FC2 release? It > would be possible to integrate also the samba part of the user records > directly to the LDAP directory. The only thing we need is a useful ldap > administration frontend and the command line tools for creating and > modifying the user records from the command line. The most of the > command line tools are shipped with the samba source code. It it is > desired, i can make a RPM for that. While I am an LDAP advocate and agree that an admin tool for managing users and groups in LDAP would be an appreciated addition (and maybe managing printers and such there too), using it as the default would be way overkill. There are simply too many problems and it's not easy for the less experienced to deal with. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Tired of spam and viruses in your e-mail? Get the * * Naked Ape Mail Defender! http://nakedape.cc/r/maildefender * -------------- 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 felipe_alfaro at linuxmail.org Wed Nov 26 22:10:45 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 26 Nov 2003 23:10:45 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <3FC4C2F4.3030704@israel-jugendtag.ch> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> Message-ID: <1069884644.2145.3.camel@teapot.felipe-alfaro.com> On Wed, 2003-11-26 at 16:12, Roland K?ser wrote: > The redmond bill hat not that many good > ideas but the one with the registry was a good one. I couldn't disagree more. The Windoze registry is a pseudo-monolithic piece of binary information that can't be easily edited, backed up or manually edited in case of corruption or failure. Even GNOME's approach with GConf is still a mess (have you ever tried looking for a config element inside the XML files?) I don't mind Linux having a lot of configuration files. What I would like to see is a configuration tool that knows about those files, knows how to modify them and allows the user to do those changes through a streamlined, homogeneous user interface. From ms-nospam-0306 at arcor.de Wed Nov 26 22:22:34 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 26 Nov 2003 23:22:34 +0100 Subject: REQ: Tripwire developers / testers In-Reply-To: References: Message-ID: <20031126232234.6af916d6.ms-nospam-0306@arcor.de> On Wed, 26 Nov 2003 19:05:38 +0000, Keith G. Robertson-Turner wrote: > I'm requesting help from anyone with even an hour or two two spare per > week, to get development moving again. My current busy schedule (and my > day job) would make progress painfully slow otherwise. Testing in LDAP and NIS environments would be helpful. Everyone with interest in Tripwire, please note that you can speed up the package approval at fedora.us if you get involved into reviewing and approving package submissions: http://www.fedora.us/wiki/PackageSubmissionQAPolicy The current package queue: http://fedora.us/QA -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Wed Nov 26 22:30:52 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 26 Nov 2003 17:30:52 -0500 Subject: I gotta ask this ... In-Reply-To: References: Message-ID: <20031126223052.GC7682@devserv.devel.redhat.com> > I have seen several posts in the past where someone asks about building > Fedora ISO images. I have yet to see a response. > > Surely _someone_ must know how this is done. Why is there never a response? > Is this knowledge a 'secret sauce' that nobody wishes to share? Not really secret sauce. Build all the packages, boot the result, build all the packages again with it, figure out how to fit it all and the installer on the CD images and burn. Lots of this is currently done by the Red Hat internal build systems and those are tied to a lot of Red Hat specific baggage you really don't want. An external build system is on the todo list for Fedora From ms-nospam-0306 at arcor.de Wed Nov 26 22:32:52 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 26 Nov 2003 23:32:52 +0100 Subject: I gotta ask this ... In-Reply-To: References: Message-ID: <20031126233252.4bb66c4f.ms-nospam-0306@arcor.de> On Wed, 26 Nov 2003 21:26:01 +0000, Fezzik Giant wrote: > I have seen several posts in the past where someone asks about building > Fedora ISO images. I have yet to see a response. > > Surely _someone_ must know how this is done. Why is there never a response? > Is this knowledge a 'secret sauce' that nobody wishes to share? Let me guess. Those who know how to do it and who are subscribed here either will answer later or are tired of re-posting information that can be found in the various list archives or via Google. -- Casting "minor flame-shield"... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Wed Nov 26 22:32:46 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 26 Nov 2003 17:32:46 -0500 Subject: FC2 and general LDAP Support In-Reply-To: <3FC5214D.5070603@israel-jugendtag.ch> References: <3FC48BF0.60005@israel-jugendtag.ch> <20031126113615.GN28476@localhorst.br.de> <3FC49B28.7020308@israel-jugendtag.ch> <20031126181326.GF5695@devserv.devel.redhat.com> <3FC5214D.5070603@israel-jugendtag.ch> Message-ID: <20031126223246.GD7682@devserv.devel.redhat.com> > >"When all you have is a hammer everything looks like a nail" (Lost your question, please quote email the right way up) It is a very famous quote about the dangers of trying to make everything fit one paradigm when in fact it might not be a good fit. From skvidal at phy.duke.edu Wed Nov 26 22:34:00 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 26 Nov 2003 17:34:00 -0500 Subject: yum tries to update gpgme03 with gpgme? In-Reply-To: <20031125203425.714c49c4.ms-nospam-0306@arcor.de> References: <20031125015251.7ecc7c86.ms-nospam-0306@arcor.de> <1069730521.3559.15.camel@binkley> <20031125203425.714c49c4.ms-nospam-0306@arcor.de> Message-ID: <1069886040.3519.3.camel@binkley> On Tue, 2003-11-25 at 14:34, Michael Schwendt wrote: > https://bugzilla.fedora.us/show_bug.cgi?id=1059 Hi, I took a good long look at this bug, it's happening AFTER yum hands off the transaction to the rpm callback. I've checked the transaction set that yum is giving to the rpm callback and it definitely does not include the erasure. so this is an rpm-python or rpm bug. -sv From pros-n-cons at bak.rr.com Wed Nov 26 22:39:41 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Wed, 26 Nov 2003 14:39:41 -0800 Subject: I gotta ask this ... In-Reply-To: References: Message-ID: <20031126143941.4e49b97d.pros-n-cons@bak.rr.com> On Wed, 26 Nov 2003 21:26:01 +0000 Fezzik Giant wrote: > Hi everyone, > > I have seen several posts in the past where someone asks about building > Fedora ISO images. I have yet to see a response. > > Surely _someone_ must know how this is done. Why is there never a response? > Is this knowledge a 'secret sauce' that nobody wishes to share? kickstart From iamfezzik at hotmail.com Wed Nov 26 22:46:18 2003 From: iamfezzik at hotmail.com (Fezzik Giant) Date: Wed, 26 Nov 2003 22:46:18 +0000 Subject: I gotta ask this ... Message-ID: Thanks Alan! Build all the packages: well how, exactly, does one do this? Say I'm at RH9 and I want to build the Fedora Core from source. When I build the RPMs then the result will overwrite my RH9 binaries, will it not? What I'm looking for is a documented sequence of steps, like "Linux From Scratch" that will result in an ISO of Fedora Core. Starting with the source RPMs, of course :) As for the Todo list item, is this actively being worked on? Who would I contact to offer my help? Fez >From: Alan Cox >Reply-To: fedora-devel-list at redhat.com >To: fedora-devel-list at redhat.com >Subject: Re: I gotta ask this ... >Date: Wed, 26 Nov 2003 17:30:52 -0500 > > > I have seen several posts in the past where someone asks about building > > Fedora ISO images. I have yet to see a response. > > > > Surely _someone_ must know how this is done. Why is there never a >response? > > Is this knowledge a 'secret sauce' that nobody wishes to share? > >Not really secret sauce. Build all the packages, boot the result, build >all the packages again with it, figure out how to fit it all and the >installer >on the CD images and burn. > >Lots of this is currently done by the Red Hat internal build systems and >those are tied to a lot of Red Hat specific baggage you really don't want. > >An external build system is on the todo list for Fedora > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From iamfezzik at hotmail.com Wed Nov 26 23:08:40 2003 From: iamfezzik at hotmail.com (Fezzik Giant) Date: Wed, 26 Nov 2003 23:08:40 +0000 Subject: I gotta ask this ... Message-ID: Hi Vincent, kickstart seems to be a tool for building a disto once you have the source RPMs built, is it not? I'm trying to get to the stage where I can build the source RPMs into a disto. Thanks for the help! That's a great pointer ... Gil >From: Vincent >Reply-To: fedora-devel-list at redhat.com >To: fedora-devel-list at redhat.com >Subject: Re: I gotta ask this ... >Date: Wed, 26 Nov 2003 14:39:41 -0800 > >On Wed, 26 Nov 2003 21:26:01 +0000 >Fezzik Giant wrote: > > > Hi everyone, > > > > I have seen several posts in the past where someone asks about building > > Fedora ISO images. I have yet to see a response. > > > > Surely _someone_ must know how this is done. Why is there never a >response? > > Is this knowledge a 'secret sauce' that nobody wishes to share? > >kickstart > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list _________________________________________________________________ Is there a gadget-lover on your gift list? MSN Shopping has lined up some good bets! http://shopping.msn.com From wcooley at nakedape.cc Wed Nov 26 23:08:20 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Wed, 26 Nov 2003 15:08:20 -0800 Subject: FC2 and general LDAP Support In-Reply-To: <20031126182601.GB13830@devserv.devel.redhat.com> References: <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <3FC4B7B6.8060800@israel-jugendtag.ch> <20031126182601.GB13830@devserv.devel.redhat.com> Message-ID: <1069888100.3700.55.camel@denk.nakedape.priv> On Wed, 2003-11-26 at 10:26, Michael K. Johnson wrote: > On Wed, Nov 26, 2003 at 03:24:54PM +0100, Roland K?ser wrote: > > shell. The only thing needed to change is to replace the "normal" > > useradd, usermod, userdel, groupadd, groupmod and groupdel by the ones > > shipped with samba. > > That's too LDAP-centric. It's good to make LDAP work better, but > don't do it at the expense of other, equally valid configurations. > Tools that take the system configuration into account are what you > really want. That will work with whatever configuration you have. > And considering the amount of work in the user tools that come by > default, I'd suggest modifying those rather than a wholesale switch > as the best option. There are fairly easy ways to make it work, though. One approach would be to use 'alternatives' and install shadow-utils binaries as 'useradd.files', LDAP utilities as 'useradd.ldap', etc. Or, take the 'fsck' approach and have a front-end program that determines which backend to use at runtime, and runs 'useradd.ldap' when LDAP is configured. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * * Good, fast and cheap: Pick all 3! * * * * * * * * Naked Ape Consulting http://nakedape.cc * -------------- 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 robert at marcanoonline.com Wed Nov 26 23:11:35 2003 From: robert at marcanoonline.com (Robert Marcano) Date: Wed, 26 Nov 2003 19:11:35 -0400 Subject: I gotta ask this ... In-Reply-To: References: Message-ID: <1069888295.4389.22.camel@pcrobert.intranet.promca.com> On Wed, 2003-11-26 at 18:46, Fezzik Giant wrote: > Thanks Alan! > > Build all the packages: well how, exactly, does one do this? Say I'm at RH9 > and I want to build the Fedora Core from source. When I build the RPMs then > the result will overwrite my RH9 binaries, will it not? I have made a rebuild of a Red Hat version different that the one installed using a chroot environment (copy all the system to a new directory, and execute chroot /newdir) a few packages did not build in the chroot environment but you can try to build them outside it Each time you build a RPM, install it in the chroot environment in order to solve the dependencies required to the other SRPMs > > What I'm looking for is a documented sequence of steps, like "Linux From > Scratch" that will result in an ISO of Fedora Core. Starting with the source > RPMs, of course :) > > As for the Todo list item, is this actively being worked on? Who would I > contact to offer my help? > > Fez > > >From: Alan Cox > >Reply-To: fedora-devel-list at redhat.com > >To: fedora-devel-list at redhat.com > >Subject: Re: I gotta ask this ... > >Date: Wed, 26 Nov 2003 17:30:52 -0500 > > > > > I have seen several posts in the past where someone asks about building > > > Fedora ISO images. I have yet to see a response. > > > > > > Surely _someone_ must know how this is done. Why is there never a > >response? > > > Is this knowledge a 'secret sauce' that nobody wishes to share? > > > >Not really secret sauce. Build all the packages, boot the result, build > >all the packages again with it, figure out how to fit it all and the > >installer > >on the CD images and burn. > > > >Lots of this is currently done by the Red Hat internal build systems and > >those are tied to a lot of Red Hat specific baggage you really don't want. > > > >An external build system is on the todo list for Fedora > > From roli at israel-jugendtag.ch Wed Nov 26 23:16:03 2003 From: roli at israel-jugendtag.ch (=?UTF-8?B?Um9sYW5kIEvDpHNlcg==?=) Date: Thu, 27 Nov 2003 00:16:03 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <1069884644.2145.3.camel@teapot.felipe-alfaro.com> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> <1069884644.2145.3.camel@teapot.felipe-alfaro.com> Message-ID: <3FC53433.5050500@israel-jugendtag.ch> Yeah, the idea of using a homegeneous user interface is a good one. Please rememeber the linuxconf tool on earlier redhat version. But is really good tool was removed from the distribution. But why? But i cannot agree with Your objections to the main registry concept. I agree with the argument that the actual registry to complex and its hard to find configuration settings. But I say it again: I doesn't need to be registry copy. We can also learn from those mistakes and make it better. But for me as System Administrator in heterogenous networks with linux servers and windows workstations, i had the less of troubles with the registry in average. Again try to imagine the benefits of big networks. Just a small example: Think of blade servers for web-application clusters. In a number of 50 to 100 servers. With the ldap system it might be possible to just remotly install a new blade. It this installation starts for the first time, it takes all the configuration settings out of an centralized configuration store and works after that automaticly. If its need to change the default start page of a webserver, the connection to the database for the applications, etc. with that system it needs just to be changed in the central config store and not on every single machine. >While I am an LDAP advocate and agree that an admin tool for managing >users and groups in LDAP would be an appreciated addition (and maybe >managing printers and such there too), using it as the default would be >way overkill. There are simply too many problems and it's not easy for >the less experienced to deal with. It is not ment that with an LDAP Server all the users needs to know about LDIF-files, schema files etc. The goal behind it should be that the users doesn't needs to know all about that. They should can administrate the system as it was bevore. Roland Felipe Alfaro Solana schrieb: >On Wed, 2003-11-26 at 16:12, Roland K?ser wrote: > > >>The redmond bill hat not that many good >>ideas but the one with the registry was a good one. >> >> > >I couldn't disagree more. The Windoze registry is a pseudo-monolithic >piece of binary information that can't be easily edited, backed up or >manually edited in case of corruption or failure. Even GNOME's approach >with GConf is still a mess (have you ever tried looking for a config >element inside the XML files?) > >I don't mind Linux having a lot of configuration files. What I would >like to see is a configuration tool that knows about those files, knows >how to modify them and allows the user to do those changes through a >streamlined, homogeneous user interface. > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Roland K?ser Bocksrietstr. 54 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch From greg at lugs.org.sg Wed Nov 26 23:25:24 2003 From: greg at lugs.org.sg (greg at lugs.org.sg) Date: Thu, 27 Nov 2003 07:25:24 +0800 (SGT) Subject: I gotta ask this ... In-Reply-To: Message-ID: On 26-Nov-2003 Fezzik Giant wrote: > > Thanks Alan! > > Build all the packages: well how, exactly, does one do this? Say I'm at RH9 > and I want to build the Fedora Core from source. When I build the RPMs then > the result will overwrite my RH9 binaries, will it not? no, it won't. The resultant rpms will be in a .../RPMS directory. Then, as Alan sorta stated you need to install this. That is done (as someone else stated) via kickstart. Then re-build all the backages again, to make sure that you are building against the necessary binaries, etc. *then* you need to figure out how to distrubute the packages onto a cd, etc... > What I'm looking for is a documented sequence of steps, like "Linux From > Scratch" that will result in an ISO of Fedora Core. Starting with the source > RPMs, of course :) > > As for the Todo list item, is this actively being worked on? Who would I > contact to offer my help? > > Fez > >>From: Alan Cox >>Reply-To: fedora-devel-list at redhat.com >>To: fedora-devel-list at redhat.com >>Subject: Re: I gotta ask this ... >>Date: Wed, 26 Nov 2003 17:30:52 -0500 >> >> > I have seen several posts in the past where someone asks about building >> > Fedora ISO images. I have yet to see a response. >> > >> > Surely _someone_ must know how this is done. Why is there never a >>response? >> > Is this knowledge a 'secret sauce' that nobody wishes to share? >> >>Not really secret sauce. Build all the packages, boot the result, build >>all the packages again with it, figure out how to fit it all and the >>installer >>on the CD images and burn. >> >>Lots of this is currently done by the Red Hat internal build systems and >>those are tied to a lot of Red Hat specific baggage you really don't want. >> >>An external build system is on the todo list for Fedora >> >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoin.m > sn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list +---------------------------------------------------------------------+ You can release software that's good, software that's inexpensive, or software that's available on time. You can usually release software that has 2 of these 3 attributes -- but not all 3. | Greg Hosler greg at hosler.per.sg | +---------------------------------------------------------------------+ From alan at redhat.com Wed Nov 26 23:45:06 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 26 Nov 2003 18:45:06 -0500 Subject: I gotta ask this ... In-Reply-To: References: Message-ID: <20031126234506.GA22360@devserv.devel.redhat.com> > Build all the packages: well how, exactly, does one do this? Say I'm at RH9 > and I want to build the Fedora Core from source. When I build the RPMs then > the result will overwrite my RH9 binaries, will it not? RPM builds binaries in a thing called a "buildroot" so the packages wont trash your system as they are being built > What I'm looking for is a documented sequence of steps, like "Linux From > Scratch" that will result in an ISO of Fedora Core. Starting with the > source RPMs, of course :) The big problem is figuring out the order (and hacking around the odd loop where you have to build a boostrap version of a package to get started). Given an order its rpm -ba package repeated a lot > As for the Todo list item, is this actively being worked on? Who would I > contact to offer my help? Not sure who is co-ordinating that From alan at redhat.com Wed Nov 26 23:50:00 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 26 Nov 2003 18:50:00 -0500 Subject: FC2 and general LDAP Support In-Reply-To: <3FC53433.5050500@israel-jugendtag.ch> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> <1069884644.2145.3.camel@teapot.felipe-alfaro.com> <3FC53433.5050500@israel-jugendtag.ch> Message-ID: <20031126235000.GB22360@devserv.devel.redhat.com> On Thu, Nov 27, 2003 at 12:16:03AM +0100, Roland K?ser wrote: > Yeah, the idea of using a homegeneous user interface is a good one. > Please rememeber the linuxconf tool on earlier redhat version. But is > really good tool was removed from the distribution. But why? Maintainability mostly. There are other problems with a single program (as opposed to a single user interface) that it had too. There are lots of ways of hitting many of Linuxconf's goals (eg HTML and tools for command/gui mode that just wrap web widgets and drive them into the same backend) > It is not ment that with an LDAP Server all the users needs to know > about LDIF-files, schema files etc. The goal behind it should be that > the users doesn't needs to know all about that. They should can > administrate the system as it was bevore. Mechanism and goal are seperable. So lets imagine I'm a random end user or admin who doesn't know (or care) about stuff like LDAP. Can you concisely describe why I want the things you see it giving - without reference to the technology at all. From iamfezzik at hotmail.com Thu Nov 27 00:00:39 2003 From: iamfezzik at hotmail.com (Fezzik Giant) Date: Thu, 27 Nov 2003 00:00:39 +0000 Subject: I gotta ask this ... Message-ID: Alan, Thanks again for taking the time to answer my questions. I'll give these ideas a shot and let you know :) As for the co-ordinator -- hopefully they'll see my messages and contact me. Cheers! >From: Alan Cox >Reply-To: fedora-devel-list at redhat.com >To: fedora-devel-list at redhat.com >Subject: Re: I gotta ask this ... >Date: Wed, 26 Nov 2003 18:45:06 -0500 > [ snipage ] > >Not sure who is co-ordinating that > _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From seyman at wanadoo.fr Thu Nov 27 00:10:48 2003 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Thu, 27 Nov 2003 01:10:48 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <1069888100.3700.55.camel@denk.nakedape.priv> References: <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <3FC4B7B6.8060800@israel-jugendtag.ch> <20031126182601.GB13830@devserv.devel.redhat.com> <1069888100.3700.55.camel@denk.nakedape.priv> Message-ID: <20031127001048.GB10299@orient.maison.moi> On Wed, Nov 26, 2003 at 03:08:20PM -0800, Wil Cooley wrote: > > There are fairly easy ways to make it work, though. One approach would Wouldn't it be easier to keep things the way they are now (ie stay with the multiple files way of doing things as default and make choosing LDAP as easy as clicking on a checkbox)? Emmanuel From wcooley at nakedape.cc Thu Nov 27 00:27:32 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Wed, 26 Nov 2003 16:27:32 -0800 Subject: FC2 and general LDAP Support In-Reply-To: <20031127001048.GB10299@orient.maison.moi> References: <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <3FC4B7B6.8060800@israel-jugendtag.ch> <20031126182601.GB13830@devserv.devel.redhat.com> <1069888100.3700.55.camel@denk.nakedape.priv> <20031127001048.GB10299@orient.maison.moi> Message-ID: <1069892852.3700.59.camel@denk.nakedape.priv> On Wed, 2003-11-26 at 16:10, Emmanuel Seyman wrote: > On Wed, Nov 26, 2003 at 03:08:20PM -0800, Wil Cooley wrote: > > > > There are fairly easy ways to make it work, though. One approach would > > Wouldn't it be easier to keep things the way they are now (ie stay > with the multiple files way of doing things as default and make choosing > LDAP as easy as clicking on a checkbox)? Well, from the context of switching, yes, it would. The infrastructure I described (and I am not advocating making LDAP the default) would be one way to make it work--i.e., authconfig runs 'alernatives' or sets whatever setting appropriate for the front-end 'useradd'. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * * Good, fast and cheap: Pick all 3! * * * * * * * * Naked Ape Consulting http://nakedape.cc * -------------- 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 lowen at pari.edu Thu Nov 27 00:37:32 2003 From: lowen at pari.edu (Lamar Owen) Date: Wed, 26 Nov 2003 19:37:32 -0500 Subject: SMP i586? In-Reply-To: <1069865656.7945.13.camel@delerium.codemonkey.org.uk> References: <200311211715.43696.lowen@pari.edu> <20031125184513.GB24345@devserv.devel.redhat.com> <1069865656.7945.13.camel@delerium.codemonkey.org.uk> Message-ID: <200311261937.32379.lowen@pari.edu> On Wednesday 26 November 2003 11:54 am, Dave Jones wrote: > For the curious, this is the dual P90 that Caldera[*] sent Alan > for SMP development. It's incredibly clunky, weighs a ton, and > in comparison to any of todays hardware, is almost painful to use > for anything serious. Sounds alot like the HP NetServer LS 5/133 I have.... big, bulky, heavy, and a royal pain to use (mixed EISA PCI box). But it_was_ a freebie, and it works great, has a built-in aic7xxx dual channel controller, and a six bay hotswap SCA chassis. It's being built up as a CD server, with 98 CD-ROM drives hooked up to it, eventually. The CD's are rack mounts made by SMS and include the requisite LUN SCSI Expander with seven CD's per unit, attached via two AHA-1740's. Will be interesting to see if it works correctly with the Linux kernel LUN support (I had to rebuild the kernel for multiple luns anyway, so building for SMP wasn't that big of a deal). > It would be fun to get Fedora on that monster some time though. It took IIRC a mere 2 hours to upgrade this beast to FC1, from RHL 8.0. The upgrade zonked the lilo config, and blew out the SMP kernel at the same time. Interesting upgrade, it was. The reboot acutally picked up the old kernel (I had a custom 2.4.20 kernel with SuperFreeS/WAN, which was a good thing, otherwise the box might not have booted at all), but tons of module errors later I was able to edit lilo.conf, recreate some lilo files, and rerun /sbin/lilo to get the thing booting again. And I know it's not a supported config.... > I thought we were actually churning out i586-smp kernels, but > I just checked and spotted the exclusion in the spec file. > I'll nuke that, and push one out sometime for folks to play with. Dave, one day when you have time I'd like for you to explain the kernel spec's use of --with and --without and how that's communicated to the spec file build logic. I would love to use --with and --without to do the conditional subpackage building in PostgreSQL instead of the more unweildy --define 'tcl 0' etc. This might even be interesting to others on list. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From drepper at redhat.com Thu Nov 27 00:50:25 2003 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 26 Nov 2003 16:50:25 -0800 Subject: FC2 and general LDAP Support In-Reply-To: <3FC48BF0.60005@israel-jugendtag.ch> References: <3FC48BF0.60005@israel-jugendtag.ch> Message-ID: <3FC54A51.7050002@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lengthy thread, but I still want to add my 2?. Making LDAP the default is overkill for a lot of people. Centralized administration is useful in larger networks and maybe even in some home networks. My home network certainly qualifies as not-small but I still wouldn't want it since I have different configurations on the different machines. LDAP must be introduced on demand, and not forced upon one. BTW: it's not only the LDAP daemon which is needed, every machine in the network would also have to use nscd. Without it LDAP can be, ehm, slow. What I completely agree with is that the LDAP integration into the distribution isn't as good as it could get (euphemism). Every time I have to install it I do something wrong and it ends up costing me hours. So, what I'd suggest as a first step is writing some meta RPMs which do the conversion for you. This Sun jvm RPM which has been repeatedly mentioned here is a splendid idea: don't distribute the code, just a way to make it work. Make the code a dependency. Same can be done for the LDAP stuff. Make an RPM which requires all the LDAP components which then does all or parts of this list: ~ create a key for the server ~ run the migration scripts ~ make the ldap nss module used locally ~ make sure nscd is running ~ eventually replace programs like useradd with useradd.ldap ~ create a script the admin can run on the other machines in the network ~ etc etc Make it a pleasant experience to install LDAP. No programming experience requires, just admin knowledge. Step 2 is then creating an environment to actually maintain such an installation. Probably graphic tools etc. But this is step 2. IMO such meta RPMs are truly a nice way to do these things. There can even be multiple versions of such RPMs. For instance for the LDAP case, with or without AD support. That's a nice little project for somebody who wants to get involved in the FC project. I can certainly add what I know. Volunteers? - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/xUpR2ijCOnn/RHQRAoshAKChePkYG8o4qhZ3utsxNEj20pYDIgCeJOc6 XaITdUs0RAW1LV0/PtWKBlI= =9LLk -----END PGP SIGNATURE----- From xose at wanadoo.es Thu Nov 27 00:54:30 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Thu, 27 Nov 2003 01:54:30 +0100 Subject: RPM tricks References: <200311211715.43696.lowen@pari.edu> <20031125184513.GB24345@devserv.devel.redhat.com> <1069865656.7945.13.camel@delerium.codemonkey.org.uk> <200311261937.32379.lowen@pari.edu> Message-ID: <3FC54B46.2050901@wanadoo.es> Lamar Owen wrote: > Dave, one day when you have time I'd like for you to explain the kernel spec's > use of --with and --without and how that's communicated to the spec file > build logic. I would love to use --with and --without to do the conditional > subpackage building in PostgreSQL instead of the more unweildy --define 'tcl > 0' etc. This might even be interesting to others on list. I have done it in the zmailer spec file, easy: %configure \ --includedir=%{_Zincludedir} \ --libdir=%{_libdir} \ --mandir=%{_mandir} \ --prefix=%{_prefix} \ --with-perl-installdirs=PREFIX=%{buildroot}/%{_prefix} \ --with-zconfig=%{_Zsysconfdir}/zmailer.conf \ --with-logdir=%{_Zlogdir} \ --with-mailbin=%{_Zlibexecdir} \ --with-mailbox=%{_Zmaildir} \ --with-mailvar=%{_Zsysconfdir} \ --with-mailshare=%{_Zsysconfdir} \ --with-postoffice=%{_Zpostoffdir} \ --with-rmailpath=%{_bindir}/rmail \ --with-sendmailpath=%{_sbindir}/sendmail \ --with-vacationpath=%{_bindir}/vacation \ --with-system-malloc \ %{?_with_ssl:--with-openssl} \ %{?_with_ldap:--with-ldap} \ %{?_with_sasl2:--with-sasl2} \ %{?_with_ipv6:--with-ipv6} \ %{?_with_tcpw:--with-tcp-wrappers} \ %{?_with_whoson:--with-whoson} \ %{?_with_yp:--with-yp} -- HTML mails are going to trash automagically From ms-nospam-0306 at arcor.de Thu Nov 27 01:02:59 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 27 Nov 2003 02:02:59 +0100 Subject: AIDE versus Tripwire Re: Tripwire news In-Reply-To: References: <20031124181319.1e7f4b55.ms-nospam-0306@arcor.de> Message-ID: <20031127020259.090e66ba.ms-nospam-0306@arcor.de> On Thu, 27 Nov 2003 01:14:42 +0100 (CET), unspawn wrote: > //O.T.; Michael I hope you will join the Aide mailinglist to help iron out > whatever is wrong or submit a bugreport, TIA. My last series of bug report submissions is three weeks old. They are still open. I always appreciate feedback on bug reports. Since memory leaks (and Valgrind leak-checks) have been discussed on one of the mailing-lists before, I didn't report them again separately when I contributed fixes for some leaks two months ago. There are still several memory leaks. My comment in SF.net request ID 803001 explains why I think some of the remaining leaks may be more difficult to fix. -- From ms-nospam-0306 at arcor.de Thu Nov 27 01:06:18 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 27 Nov 2003 02:06:18 +0100 Subject: SMP i586? In-Reply-To: <200311261937.32379.lowen@pari.edu> References: <200311211715.43696.lowen@pari.edu> <20031125184513.GB24345@devserv.devel.redhat.com> <1069865656.7945.13.camel@delerium.codemonkey.org.uk> <200311261937.32379.lowen@pari.edu> Message-ID: <20031127020618.2bb9fe9a.ms-nospam-0306@arcor.de> On Wed, 26 Nov 2003 19:37:32 -0500, Lamar Owen wrote: > Dave, one day when you have time I'd like for you to explain the kernel spec's > use of --with and --without and how that's communicated to the spec file > build logic. I would love to use --with and --without to do the conditional > subpackage building in PostgreSQL instead of the more unweildy --define 'tcl > 0' etc. This might even be interesting to others on list. There are docs about that in: /usr/share/doc/rpm-*/conditionalbuilds -- From enrico.scholz at informatik.tu-chemnitz.de Thu Nov 27 02:12:36 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 27 Nov 2003 03:12:36 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <3FC48BF0.60005@israel-jugendtag.ch> ( =?iso-8859-1?q?Roland_K=E4ser's_message_of?= "Wed, 26 Nov 2003 12:18:08 +0100") References: <3FC48BF0.60005@israel-jugendtag.ch> Message-ID: <87k75mr23v.fsf@kosh.ultra.csn.tu-chemnitz.de> roli at israel-jugendtag.ch (Roland K?ser) writes: > What about moving the user database to LDAP for the FC2 release? LDAP is not LDAP. Depending on the environment, different schemes with different, perhaps mandatory attributes will be used. So you will need some pre-configuration before installing the real Fedora Core and the useradd tools must be configurable to support the used scheme with reasonable defaults. 'useradd' will have to deal with other attributes (address, jpegphoto) and used authentication method (e.g. krb5 allows special password attributes). Implementing this is not trivial and would be too much overkill for normal usage of FC (a standalone desktop). The nss_ldap module is ... aeh .. a little bit unstable; using it with TLS and non-selfsigned certificates gives mysterious faults when CA chain is not known, and network-faults are giving authentication errors for local users (root). > It would be possible to integrate also the samba part of the user > records directly to the LDAP directory. The only thing we need is a > useful ldap administration frontend I have never tested it, but http://www.gonicus.de/eng/index.html sounds very promising. Enrico From nakedchimp at comcast.net Thu Nov 27 02:53:09 2003 From: nakedchimp at comcast.net (NakedChimp) Date: Wed, 26 Nov 2003 20:53:09 -0600 Subject: FC2 and general LDAP Support In-Reply-To: <1069884644.2145.3.camel@teapot.felipe-alfaro.com> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> <1069884644.2145.3.camel@teapot.felipe-alfaro.com> Message-ID: <1069901588.4367.319.camel@atari.slipstream.lan> On Wed, 2003-11-26 at 16:10, Felipe Alfaro Solana wrote: > On Wed, 2003-11-26 at 16:12, Roland K?ser wrote: > > The redmond bill hat not that many good > > ideas but the one with the registry was a good one. > > I couldn't disagree more. The Windoze registry is a pseudo-monolithic > piece of binary information that can't be easily edited, backed up or > manually edited in case of corruption or failure. Even GNOME's approach > with GConf is still a mess (have you ever tried looking for a config > element inside the XML files?) > Just had to throw in my two cents. First off, yes, I am an "Windoze" administrator for a company with about 50000 workstations and 3000 servers. I have also been using various Linux distributions exclusively at home since early '95 and pimp them every chance I get. I realize that I am not an guru with Linux (and have never used it outside a personal workstation or a Web/File/whatever server), but I do feel I am more then qualified to discuss the Windows Registry. Second off, the Registry _can_ be easily edited and backed up. There are numerous tools, some provided by Microsoft themselves, which give you this capability. If I need to make a change to an app I can create a .REG file for a user with _very_ little work and have them import it on their machine simply by double clicking on it. App changed with no scripting or having the user edit a file. Various scripting languages, such as Perl, WinBatch and VBScript have also extended what the tools offer to give you even more power. How do I know this? Because in a matter of a minute I can sit down and write a script that will go out and change any key in the registry I need to. I have also written Perl scripts that contain about 1000 lines which farm information from the registry and give me better Hardware/Software Inventory then what I get from Third party tools. I didn't have to go through various files, parsing the information out from various different formats to get this information. As far as backup goes, Windows has shipped with a method of backing up the Registry for as long as I can remember. The users even have their own Registry file that stores their configuration which can be backed up and restored easily. On the point about fixing corruption however you are dead on, which has been an issue in the past, but I have yet to see a corrupt registry with Win2K and above OS's (not that it cant happen, I just haven't seen it). As far as failure goes, it all depends on what you mean. If you mean the OS just fails to boot up because someone misconfigured the Registry, then this is wrong as I have dozens of times taken a registry file from one machine and loaded it on another, made the change and put it back on the original machine. In my opinion as an administrator for a large environment, GConf is a blessing. Some people may not like it, but it beats the pants off of any other configuration method I have seen out there, and I for one am glad that Havoc brought it to fruition. I am eagerly awaiting the day that I can have GConf use a DB or LDAP instead of just the filesystem, that way I can configure all the settings in one central location, like Microsoft's Active Directory or Novell's Directory Services. Dislike windows if you will, but don't bash things about it that you have very little idea on how they work. And please don't ignore things out there because you perceive them to be junk. Microsoft isn't the greatest company out there, but they do have some amazingly smart people working for them who have come up with some very good products and ways of doing things. > I don't mind Linux having a lot of configuration files. What I would > like to see is a configuration tool that knows about those files, knows > how to modify them and allows the user to do those changes through a > streamlined, homogeneous user interface. > I have nothing against configurations files. However, from an administrators standpoint, if I have to do something that cannot simply be done by a GUI interface it is a waste of my time to shuffle through each configuration file figuring out each all of their unique nuances. I would much rather prefer something predictable and more customizable. For Example, if I'm going to want to change the settings for an application AppA, I am not going to want to dig through a dot file and figure out the format that this should be put in. Some files require items in a specific order. In some files "#" is a comment while in others a ";" is a comment. I would much rather say, "here is the key that I need changed, and this is the value I need it changed to" and be done with it. What if the app was installed in a different location? Then I have to hunt for it. What If I need to allow the user to change a value, but I don't want them to be able to change every value? In a Registry like system I can lock this down as far as I need it. In a configuration file I need to give the user access to the whole thing (we will leave out discussions of the future of ReiserFS at this point). There are certain things that cannot be easily solved by configuration files and GUI front ends, and I think this is something that seriously needs to be taken look at. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From steve at silug.org Thu Nov 27 03:22:58 2003 From: steve at silug.org (Steven Pritchard) Date: Wed, 26 Nov 2003 21:22:58 -0600 Subject: meta-packages (was Re: FC2 and general LDAP Support) In-Reply-To: <3FC54A51.7050002@redhat.com> References: <3FC48BF0.60005@israel-jugendtag.ch> <3FC54A51.7050002@redhat.com> Message-ID: <20031127032258.GA3037@osiris.silug.org> On Wed, Nov 26, 2003 at 04:50:25PM -0800, Ulrich Drepper wrote: > IMO such meta RPMs are truly a nice way to do these things. That reminds me... Since Fedora Core includes tools that will automatically install dependencies, would now be a good time to think about adding meta-packages for things like KDE, GNOME, etc.? Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From stan at ccs.neu.edu Thu Nov 27 02:18:05 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Wed, 26 Nov 2003 21:18:05 -0500 Subject: evolution problems (filters) In-Reply-To: <47f55aa703046007d3@[192.168.170.10]> References: <44b8697d02040f07d3@[192.168.170.10]> <47f55aa703046007d3@[192.168.170.10]> Message-ID: <1069899484.1413.4.camel@duergar> On Wed, 2003-11-26 at 03:33, =?ISO-8859-1?Q? Nils O. Sel=E5sdal?= wrote: > Be sure you have a "Stop Processing" rule after your "Move Message to > .." or similar. If you don't have that, the message will be matched > against several rules, and potentionally copied for each match. > Umm what? You have to use Stop Processing in every rule that moves messages to a folder??? I thought that was only necessary with piped or external commands? If so that is retarded... -sb From cmadams at hiwaay.net Thu Nov 27 03:59:15 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 26 Nov 2003 21:59:15 -0600 Subject: SMP i586? In-Reply-To: <200311261937.32379.lowen@pari.edu> References: <200311211715.43696.lowen@pari.edu> <20031125184513.GB24345@devserv.devel.redhat.com> <1069865656.7945.13.camel@delerium.codemonkey.org.uk> <200311261937.32379.lowen@pari.edu> Message-ID: <20031127035915.GA1329137@hiwaay.net> Once upon a time, Lamar Owen said: > Dave, one day when you have time I'd like for you to explain the kernel spec's > use of --with and --without and how that's communicated to the spec file > build logic. I would love to use --with and --without to do the conditional > subpackage building in PostgreSQL instead of the more unweildy --define 'tcl > 0' etc. This might even be interesting to others on list. Last time I looked, the kernel.spec file dropped all support for --with and --without some time back. There are still references in comments, but I don't think any actually work (unless there is some behind the scenes RPM magic going on). It is kind of annoying when you are trying to rebuild just one package. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From pmatilai at welho.com Thu Nov 27 08:00:18 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 27 Nov 2003 10:00:18 +0200 (EET) Subject: meta-packages (was Re: FC2 and general LDAP Support) In-Reply-To: <20031127032258.GA3037@osiris.silug.org> References: <3FC48BF0.60005@israel-jugendtag.ch> <3FC54A51.7050002@redhat.com> <20031127032258.GA3037@osiris.silug.org> Message-ID: On Wed, 26 Nov 2003, Steven Pritchard wrote: > On Wed, Nov 26, 2003 at 04:50:25PM -0800, Ulrich Drepper wrote: > > IMO such meta RPMs are truly a nice way to do these things. > > That reminds me... Since Fedora Core includes tools that will > automatically install dependencies, would now be a good time to think > about adding meta-packages for things like KDE, GNOME, etc.? Been there, done that, trust me you do not want those as meta-packages (empty packages except with huge amount of requires: foo, bar ...). There are better ways to achieve the effect, have a look at yum's groupinstall operation which uses comps.xml to find out what belongs to what group but doesn't require installing additional bogus packages which just create bogus dependencies. Apt can do the same with a little help from Lua, latest apt-rpm version has apt-groupinstall in contrib/ directory which does just that. - Panu - From nos at utel.no Thu Nov 27 08:06:58 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Thu, 27 Nov 2003 09:06:58 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <4b66ce9904055e07d3@[192.168.170.10]> References: <3FC48BF0.60005@israel-jugendtag.ch><4b66ce9904055e07d3@[192.168.170.10]> Message-ID: <4cf703a904058207d3@[192.168.170.10]> On Thu, 2003-11-27 at 01:50, Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lengthy thread, but I still want to add my 2?. > > Making LDAP the default is overkill for a lot of people. Centralized > administration is useful in larger networks and maybe even in some home > networks. My home network certainly qualifies as not-small but I still > wouldn't want it since I have different configurations on the different > machines. LDAP must be introduced on demand, and not forced upon one. > > BTW: it's not only the LDAP daemon which is needed, every machine in the > network would also have to use nscd. Without it LDAP can be, ehm, slow. > > > What I completely agree with is that the LDAP integration into the > distribution isn't as good as it could get (euphemism). Every time I > have to install it I do something wrong and it ends up costing me hours. > > So, what I'd suggest as a first step is writing some meta RPMs which do > the conversion for you. This Sun jvm RPM which has been repeatedly > mentioned here is a splendid idea: don't distribute the code, just a way > to make it work. Make the code a dependency. > > Same can be done for the LDAP stuff. Make an RPM which requires all the > LDAP components which then does all or parts of this list: > > ~ create a key for the server > ~ run the migration scripts > ~ make the ldap nss module used locally > ~ make sure nscd is running > ~ eventually replace programs like useradd with useradd.ldap > ~ create a script the admin can run on the other machines in the network > ~ etc etc Authconfig allows you to do atleast half of this. Atleast most things needed at the client side. What is more needed is an administration application. Capable of doing what gq does today, but also more specialized features such as initializing the ldap server. -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From felipe_alfaro at linuxmail.org Thu Nov 27 08:21:21 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 27 Nov 2003 09:21:21 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <3FC53433.5050500@israel-jugendtag.ch> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> <1069884644.2145.3.camel@teapot.felipe-alfaro.com> <3FC53433.5050500@israel-jugendtag.ch> Message-ID: <1069921280.2476.6.camel@teapot.felipe-alfaro.com> On Thu, 2003-11-27 at 00:16, Roland K?ser wrote: > Think of blade servers for web-application clusters. In a number of 50 > to 100 servers. With the ldap system it might be possible to just > remotly install a new blade. It this installation starts for the first > time, it takes all the configuration settings out of an centralized > configuration store and works after that automaticly. If its need to > change the default start page of a webserver, the connection to the > database for the applications, etc. with that system it needs just to be > changed in the central config store and not on every single machine. > > >While I am an LDAP advocate and agree that an admin tool for managing > >users and groups in LDAP would be an appreciated addition (and maybe > >managing printers and such there too), using it as the default would be > >way overkill. There are simply too many problems and it's not easy for > >the less experienced to deal with. > > It is not ment that with an LDAP Server all the users needs to know > about LDIF-files, schema files etc. The goal behind it should be that > the users doesn't needs to know all about that. They should can > administrate the system as it was bevore. I didn't say I wasn't against LDAP ;-), but against a registry-like repository like Windoze Registry. I even don't like GNOME's GConf. While I worked at Sun, I worked heavily with Sun ONE products. Nearly all of them store their configuration on a centralized LDAP server. But as someone said, having LDAP used by default is overkill.We must work towards this goal: all applications should support LDAP, but also should support local files and use them by default. For some scenarios, LDAP is not suitable, like for example, appliances or servers running on the DMZ. I think that deploying an LDAP server on the DMZ is overkill. From felipe_alfaro at linuxmail.org Thu Nov 27 08:30:28 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 27 Nov 2003 09:30:28 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <1069901588.4367.319.camel@atari.slipstream.lan> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> <1069884644.2145.3.camel@teapot.felipe-alfaro.com> <1069901588.4367.319.camel@atari.slipstream.lan> Message-ID: <1069921828.2476.14.camel@teapot.felipe-alfaro.com> On Thu, 2003-11-27 at 03:53, NakedChimp wrote: > corruption however you are dead on, which has been an issue in the past, > but I have yet to see a corrupt registry with Win2K and above OS's (not > that it cant happen, I just haven't seen it). As far as failure goes, > it all depends on what you mean. If you mean the OS just fails to boot > up because someone misconfigured the Registry, then this is wrong as I > have dozens of times taken a registry file from one machine and loaded > it on another, made the change and put it back on the original machine. Then, there's the problem with the maximum registry size, registry hives starting to grow but not being compacted, machines being unable to boot because the registry is bigger than 16MB and Windows won't load it, etc. I didn't say Windoze Registry didn't work well in most cases. In fact, I have only had a couple of minor problems with it. The whole idea is great, but I think the implementation is weak. I prefer GNOME'S GConf which approaches the same goal just with a different implementation. > In my opinion as an administrator for a large environment, GConf is a > blessing. Some people may not like it, but it beats the pants off of > any other configuration method I have seen out there, and I for one am > glad that Havoc brought it to fruition. I am eagerly awaiting the day > that I can have GConf use a DB or LDAP instead of just the filesystem, > that way I can configure all the settings in one central location, like > Microsoft's Active Directory or Novell's Directory Services. In fact, this is a great idea. Maybe Novell can devote some developers to build different GConf engines as you describe. > > Dislike windows if you will, but don't bash things about it that you > have very little idea on how they work. And please don't ignore things > out there because you perceive them to be junk. Microsoft isn't the > greatest company out there, but they do have some amazingly smart people > working for them who have come up with some very good products and ways > of doing things. It's a lot of time since I don't work with Windows anymore, and I'm not bashing it. Having worked with it for more than a decade I think I knew about it in great detail. I was saying that I didn't like the Registry implementation, nothing more. Please, don't get me wrong :-) From Nicolas.Mailhot at laposte.net Thu Nov 27 08:59:33 2003 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 27 Nov 2003 09:59:33 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <20031126235000.GB22360@devserv.devel.redhat.com> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> <1069884644.2145.3.camel@teapot.felipe-alfaro.com> <3FC53433.5050500@israel-jugendtag.ch> <20031126235000.GB22360@devserv.devel.redhat.com> Message-ID: <1069923572.9270.10.camel@ulysse.olympe.o2t> Le jeu 27/11/2003 ? 00:50, Alan Cox a ?crit : > On Thu, Nov 27, 2003 at 12:16:03AM +0100, Roland K?ser wrote: > > It is not ment that with an LDAP Server all the users needs to know > > about LDIF-files, schema files etc. The goal behind it should be that > > the users doesn't needs to know all about that. They should can > > administrate the system as it was bevore. > > Mechanism and goal are seperable. So lets imagine I'm a random end user > or admin who doesn't know (or care) about stuff like LDAP. Can you concisely > describe why I want the things you see it giving - without reference to the > technology at all. Easy scalability beyond single-system networks A contact db that is actually shared between all mail apps, is remotely accessible and contains every single local user as soon as it's created. Easier samba integration. Lots of cool postfix(...) rewriting tricks. Other people will see other things (like a shared gconf backend...) The fact is right now openldap is a pig to install/configure but if it weren't I'm sure an awful lot of people could find a use for it. Just take every single config file on the system that is a list of something and you'll probably be better of with a ldap version of it. (now of course if ldap can not be made light enough for single-user systems that's a big showstopper). 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 Nicolas.Mailhot at laposte.net Thu Nov 27 09:02:15 2003 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 27 Nov 2003 10:02:15 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <1069892852.3700.59.camel@denk.nakedape.priv> References: <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <3FC4B7B6.8060800@israel-jugendtag.ch> <20031126182601.GB13830@devserv.devel.redhat.com> <1069888100.3700.55.camel@denk.nakedape.priv> <20031127001048.GB10299@orient.maison.moi> <1069892852.3700.59.camel@denk.nakedape.priv> Message-ID: <1069923734.9270.13.camel@ulysse.olympe.o2t> Le jeu 27/11/2003 ? 01:27, Wil Cooley a ?crit : > On Wed, 2003-11-26 at 16:10, Emmanuel Seyman wrote: > > On Wed, Nov 26, 2003 at 03:08:20PM -0800, Wil Cooley wrote: > > > > > > There are fairly easy ways to make it work, though. One approach would > > > > Wouldn't it be easier to keep things the way they are now (ie stay > > with the multiple files way of doing things as default and make choosing > > LDAP as easy as clicking on a checkbox)? > > Well, from the context of switching, yes, it would. However like for kernel 2.4 v 2.6 you won't achieve the same level of integration/quality unless you choose a single method as default. 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 twaugh at redhat.com Thu Nov 27 10:05:57 2003 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 27 Nov 2003 10:05:57 +0000 Subject: VNC can't stats binary! In-Reply-To: <1069718890.20570.6.camel@va.local.linuxlobbyist.org> References: <3FC089A0.9090609@opentle.org> <1069718890.20570.6.camel@va.local.linuxlobbyist.org> Message-ID: <20031127100557.GG6829@redhat.com> On Mon, Nov 24, 2003 at 07:08:11PM -0500, Paul Iadonisi wrote: > I'm not sure what you mean by saying you couldn't rebuild it, but I > don't think that's relevant, anyhow. The problem is likely with the > 'file' command, not with Xvnc itself. Indeed --- and it's even in bugzilla, and referenced in the file(1) changelog in rawhide (where it is fixed). Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mr-fedora at linuxalert.org Thu Nov 27 10:12:01 2003 From: mr-fedora at linuxalert.org (Magnus Runesson) Date: Thu, 27 Nov 2003 11:12:01 +0100 Subject: FC2 and general LDAP Support In-Reply-To: <4cf703a904058207d3@[192.168.170.10]> References: <3FC48BF0.60005@israel-jugendtag.ch> <4b66ce9904055e07d3@[192.168.170.10]> <4cf703a904058207d3@[192.168.170.10]> Message-ID: <1069927921.5853.10.camel@pamina.linuxalert.org> > Authconfig allows you to do atleast half of this. Atleast most things > needed at the client side. What is more needed is an administration > application. Capable of doing what gq does today, but also more > specialized features such as initializing the ldap server. The problem is that authconfig is buggy and creates a faulty config for pam using LDAP See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55193 Patches and solutions can be found there. Can someone with proper rights please integrate one of the solutions into Fedora. /Magnus -- Magnus Runesson From mrchoke at opentle.org Thu Nov 27 10:50:15 2003 From: mrchoke at opentle.org (Supphachoke Suntiwichaya) Date: Thu, 27 Nov 2003 17:50:15 +0700 Subject: VNC can't stats binary! In-Reply-To: <1069718890.20570.6.camel@va.local.linuxlobbyist.org> References: <3FC089A0.9090609@opentle.org> <1069718890.20570.6.camel@va.local.linuxlobbyist.org> Message-ID: <3FC5D6E7.8080100@opentle.org> Paul Iadonisi wrote: >On Sun, 2003-11-23 at 05:19, Supphachoke Suntiwichaya wrote: > > >>I download vnc-server-4.0-0.beta4.3.2.i386.rpm from update site. >>It seem incorrect. >> >>it norespond when >> >># file /usr/bin/Xvnc >> >>?? >> >>I rebuilded but it can't .. >> >> > > I'm not sure what you mean by saying you couldn't rebuild it, but I >don't think that's relevant, anyhow. The problem is likely with the >'file' command, not with Xvnc itself. Wanna see something even > > Sorry about my English. >weirder? Try 'file /usr/bin/*' and you'll notice that it *doesn't* hang >and even returns 'executable,' for Xvnc. Try any other file glob >(/usr/bin/X*, /usr/bin/[x-z]*' that matches Xvnc, and it does hang. >Something very strange is going on here. I even tried a for loop to >loop through all the binaries in /usr/bin, /bin, /usr/sbin, /sbin, and >/usr/X11R6/bin and Xvnc is the *only* binary that the file command hangs >on. > > > I make a new distribution and used update package (VNC) from update site, script udp-installroot can't run "file /usr/bin/Xvnc " it not responde . but not happen when used old VNC .. MrChoke > Running it with strace doesn't reveal anything very informative, at >least not to me. > > Anybody else seeing this behavior? > > > -- Name : Supphachoke Suntiwichaya Email : MrChoke at opentle.org URL : http://jedi.links.nectec.or.th/mrchoke/ Distribution : LinuxTLE 5.0.95 (AowThai) OS : Linux 2.4.22-6_1.2115.nptl_2tle #1 Sun Nov 23 12:51:40 ICT 2003 i686 GNU/Linux Uptime : 17:40:00 up 2 days, 7:25, 1 user, load average: 1.27, 0.55, 0.36 -------------- next part -------------- An HTML attachment was scrubbed... URL: From iamfezzik at hotmail.com Thu Nov 27 15:32:18 2003 From: iamfezzik at hotmail.com (Fezzik Giant) Date: Thu, 27 Nov 2003 15:32:18 +0000 Subject: I gotta ask this ... Message-ID: Hi Michael, On the face of it, you'd think that -- and I'm normally a pretty patient person. However I've seen several requests go unanswered over the last few weeks, which made me wonder. As for googling, yeah I did that. For a few days. Nothing concrete came up. Certainly nothing as good as the information I've accumulated from the posts last night. Perhaps I'm not adept at googling but I tried several variations of searchs. And, if people are tired of answer this question -- well theres a good entry for a FAQ :) In any case, thanks for the suggestions. F >From: Michael Schwendt >Reply-To: fedora-devel-list at redhat.com >To: fedora-devel-list at redhat.com >Subject: Re: I gotta ask this ... >Date: Wed, 26 Nov 2003 23:32:52 +0100 > >On Wed, 26 Nov 2003 21:26:01 +0000, Fezzik Giant wrote: > > > I have seen several posts in the past where someone asks about building > > Fedora ISO images. I have yet to see a response. > > > > Surely _someone_ must know how this is done. Why is there never a >response? > > Is this knowledge a 'secret sauce' that nobody wishes to share? > >Let me guess. Those who know how to do it and who are subscribed here >either will answer later or are tired of re-posting information that can be >found in the various list archives or via Google. > > >-- >Casting "minor flame-shield"... ><< attach3 >> _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From nakedchimp at comcast.net Thu Nov 27 16:16:33 2003 From: nakedchimp at comcast.net (NakedChimp) Date: Thu, 27 Nov 2003 10:16:33 -0600 Subject: FC2 and general LDAP Support In-Reply-To: <1069921828.2476.14.camel@teapot.felipe-alfaro.com> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> <1069884644.2145.3.camel@teapot.felipe-alfaro.com> <1069901588.4367.319.camel@atari.slipstream.lan> <1069921828.2476.14.camel@teapot.felipe-alfaro.com> Message-ID: <1069949792.4367.340.camel@atari.slipstream.lan> On Thu, 2003-11-27 at 02:30, Felipe Alfaro Solana wrote: > Then, there's the problem with the maximum registry size, registry hives > starting to grow but not being compacted, machines being unable to boot > because the registry is bigger than 16MB and Windows won't load it, etc. > This has been fixed for a while (since NT4?). I'm pretty sure I have seen rare cases of the Registry files growing in excess of 40MB, and I know there has been occasions in the past where I have had to bump up the Max Registry size to 40MB because an application would not install (ClearCase/ClearQuest). However, you are correct about the compression issue, which is my mind a huge downfall. I'm not trying to say that the Windows Registry does not have any flaws, but from an Enterprise standpoint it really is a better way of doing things then configuration files. Then came along GConf however and the book is now beginning to be rewritten :) > It's a lot of time since I don't work with Windows anymore, and I'm not > bashing it. Having worked with it for more than a decade I think I knew > about it in great detail. I was saying that I didn't like the Registry > implementation, nothing more. Please, don't get me wrong :-) > I apologize for reading your message wrong. I just want it to get through that from an Enterprise standpoint, a Registry like system (ie. a central standard repository for configuration information, for example GConf) is really a much better way of doing things then having to write a complex backend parser for a simple GUI frontend. With a Registry type system I am no longer required to write these complex backend parsers, and I can concentrate on spewing out nice friendly frontends at an alarming rate, and for those who have the need to make mass changes, they can write quick little tools to do their job using standard command line tools or even something like the GConf Perl module. From shahms at shahms.com Thu Nov 27 18:08:07 2003 From: shahms at shahms.com (Shahms E. King) Date: Thu, 27 Nov 2003 10:08:07 -0800 Subject: FC2 and general LDAP Support In-Reply-To: <87k75mr23v.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <3FC48BF0.60005@israel-jugendtag.ch> <87k75mr23v.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1069956487.5273.17.camel@localhost.localdomain> On Wed, 2003-11-26 at 18:12, Enrico Scholz wrote: > roli at israel-jugendtag.ch (Roland K?ser) writes: > > > What about moving the user database to LDAP for the FC2 release? > > LDAP is not LDAP. Depending on the environment, different schemes with > different, perhaps mandatory attributes will be used. So you will need > some pre-configuration before installing the real Fedora Core and the > useradd tools must be configurable to support the used scheme with > reasonable defaults. 'useradd' will have to deal with other attributes > (address, jpegphoto) and used authentication method (e.g. krb5 allows > special password attributes). > > Implementing this is not trivial and would be too much overkill for normal > usage of FC (a standalone desktop). The nss_ldap module is ... aeh .. a > little bit unstable; using it with TLS and non-selfsigned certificates > gives mysterious faults when CA chain is not known, and network-faults are > giving authentication errors for local users (root). Different schemas is one thing, but, um, there are actually standard schemas defined (that come with OpenLDAP) for all of this. You can pretty much bet that if someone has users and groups in the LDAP server, they're using posixAccount and posixGroup objectclasses to do it. And if they're using Samba 2.x with LDAP they're using sambaAccount (yes, I promise you they are, they don't have a choice in the matter). The useradd tools don't need to know anything about the schema beyond what is already available in /etc/ldap.conf (which provides a simple system of 'attribute maps' to deal with slight variations in attribute names between schemas that don't follow the "standard" -- NDS, AIX, and AD SFU being the most egregious offenders). Additionally, while I think it's ridiculous to put the user database in LDAP where it isn't warranted (especially by default), if that were to happen, schemas would not be an issue as there would only be one schema used by the Fedora LDAP user information and you can be almost certain the Fedora user management tools would understand that schema at the very least. There is a difference between stability and a poor default configuration. I have had problems with SSL/TLS as well (but, well, the certs we use have issues, they're self-signed and expired, so having problems is to be expected ;-P). Network faults (well, *any* fault) can cause auth errors for local users if pam is configured incorrectly, otherwise network errors will not impact local users *at all* (well, other than a possible delay when they enter their password). Unfortunately, the Fedora authconfig *slightly* misconfigures pam by leaving out 'service_err=ignore' (I think, it's been a while since I've had to fix this anywhere it might be 'system_err=ignore' that it doesn't add.) But anyway, once it's correctly configured I've never had any problems with stability. -- --Shahms -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jules at tdcadsl.dk Thu Nov 27 19:48:41 2003 From: jules at tdcadsl.dk (Jules Colding) Date: Thu, 27 Nov 2003 20:48:41 +0100 Subject: I gotta ask this ... In-Reply-To: <20031126223052.GC7682@devserv.devel.redhat.com> References: <20031126223052.GC7682@devserv.devel.redhat.com> Message-ID: <1069962521.8430.77.camel@localhost.localdomain> On Wed, 2003-11-26 at 23:30, Alan Cox wrote: > > I have seen several posts in the past where someone asks about building > > Fedora ISO images. I have yet to see a response. > > > > Surely _someone_ must know how this is done. Why is there never a response? > > Is this knowledge a 'secret sauce' that nobody wishes to share? > > Not really secret sauce. Build all the packages, boot the result, build > all the packages again with it, figure out how to fit it all and the installer > on the CD images and burn. One way to do this is to look at LFS. The idea is to make a shell script to do what the LFS book says. I have done this once and are doing it again (for various reasons) right now. It would be a simple, but tedious, job to replace the LFS packages with fedora packages. One downside with my current approach is that I am building a system from tarballs and SRPMs but the resulting "distribution" is not RPM based. I think someone could fix this when I am done.. Just ask and I will mail the resulting scripts (under the GPL) to whoever wants them, when I am done. -- jules From wrrhdev at riede.org Thu Nov 27 20:43:10 2003 From: wrrhdev at riede.org (Willem Riede) Date: Thu, 27 Nov 2003 15:43:10 -0500 Subject: FC2, 2.6 vs 2.4 In-Reply-To: <1069699017.2670.4.camel@delerium.codemonkey.org.uk> (from davej@redhat.com on Mon, Nov 24, 2003 at 13:36:57 -0500) References: <200311132238.hADMc9J30475@devserv.devel.redhat.com> <3FB40D0B.7000708@wanadoo.es> <20031113230813.GF968812@hiwaay.net> <3FB53CC8.2000306@wanadoo.es> <1068845910.1119.7.camel@agnes.fremen.dune> <3FB556FF.2090601@wanadoo.es> <200311180702.hAI72STS021128@devserv.devel.redhat.com> <1069699017.2670.4.camel@delerium.codemonkey.org.uk> Message-ID: <20031127204310.GL5672@linnie.riede.org> On 2003.11.24 13:36, Dave Jones wrote: > On Tue, 2003-11-18 at 07:02, Pete Zaitcev wrote: > > > The problem with ide-scsi is that it's needed for tapes. > > Burning is easy. > > It's my current understanding that ide-tape is less broken than > ide-scsi. (Although it too needs fixing iirc). For OnStream tapes the reverse is true. ide-tape's support is obsolete as well as broken. Here having ide-scsi+osst is the only way. Thanks, Willem Riede. From iainr at zathras.org Thu Nov 27 21:06:47 2003 From: iainr at zathras.org (Iain Rae) Date: Thu, 27 Nov 2003 21:06:47 +0000 Subject: FC2 and general LDAP Support In-Reply-To: <1069921280.2476.6.camel@teapot.felipe-alfaro.com> References: <487bd5ee03048b07d3@[192.168.170.10]> <488b6a5203048f07d3@[192.168.170.10]> <48e20ffc0304ad07d3@[192.168.170.10]> <48f1bc280304b207d3@[192.168.170.10]> <492ca0e40304c907d3@[192.168.170.10]> <4933743f0304d107d3@[192.168.170.10]> <3FC4C2F4.3030704@israel-jugendtag.ch> <1069884644.2145.3.camel@teapot.felipe-alfaro.com> <3FC53433.5050500@israel-jugendtag.ch> <1069921280.2476.6.camel@teapot.felipe-alfaro.com> Message-ID: <3FC66767.80205@zathras.org> Felipe Alfaro Solana wrote: >On Thu, 2003-11-27 at 00:16, Roland K?ser wrote: > > > >>Think of blade servers for web-application clusters. In a number of 50 >>to 100 servers. With the ldap system it might be possible to just >>remotly install a new blade. It this installation starts for the first >>time, it takes all the configuration settings out of an centralized >>configuration store and works after that automaticly. If its need to >>change the default start page of a webserver, the connection to the >>database for the applications, etc. with that system it needs just to be >>changed in the central config store and not on every single machine. >> >> >> >>>While I am an LDAP advocate and agree that an admin tool for managing >>>users and groups in LDAP would be an appreciated addition (and maybe >>>managing printers and such there too), using it as the default would be >>>way overkill. There are simply too many problems and it's not easy for >>>the less experienced to deal with. >>> >>> >>It is not ment that with an LDAP Server all the users needs to know >>about LDIF-files, schema files etc. The goal behind it should be that >>the users doesn't needs to know all about that. They should can >>administrate the system as it was bevore. >> >> > >I didn't say I wasn't against LDAP ;-), but against a registry-like >repository like Windoze Registry. I even don't like GNOME's GConf. > >While I worked at Sun, I worked heavily with Sun ONE products. Nearly >all of them store their configuration on a centralized LDAP server. But >as someone said, having LDAP used by default is overkill.We must work >towards this goal: all applications should support LDAP, but also should >support local files and use them by default. For some scenarios, LDAP is >not suitable, like for example, appliances or servers running on the >DMZ. I think that deploying an LDAP server on the DMZ is overkill. > > Also you get into all kinds of fun and games with laptops, if you want to use them disconnected then you're going to have to run a local ldap server and deal with all the replication issues that go with it. > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From iamfezzik at hotmail.com Thu Nov 27 21:13:45 2003 From: iamfezzik at hotmail.com (Fezzik Giant) Date: Thu, 27 Nov 2003 21:13:45 +0000 Subject: I gotta ask this ... Message-ID: Yes, I've recently looked at the LFS book. I wish it was scripted :) Right now the package dependencies are getting in my way (in terms of a manual process). I'm thinking of writing a script that extracts the 'BuildRequires' tags, creates a directed graph of the build dependencies (as different from the installation dependencies), does a topological sort on the graph and kicks off the build process. I would love to get some comments on this approach. Hopefully it's been done and someone can send a link. Cheers! >From: Jules Colding >Reply-To: fedora-devel-list at redhat.com >To: fedora-devel-list at redhat.com >Subject: Re: I gotta ask this ... >Date: Thu, 27 Nov 2003 20:48:41 +0100 > >On Wed, 2003-11-26 at 23:30, Alan Cox wrote: > > > I have seen several posts in the past where someone asks about >building > > > Fedora ISO images. I have yet to see a response. > > > > > > Surely _someone_ must know how this is done. Why is there never a >response? > > > Is this knowledge a 'secret sauce' that nobody wishes to share? > > > > Not really secret sauce. Build all the packages, boot the result, build > > all the packages again with it, figure out how to fit it all and the >installer > > on the CD images and burn. > >One way to do this is to look at LFS. The idea is to make a shell script >to do what the LFS book says. I have done this once and are doing it >again (for various reasons) right now. It would be a simple, but >tedious, job to replace the LFS packages with fedora packages. > >One downside with my current approach is that I am building a system >from tarballs and SRPMs but the resulting "distribution" is not RPM >based. I think someone could fix this when I am done.. > >Just ask and I will mail the resulting scripts (under the GPL) to >whoever wants them, when I am done. > > >-- > jules > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list _________________________________________________________________ Need a shot of Hank Williams or Patsy Cline? The classic country stars are always singing on MSN Radio Plus. Try one month free! http://join.msn.com/?page=offers/premiumradio From claus at beerta.de Thu Nov 27 21:15:19 2003 From: claus at beerta.de (Claus Beerta) Date: Thu, 27 Nov 2003 22:15:19 +0100 Subject: php cli version Message-ID: <1069967718.27341.8.camel@eclipse.is-asp.com> Hi! There seems to be no Version of PHP available which is only for cli usage, i.E build without support for Apache. The PHP package for Fedora Core 1 ships with the cli version, but debends on apache. Is this the way it is supposed to be? I'd rather have a stand-alone version of PHP for shell-scripting too :) Regards, Claus -- Claus Beerta From alan at redhat.com Thu Nov 27 21:29:21 2003 From: alan at redhat.com (Alan Cox) Date: Thu, 27 Nov 2003 16:29:21 -0500 Subject: php cli version In-Reply-To: <1069967718.27341.8.camel@eclipse.is-asp.com> References: <1069967718.27341.8.camel@eclipse.is-asp.com> Message-ID: <20031127212921.GA1637@devserv.devel.redhat.com> > There seems to be no Version of PHP available which is only for cli > usage, i.E build without support for Apache. The PHP package for Fedora > Core 1 ships with the cli version, but debends on apache. > > Is this the way it is supposed to be? I'd rather have a stand-alone > version of PHP for shell-scripting too :) So install Apache and dont enable it 8). Seriously there is a serious problem if you have too many trivial package splits so you have to make a few tradeoffs on the way From enrico.scholz at informatik.tu-chemnitz.de Fri Nov 28 05:31:07 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 28 Nov 2003 06:31:07 +0100 Subject: The current fedora.us buildsystem and future directions Message-ID: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> Hello, the Fedora Project will need a buildsystem which features[1]: Process separation: it MUST be impossible to kill or ptrace processes of other buildroots or of the system. Hiding of foreign processes SHOULD be provided. Device/kernel protection: Direct hardware access through /dev/* entries or modification of kernel parameters through /proc MUST be impossible. Forbidding the creation of such special files is one way to reach it, access restriction another one. Unbreakable chroots: it MUST be impossible for a process in a buildroot to have any kind of access on objects of the systems (e.g. ssh-keys), or write-access on other buildroots. No buildroot-reusing: each build MUST happen in an environment which can not be influenced by previous builds in this environment. This includes both filesystem-objects, and processes. Resource-restrictions: excessive resource-usage (memory, diskspace,...) of a build SHOULD be prevented. Usage of certain resources (e.g. network) MUST be prohibited Good performance: the buildsystem SHOULD should have only a small or non-existing impact on the performance. Working environment: building of common packages MUST succeed. This requires certain /dev entries, and a mounted /proc filesystem at least. Mature userinterface: the system SHOULD assist the buildmaster and automate the most tasks, so that the spent time will be reduced to a minimum. The reasons for these items and how they are solved in the current fedora.us buildsystem are described in http://www.tu-chemnitz.de/~ensc/fedora.us-build/html [HTML], respectively http://www.tu-chemnitz.de/~ensc/fedora.us-build/files/buildsystem.pdf [PDF, 204 KiB] The described buildsystem is in use for a short time only, but it seems to be secure and to work well (it was used in the rh9* -> fc1 mass-rebuild for the most packages). There were some cases which needed manual intervention (e.g. manual disttags), but these were exceptions. A core part is a vserver[2] capable kernel. Unfortunately, it is not ported to the kernels which are shipped with Fedora yet, and chances are only low that it comes into the official 2.6 kernel. Since Red Hat wants a selfhosting buildsystem, alternatives must be investigated. SELinux offers interesting features, but it is new and there are lot of open questions[3]: 1. SELinux can protect foreign processes. But is it possible to hide them in /proc also? 2. Is chroot(2) implemented in a safe manner? Or, can parent directories of build-roots be protected with SELinux policies? Is a safe chroot(2) required at all? 3. What is the performance impact of the policy checking? 4. How can disk/memory usage restricted with SELinux? Would CKRM be an option? 5. Can special mount-operations (e.g. /proc filesystem) be allowed by the policy, or does this require userspace helper also? 6. Setup of an SELinux policy seems to be very complicated. How possible are holes in a setup? It would be nice when an SELinux expert could take a look at this questions and how it can be used in the buildsystem. UML might be another option, but its status (chances to come into official 2.6) and performance impact is not clear. Enrico Footnotes: [1] http://www.tu-chemnitz.de/~ensc/fedora.us-build/html/index.html#id2503177 [2] http://linux-vserver.org [3] http://www.tu-chemnitz.de/~ensc/fedora.us-build/html/ar01s02.html#sec:components:selinux -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From mvd at mylinux.com.ua Fri Nov 28 11:19:55 2003 From: mvd at mylinux.com.ua (Maxim Dziumanenko) Date: Fri, 28 Nov 2003 13:19:55 +0200 Subject: I gotta ask this ... In-Reply-To: References: Message-ID: <1070018394.1882.78.camel@localhost.localdomain> ???, 2003-11-27 ? 23:13, Fezzik Giant ???????: > Yes, I've recently looked at the LFS book. I wish it was scripted :) > > Right now the package dependencies are getting in my way (in terms of a > manual process). I'm thinking of writing a script that extracts the > 'BuildRequires' tags, creates a directed graph of the build dependencies (as > different from the installation dependencies), does a topological sort on > the graph and kicks off the build process. > > I would love to get some comments on this approach. Hopefully it's been done > and someone can send a link. I'm using rather simple prototype of build system written in python. This is not a complete solution, but it works well for me. It works this way: 1. It analyzes spec file and determines list of packages needed to build(BuildReq BuildPreReq fields). 2. Append to this list basic packages needed to build (gcc, rpm-build ...) 3. Recursively determines all packages needed by packages from this list and appends them to list too. 4. Installs them in chroot jail, copies spec and sources, setup environment 5. Build package in chroot 6. If all is Ok, it copies built packages to package set and remove chroot jail. This approach has several advantages 1. You don't break your system anyhow. 2. You always build against actual RPMs 3. This way can be built package to any version of distribution, everything you need is set of its RPM packages. You don't need several virtual or real machines for this. 4. You save disk space, since you don't need to have installed all development packages needed to build every package in distribution. 5. It helps to discover missing dependencies between packages. If some dependency is missing - required package wont be installed in chroot, therefore you cannot built your package until you fix it. Disadvantages: 1. Installing packages in chroot jail need 1-2 minutes on Athlon 2.4GHz with IDE disk. It is possible to reduce this time using RAID. It would be great to append dependencies resolution scheme to build several source packages automatically. But it's impossible for me now because many Fedora packages have missing dependencies and build process stops very often. PS. Sorry for poor English. -- Maxim Dziumanenko myLinux -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: ?? ??????? ??????????????????????? ????????? ???????? ???????? URL: From rbharati at ensim.com Fri Nov 28 13:23:19 2003 From: rbharati at ensim.com (Ritesh Bharati) Date: Fri, 28 Nov 2003 18:53:19 +0530 Subject: how upgrade works? Message-ID: <3FC74C47.6000405@ensim.com> hi, I was trieng to upgrade of 7.3 to FC1 using apt , Which failed , then was wondering how FC1 upgrade process work. I have rh7.3 installed and I tried to upgrade it to FC1 using apt-get -f -y -d -o dist-upgrade Dir::Cache::Archives=/temp/upgrade . BUT it failed with pre-depends . I tried to Hold those packahes in apt upgrade, no use. I tried to apt-get install on all installed packages on m y RH7.3... again i got pre-dependency list.. :)... dependency cycle.... There are may rpms in RH7.3 whcih are replaced by other rpms in FC1. Can somebody throw some light on ... How pre-dendency / dependency cycle is taken care by FC1 upgrade process. How upgrade works ?? This could lead to hope of light to other developes who want to upgrade their boxes using apt-get/yum .. thanks in advance Ritesh Bharati From buildsys at porkchop.devel.redhat.com Fri Nov 28 13:27:50 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Fri, 28 Nov 2003 08:27:50 -0500 Subject: rawhide report: 20031128 changes Message-ID: <200311281327.hASDRoo02969@porkchop.devel.redhat.com> New package tk Tk graphical toolkit for the Tcl scripting language Updated Packages: MagicPoint-1.10a-5 ------------------ * Fri Nov 28 2003 Akira TAGOH 1.10a-5 - magicpoint-1.10a-fix-gcc-warnings.patch: updated for more gcc3 compliant. (#110773) distcache-0.4.2-7 ----------------- * Fri Nov 28 2003 Joe Orton 0.4.2-7 - sync with upstream: use -sock{owner,perms} in dc_client im-sdk-11_4-2 ------------- * Tue Nov 25 2003 Thomas Woerner 1:11_4-2 - fixed libdir problem * Tue Nov 18 2003 Thomas Woerner - Fixed RPATH: Fixed prefix in %build, simplified %install, Readded BuildRequires for Canna-devel (for CannaLE.so, ..) kdbg-1.2.9-2 ------------ * Thu Nov 27 2003 Than Ngo 1:1.2.9-2 - rebuild against KDE 3.2 kdeaddons-3.1.93-0.3 -------------------- * Thu Nov 27 2003 Than Ngo 3.1.93-0.3 - fixed typo * Thu Nov 27 2003 Than Ngo 3.1.93-0.2 - get rid of rpath * Tue Nov 11 2003 Than Ngo 3.1.93-0.1 - KDE 3.2 Beta1 - cleanup specfile - remove some unneeded patch files kdebindings-3.1.93-0.1 ---------------------- * Wed Nov 12 2003 Than Ngo 3.1.93-0.1 - KDE 3.2 Beta1 - remove some unneeded patch files - cleanup kdeedu-3.1.93-0.2 ----------------- * Thu Nov 27 2003 Than Ngo 3.1.93-0.2 - get rid of rpath * Wed Nov 12 2003 Than Ngo 3.1.93-0.1 - KDE 3.2 Beta1 - cleanup - remove some unneeded patch files kdemultimedia-3.1.93-0.2 ------------------------ * Thu Nov 27 2003 Than Ngo 6:3.1.93-0.2 - enable alsa support - get rid of rpath openmotif-2.2.2-16.2 -------------------- * Thu Nov 27 2003 Thomas Woerner 2.2.2-16.2 - removed rpath rpmdb-fedora-1.90-0.20031128 ---------------------------- setserial-2.17-14 ----------------- * Thu Nov 27 2003 Tim Waugh 2.17-14 - Build requires groff (bug #111088). sip-3.8-2 --------- * Thu Nov 27 2003 Than Ngo 3.8-2 - rebuild against python 2.3 and Qt 3.2.3 tcl-8.4.5-2 ----------- * Fri Nov 28 2003 Jens Petersen - 8.4.5-2 - put private header files under generic and unix subdirs - include real generic/tclPort.h not just a symlink to tclUnixPort.h - add tclMath.h to /usr/include/tcl-private/generic for building tk * Thu Nov 27 2003 Jens Petersen - 8.4.5-1 - new package split out from tcltk - update to tcl 8.4.5 (#88429) - drop tcl-8.3.3-heiierarchy.patch, tcl-8.3.3-dlopen.patch and tcl8.3.5-koi8-u.enc-88806.patch - include private include headers under /usr/include/tcl-private - filtered changelog for tcl - buildrequire autoconf213 (#110583) [mvd at mylinux.com.ua] * Wed Oct 15 2003 Jens Petersen - 8.3.5-93 * Wed Sep 17 2003 Matt Wilson 8.3.5-92 - rebuild again for #91211 * Wed Sep 17 2003 Matt Wilson 8.3.5-91 - rebuild to fix gzipped file md5sums (#91211) * Fri Jul 04 2003 Jens Petersen - 8.3.5-90 - split out devel files from tcl and tk into -devel subpackages (#90087) - fix tcl package path in tclConfig.sh to point to datadir (#90160) [reported by Michal Jaegermann] - remove gratuitous whitespace in koi8-u.enc (#88806) [reported with fix by Victor Cheburkin] - update ucs4 patch to also change regcustom.h, but disable it for now (#89098) * Thu Feb 06 2003 Jens Petersen - 8.3.5-88 - use ucs4 wide chars since python now does (tkinter) * Fri Jan 17 2003 Jens Petersen - 8.3.5-85 - add some requires * Tue Jan 14 2003 Jens Petersen - 8.3.5-84 - link all libs with DT_SONAME using tcl.m4 patch (#81297) - drop synthetic lib provides - remove obsolete patches from srpm - update buildrequires - use buildroot instead of RPM_BUILD_ROOT - install all man pages under mandir, instead of moving some from /usr/man - install libtcl and libtk mode 755 - introduce _genfilelist macro for clean single-sweep find filelist generation for each package - use perl to remove buildroot prefix from filelists * Tue Jan 07 2003 Jeff Johnson 8.3.5-80 - rebuild to generate deps for4 DSO's w/o DT_SONAME correctly. * Sat Jan 04 2003 Jeff Johnson 8.3.5-79 - set execute bits on library so that requires are generated. * Tue Dec 10 2002 Jens Petersen 8.3.5-78 - make lib symlinks to .so not .so.0 * Tue Dec 10 2002 Jens Petersen 8.3.5-77 - fix summary-not-capitalized for tclx, tcllib, tcl-html * Mon Dec 09 2002 Jens Petersen 8.3.5-76 - make it build on x86_64 (details below) - don't explicitly update config.{guess,sub} since %configure does it for us - added "--without check" rpmbuild option to disable running tests in future - build and install tcl and tk with script files under datadir (not libdir) - generate filelists from datadir and not from mandir from now on * Tue Dec 03 2002 Jens Petersen - update to tcl-8.3.5, tk-8.3.5, tcl-html-8.3.5 - update url for tcl, tk, tclx, itcl, tcllib - build without all makecfg patches for now - in particular use upstream versioned library name convention - add backward compatible lib symlinks for now - add unversioned symlinks for versioned bindir files - use make's -C option rather than jumping in and out of source dirs during install - use INSTALL_ROOT destdir-like make variable instead of makeinstall for all subpackages except tix and itcl * Mon Oct 21 2002 Jens Petersen - update to tcl-8.3.4, tk-8.3.4 (#75600), tcllib-1.3, itcl-3.2.1, tix-8.1.3 (#59098) - drop obsolete tcl cruft, tcl refcount, tix perf patches - added tcltk html manual - drop the crud compat dir symlinks in libdir - package now builds without tcl or tk installed (partly #52606) - replace all relative paths by absolutes ones, using new tcltktop - give absolute paths to tcl and tk when configuring - give buildroot bindir path to tcllib make - export buildroot libdir in LD_LIBRARY_PATH when installing - replace tclvers and tkvers by tcltkvers and use it - replace tcl_major and tk_major by tcltk_major and use it - don't explicitly provide 64bit libs on ia64 and sparc64 * Mon Jan 07 2002 Florian La Roche - fix config.guess and config.sub to newer versions * Wed Aug 29 2001 Adrian Havill * Mon Aug 8 2001 Adrian Havill - re-enable glibc string and math inlines; recent gcc is a-ok. - optimize at -O2 instead of -O - rename "soname" patches related to makefile/autoconf changes - added elf "needed" for tk, tclx, tix, itk * Thu Jul 19 2001 Adrian Havill - used %makeinstall to brute force fix any remaining unflexible makefile dirs - fixed bad ref count release in tcl (bug 49406) - revert --enable-threads, linux is (still) not ready (yet) (bug 49251) * Sun Jul 08 2001 Adrian Havill - refresh all sources to latest stable (TODO: separate expect/expectk) - massage out some build stuff to patches (TODO: libtoolize hacked constants) - remove patches already rolled into the upstream - removed RPATH (bugs 45569, 46085, 46086), added SONAMEs to ELFs - changed shared object filenames to something less gross - reenable threads which seem to work now - made compile-friendly for IA64 * Sun Jun 24 2001 Elliot Lee - Bump release + rebuild for 7.2. * Fri Mar 23 2001 Bill Nottingham - bzip2 sources * Mon Mar 19 2001 Preston Brown - build fix from ahavill. * Tue Feb 13 2001 Adrian Havill - added "ja_JP.eucJP" to locale list for tcl * Tue Feb 13 2001 Adrian Havill - rebuild so make check passes * Fri Oct 20 2000 Than Ngo - rebuild with -O0 on alpha (bug #19461) * Thu Aug 17 2000 Jeff Johnson - summaries from specspo. * Thu Aug 03 2000 Jeff Johnson - merge "best known" patches from searching, stubs were broken. * Thu Jul 27 2000 Jeff Johnson - rebuild against "working" util-linux col. * Wed Jul 12 2000 Prospector - automatic rebuild * Fri Jun 16 2000 Jeff Johnson - don't mess with %{_libdir}, it's gonna be a FHS pita. * Fri Jun 02 2000 Jeff Johnson - FHS packaging changes. - revert --enable-threads, linux is not ready (yet) (#11789). - tcl/tk: update to 8.3.1 (#10779). - abstract major tcltk version for soname expansion etc. * Sat Mar 18 2000 Jeff Johnson - update to (tcl,tk}-8.2.3, expect-5.31, and itcl-3.1.0, URL's as well. - use perl to drill out pre-pended RPM_BUILD_ROOT. - configure with --enable-threads (experimental). - correct hierarchy spelling (#7082). * Tue Mar 07 2000 Jeff Johnson - rebuild for sparc baud rates > 38400. * Mon Feb 07 2000 Bill Nottingham - handle compressed manpages * Thu Feb 03 2000 Elliot Lee - Make changes from bug number 7602 - Apply patch from bug number 7537 - Apply fix from bug number 7157 - Add fixes from bug #7601 to the runtcl patch * Wed Feb 02 2000 Cristian Gafton - fix descriptions - man pages are compressed (whatapain) * Tue Nov 30 1999 Jakub Jelinek - compile on systems where SIGPWR == SIGLOST. * Sat May 01 1999 Jeff Johnson - update tcl/tk to 8.0.5. * Tue Feb 16 1999 Jeff Johnson - upgrade tcl/tk/tclX to 8.0.4 * Tue Jan 12 1999 Cristian Gafton - call libtoolize to allow building on the arm - build for glibc 2.1 - strip binaries * Thu Sep 10 1998 Jeff Johnson - update tcl/tk/tclX to 8.0.3, expect is updated also. * Thu May 07 1998 Prospector System - translations modified for de, fr, tr * Thu Apr 09 1998 Erik Troan - updated version numbers of tcl/tk to relflect inclusion of p2 * Wed Mar 25 1998 Cristian Gafton - updated tcl/tk to patch level 2 * Wed Oct 22 1997 Otto Hammersmith - added patch to remove libieee test in configure.in for tcl and tk. Shouldn't be needed anymore for glibc systems, but this isn't the "proper" solution for all systems - fixed src urls * Mon Oct 06 1997 Erik Troan - removed version numbers from descriptions * Mon Sep 22 1997 Erik Troan - updated to tcl/tk 8.0 and related versions of packages * Tue Jun 17 1997 Erik Troan - built against glibc vim-6.2.154-2 ------------- * Thu Nov 27 2003 Karsten Hopp 1:6.2.154-2 - fix date in specfile changelog entries webalizer-2.01_10-16 -------------------- * Fri Nov 28 2003 Joe Orton 2.01_10-16 - merge from Taroon * Tue Oct 21 2003 Florian La Roche - add %clean specfile target * Fri Aug 01 2003 Joe Orton 2.01_10-15.ent - support large (>2gb) log files on 32-bit platforms - move default output directory to /var/www/usage - add conf.d/webalizer.conf to add alias for /usage - only allow access to usage stats from localhost by default - change default config: don't ignore out-of-sequence log entries, count .php and .shtml as "page" extensions. * Thu Jul 03 2003 Joe Orton - rebuilt xsane-0.91-2 ------------ * Thu Nov 27 2003 Thomas Woerner 0.91-2 - removed rpath * Wed Oct 08 2003 Tim Waugh - Avoid undefined behaviour in xsane-preview.c (bug #106314). From snookertb at comcast.net Fri Nov 28 16:29:23 2003 From: snookertb at comcast.net (snookertb) Date: Fri, 28 Nov 2003 11:29:23 -0500 Subject: fstab problem with mount In-Reply-To: <3FC3A47E.8040300@comcast.net> References: <3FC3A47E.8040300@comcast.net> Message-ID: <3FC777E3.20802@comcast.net> The problem appears to be the second disk that I had connected to transfer files from. It was an old RH9 install which also names the partitions /boot. This label conflict seems to be at the root of the problem. Configuration is disk 1 with a new install of FC1 and disk 2 with an old install of rh9. Both disk end up with disk partitions labeled /boot. So when I tried to make a mount on disk 1 of a new partition, to hold the files, and then a mount of the disk 2 / partition, things got flakey. IMHO there needs to be a resolution to this or at least a work around put in the docs. I loaded up knoppix and transferred the files then deleted the original disk 2 partitions, reformatted and installed new disk 2 partitions and all is OK. I got in this fix by trying to do a simple install of a new bigger faster main disk and preserve the old files on the exiting disk. A pretty common upgrade approach if you ask me. tb From julo at altern.org Fri Nov 28 21:38:40 2003 From: julo at altern.org (Julien Olivier) Date: Fri, 28 Nov 2003 21:38:40 +0000 Subject: Strange bug freezing my laptop Message-ID: <1070055520.3508.13.camel@localhost.localdomain> Hi guys. I have been trying to solve a bug for about a week now, but I can't manage to understand what happens: >From time to time (rather randomly), my CPU gets used at 100% (at least, my laptop's led blinks a lot), my mouse works (I can move it but not click) but not my keyboard. Then, about 30 seconds later, even the mouse stops moving and I have to hard-reboot my laptop. As I listen to music all day long, it always happens while playing music (of course it could a coincidence). So, I filed a bug against rhythmbox: GNOME bugzilla's bug #127814 (http://bugzilla.gnome.org/show_bug.cgi?id=127814). Then, I noticed that it also happened with XMMS and MPG123, as well as rhythmbox-gstreamer and rhythmbox-xine. I also tried to activate/deactivate ESD. Same result. Then, I installed ALSA. The freeze kept happening. Then I saw that Alan Cox advised to append apm=off, nohlt, or acpi=off to grub.conf to fix a freeze-at-idle bug. I tried all 3 (in combinations or individually), and none helped. Sometimes it freezes at idle, and sometimes while I'm using my laptop. I tried letting top run in a visible terminal. But when it froze, i couldn't see anything special in top. What's very strange is that it seems to happen very randomly, but tends to happen more often on the afternoon (around 4pm) after about 15 min of idle... I'm really totally lost... please help me solve this very critical bug. PS: I happily used Redhat 8, then 9 on this very same laptop before and never had this bug. PPS: I usually run GNOME-2.4, with Evolution, Rhythmbox and Mozilla. -- Julien Olivier From redhat-forums at genesis-x.nildram.co.uk Fri Nov 28 16:50:54 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Fri, 28 Nov 2003 16:50:54 +0000 Subject: New release: tripwire-2.3.1-18.fdr.3 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New release: tripwire-2.3.1-18.fdr.3 http://www.genesis-x.nildram.co.uk/filez/tripwire-2.3.1-18.fdr.3.src.rpm http://www.genesis-x.nildram.co.uk/filez/md5sum Also new: http://www.genesis-x.nildram.co.uk/filez/tripwire-2.3.1-18.fdr.3.i386.rpm http://www.genesis-x.nildram.co.uk/filez/tripwire-2.3.1-18.fdr.3.i686.rpm (Debuginfo packages not published, since they are 21MB each! Build yourself) Unchanged: http://www.genesis-x.nildram.co.uk/filez/GENESIS-RPM-KEY.asc Changes: Merged in changes from attachment (id=442) (big .spec cleanup) Implemented remaining parts of the old gcc3 patch Proper debuginfo packages build now ToDo: Long term future depends on license issues and fixing various parts of the code, both of which can be attributed to mainly just one component - cryptlib. My preference is to move away from cryptlib and use libmcrypt and mhash instead, but then ultimately my goal is to move towards an unquestionably OSS replacement for tripwire anyway. There are other projects out there, but I aim to use tripwire as a stepping stone, until certain other projects reach maturity. This will be the last update until after the silly season. The next likely development will be either fixing cryptlib or moving to libmcrypt. That's a big job, so don't expect much in the way of big changes for a few months at least. Keith G. Robertson-Turner tripwire-devel at genesis-x.nildram.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/x3yM2XoLj+pGfn8RAgDtAJ0TkZe2mK0rBIILzC9Ymo3Uuzy9HQCcCqDv 7MQsrMhhVpXmh2YDSIJuSVc= =hBzY -----END PGP SIGNATURE----- From wrrhdev at riede.org Fri Nov 28 17:50:25 2003 From: wrrhdev at riede.org (Willem Riede) Date: Fri, 28 Nov 2003 12:50:25 -0500 Subject: Building a module outside the source tree Message-ID: <20031128175025.GR5672@linnie.riede.org> Building a module outside the source tree is supposed to be possible with: make -C/usr/src/linux-2.4.22-1.2115.nptl SUBDIRS=$PWD modules and a simple Makefile like: # # Makefile for osst # CFLAGS_osst.o = -I$(TOPDIR)/drivers/scsi obj-m += osst.o include $(TOPDIR)/Rules.make (if I'm not mistaken, that is...) But when I do so (as ordinary user), I get permission problems make: Entering directory `/usr/src/linux-2.4.22-1.2115.nptl' /bin/sh: line 1: .ver: Permission denied make: *** [include/linux/version.h] Error 1 make: Leaving directory `/usr/src/linux-2.4.22-1.2115.nptl' What am I missing?? FYI, here is what make wants to do - change all sorts of things in the source tree, which I really wanted to keep in sync with the rpm, except for copying the right .config in place, that is... [wriede at betatest osst]$ make -n -C/usr/src/linux-2.4.22-1.2115.nptl SUBDIRS=$PWD modules make: Entering directory `/usr/src/linux-2.4.22-1.2115.nptl' expr length "2.4.22-1.2115.nptlsmp" \<= 64 > /dev/null || \ (echo KERNELRELEASE \"2.4.22-1.2115.nptlsmp\" exceeds 64 characters >&2; false) echo \#define UTS_RELEASE \"2.4.22-1.2115.nptlsmp\" > .ver echo \#define LINUX_VERSION_CODE `expr 2 \\* 65536 + 4 \\* 256 + 22` >> .ver echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' >>.ver mv -f .ver include/linux/version.h gcc32 -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/split-include scripts/split-include.c scripts/split-include include/linux/autoconf.h include/config touch include/config/MARKER make -r -f tmp_include_depends all make[1]: Entering directory `/usr/src/linux-2.4.22-1.2115.nptl' touch /usr/src/linux-2.4.22-1.2115.nptl/fs/hfsplus/hfsplus_fs.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/auto_fs.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/autofs/autofs_i.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/udf/udfdecl.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/module.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/compatmac.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/mtd/compatmac.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/mtd/mtd.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/jffs/jffs_fm.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/jffs/intrep.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/auto_fs4.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/autofs4/autofs_i.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/freevxfs/vxfs_kcompat.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/freevxfs/vxfs.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/xfs/pagebuf/page_buf.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/xfs/linux/xfs_linux.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/xfs/pagebuf/page_buf_internal.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/xfs/support/mrlock.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/xfs/support/sema.h touch /usr/src/linux-2.4.22-1.2115.nptl/fs/xfs/xfs.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/irda/irnet/irnet.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/irda/irnet/irnet_irda.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/irda/irnet/irnet_ppp.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/if_wanpipe.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/sock.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/khttpd/prototypes.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/atmdev.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/atm/addr.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/atm/ipcommon.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/atm/lec.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/atm/lec_arpc.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/atm/mpoa_caches.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/atm/mpc.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/atm/resources.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/atm/signaling.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/bluetooth/bluetooth.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/bluetooth/cmtp/cmtp.h touch /usr/src/linux-2.4.22-1.2115.nptl/net/bluetooth/bnep/bnep.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/ip.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/checksum.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/e1000/e1000.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/e100/e100.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/e100/e100_config.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/e100/e100_phy.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/wan/8253x/ring.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/wan/8253x/8253xioc.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/wan/8253x/8253x.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/wan/8253x/8253xctl.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/wan/8253x/8253xmcs.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/pcmcia/wavelan_cs.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/wireless/orinoco.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/aironet4500.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/arlan.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/dl2k.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/mv64340_eth.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/net/wavelan.p.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/ftape.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/ftape/lowlevel/ftape-bsm.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/ftape/lowlevel/fdc-io.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/ftape/lowlevel/ftape-rw.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/ftape/lowlevel/ftape-ctl.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/ftape/lowlevel/ftape-ecc.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/ftape/lowlevel/ftape_syms.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/ftape/zftape/zftape-init.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/ftape/zftape/zftape_syms.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drmP.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/ati_pcigart.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_agpsupport.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_auth.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_bufs.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_context.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_dma.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_drawable.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_fops.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_init.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_ioctl.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_lists.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_lock.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_memory.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_proc.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_scatter.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_stub.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm/drm_vm.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/char/drm-4.0/drmP.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/aic7xxx/aic79xx_osm.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/aic7xxx/aic7xxx_osm.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/sym53c8xx_2/sym53c8xx.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/sym53c8xx_2/sym_glue.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/3w-xxxx.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/53c7,8xx.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/advansys.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/aha152x.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/dc390.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/dpti.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/gdth.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/imm.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/in2000.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/ini9100u.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/inia100.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/megaraid.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/megaraid2.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/sym53c8xx_defs.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/ncr53c8xx.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/pci2000.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/pci2220i.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/ppa.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/qla1280.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/sym53c416.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/sym53c8xx.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi/zalon7xx.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/audigy/emu_wrapper.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/audigy/hwaccess.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/audigy/timer.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/audigy/cardwi.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/audigy/voicemgr.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/audigy/cardwo.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/audigy/ecard.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/audigy/recmgr.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/os.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/sound_config.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/ac97.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sound/nm256.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/isdn/icn/icn.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/isdn/sc/includes.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/isdn/isdnloop/isdnloop.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/wanrouter.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/isdn/isdn_x25iface.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/sbus/audio/amd7930.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/ide/raid/ataraid.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/matrox/matroxfb_base.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/matrox/g450_pll.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/matrox/matroxfb_DAC1064.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/matrox/matroxfb_Ti3026.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/matrox/matroxfb_accel.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/i2c.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/i2c-algo-bit.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/matrox/matroxfb_crtc2.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/matrox/matroxfb_g450.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/matrox/matroxfb_maven.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/matrox/matroxfb_misc.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/sis/osdef.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/sis/init.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/video/sis/init301.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/host/ehci.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/usb.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/host/uhci.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/host/uhci-debug.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/storage/usb.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/storage/initializers.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/storage/protocol.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/storage/transport.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/auerbuf.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/auerchain.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/auerserv.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/auerchar.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/auerisdn_b.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/auerisdn.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/auermain.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/videodev.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/ov511.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/pwc.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/pwc-uncompress.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/scanner.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/se401.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/usbdfu.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/usb/usbvideo.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/atm/eni.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/atm/horizon.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/atm/idt77105.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/atm/nicstar.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/atm/suni.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/atm/zatm.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/phonedev.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/telephony/ixj.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/ieee1394/ieee1394_types.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/ieee1394/ohci1394.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/ieee1394/dv1394-private.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/ieee1394/hosts.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/ieee1394/ieee1394_core.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/ieee1394/ieee1394_transactions.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/ieee1394/iso.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/ieee1394/nodemgr.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/media/video/bttv.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/media/video/bttvp.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/media/video/cpia.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/media/video/saa7146.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/i2c-old.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/media/video/zr36120.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/mtd/devices/ms02-nv.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/md/dm.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/md/dm-snapshot.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/lvm.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/md/lvm-internal.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/message/fusion/linux_compat.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/message/fusion/mptbase.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/message/fusion/mptctl.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/message/fusion/mptlan.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/message/fusion/mptscsih.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/message/i2o/i2o_scsi.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/addon/bcm/ubslinux.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/addon/bcm/ubssys.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/addon/bcm/ubsec.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/addon/bcm/ubsio.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/addon/bcm/cdevincl.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/addon/bcm/prototypes.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/addon/bcm/ubsincl.h touch /usr/src/linux-2.4.22-1.2115.nptl/drivers/addon/cipe/cipe.h touch /usr/src/linux-2.4.22-1.2115.nptl/arch/i386/math-emu/fpu_system.h touch /usr/src/linux-2.4.22-1.2115.nptl/arch/i386/math-emu/fpu_emu.h touch /usr/src/linux-2.4.22-1.2115.nptl/arch/i386/math-emu/exception.h touch /usr/src/linux-2.4.22-1.2115.nptl/arch/i386/math-emu/reg_constant.h touch /usr/src/linux-2.4.22-1.2115.nptl/arch/i386/math-emu/status_w.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/asm/linux_logo.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/i2c-algo-sibyte.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/crypto.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/i2c-dev.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/intermezzo_psdev.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/config.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/mtd/pmc551.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/mtd/nftl.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/mtd/map.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/mtd/doc2000.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/mtd/jedec.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/mtd/gen_probe.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/sdladrv.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/wanpipe.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/cyclomx.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/ipsec.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/zftape.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/efs_fs.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/i2c-algo-pcf.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/atm_idt77105.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/raid/md_compatible.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/raid/md.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/raid/linear.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/raid/raid0.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/raid/raid1.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/raid/xor.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/raid/raid5.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/raid/multipath.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/netfilter_ipv4/ipchains_core.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/if_wanpipe_common.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/i2c-algo-ite.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/intermezzo_journal.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/intermezzo_kml.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/firmware.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/vblankdev.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/linux/i2c-isa.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/tcp.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/atmclip.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/transp_v6.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/ipv6.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/icmp.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/udp.h touch /usr/src/linux-2.4.22-1.2115.nptl/include/net/dn_route.h make[1]: Leaving directory `/usr/src/linux-2.4.22-1.2115.nptl' make -C /home/wriede/osst CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4.22-1.2115.nptl/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.22-1.2115.nptl/include/linux/modversions.h" MAKING_MODULES=1 modules make[1]: Entering directory `/home/wriede/osst' gcc32 -D__KERNEL__ -I/usr/src/linux-2.4.22-1.2115.nptl/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.22-1.2115.nptl/include/linux/modversions.h -nostdinc -iwithprefix include -DKBUILD_BASENAME=osst -I/usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi -c -o osst.o osst.c ( \ echo 'ifeq (-D__KERNEL__ -I/usr/src/linux-2.4.22-1.2115.nptl/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.22-1.2115.nptl/include/linux/modversions.h -nostdinc -iwithprefix include -I/usr/src/linux-2.4.22-1.2115.nptl/drivers/scsi,$(strip $(subst $(comma),:,$(CFLAGS) $(EXTRA_CFLAGS_nostdinc) $(CFLAGS_osst.o))))' ; \ echo 'FILES_FLAGS_UP_TO_DATE += osst.o' ; \ echo 'endif' \ ) > .//.osst.o.flags make[1]: Leaving directory `/home/wriede/osst' make: Leaving directory `/usr/src/linux-2.4.22-1.2115.nptl' Thanks, Willem Riede. From fedora at leemhuis.info Fri Nov 28 18:39:16 2003 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 28 Nov 2003 19:39:16 +0100 Subject: Self-Introduction: Thorsten Leemhuis Message-ID: <1070044756.1717.55.camel@work.thl.home> Full legal name: Thorsten Leemhuis Country, City: Hannover, Germany Company or School: Interest is private, if you want to know where I spent my days ask you favorite search-engine ;-) Goals: Build and QA packages that I use myself that are currently missing and may (or may not) be usable for others. Historical qualifications: None appreciable ;-) Okay, some real info: After 10 years I changed from OS/2 to Red Hat Linux in the beginning of 2000. Good in bash-programming, some skills in java. Don't know if I ever find enough time to really learn C or Python. Lot of interest and know-how in Linux compatible hardware and how to make it work. GPG KEYID and fingerprint pub 1024D/55FB7C4E 2003-11-28 Thorsten Leemhuis Schl.-Fingerabdruck = BB70 9E3B 9941 B800 006A 54A9 D997 D8BA 55FB 7C4E sub 1024g/A587192E 2003-11-28 [verf?llt: 2005-11-27] CU thl From stan at ccs.neu.edu Sat Nov 29 21:46:46 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Sat, 29 Nov 2003 16:46:46 -0500 Subject: CPAN RPM archive? Message-ID: <1070142405.19063.10.camel@duergar> Hey, I was wondering if there were any sites that have CPAN modules already in RPMs ready to install for say Fedora or RH? (even if its just using simple cpan2rpm program) If not would there be any interest in creating one? -sb From orospakr at infomaninc.dyndns.org Fri Nov 28 21:47:46 2003 From: orospakr at infomaninc.dyndns.org (Andrew Clunis) Date: Fri, 28 Nov 2003 16:47:46 -0500 Subject: Strange bug freezing my laptop In-Reply-To: <1070055520.3508.13.camel@localhost.localdomain> References: <1070055520.3508.13.camel@localhost.localdomain> Message-ID: <1070056065.2516.4.camel@localhost.localdomain> Hello! What laptop do you have? I had similar issues with my tp 600x with Fedora Core 1 (and indeed any other distro), namely my cardbus xircom card would freeze the system... turned it it was conflicting with one of IBM's weirdo serial ports that the kernel wasn't detecting. it could be something like that, perhaps not even related to your audio. try posting your dmesg as well, especially if you get it to come back after a lockup... Regards, Andrew C. On Fri, 2003-11-28 at 16:38, Julien Olivier wrote: > Hi guys. > > I have been trying to solve a bug for about a week now, but I can't > manage to understand what happens: > > >From time to time (rather randomly), my CPU gets used at 100% (at least, > my laptop's led blinks a lot), my mouse works (I can move it but not > click) but not my keyboard. Then, about 30 seconds later, even the mouse > stops moving and I have to hard-reboot my laptop. > > As I listen to music all day long, it always happens while playing music > (of course it could a coincidence). So, I filed a bug against rhythmbox: > GNOME bugzilla's bug #127814 > (http://bugzilla.gnome.org/show_bug.cgi?id=127814). > > Then, I noticed that it also happened with XMMS and MPG123, as well as > rhythmbox-gstreamer and rhythmbox-xine. I also tried to > activate/deactivate ESD. Same result. Then, I installed ALSA. The freeze > kept happening. Then I saw that Alan Cox advised to append apm=off, > nohlt, or acpi=off to grub.conf to fix a freeze-at-idle bug. I tried all > 3 (in combinations or individually), and none helped. > > Sometimes it freezes at idle, and sometimes while I'm using my laptop. > > I tried letting top run in a visible terminal. But when it froze, i > couldn't see anything special in top. > > What's very strange is that it seems to happen very randomly, but tends > to happen more often on the afternoon (around 4pm) after about 15 min of > idle... > > I'm really totally lost... please help me solve this very critical bug. > > PS: I happily used Redhat 8, then 9 on this very same laptop before and > never had this bug. > > PPS: I usually run GNOME-2.4, with Evolution, Rhythmbox and Mozilla. -------------- 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 arnaud.abelard at sciences.univ-nantes.fr Fri Nov 28 21:58:15 2003 From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard) Date: Fri, 28 Nov 2003 22:58:15 +0100 (CET) Subject: Strange bug freezing my laptop In-Reply-To: <1070055520.3508.13.camel@localhost.localdomain> References: <1070055520.3508.13.camel@localhost.localdomain> Message-ID: <49438.82.67.136.167.1070056695.squirrel@webmail.sciences.univ-nantes.fr> > Hi guys. Helllo, >>From time to time (rather randomly), my CPU gets used at 100% (at >> least, > my laptop's led blinks a lot), my mouse works (I can move it but not > click) but not my keyboard. Then, about 30 seconds later, even the mouse > stops moving and I have to hard-reboot my laptop. Doesn't look like a CPU consumption but more like a memory problem... have you tried monitoring your memory usage? (even with the system monitor applet) If you aren't working as root on your laptop you could use pam_limits to limit your memory usage (and see what process gets killed by using too much memory) or keep an eye on a top sorted by memory usage. > As I listen to music all day long, it always happens while playing music > (of course it could a coincidence). So, I filed a bug against rhythmbox: > GNOME bugzilla's bug #127814 > (http://bugzilla.gnome.org/show_bug.cgi?id=127814). > > Then, I noticed that it also happened with XMMS and MPG123, as well as > rhythmbox-gstreamer and rhythmbox-xine. I also tried to Could be an acpi problem, lots of laptops are acpi only, disabling acpi might damage them (CPU overheat, etc)... can you tell your laptop's getting hot? who knows... the fan might not run as often as it should, but then if RH8 was running fine... my bet is a memory leak. > > -- > Julien Olivier Bien le bonsoir ;-) > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From walters at verbum.org Sat Nov 29 22:33:31 2003 From: walters at verbum.org (Colin Walters) Date: Sat, 29 Nov 2003 17:33:31 -0500 Subject: The current fedora.us buildsystem and future directions In-Reply-To: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1070145211.22295.1.camel@nexus.verbum.private> On Fri, 2003-11-28 at 00:31, Enrico Scholz wrote: > 1. SELinux can protect foreign processes. But is it possible to hide > them in /proc also? It is not currently possible to hide them. However, the entries in /proc have the same type as the domain of the running process. So if you don't allow any operations on that type (including getattr), then the only thing one can tell is that a process exists at that PID. > 2. Is chroot(2) implemented in a safe manner? Or, can parent directories > of build-roots be protected with SELinux policies? Is a safe chroot(2) > required at all? Using SELinux, a chroot doesn't provide any additional direct security. However, you may find it convenient to use a chroot in this instance so that different sets of packages can be installed, etc. > 3. What is the performance impact of the policy checking? Minimal; IIRC the overhead was something like 1-2% for very system-call intensive tasks, and negligible after that. > 4. How can disk/memory usage restricted with SELinux? Would CKRM be an > option? SELinux does not deal with resource restrictions. > 5. Can special mount-operations (e.g. /proc filesystem) be allowed by > the policy, or does this require userspace helper also? The mount system call is restricted, yes. > 6. Setup of an SELinux policy seems to be very complicated. How possible > are holes in a setup? Assuming that there are no bugs in the kernel, it is impossible to reach sysadm_t (essentially equivalent to the SELinux "root") if the policy doesn't very explicitly permit it. I hope that answers your questions! -------------- 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 walters at verbum.org Fri Nov 28 23:12:55 2003 From: walters at verbum.org (Colin Walters) Date: Fri, 28 Nov 2003 18:12:55 -0500 Subject: The current fedora.us buildsystem and future directions In-Reply-To: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1070061174.4351.8.camel@nexus.verbum.private> On Fri, 2003-11-28 at 00:31, Enrico Scholz wrote: > 1. SELinux can protect foreign processes. But is it possible to hide > them in /proc also? It is not currently possible to hide them. However, the entries in /proc have the same type as the domain of the running process. So if you don't allow any operations on that type (including getattr), then the only thing one can tell is that a process exists at that PID. > 2. Is chroot(2) implemented in a safe manner? Or, can parent directories > of build-roots be protected with SELinux policies? Is a safe chroot(2) > required at all? Using SELinux, a chroot doesn't provide any additional direct security. However, you may find it convenient to use a chroot in this instance so that different sets of packages can be installed, etc. > 3. What is the performance impact of the policy checking? Minimal; IIRC the overhead was something like 1-2% for very system-call intensive tasks, and negligible after that. > 4. How can disk/memory usage restricted with SELinux? Would CKRM be an > option? SELinux does not deal with resource restrictions. > 5. Can special mount-operations (e.g. /proc filesystem) be allowed by > the policy, or does this require userspace helper also? The mount system call is restricted, yes. > 6. Setup of an SELinux policy seems to be very complicated. How possible > are holes in a setup? Assuming that there are no bugs in the kernel, it is impossible to reach sysadm_t (essentially equivalent to the SELinux "root") if the policy doesn't very explicitly permit it. I hope that answers your questions! -------------- 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 pp at ee.oulu.fi Fri Nov 28 23:58:27 2003 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Sat, 29 Nov 2003 01:58:27 +0200 Subject: Vic^H^Holunteers needed for updated SATA code testing In-Reply-To: <20031116183756.GA21083@ee.oulu.fi> References: <20031116183756.GA21083@ee.oulu.fi> Message-ID: <20031128235827.GA23027@ee.oulu.fi> On Sun, Nov 16, 2003 at 08:37:56PM +0200, Pekka Pietikainen wrote: > - Did I break anything? (the amount of changes in header files I merged from > 2.4.22-bk to fc1 like scsi.h were a bit worrying...) Promise 376 + athlon > works ok, and it did compile, so I decided to ship it :-) > - Is the Promise 378 PCI id 0x3378 and does the code work on one? > - driver disk or boot.iso that would let people install FC1 on SATA-only > boxes Positive comments so far from Promise and VIA users, so I reused someones RFE in bugzilla for this (#103980) to possibly get it in a future kernel update. The existance of boards with a 0x3378 PCI id is still a mystery, supposedly they're on some Asus boards, but I still have no conclusive evidence either way. Anyone? I've also not heard of anyone managing a working install image, if anyone got it running, would they mind sharing? ;-) -- Pekka Pietikainen From notting at redhat.com Sat Nov 29 02:25:51 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 28 Nov 2003 21:25:51 -0500 Subject: The current fedora.us buildsystem and future directions In-Reply-To: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20031129022551.GA31280@devserv.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > 1. SELinux can protect foreign processes. But is it possible to hide > them in /proc also? If you cannot access it, why does it matter if it is visible? > 4. How can disk/memory usage restricted with SELinux? Would CKRM be an > option? SELinux doesn't deal with resource limitations; that would be handled by CKRM or something similar. > 5. Can special mount-operations (e.g. /proc filesystem) be allowed by > the policy, or does this require userspace helper also? Not sure what you're asking here. Mount can be allowed or disallowed based on the policy. Bill From 64bit_fedora at comcast.net Sun Nov 30 00:16:35 2003 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Sat, 29 Nov 2003 18:16:35 -0600 Subject: Vic^H^Holunteers needed for updated SATA code testing In-Reply-To: <20031128235827.GA23027@ee.oulu.fi> References: <20031116183756.GA21083@ee.oulu.fi> <20031128235827.GA23027@ee.oulu.fi> Message-ID: <20031130001635.GA12006@comcast.net> > Positive comments so far from Promise and VIA users, so I reused someones RFE > in bugzilla for this (#103980) to possibly get it in a future kernel > update. I have merged these patches into the current Fedora kernel for AMD64, hopefully it will stay there until release, in which case, it should ship with an errata kernel for i386 users as well. > > I've also not heard of anyone managing a working install image, if anyone > got it running, would they mind sharing? ;-) It is in the install image for x86_64, when I get some spare cycles I will do an install image for i?86 with this kernel. Justin M. Forbes From julo at altern.org Sun Nov 30 00:36:28 2003 From: julo at altern.org (Julien Olivier) Date: Sun, 30 Nov 2003 00:36:28 +0000 Subject: Strange bug freezing my laptop In-Reply-To: <1070056065.2516.4.camel@localhost.localdomain> References: <1070055520.3508.13.camel@localhost.localdomain> <1070056065.2516.4.camel@localhost.localdomain> Message-ID: <1070152588.15166.3.camel@localhost.localdomain> On Fri, 2003-11-28 at 21:47, Andrew Clunis wrote: > Hello! > Hi > What laptop do you have? I have a Fujitsu/Siemens Amilo D laptop. > I had similar issues with my tp 600x with > Fedora Core 1 (and indeed any other distro), namely my cardbus xircom > card would freeze the system... turned it it was conflicting with one of > IBM's weirdo serial ports that the kernel wasn't detecting. > > it could be something like that, perhaps not even related to your > audio. try posting your dmesg as well, especially if you get it to come > back after a lockup... > I'll post my dmesg as soon as i make it freeze again. The good news is that after removing the notification area from the panel, I don't seem to have the freeze again. It might happen again though... > Regards, > Andrew C. > Thanks for your email. -- Julien Olivier From 64bit_fedora at comcast.net Sat Nov 29 06:17:47 2003 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Sat, 29 Nov 2003 00:17:47 -0600 Subject: Fedora Core 1 AMD 64 Preview update. In-Reply-To: <600B91D5E4B8D211A58C00902724252C01BC0460@piramida.hermes.si> References: <600B91D5E4B8D211A58C00902724252C01BC0460@piramida.hermes.si> Message-ID: <20031129061747.GA5277@comcast.net> Well, here it is... a preview anyway. For those of you on the edge of your seat waiting for an AMD64 version of Fedora Core 1, we present a preview. ISOs will not be provided for this release, but everything is there for an install. It is generally version synced with Fedora Core 1 and the current updates. Please test it out, and send any questions/complaints/bugs to me if you would before bugzilla, as this is not an official release of any caliber yet, just a preview. I will forward what is necessary to bugzilla. /*************************************************************************** * WARNING: This release is a preview, it is not an official Fedora * Core 1 Release, this is not an official Fedora Core Test Release. * This release may very well cause damage to your data, your system, * your pets and loved ones, and most certainly your sleep schedule. * There is no guarantee of any type on performance, stability, or * your sanity. Use at your own risk. ***************************************************************************/ Now that the formality is out of the way, the tree is available at: http://fedora.linux.duke.edu/fc1_x86_64/ Enjoy, and let me know. We will be working diligently in the background to move closer to a stable Fedora Core system for AMD64. KNOWN ISSUES: - SATA: Some SATA controllers, notably Sil, do not work - ACPI is not really functional on NForce 3. Please install and boot with acpi=off - Mozilla: both 32-bit and 64-bit mozilla are installed. This is to meet the dependencies of other installed applications. A system to handle user selection at boot time has not been implemented yet. Current work around is to pull /usr/bin/mozilla from the 32-bit package as /usr/bin/mozilla32 and 64-bit as mozilla64, then just link your preference to /usr/bin/mozilla. The standard plugins do work in Mozilla 32-bit. - No documentation (release notes, etc) has been updated, and fedora-release is still synced with FC1 (IE wrong for preview) - If you are looking to use this kernel on i686, etc. I have not updated the config files for anything but x86_64 yet. The kernel should build and work fine, but the SRPM will probably complain when 'make oldconfig' asks for input. I am sure I am leaving something out, it is late, and I am eternally short on sleep, let me know what else you find. Thanks, Justin M. Forbes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From julo at altern.org Sun Nov 30 00:39:59 2003 From: julo at altern.org (Julien Olivier) Date: Sun, 30 Nov 2003 00:39:59 +0000 Subject: Strange bug freezing my laptop In-Reply-To: <49438.82.67.136.167.1070056695.squirrel@webmail.sciences.univ-nantes.fr> References: <1070055520.3508.13.camel@localhost.localdomain> <49438.82.67.136.167.1070056695.squirrel@webmail.sciences.univ-nantes.fr> Message-ID: <1070152798.15166.8.camel@localhost.localdomain> On Fri, 2003-11-28 at 21:58, Arnaud Abelard wrote: > > Hi guys. > > Helllo, > > >>>From time to time (rather randomly), my CPU gets used at 100% (at > >> least, > > my laptop's led blinks a lot), my mouse works (I can move it but not > > click) but not my keyboard. Then, about 30 seconds later, even the mouse > > stops moving and I have to hard-reboot my laptop. > > Doesn't look like a CPU consumption but more like a memory problem... have > you tried monitoring your memory usage? (even with the system monitor > applet) If you aren't working as root on your laptop you could use > pam_limits to limit your memory usage (and see what process gets killed by > using too much memory) or keep an eye on a top sorted by memory usage. > As I said in a previous email, the bug seems to have gone when I removed the notification area from the panel. If it happens again, I'll also watch my memory usage. That said, the notification area could have had a memory leak. > Could be an acpi problem, lots of laptops are acpi only, disabling acpi > might damage them (CPU overheat, etc)... can you tell your laptop's > getting hot? who knows... the fan might not run as often as it should, but > then if RH8 was running fine... > I had a problem with my CPU a few weeks ago. It was stuck. I managed to repair it and now it works fine. The laptop doesn't seem to over-heat. More over, I could reproduce the bug with or without ACPI, and with or without APM. So I don't think it's ACPI or APM-related. > my bet is a memory leak. > I'll watch that. Thanks for the tip. > Bien le bonsoir ;-) > A toi aussi :) -- Julien Olivier From chris at chrisgrau.com Sun Nov 30 00:52:00 2003 From: chris at chrisgrau.com (Chris Grau) Date: Sat, 29 Nov 2003 16:52:00 -0800 Subject: CPAN RPM archive? In-Reply-To: <1070142405.19063.10.camel@duergar> References: <1070142405.19063.10.camel@duergar> Message-ID: <20031130005200.GA15845@chrisgrau.com> On Sat, Nov 29, 2003 at 04:46:46PM -0500, Stan Bubrouski wrote: > Hey, > > I was wondering if there were any sites that have CPAN modules already > in RPMs ready to install for say Fedora or RH? (even if its just using > simple cpan2rpm program) http://rpmpan.sourceforge.net/ From mail at oripessach.com Sun Nov 30 01:04:47 2003 From: mail at oripessach.com (Ori Pessach) Date: Sat, 29 Nov 2003 18:04:47 -0700 Subject: net-snmp problem in Fedora Core 1 Message-ID: <3FC9422F.7020502@oripessach.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, When compiling wap11gui (http://wap11gui.sourceforge.net), I run into the following error: g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/lib/qt-3.1/include - -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT - -DDATADIR=\"/usr/local/share/wap11gui\" -Wnon-virtual-dtor - -Wno-long-long -Wbad-function-cast -Wundef -Wall -pedantic -W - -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -ansi - -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -O2 - -fno-exceptions -fno-check-new -fexceptions -DNET_SNMP=1 -c -o macauthimp.o `test -f macauthimp.cpp || echo './'`macauthimp.cpp cc1plus: warning: "-Wbad-function-cast" is valid for C/ObjC but not for C++ In file included from /usr/include/net-snmp/utilities.h:26, ~ from /usr/include/net-snmp/net-snmp-includes.h:64, ~ from wap11config.h:24, ~ from macauthimp.h:21, ~ from macauthimp.cpp:22: /usr/include/net-snmp/library/getopt.h:8: error: declaration of `int ~ getopt(int, char* const*, const char*)' throws different exceptions /usr/include/getopt.h:154: error: than previous declaration `int getopt(int, ~ char* const*, const char*) throw ()' make[1]: *** [macauthimp.o] Error 1 make[1]: Leaving directory `/home/ori/projects/wap11gui/wap11gui' make: *** [all-recursive] Error 1 The problem is that /usr/include/net-snmp/utilities.h defines getopt() as an extern, instead of including , as it probably should. The proper getopt.h is included by unistd.h, which, in a QT app, is included somewhere insode the bowels of QT. This means that every QT app that tries to use net-snmp under Fedora won't compile. I can't think of any way an application could work around this. This appears to be a new problem - RH 9 and 8.0 didn't have this, and I haven't seen this problem on any other platform I tried compiling on (Mandrake, SuSe, FreeBSD and Mac OS X). - -- Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/yUIrzA/uWWyw6uQRApz7AJsGzjRXmokCKQxeN6tI4IH2fXfuNgCgx8Cr vXLbyCJLw7CpmSbBYFWHxIs= =Jm6t -----END PGP SIGNATURE----- From fedora at leemhuis.info Sat Nov 29 10:04:09 2003 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 29 Nov 2003 11:04:09 +0100 Subject: Self-Introduction: Thorsten Leemhuis Message-ID: <1070100249.1590.7.camel@work.thl.home> [second attempt, seems the first mail didn't make it to the list] Full legal name: Thorsten Leemhuis Country, City: Hannover, Germany Goals: Build and QA packages that I use myself that are currently missing and may (or may not) be usable for others. Historical qualifications: None appreciable ;-) Okay, some real info: After 10 years I changed from OS/2 to Red Hat Linux in the beginning of 2000. Good in bash-programming, some skills in java. Don't know if I ever find enough time to really learn C or Python. Lot of interest and know-how in Linux compatible hardware and how to make it work. GPG KEYID and fingerprint pub 1024D/55FB7C4E 2003-11-28 Thorsten Leemhuis Schl.-Fingerabdruck = BB70 9E3B 9941 B800 006A 54A9 D997 D8BA 55FB 7C4E sub 1024g/A587192E 2003-11-28 [verf?llt: 2005-11-27] CU thl From buildsys at porkchop.devel.redhat.com Sat Nov 29 12:28:37 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sat, 29 Nov 2003 07:28:37 -0500 Subject: rawhide report: 20031129 changes Message-ID: <200311291228.hATCSbh12711@porkchop.devel.redhat.com> New package expect A program-script interaction and testing utility Removed package tcltk Updated Packages: PyQt-3.8.1-3 ------------ * Thu Nov 27 2003 Than Ngo 3.8.1-3 - rebuild against python 2.3/ Qt 3.2.3 bash-2.05b-33 ------------- * Fri Nov 28 2003 Tim Waugh 2.05b-33 - Speed up UTF-8 command-line redrawing in the common case (bug #102353, bug #110777). foomatic-3.0.0-12 ----------------- * Sat Nov 29 2003 Tim Waugh 3.0.0-12 - Undo over-zealous percent escaping in PostScript.xml - Build requires libxml2-devel (bug #110589). - Use relative, not absolute, symlink for CUPS filter. kdesdk-3.1.93-0.4 ----------------- * Fri Nov 28 2003 Than Ngo 2:3.1.93-0.4 - fixed db4 issue * Thu Nov 27 2003 Than Ngo 2:3.1.93-0.3 - get rid of rpath * Wed Nov 26 2003 Than Ngo 2:3.1.93-0.2 - fixed type conflict on x86_64 * Thu Nov 13 2003 Than Ngo 2:3.1.93-0.1 - KDE 3.2 Beta1 - cleanup mktemp-1.5-6 ------------ * Fri Nov 28 2003 Phil Knirsch 2:1.5-6 - Bumped release and rebuilt. postgresql-7.4-3 ---------------- * Fri Nov 28 2003 David Jee 7.4-3 - uncomment buildrequires tcl-devel * Fri Nov 28 2003 David Jee 7.4-2 - rebuild * Mon Nov 24 2003 David Jee 7.4-1 - initial Red Hat build - move jars to /usr/share/java - fix rpm-multilib patch to use sysconfig * Fri Nov 21 2003 Lamar Owen - 7.4-0.1PGDG - Development JDBC jars in addition to the 7.3 jars; will replace the - 7.3 jars once 7.4 official jars are released. - Changed to use the bzip2 source to save a little size. - Removed some commented out portions of the specfile. - Removed the 7.3.4 PDF docs. Will replace with 7.4 PDF's once they - are ready. * Tue Nov 18 2003 Kaj J. Niemi 7.4-0.1 - 7.4 - Fixed Patch #1 (now rpm-pgsql-7.4.patch) - Fixed Patch #2 (now rpm-multilib-7.4.patch): - Patch #4 is unnecessary (upstream) - Fixed Patch #6 (now postgresql-7.4-src-tutorial.patch) - Added Patch #8 (postgresql-7.4-com_err.patch) as com_err() is provided by e2fsprogs and CPPFLAGS gets lost somewhere inside configure (bad macro?) - No 7.4 PDF docs available yet (Source #17) - PyGreSQL is separated from the upstream distribution but we include it as usual (Source #18) - Default to compiling libpq and ECPG as fully thread-safe - 7.4 Origin. See previous spec files for previous history. Adapted - from Red Hat and PGDG's 7.3.4 RPM, directly descended from - postgresql-7.3.4-2 as shipped in Fedora Core 1. python-2.3.2-7 -------------- * Fri Nov 28 2003 Mihai Ibanescu 2.3.2-7 - rebuilt against newer tcl/tk readline-4.3-9 -------------- * Fri Nov 28 2003 Thomas Woerner 4.3-9 - removed rpath readline41-4.1-18 ----------------- * Fri Nov 28 2003 Thomas Woerner 4.1-18 - removed rpath rpmdb-fedora-1.90-0.20031129 ---------------------------- s390utils-1.2.3-1 ----------------- * Fri Nov 28 2003 Phil Knirsch 2:1.2.3-1 - New bugfix release 1.2.3 came out today, updated again. wget-1.9.1-2 ------------ * Fri Nov 28 2003 Karsten Hopp 1.9.1-2 - add patch from -stable CVS * Fri Nov 28 2003 Karsten Hopp 1.9.1-1 - update to 1.9.1 - remove obsolete patches From lowen at pari.edu Sat Nov 29 17:50:52 2003 From: lowen at pari.edu (Lamar Owen) Date: Sat, 29 Nov 2003 12:50:52 -0500 Subject: SMP i586? In-Reply-To: <20031127035915.GA1329137@hiwaay.net> References: <200311211715.43696.lowen@pari.edu> <200311261937.32379.lowen@pari.edu> <20031127035915.GA1329137@hiwaay.net> Message-ID: <200311291250.52403.lowen@pari.edu> On Wednesday 26 November 2003 10:59 pm, Chris Adams wrote: > Last time I looked, the kernel.spec file dropped all support for --with > and --without some time back. There are still references in comments, > but I don't think any actually work (unless there is some behind the > scenes RPM magic going on). > It is kind of annoying when you are trying to rebuild just one package. Hmmm. The last time I used the --with/--without (the only time I've used those options, AAMOF, was when building a SuperFreeS/WAN kernel source RPM for Red Hat 8.0 (2.4.20 kernel). It worked then; but that's a fairly old spec. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From lowen at pari.edu Sat Nov 29 17:52:43 2003 From: lowen at pari.edu (Lamar Owen) Date: Sat, 29 Nov 2003 12:52:43 -0500 Subject: SMP i586? In-Reply-To: <20031127020618.2bb9fe9a.ms-nospam-0306@arcor.de> References: <200311211715.43696.lowen@pari.edu> <200311261937.32379.lowen@pari.edu> <20031127020618.2bb9fe9a.ms-nospam-0306@arcor.de> Message-ID: <200311291252.43507.lowen@pari.edu> On Wednesday 26 November 2003 08:06 pm, Michael Schwendt wrote: > There are docs about that in: /usr/share/doc/rpm-*/conditionalbuilds Now that's a useful tidbit for the archives. One must remember not to just read the docs one time, but refer back to the docs occasionally to see what's changed. For so long there was very little documented; now it seems that that has improved. I follow rpm-list infrequently, but I guess I need to do some catchup reading. Thanks. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From stan at ccs.neu.edu Sun Nov 30 07:04:47 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Sun, 30 Nov 2003 02:04:47 -0500 Subject: CPAN RPM archive? In-Reply-To: <20031130005200.GA15845@chrisgrau.com> References: <1070142405.19063.10.camel@duergar> <20031130005200.GA15845@chrisgrau.com> Message-ID: <1070175886.19063.23.camel@duergar> On Sat, 2003-11-29 at 19:52, Chris Grau wrote: > On Sat, Nov 29, 2003 at 04:46:46PM -0500, Stan Bubrouski wrote: > > Hey, > > > > I was wondering if there were any sites that have CPAN modules already > > in RPMs ready to install for say Fedora or RH? (even if its just using > > simple cpan2rpm program) > > http://rpmpan.sourceforge.net/ > > Are there any places that supply the source RPMs? All I see are noarch and i386 rpms. There are definitely a few things (like Digest::xxx modules) I'd like to be able to compile with optimizations. I was trying cpan2rpm today which is pretty cool, but build reqs. and dependencies are all looked for as rpms which is annoying. I know you can have it ignore them, but that just complicates things and isn't a real solution. If no such archive exists, would anyone be interested in hosting one for Fedora? I'll put in the work (though spec file magic will require some help) getting modules worked up initially in my spare time if the community would find it helpful. Would any of you be interested in such a project? I find it annoying installing modules and their requisits every time I find I need them. Plus keeping track of what I've installed is a hassle and half, the idea is to use rpm to alleviate such headaches, after all perl just r0x. I am wondering though if anyone has any ideas about how to go about not messing up the perl packages entries when you want to update the modules that come included with the packages? -sb > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From chris at chrisgrau.com Sun Nov 30 08:10:32 2003 From: chris at chrisgrau.com (Chris Grau) Date: Sun, 30 Nov 2003 00:10:32 -0800 Subject: CPAN RPM archive? In-Reply-To: <1070175886.19063.23.camel@duergar> References: <1070142405.19063.10.camel@duergar> <20031130005200.GA15845@chrisgrau.com> <1070175886.19063.23.camel@duergar> Message-ID: <20031130081032.GA17351@chrisgrau.com> On Sun, Nov 30, 2003 at 02:04:47AM -0500, Stan Bubrouski wrote: > If no such archive exists, would anyone be interested in hosting one > for Fedora? I don't know of one. I'd be happy to contribute to such an effort. I already maintain several dozen .spec files for CPAN modules for work and personal use, since I'm a fan of RPM. I've developed (what I think) is a pretty good .spec template for the job, though I haven't yet hacked cpan2rpm to use it. You could always email the maintainer of RPMPan to ask if he'd mind posting the source RPMs as well. It seems he already has an apt repository, so it should work with Fedora's up2date. -chris From buildsys at porkchop.devel.redhat.com Sun Nov 30 11:37:04 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sun, 30 Nov 2003 06:37:04 -0500 Subject: rawhide report: 20031130 changes Message-ID: <200311301137.hAUBb4x16317@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.90-0.20031130 ---------------------------- From warren at togami.com Sun Nov 30 12:02:43 2003 From: warren at togami.com (Warren Togami) Date: Sun, 30 Nov 2003 02:02:43 -1000 Subject: CPAN RPM archive? In-Reply-To: <20031130081032.GA17351@chrisgrau.com> References: <1070142405.19063.10.camel@duergar> <20031130005200.GA15845@chrisgrau.com> <1070175886.19063.23.camel@duergar> <20031130081032.GA17351@chrisgrau.com> Message-ID: <1070193762.6099.9.camel@laptop> I would urge you all to look at the cpan2rpm and perl-RPM-Specfile at fedora.us. Ville Skytta worked hard to modify both packages to output RHattified spec files that for the most part "proper". In many cases fedora.us has simply used auto-generated specs and modified it slightly to have better descriptions, comments and a changelog. In some instances however minor patches are needed to make it properly integrate in a Red Hat-ish way. http://www.fedora.us/QA A great many perl packages are currently in Fedora QA. We need other qualified perl people to test the functionality and properness of these packages in order to help get them published sooner. Some of the NEEDSWORK keyword problems are examples why it is not only a simple matter of automatic generation of spec files. https://bugzilla.fedora.us/show_bug.cgi?id=377 I especially would appreciate comment on this one, where the build works on RH9 but fails on FC1. Thanks, Warren Togami warren at togami.com From julo at altern.org Sun Nov 30 12:30:20 2003 From: julo at altern.org (Julien Olivier) Date: Sun, 30 Nov 2003 12:30:20 +0000 Subject: Strange bug freezing my laptop In-Reply-To: <1070152588.15166.3.camel@localhost.localdomain> References: <1070055520.3508.13.camel@localhost.localdomain> <1070056065.2516.4.camel@localhost.localdomain> <1070152588.15166.3.camel@localhost.localdomain> Message-ID: <1070195419.3513.13.camel@localhost.localdomain> > I'll post my dmesg as soon as i make it freeze again. > And here it is :) Sadly, the freeze happened again without the notification area. So, it's something else. I attache the dmesg output just after the hard-reboot. My laptop has been up playing music all night long, and has frozen while I was writing an email around noon. I was running GNOME, rhythmbox, evolution and mozilla. Thanks for your help. -- Julien Olivier -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg Type: application/octet-stream Size: 11608 bytes Desc: not available URL: From Nicolas.Mailhot at laPoste.net Sun Nov 30 13:14:26 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 30 Nov 2003 14:14:26 +0100 Subject: fstab problem with mount In-Reply-To: <3FC777E3.20802@comcast.net> References: <3FC3A47E.8040300@comcast.net> <3FC777E3.20802@comcast.net> Message-ID: <1070198066.3155.4.camel@m202.net81-64-234.noos.fr> Le ven 28/11/2003 ? 17:29, snookertb a ?crit : > The problem appears to be the second disk that I had connected to > transfer files from. It was an old RH9 install which also names the > partitions /boot. This label conflict seems to be at the root of the > problem. > > Configuration is disk 1 with a new install of FC1 and disk 2 with an old > install of rh9. Both disk end up with disk partitions labeled /boot. So > when I tried to make a mount on disk 1 of a new partition, to hold the > files, and then a mount of the disk 2 / partition, things got flakey. > > IMHO there needs to be a resolution to this or at least a work around > put in the docs. I loaded up knoppix and transferred the files then > deleted the original disk 2 partitions, reformatted and installed new > disk 2 partitions and all is OK. You should have just relabelled the old partitions with e2label > I got in this fix by trying to do a simple install of a new bigger > faster main disk and preserve the old files on the exiting disk. A > pretty common upgrade approach if you ask me. e2label is your friend. When you use labelled fstab it's *your* job to check there aren't two partitions with the same label on the system. Anaconda sure needs to expose labels and allow setting them in the format screen, but that wouldn't have helped you here. 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 ville.skytta at iki.fi Sun Nov 30 13:15:08 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 30 Nov 2003 15:15:08 +0200 Subject: CPAN RPM archive? In-Reply-To: <1070193762.6099.9.camel@laptop> References: <1070142405.19063.10.camel@duergar> <20031130005200.GA15845@chrisgrau.com> <1070175886.19063.23.camel@duergar> <20031130081032.GA17351@chrisgrau.com> <1070193762.6099.9.camel@laptop> Message-ID: <1070198108.25525.130.camel@bobcat.mine.nu> On Sun, 2003-11-30 at 14:02, Warren Togami wrote: > I would urge you all to look at the cpan2rpm and perl-RPM-Specfile at > fedora.us. Ville Skytta worked hard to modify both packages to output > RHattified spec files that for the most part "proper". In many cases > fedora.us has simply used auto-generated specs and modified it slightly > to have better descriptions, comments and a changelog. In some > instances however minor patches are needed to make it properly integrate > in a Red Hat-ish way. Some minor corrections and my IMHO, YMMV status: I haven't really looked into cpan2rpm but I have made some improvements to the perl-RPM-Specfile package (be sure to grab the fedora.us version as all changes have been submitted upstream, but not applied yet). Anyway, both cpanflute2 and cpan2rpm produce pretty obfuscated specfiles. Instead of using them, there's a bunch of perl-* packages in the www.fedora.us/QA queue (and lots more not-yet-submitted ones at cachalot.mine.nu/1/SRPMS.fdr/) which are based on a template which is based on earlier discussions in bugzilla.fedora.us and fedora-devel at fedora.us list. I've just submitted the specfile template to https://bugzilla.fedora.us/show_bug.cgi?id=1010 for comments. cpanflute2 and/or cpan2rpm could possibly be tweaked more towards this. The main difference currently with the template and cpanflute2 is that the template takes care of removing more unneeded files and bluntly works around the unowned dirs issue in the past and current RH and FC perl packages, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73970 For some weird reason, even though perl module packages (especially when a template is consistently used) are trivial to review, the QA process seems to take a long time. Help is certainly welcome in this area. From Nicolas.Mailhot at laPoste.net Sun Nov 30 13:17:14 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 30 Nov 2003 14:17:14 +0100 Subject: Strange bug freezing my laptop In-Reply-To: <1070152798.15166.8.camel@localhost.localdomain> References: <1070055520.3508.13.camel@localhost.localdomain> <49438.82.67.136.167.1070056695.squirrel@webmail.sciences.univ-nantes.fr> <1070152798.15166.8.camel@localhost.localdomain> Message-ID: <1070198233.3155.7.camel@m202.net81-64-234.noos.fr> Le dim 30/11/2003 ? 01:39, Julien Olivier a ?crit : > On Fri, 2003-11-28 at 21:58, Arnaud Abelard wrote: > > > Hi guys. > > > > Helllo, > > > > >>>From time to time (rather randomly), my CPU gets used at 100% (at > > >> least, > > > my laptop's led blinks a lot), my mouse works (I can move it but not > > > click) but not my keyboard. Then, about 30 seconds later, even the mouse > > > stops moving and I have to hard-reboot my laptop. > > > > Doesn't look like a CPU consumption but more like a memory problem... have > > you tried monitoring your memory usage? (even with the system monitor > > applet) If you aren't working as root on your laptop you could use > > pam_limits to limit your memory usage (and see what process gets killed by > > using too much memory) or keep an eye on a top sorted by memory usage. > > > > As I said in a previous email, the bug seems to have gone when I removed > the notification area from the panel. If it happens again, I'll also > watch my memory usage. > > That said, the notification area could have had a memory leak. The notification area is *evil*. When I forget to remove it on any system I have many problems just like you. 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 rms at 1407.org Sun Nov 30 14:41:54 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 30 Nov 2003 14:41:54 +0000 Subject: abiword tentative yum repo Message-ID: <1070203314.3314.14.camel@roque> Hi, I'm trying to setup an yum repo for AbiWord at savannah.gnu.org/download/yum I know I have some directory structure tactical problems, but I'll solve them when I'm on a faster network, so let's not talk about them right now, since I'm running into some weird problem, I think totally unrelated to the dirs. [root at roque root]# yum install abiword-plugins-impexp Gathering header information file(s) from server(s) Server: AbiWord cvsbuilds and releases for Fedora Core 1 - i386 Server: Fedora Core 1 - i386 - Base Server: Fedora Core 1 - i386 - Released Updates Finding updated packages Downloading needed headers Resolving dependencies .....identical dependency loop exceeded package abiword needs libwpd-1.so.2 (not provided) Now, I have zero matches of libwpd-1.so.2 on the rpms I provide at savannah. Where's that comming from? Can someone help me? 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 Sun Nov 30 14:45:51 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 30 Nov 2003 14:45:51 +0000 Subject: abiword tentative yum repo In-Reply-To: <1070203314.3314.14.camel@roque> References: <1070203314.3314.14.camel@roque> Message-ID: <1070203551.3314.17.camel@roque> On Sun, 2003-11-30 at 14:41, Rui Miguel Seabra wrote: > [root at roque root]# yum install abiword-plugins-impexp > Gathering header information file(s) from server(s) > Server: AbiWord cvsbuilds and releases for Fedora Core 1 - i386 > Server: Fedora Core 1 - i386 - Base > Server: Fedora Core 1 - i386 - Released Updates > Finding updated packages > Downloading needed headers > Resolving dependencies > .....identical dependency loop exceeded > package abiword needs libwpd-1.so.2 (not provided) BTW, this is not true. abiword-VER does not depend on libwpd, abiword-plugins-tools-VER does not as well. abiword-plugins-impexp does depend on libwpd, but not the version yum is complaining... 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 Sun Nov 30 14:49:28 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 30 Nov 2003 14:49:28 +0000 Subject: abiword tentative yum repo In-Reply-To: <1070203551.3314.17.camel@roque> References: <1070203314.3314.14.camel@roque> <1070203551.3314.17.camel@roque> Message-ID: <1070203767.3314.19.camel@roque> And when installed separately all three packages install without a problem... On Sun, 2003-11-30 at 14:45, Rui Miguel Seabra wrote: > On Sun, 2003-11-30 at 14:41, Rui Miguel Seabra wrote: > > [root at roque root]# yum install abiword-plugins-impexp > > Gathering header information file(s) from server(s) > > Server: AbiWord cvsbuilds and releases for Fedora Core 1 - i386 > > Server: Fedora Core 1 - i386 - Base > > Server: Fedora Core 1 - i386 - Released Updates > > Finding updated packages > > Downloading needed headers > > Resolving dependencies > > .....identical dependency loop exceeded > > package abiword needs libwpd-1.so.2 (not provided) > > BTW, this is not true. abiword-VER does not depend on libwpd, > abiword-plugins-tools-VER does not as well. > > abiword-plugins-impexp does depend on libwpd, but not the version yum is > complaining... > > 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 skvidal at phy.duke.edu Sun Nov 30 16:38:17 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 30 Nov 2003 11:38:17 -0500 Subject: abiword tentative yum repo In-Reply-To: <1070203314.3314.14.camel@roque> References: <1070203314.3314.14.camel@roque> Message-ID: <1070210297.3519.33.camel@binkley> > I know I have some directory structure tactical problems, but I'll solve > them when I'm on a faster network, so let's not talk about them right > now, since I'm running into some weird problem, I think totally > unrelated to the dirs. > > [root at roque root]# yum install abiword-plugins-impexp > Gathering header information file(s) from server(s) > Server: AbiWord cvsbuilds and releases for Fedora Core 1 - i386 > Server: Fedora Core 1 - i386 - Base > Server: Fedora Core 1 - i386 - Released Updates > Finding updated packages > Downloading needed headers > Resolving dependencies > .....identical dependency loop exceeded > package abiword needs libwpd-1.so.2 (not provided) > > > Now, I have zero matches of libwpd-1.so.2 on the rpms I provide at > savannah. Where's that comming from? Can someone help me? out of curiosity. You're installing abiword-plugins-impexp do you have abiword installed already? do an rpm -q --requires abiword and tell me if you see a dependency on libwpd-1.so.2. For the abiword shipped in fedora core 1, I see that dependency. can you point me at these packages so I can see their dependencies, I think something is not right in one of the packages. -sv From skvidal at phy.duke.edu Sun Nov 30 16:49:01 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 30 Nov 2003 11:49:01 -0500 Subject: abiword tentative yum repo In-Reply-To: <1070203767.3314.19.camel@roque> References: <1070203314.3314.14.camel@roque> <1070203551.3314.17.camel@roque> <1070203767.3314.19.camel@roque> Message-ID: <1070210940.3519.37.camel@binkley> On Sun, 2003-11-30 at 09:49, Rui Miguel Seabra wrote: > And when installed separately all three packages install without a > problem... Hi, I downloaded the abiword abiword-plugins-impexp from http://www.abisource.com/download/ I made a local yum repository w/just the two packages for abiword and included that yum repo in my yum.conf. when I run yum install abiword-plugins-impexp after having removed abiword and libwpd. yum finds both of those dependencies and installs them. Are you sure fedora core repositories are working correctly? b/c libwpd should be findable w/o a problem. -sv From jaap at haitsma.org Sun Nov 30 17:06:18 2003 From: jaap at haitsma.org (Jaap A. Haitsma) Date: Sun, 30 Nov 2003 18:06:18 +0100 Subject: Idea for ftp (apt yum) mirrors Message-ID: <3FCA238A.40909@haitsma.org> For popular ftp sites there usually exist quite a number of mirrors. The link on the webpage of the original developer/owner to his own ftp site. Furthermore there is usually a page containing all the mirror sites. Consquence of this is that ftp site of the original developer/owner gets most of the traffic and quite some users experience a download which is slower then would be needed (a mirror close by would probably be faster). For Windooz there exist programs which you run on your machine which automatically find the best mirror or download from multiple mirrors E.g. Download Accelelator http://www.speedbit.com/DAP7/DefaultT.asp? Disadvantage of this is that you need this extra program. Isn't it possible to solve this just on the server side, so that for a user it is just transparent where the file comes from. I'll try to explain it further with an example. Let's say redhat publishes a new file and put a link on their webpage If a user now clicks on the link a javascript will run in the browser of the user which checks which of the mirrors is geographically close by and has still spare capacity and starts downloading from that file. This has 3 advantages. The user receives the file earlier, Redhat saves some bandwidth and its completely transparent I don't know if javascript can do this but I just use for explaining the idea. You could also enhance apt or yum with this. Does this exist? Is it possible? If it possible/exists why does nobody use it. Jaap From julo at altern.org Sun Nov 30 17:15:27 2003 From: julo at altern.org (Julien Olivier) Date: Sun, 30 Nov 2003 17:15:27 +0000 Subject: Strange bug freezing my laptop In-Reply-To: <1070198233.3155.7.camel@m202.net81-64-234.noos.fr> References: <1070055520.3508.13.camel@localhost.localdomain> <49438.82.67.136.167.1070056695.squirrel@webmail.sciences.univ-nantes.fr> <1070152798.15166.8.camel@localhost.localdomain> <1070198233.3155.7.camel@m202.net81-64-234.noos.fr> Message-ID: <1070212526.3513.24.camel@localhost.localdomain> > > That said, the notification area could have had a memory leak. > > The notification area is *evil*. When I forget to remove it on any > system I have many problems just like you. But this time it doesn't seem to be guilty as I could reproduce the bug without it running... -- Julien Olivier From jos at xos.nl Sun Nov 30 17:19:49 2003 From: jos at xos.nl (Jos Vos) Date: Sun, 30 Nov 2003 18:19:49 +0100 Subject: Idea for ftp (apt yum) mirrors In-Reply-To: <3FCA238A.40909@haitsma.org>; from jaap@haitsma.org on Sun, Nov 30, 2003 at 06:06:18PM +0100 References: <3FCA238A.40909@haitsma.org> Message-ID: <20031130181949.A13764@xos037.xos.nl> On Sun, Nov 30, 2003 at 06:06:18PM +0100, Jaap A. Haitsma wrote: > I don't know if javascript can do this but I just use for explaining the > idea. > > You could also enhance apt or yum with this. > > Does this exist? Is it possible? If it possible/exists why does nobody > use it. Javascript (brrr...) would only work with a (graphical) browser, while lost of downloads are done via command-line ftp (ncftpget) or http (curl, wget) clients. Furthermore, AFAIK there is no (free) system that easily finds a *geographically* nearby mirror. In Europe you could maybe check on your own country (== top level domain), but this does not work for .com etc. domains that many European companies have. And, last but not least, as one of the maintainers of a big ftp site I can say that lost of people *do* know how to find a nearby mirror, so there is no real need for this. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jaap at haitsma.org Sun Nov 30 17:32:05 2003 From: jaap at haitsma.org (Jaap A. Haitsma) Date: Sun, 30 Nov 2003 18:32:05 +0100 Subject: Idea for ftp (apt yum) mirrors In-Reply-To: <20031130181949.A13764@xos037.xos.nl> References: <3FCA238A.40909@haitsma.org> <20031130181949.A13764@xos037.xos.nl> Message-ID: <3FCA2995.9050208@haitsma.org> Jos Vos wrote: > On Sun, Nov 30, 2003 at 06:06:18PM +0100, Jaap A. Haitsma wrote: > > >>I don't know if javascript can do this but I just use for explaining the >>idea. >> >>You could also enhance apt or yum with this. >> >>Does this exist? Is it possible? If it possible/exists why does nobody >>use it. > > > Javascript (brrr...) would only work with a (graphical) browser, while > lost of downloads are done via command-line ftp (ncftpget) or http > (curl, wget) clients. > > Furthermore, AFAIK there is no (free) system that easily finds a > *geographically* nearby mirror. In Europe you could maybe check on > your own country (== top level domain), but this does not work for > .com etc. domains that many European companies have. > > And, last but not least, as one of the maintainers of a big ftp site > I can say that lost of people *do* know how to find a nearby mirror, > so there is no real need for this. > Of course people would still be able to get it still with wget or ftp or similar tools. Only if you click on the link on the webpage you would get this feature. Like I said the javascript was just an example. I would even prefer to do this completely on the server side, but I do not really see how that will be possible. The nice thing of what I propose that it is adaptive and transparent. From Nicolas.Mailhot at laPoste.net Sun Nov 30 18:17:57 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 30 Nov 2003 19:17:57 +0100 Subject: Idea for ftp (apt yum) mirrors In-Reply-To: <3FCA2995.9050208@haitsma.org> References: <3FCA238A.40909@haitsma.org> <20031130181949.A13764@xos037.xos.nl> <3FCA2995.9050208@haitsma.org> Message-ID: <1070216277.2389.4.camel@m202.net81-64-234.noos.fr> Le dim 30/11/2003 ? 18:32, Jaap A. Haitsma a ?crit : > Of course people would still be able to get it still with wget or ftp or > similar tools. Only if you click on the link on the webpage you would > get this feature. The fact is, the server should just provide a mirror list and let the download manager do whatever is smartest with it. There is absolutely nothing a user can do manually to check what mirror is best a software can not do better (except for weird pricing policies, but that's what manual overrides are for). See the previous (unfinished) thread on this. 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 mrsam at courier-mta.com Sun Nov 30 18:26:07 2003 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 30 Nov 2003 13:26:07 -0500 Subject: Idea for ftp (apt yum) mirrors References: <3FCA238A.40909@haitsma.org> <20031130181949.A13764@xos037.xos.nl> Message-ID: Jos Vos writes: > On Sun, Nov 30, 2003 at 06:06:18PM +0100, Jaap A. Haitsma wrote: > >> I don't know if javascript can do this but I just use for explaining the >> idea. >> >> You could also enhance apt or yum with this. >> >> Does this exist? Is it possible? If it possible/exists why does nobody >> use it. > > Javascript (brrr...) would only work with a (graphical) browser, while > lost of downloads are done via command-line ftp (ncftpget) or http > (curl, wget) clients. The default list of up2date sources already uses an HTTP redirect: Nov 24 07:11:05 Privoxy(-1158255696) Request: fedora.redhat.com/releases/fedora-core-1/headers/header.info Nov 24 07:11:05 Privoxy(-1158255696) Request: download.fedora.redhat.com/pub/fedora/linux/core/1/i386/os/headers/header.info Looking at the logs, _EVERY_ request from up2date gets redirected in this fashion. This actually slows things down for no good reason. The only thing that needs to be done here is to have up2date pay attention to the first redirect, and all subsequent requests would go directly to the redirected site; then have the original redirector check the available mirrors, and choose the most appropriate one for the client's request. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From julo at altern.org Sun Nov 30 19:56:37 2003 From: julo at altern.org (Julien Olivier) Date: Sun, 30 Nov 2003 19:56:37 +0000 Subject: Strange bug freezing my laptop In-Reply-To: <1070195419.3513.13.camel@localhost.localdomain> References: <1070055520.3508.13.camel@localhost.localdomain> <1070056065.2516.4.camel@localhost.localdomain> <1070152588.15166.3.camel@localhost.localdomain> <1070195419.3513.13.camel@localhost.localdomain> Message-ID: <1070222197.3568.7.camel@localhost.localdomain> Today, I let my laptop running all day long. When I came back, it was still working but the hard disk's led was on. All _seemed_ to work as normal but going to a virtual console (CTRL-ALT-1), I saw several error messages like stating there was an I/O error trying to access /dev/hda3. And every app had problems: rhythmbox couldn't play music anymore, complaining about missing plugins, evolution couldn't save messages because it couldn't write on the hard drive etc... I rebooted my laptop and all was OK again... Does that sound familiar to anyone ? Should I try appending ide=nodma to grub.conf ? -- Julien Olivier From mail at oripessach.com Sun Nov 30 21:56:04 2003 From: mail at oripessach.com (Ori Pessach) Date: Sun, 30 Nov 2003 14:56:04 -0700 Subject: Strange bug freezing my laptop In-Reply-To: <1070222197.3568.7.camel@localhost.localdomain> References: <1070055520.3508.13.camel@localhost.localdomain> <1070056065.2516.4.camel@localhost.localdomain> <1070152588.15166.3.camel@localhost.localdomain> <1070195419.3513.13.camel@localhost.localdomain> <1070222197.3568.7.camel@localhost.localdomain> Message-ID: <3FCA6774.6040702@oripessach.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julien Olivier wrote: | Today, I let my laptop running all day long. When I came back, it was | still working but the hard disk's led was on. All _seemed_ to work as | normal but going to a virtual console (CTRL-ALT-1), I saw several error | messages like stating there was an I/O error trying to access /dev/hda3. | And every app had problems: rhythmbox couldn't play music anymore, | complaining about missing plugins, evolution couldn't save messages | because it couldn't write on the hard drive etc... I rebooted my laptop | and all was OK again... | | Does that sound familiar to anyone ? Should I try appending ide=nodma to | grub.conf ? I've seen something similar, when running with a 2.6.0test11 kernel. I got an I/O error writing the ext3 journal, and after that my root filesystem was mounted read only, which had a similar effect to what you saw. I never saw this happen with another kernel version, though. - -- Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/ymdyzA/uWWyw6uQRAu7rAKDHpUIO5dlUBbAn1Hq+Ut0R6LqCswCffJfg vG2Q4gv/fTBEWq7qWWVT+Ko= =mJns -----END PGP SIGNATURE----- From julo at altern.org Sun Nov 30 22:00:34 2003 From: julo at altern.org (Julien Olivier) Date: Sun, 30 Nov 2003 22:00:34 +0000 Subject: Strange bug freezing my laptop In-Reply-To: <3FCA6774.6040702@oripessach.com> References: <1070055520.3508.13.camel@localhost.localdomain> <1070056065.2516.4.camel@localhost.localdomain> <1070152588.15166.3.camel@localhost.localdomain> <1070195419.3513.13.camel@localhost.localdomain> <1070222197.3568.7.camel@localhost.localdomain> <3FCA6774.6040702@oripessach.com> Message-ID: <1070229634.3362.1.camel@localhost.localdomain> > I've seen something similar, when running with a 2.6.0test11 kernel. I > got an I/O error writing the ext3 journal, and after that my root > filesystem was mounted read only, which had a similar effect to what you > saw. I never saw this happen with another kernel version, though. > Just for information, I'm using the 2.4.22-1.2115.nptl kernel. -- Julien Olivier From rms at 1407.org Sun Nov 30 22:22:41 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 30 Nov 2003 22:22:41 +0000 Subject: abiword tentative yum repo In-Reply-To: <1070210297.3519.33.camel@binkley> References: <1070203314.3314.14.camel@roque> <1070210297.3519.33.camel@binkley> Message-ID: <1070230961.3314.25.camel@roque> On Sun, 2003-11-30 at 16:38, seth vidal wrote: > > [root at roque root]# yum install abiword-plugins-impexp > > Gathering header information file(s) from server(s) > > Server: AbiWord cvsbuilds and releases for Fedora Core 1 - i386 > > Server: Fedora Core 1 - i386 - Base > > Server: Fedora Core 1 - i386 - Released Updates > > Finding updated packages > > Downloading needed headers > > Resolving dependencies > > .....identical dependency loop exceeded > > package abiword needs libwpd-1.so.2 (not provided) > > Now, I have zero matches of libwpd-1.so.2 on the rpms I provide at > > savannah. Where's that comming from? Can someone help me? > > out of curiosity. You're installing abiword-plugins-impexp > do you have abiword installed already? I usually package RPMS for AbiWord and place them on Savannah. Since many complained about the dependencies, et all, I intend to put up a um repository. The first thing I do after a RedHat/Fedora Core installation in remove Abiword as distributed :) > do an rpm -q --requires abiword and tell me if you see a dependency on > libwpd-1.so.2. > For the abiword shipped in fedora core 1, I see that dependency. Yup. But not on my rpms, that's what I find weird. > can you point me at these packages so I can see their dependencies, I > think something is not right in one of the packages. Sure: http://savannah.gnu.org/download/abiword/yum 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 Sun Nov 30 22:23:59 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 30 Nov 2003 22:23:59 +0000 Subject: abiword tentative yum repo In-Reply-To: <1070210940.3519.37.camel@binkley> References: <1070203314.3314.14.camel@roque> <1070203551.3314.17.camel@roque> <1070203767.3314.19.camel@roque> <1070210940.3519.37.camel@binkley> Message-ID: <1070231038.3314.28.camel@roque> On Sun, 2003-11-30 at 16:49, seth vidal wrote: > On Sun, 2003-11-30 at 09:49, Rui Miguel Seabra wrote: > > And when installed separately all three packages install without a > > problem... > > Hi, > I downloaded the abiword abiword-plugins-impexp from > http://www.abisource.com/download/ > > I made a local yum repository w/just the two packages for abiword and > included that yum repo in my yum.conf. > > when I run yum install abiword-plugins-impexp after having removed > abiword and libwpd. > > yum finds both of those dependencies and installs them. > > Are you sure fedora core repositories are working correctly? b/c libwpd > should be findable w/o a problem. Abiword HEAD requires a more recent libwpd, and I'm talking about _my_own_ repository, which I think might be screwed so I need help, and not of FC's repos. Thanks anyway, 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: