From warren at togami.com Wed Oct 1 02:27:21 2003 From: warren at togami.com (Warren Togami) Date: Tue, 30 Sep 2003 16:27:21 -1000 Subject: xmms release number In-Reply-To: <20030930111405.J13840@devserv.devel.redhat.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> Message-ID: <1064975240.1954.48.camel@laptop> On Tue, 2003-09-30 at 05:14, Bill Nottingham wrote: > Nils Philippsen (nphilipp at redhat.com) said: > > > can't we name our release s.th. like -0.x for xmms, so that users can > > > use up2date and install the original xmms-xxx-1 from www.xmms.org with > > > MP3 support? > > > > I don't think this is necessary, as people easily can install xmms-mp3 > > packages from third parties on top of the Fedora xmms package. > > That was my initial reaction... do more people install xmms-mp3, > or the xmms.org packages? > > Bill I believe end users who don't know about apt/yum and third party repositories tend to download the full RPMS from xmms.org, while repository users tend to install xmms-mp3. Warren From skvidal at phy.duke.edu Wed Oct 1 02:36:58 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Sep 2003 22:36:58 -0400 Subject: xmms release number In-Reply-To: <1064975240.1954.48.camel@laptop> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> Message-ID: <1064975818.32323.26.camel@binkley> > I believe end users who don't know about apt/yum and third party > repositories tend to download the full RPMS from xmms.org, while > repository users tend to install xmms-mp3. > I've been giving some thought to what to do about the possible glut of packages that could be in fedora extras/alternatives/etc The problem is the same problem with the menus under X for a while - no one knew what 'xmms' was so they didn't know to look for it to play mp3s or oggs. no one knew what galeon was so they didn't know to use it for web browsing, or epiphany or hell, mozilla, for that matter. As an idea, once package submission starts happening into fedora extras it might be worthwhile to include some keywords describing the package or maybe make it a policy that packages include, in the description field a Keywords: foo bar baz line. or maybe consider building up comps.xml/yumgroups.xml files that could create groups of packages for people to search for. -sv From hp at redhat.com Wed Oct 1 02:52:30 2003 From: hp at redhat.com (Havoc Pennington) Date: 30 Sep 2003 22:52:30 -0400 Subject: xmms release number In-Reply-To: <1064975818.32323.26.camel@binkley> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> Message-ID: <1064976749.13480.108.camel@dhcppc3> On Tue, 2003-09-30 at 22:36, seth vidal wrote: > or maybe consider building up comps.xml/yumgroups.xml files that could > create groups of packages for people to search for. That's what I'd like to see. Maybe even a requirement that all "end user visible" packages be in a comps file. redhat-config-packages can then display nice sane things instead of raw RPM package names. Havoc From skvidal at phy.duke.edu Wed Oct 1 03:03:20 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Sep 2003 23:03:20 -0400 Subject: xmms release number In-Reply-To: <1064976749.13480.108.camel@dhcppc3> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> Message-ID: <1064977399.32323.54.camel@binkley> On Tue, 2003-09-30 at 22:52, Havoc Pennington wrote: > On Tue, 2003-09-30 at 22:36, seth vidal wrote: > > or maybe consider building up comps.xml/yumgroups.xml files that could > > create groups of packages for people to search for. > > That's what I'd like to see. Maybe even a requirement that all "end user > visible" packages be in a comps file. > > redhat-config-packages can then display nice sane things instead of raw > RPM package names. I'm all for it - I wrote a simple script for generating a section for a comps.xml file - they are intended for use with yum but since yumgroups.xml and comps.xml are the same file format (well, for the groups part, the packages part isn't really considered in yum - but it quietly ignores them so it's the same format :) then it would work just as well for those. http://linux.duke.edu/projects/yum/download/misc/yumgengroups.py If anyone is interested in it. -sv From notting at redhat.com Wed Oct 1 03:05:21 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Sep 2003 23:05:21 -0400 Subject: xmms release number In-Reply-To: <1064976749.13480.108.camel@dhcppc3>; from hp@redhat.com on Tue, Sep 30, 2003 at 10:52:30PM -0400 References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> Message-ID: <20030930230521.B3097@devserv.devel.redhat.com> Havoc Pennington (hp at redhat.com) said: > On Tue, 2003-09-30 at 22:36, seth vidal wrote: > > or maybe consider building up comps.xml/yumgroups.xml files that could > > create groups of packages for people to search for. > > That's what I'd like to see. Maybe even a requirement that all "end user > visible" packages be in a comps file. > > redhat-config-packages can then display nice sane things instead of raw > RPM package names. redhat-config-packages already displays the description, which is already translated, etc.... Bill From skvidal at phy.duke.edu Wed Oct 1 03:12:36 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Sep 2003 23:12:36 -0400 Subject: xmms release number In-Reply-To: <20030930230521.B3097@devserv.devel.redhat.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <20030930230521.B3097@devserv.devel.redhat.com> Message-ID: <1064977955.32323.66.camel@binkley> On Tue, 2003-09-30 at 23:05, Bill Nottingham wrote: > Havoc Pennington (hp at redhat.com) said: > > On Tue, 2003-09-30 at 22:36, seth vidal wrote: > > > or maybe consider building up comps.xml/yumgroups.xml files that could > > > create groups of packages for people to search for. > > > > That's what I'd like to see. Maybe even a requirement that all "end user > > visible" packages be in a comps file. > > > > redhat-config-packages can then display nice sane things instead of raw > > RPM package names. > > redhat-config-packages already displays the description, which > is already translated, etc.... Well I think he meant it display groups of packages to be displayed as "multimedia applications" or "sound and video" instead of 'xmms' or 'totem' or 'xine'. -sv From notting at redhat.com Wed Oct 1 03:17:17 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Sep 2003 23:17:17 -0400 Subject: xmms release number In-Reply-To: <1064977955.32323.66.camel@binkley>; from skvidal@phy.duke.edu on Tue, Sep 30, 2003 at 11:12:36PM -0400 References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <20030930230521.B3097@devserv.devel.redhat.com> <1064977955.32323.66.camel@binkley> Message-ID: <20030930231717.A22105@devserv.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > Well I think he meant it display groups of packages to be displayed as > > "multimedia applications" > > or > > "sound and video" > > instead of 'xmms' or 'totem' or 'xine'. Huh? You still need to *select* packagees, and they're already in a Sound and Video group. Bill From dan_young at parkrose.k12.or.us Wed Oct 1 03:27:25 2003 From: dan_young at parkrose.k12.or.us (Dan Young) Date: Tue, 30 Sep 2003 20:27:25 -0700 (PDT) Subject: xmms release number In-Reply-To: <1064976749.13480.108.camel@dhcppc3> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> Message-ID: <65274.12.224.134.103.1064978845.squirrel@webmail.parkrose.k12.or.us> Havoc Pennington said: > On Tue, 2003-09-30 at 22:36, seth vidal wrote: >> or maybe consider building up comps.xml/yumgroups.xml files that >> could create groups of packages for people to search for. > > That's what I'd like to see. Maybe even a requirement that all "end > user visible" packages be in a comps file. What relation (if any) does /usr/share/doc/rpm-/GROUPS have here? Is this maintained seperately, being part of the rpm package instead of comps? -Dan Young -Parkrose School District From skvidal at phy.duke.edu Wed Oct 1 03:27:27 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Sep 2003 23:27:27 -0400 Subject: xmms release number In-Reply-To: <20030930231717.A22105@devserv.devel.redhat.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <20030930230521.B3097@devserv.devel.redhat.com> <1064977955.32323.66.camel@binkley> <20030930231717.A22105@devserv.devel.redhat.com> Message-ID: <1064978847.32323.74.camel@binkley> > > Huh? You still need to *select* packagees, and they're already > in a Sound and Video group. > But for stuff outside of the core distro - it would be useful to have them in comps.xml files on the other repositories so you could have those type of groups for the non-core packages too. So if core has: xmms noatun in a multimedia group then extras might have: xine (no illegal bindings) xmms-alsa totem As it is r-c-p would need a comps.xml on the other repository for the package to be in a listed group. when I wrote the comps.xml handling for yum I wrote a class that will take one or more comps.xml files and merge the groups b/t them. So if repo1 had a comps with a group named 'sound and video' that included xmms and noatun and repo2 had a group named 'sound and video' that included xmms-alsa, totem and xine, then when you view the contents of the group from w/i yum you ended up with a group named 'sound and video' that included: xine, xmms, xmms-alsa, totel and noatun. I think what havoc was meaning that programs that are going to be exposed to the user in the extras/alternatives/etc repositories should be listed in a comps.xml file and ideally then r-c-p could handle that part and list them nicely in those groups for the user. -sv From skvidal at phy.duke.edu Wed Oct 1 03:29:28 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Sep 2003 23:29:28 -0400 Subject: xmms release number In-Reply-To: <65274.12.224.134.103.1064978845.squirrel@webmail.parkrose.k12.or.us> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <65274.12.224.134.103.1064978845.squirrel@webmail.parkrose.k12.or.us> Message-ID: <1064978968.32323.77.camel@binkley> On Tue, 2003-09-30 at 23:27, Dan Young wrote: > Havoc Pennington said: > > On Tue, 2003-09-30 at 22:36, seth vidal wrote: > >> or maybe consider building up comps.xml/yumgroups.xml files that > >> could create groups of packages for people to search for. > > > > That's what I'd like to see. Maybe even a requirement that all "end > > user visible" packages be in a comps file. > > What relation (if any) does /usr/share/doc/rpm-/GROUPS have > here? Is this maintained seperately, being part of the rpm package > instead of comps? I believe the only thing that really uses those groups anymore is rpmlint. They have almost no meaning and there isn't enough depth or breadth to let them be a good classifier, imo. -sv From notting at redhat.com Wed Oct 1 03:36:52 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Sep 2003 23:36:52 -0400 Subject: xmms release number In-Reply-To: <1064978847.32323.74.camel@binkley> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <20030930230521.B3097@devserv.devel.redhat.com> <1064977955.32323.66.camel@binkley> <20030930231717.A22105@devserv.devel.redhat.com> <1064978847.32323.74.camel@binkley> Message-ID: <20031001033652.GA12974@apone.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > I think what havoc was meaning that programs that are going to be > exposed to the user in the extras/alternatives/etc repositories should > be listed in a comps.xml file and ideally then r-c-p could handle that > part and list them nicely in those groups for the user. Sure, but this is not necessarily meta-information in the package itself. Unless you just want to create rpm groups all over again. Bill From skvidal at phy.duke.edu Wed Oct 1 03:43:46 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Sep 2003 23:43:46 -0400 Subject: xmms release number In-Reply-To: <20031001033652.GA12974@apone.devel.redhat.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <20030930230521.B3097@devserv.devel.redhat.com> <1064977955.32323.66.camel@binkley> <20030930231717.A22105@devserv.devel.redhat.com> <1064978847.32323.74.camel@binkley> <20031001033652.GA12974@apone.devel.redhat.com> Message-ID: <1064979826.32323.79.camel@binkley> On Tue, 2003-09-30 at 23:36, Bill Nottingham wrote: > seth vidal (skvidal at phy.duke.edu) said: > > I think what havoc was meaning that programs that are going to be > > exposed to the user in the extras/alternatives/etc repositories should > > be listed in a comps.xml file and ideally then r-c-p could handle that > > part and list them nicely in those groups for the user. > > Sure, but this is not necessarily meta-information in the package > itself. Unless you just want to create rpm groups all over again. I wasn't talking about meta-information in the package, I don't think havoc was either. And afaict the rpm groups weren't too widely used. -sv From axel at banzais.org Wed Oct 1 06:58:37 2003 From: axel at banzais.org (axel c) Date: Wed, 01 Oct 2003 08:58:37 +0200 Subject: PowerPC support In-Reply-To: <20030930194314.GA32555@iadonisi.to> References: <20030930102043.057EA3149B@neuromancer.voxel.net> <20030930194314.GA32555@iadonisi.to> Message-ID: <1064991517.6294.1.camel@mao.ikp.org> On Tue, 2003-09-30 at 21:43, Paul Iadonisi wrote: > Given that Fedora is intended for > the hobbyist, developer, enthusiast, I'm hoping that the answer is yes. > Just trying to keep my custom src rpms to a minimum. I'm a bit confused by that bit. If Fedora is focused on the 'developer, hobbyist, enthusiast', does that mean there won't be a RedHat for the Basic, Unskilled, Clueless Joe Desktop User? Cheers, -- axel c From pmatilai at welho.com Wed Oct 1 07:10:20 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 1 Oct 2003 10:10:20 +0300 Subject: xmms release number In-Reply-To: <1064978968.32323.77.camel@binkley> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <65274.12.224.134.103.1064978845.squirrel@webmail.parkrose.k12.or.us> <1064978968.32323.77.camel@binkley> Message-ID: <1064992220.3f7a7ddc7a2db@webmail.welho.com> Quoting seth vidal : > On Tue, 2003-09-30 at 23:27, Dan Young wrote: > > Havoc Pennington said: > > > On Tue, 2003-09-30 at 22:36, seth vidal wrote: > > >> or maybe consider building up comps.xml/yumgroups.xml files that > > >> could create groups of packages for people to search for. > > > > > > That's what I'd like to see. Maybe even a requirement that all "end > > > user visible" packages be in a comps file. > > > > What relation (if any) does /usr/share/doc/rpm-/GROUPS have > > here? Is this maintained seperately, being part of the rpm package > > instead of comps? > > I believe the only thing that really uses those groups anymore is > rpmlint. Synaptic uses (rpm) groups to organize the package tree view - typos in rpm groups show up really nicely there :) Things like Application/Multimedia + somedvdplayer Applications/Multimedia + multimediaplayer1 + multimediaplayer2 + ..etc > > They have almost no meaning and there isn't enough depth or breadth to > let them be a good classifier, imo. Yup, many packages don't have a real match in the "official" rpm group list at all and others could be put into one of several groups, typically things like python modules: is this System Environment/Libraries, Development/Libraries or Development/Languages .. when it fits to all of those. -- - Panu - From Axel.Thimm at physik.fu-berlin.de Wed Oct 1 09:27:29 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 1 Oct 2003 12:27:29 +0300 Subject: Kind request: Set release version to "10" In-Reply-To: <20030930150935.F14445@devserv.devel.redhat.com> References: <20030930160010.22963.39717.Mailman@listman.back-rdu.redhat.com> <200309301139.40201.rdieter@math.unl.edu> <20030930150935.F14445@devserv.devel.redhat.com> Message-ID: <20031001092729.GI1876@pua.nirvana> On Tue, Sep 30, 2003 at 03:09:35PM -0400, Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: > > If you read the original post, Axel's concern to upgradability from the > > previous fedora release naming standard. A concern of mine is that I > > maintain packages for all redhat releases going back to rh73, and I do it > > all from a single src.rpm, and dynamically generate a Release tag based > > upon the contents of /etc/redhat-release. Like Axel, I also would like to > > maintain upgradability from previous releases. I argue that having to > > increment Epoch solely for the purpose overcoming the Release drop (9 -> > > 0.9 ) to maintain upgrade paths is yucky. > > Well, it would have to change anyway, from rh73 to fXXX, so, you'll > still need a change of some sort. > > Seriously, changing the release version notes the change in > the release itself; its goals, its features, its methodology. So the current goals and methology are to intentionally break heritage and upgradability from rh <= 9? What happened to the goal of the new project to better support external developers and packagers? Currently I only see more problems as an external packager. It is a pity to see marketing issues and company politics creating these problems. Couldn't you find a technical clean way to promote FC's goals? Call the core "Fedora Core sponsored by Red Hat version 10" and let the tag "rh10" do its packaging wonders. Or come up with a viable solution for repos supporting multiple RH releases with the follwoing constraints: o Allow upgradability like ... <= rh7.3 <= rh8.0 <= rh9 <= "fc1" <= ... o No epoch inflation o No separate specfile maintenance. You'll probably need the latter design for Fedora Legacy anyway, so don't let the problem manifest in the next release. You can still fix it, if you want to. -- 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 Wed Oct 1 09:10:17 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 1 Oct 2003 12:10:17 +0300 Subject: Kind request: Set release version to "10" In-Reply-To: <200309300956.40729.rdieter@math.unl.edu> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> Message-ID: <20031001091017.GG1876@pua.nirvana> On Tue, Sep 30, 2003 at 09:56:40AM -0500, Rex Dieter wrote: > Florian La Roche wrote: > > Axel Thimm wrote: > > > I'd like to kindly request to set to release version to "10" or > > > something higher than "9.0.94". > > > > The decision about the version number is already done. > > If by that, you mean that the decision is to stick with 0.94 without much > discussion (that I've seen or heard) and despite it's obvious > shortcomings... that's a shame. Yes, I also miss the "open discussion of development in these lists" ... > Heading down this path will also lead to > lots of, IMO, uncessessary Epoch inflation. One example: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=105746 > I'm sure if nothing is done, many more will follow. > > I don't know about you Axel, but until I see a better alternative, I'll > personally be inflating Fedora X.Y to rh(X+10)Y in the release tag of > packages I maintain. The only other alternative is to simply increment > Epoch for everything, which is yucky, yucky. Exaclty. As packagers we have been painfully tought not to use epochs unless WW3 is about to emerge. I'll also go with your suggestion, Rex. I'd call it the "it's written rh10, but it is pronounced Fedora Core 1" idiom ... Currently anything else is a nightmare for repos with support for multiple RH releases. This does not only include existing repos, but also forthcomming repos with support for multiple releases. Did anyone making this decision consider how "Fedora Legacy" is to be sanely constructed? By bumping all epochs of "Fedora Core" to ensure upgradability, and maintaining unnecessary multiple specfiles? This decision wasn't/isn't well thought IMHO. The alternative is to drop support for upgrading from RH <= 9 to FC, which is even uglier. Please review the release decision. -- 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 Wed Oct 1 09:12:47 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 1 Oct 2003 12:12:47 +0300 Subject: Kind request: Set release version to "10" (was: Retain upgrade paths) In-Reply-To: References: <20030930075824.GD1714@pua.nirvana> Message-ID: <20031001091247.GH1876@pua.nirvana> On Tue, Sep 30, 2003 at 07:31:59AM -0400, Elliot Lee wrote: > On Tue, 30 Sep 2003, Axel Thimm wrote: > > It would neither hurt marketing goals, nor any technical issues, but > > it helps a lot with 3rd party repos supporting more than just the > > latest release. Embedding (rpm-)increasing tags into the package > > release ensures sane upgrade paths (similar to some Red Hat errata > > releases like the kernel rpms). > > With the Epoch: (which went from 0 to 1 on the redhat-release package), > everything works out fine and is rpm-increasing. You have to do it for each package in a multiple concurrent release supporting repo that exists for multiple releases of RH. Read up this thread for details and examples. -- 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 akabi at speakeasy.net Wed Oct 1 11:48:00 2003 From: akabi at speakeasy.net (ne...) Date: Wed, 1 Oct 2003 07:48:00 -0400 (EDT) Subject: PowerPC support In-Reply-To: <1064991517.6294.1.camel@mao.ikp.org> References: <20030930102043.057EA3149B@neuromancer.voxel.net> <20030930194314.GA32555@iadonisi.to> <1064991517.6294.1.camel@mao.ikp.org> Message-ID: On Oct 1, 2003 at 08:58, axel c in a maddening rage wrote: >On Tue, 2003-09-30 at 21:43, Paul Iadonisi wrote: >> Given that Fedora is intended for >> the hobbyist, developer, enthusiast, I'm hoping that the answer is yes. >> Just trying to keep my custom src rpms to a minimum. > >I'm a bit confused by that bit. If Fedora is focused on the 'developer, >hobbyist, enthusiast', does that mean there won't be a RedHat for the >Basic, Unskilled, Clueless Joe Desktop User? Don't be confused. See http://fedora.redhat.com/about/rhel.html for what will be targeted towards what in terms of users. Also take into consideration that Redhat is getting out of the consumer retail market. I would say it is about time that poor Basic, Unskilled, Clueless Joe Desktop User needs to start acquiring some skills as cynical as that might sound. -- Registered Linux User # 125653 (http://counter.li.org) Switch to: http://www.speakeasy.net/refer/190653 Postmen never die, they just lose their zip. 07:44:42 up 37 days, 19:19, 3 users, load average: 0.00, 0.00, 0.00 From ms-nospam-0306 at arcor.de Wed Oct 1 11:56:24 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 1 Oct 2003 13:56:24 +0200 Subject: Kind request: Set release version to "10" (was: Retain upgrade paths) In-Reply-To: <20031001091247.GH1876@pua.nirvana> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> Message-ID: <20031001135624.338c54e7.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 1 Oct 2003 12:12:47 +0300, Axel Thimm wrote: > > With the Epoch: (which went from 0 to 1 on the redhat-release package), > > everything works out fine and is rpm-increasing. > > You have to do it for each package in a multiple concurrent release > supporting repo that exists for multiple releases of RH. Read up this > thread for details and examples. How many packages would that be? Consider the package naming scheme of fedora.us which uses the following target release tags: rh80 < rh90 < rh90.93 < 0.94 No problems during upgrades. The other example (kernel) doesn't hold true for Fedora Core, because 0.94 contains a kernel version which is higher than Red Hat Linux 9, 8.0 and older releases: 2.4.20-20.9 < 2.4.22-1.2061.nptl 2.4.20-20.8 < 2.4.22-1.2061.nptl 2.4.20-20.7 < 2.4.22-1.2061.nptl Even if there were a kernel upgrade for RHL<=9, I'm sure it would see a lower package release version than what is in Fedora Core, e.g. 2.4.22-2 in Fedora Core and 2.4.22-1.9 in Shrike Updates. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/esDo0iMVcrivHFQRAma9AJ94XrV9hWWlf9BbuhKRyhTiuHJ2OwCgiCxP NkbVR5pA5sg/X6Pf9yexk9w= =sniF -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Wed Oct 1 12:02:57 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Oct 2003 08:02:57 -0400 Subject: xmms release number In-Reply-To: <1064992220.3f7a7ddc7a2db@webmail.welho.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <65274.12.224.134.103.1064978845.squirrel@webmail.parkrose.k12.or.us> <1064978968.32323.77.camel@binkley> <1064992220.3f7a7ddc7a2db@webmail.welho.com> Message-ID: <1065009776.32323.116.camel@binkley> > Synaptic uses (rpm) groups to organize the package tree view - typos in rpm > groups show up really nicely there :) Things like > > Application/Multimedia > + somedvdplayer > Applications/Multimedia > + multimediaplayer1 > + multimediaplayer2 > + ..etc > yah - the groups are fairly static wrt what rpmlint believes are 'correct' groups. > Yup, many packages don't have a real match in the "official" rpm group list at > all and others could be put into one of several groups, typically things like > python modules: is this System Environment/Libraries, Development/Libraries or > Development/Languages .. when it fits to all of those. That's one of the reasons why I thought keywords would be handy (in my original post) -sv From pmatilai at welho.com Wed Oct 1 13:06:14 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 1 Oct 2003 16:06:14 +0300 Subject: xmms release number In-Reply-To: <1065009776.32323.116.camel@binkley> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <65274.12.224.134.103.1064978845.squirrel@webmail.parkrose.k12.or.us> <1064978968.32323.77.camel@binkley> <1064992220.3f7a7ddc7a2db@webmail.welho.com> <1065009776.32323.116.camel@binkley> Message-ID: <1065013574.3f7ad1461b87e@webmail.welho.com> Quoting seth vidal : > > > Synaptic uses (rpm) groups to organize the package tree view - typos in > rpm > > groups show up really nicely there :) Things like > > > > Application/Multimedia > > + somedvdplayer > > Applications/Multimedia > > + multimediaplayer1 > > + multimediaplayer2 > > + ..etc > > > > yah - the groups are fairly static wrt what rpmlint believes are > 'correct' groups. ..except what rpmlint thinks are "correct" groups is miles longer a list than what's in GROUPS as distributed with rpm. > > > Yup, many packages don't have a real match in the "official" rpm group list > at > > all and others could be put into one of several groups, typically things > like > > python modules: is this System Environment/Libraries, Development/Libraries > or > > Development/Languages .. when it fits to all of those. > > That's one of the reasons why I thought keywords would be handy (in my > original post) Yup and I wholeheartedly agree keywords would be really nice. -- - Panu - From heinlein at madboa.com Wed Oct 1 13:54:28 2003 From: heinlein at madboa.com (Paul Heinlein) Date: Wed, 1 Oct 2003 06:54:28 -0700 (PDT) Subject: xmms release number In-Reply-To: <65274.12.224.134.103.1064978845.squirrel@webmail.parkrose.k12.or.us> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <65274.12.224.134.103.1064978845.squirrel@webmail.parkrose.k12.or.us> Message-ID: On Tue, 30 Sep 2003, Dan Young wrote: > What relation (if any) does /usr/share/doc/rpm-/GROUPS have > here? Is this maintained seperately, being part of the rpm package > instead of comps? The GROUPS file provides a (not terribly well-defined) set of broad categories for packages. A GROUP tends to define what a package does (it's a library, daemon, application, documentation), though in some cases it defines a relationship (it's part of the Base system). The comps.xml file provides package groupings for installation tools. The comps file combines packages of differing GROUPS into a useful installation category. For example, the Red Hat 9 "Printing Support" comps group includes packages from all sorts of GROUPS: 4Suite: Development/Libraries a2ps: Applications/Publishing cups: System Environment/Daemons enscript: Applications/Publishing ghostscript: Applications/Publishing hpijs: Applications/Publishing ttfprint: System Environment/Base redhat-config-printer: System Environment/Daemons ... The newer comps.xml mechanism also has a way to specify installation-time dependencies. --Paul Heinlein From bill at noreboots.com Wed Oct 1 13:54:04 2003 From: bill at noreboots.com (Bill Anderson) Date: 01 Oct 2003 07:54:04 -0600 Subject: Since Fedora is not aimed at enterpise/business .. Message-ID: <1065016443.6301.37.camel@locutus> Does this mean we can now stop requiring kerberos in everything that can have it required? I submit that the vast majority of Fedora target "market"will not ever need krb in Fedora. Can we please make this change? In the past the answer has always been "well enterprises and medium sized businesses may need it". Well, they can buy RHEL now. Please let Fedora Core return to the non massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in days. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From hadess at hadess.net Wed Oct 1 13:56:53 2003 From: hadess at hadess.net (Bastien Nocera) Date: Wed, 01 Oct 2003 14:56:53 +0100 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065016443.6301.37.camel@locutus> References: <1065016443.6301.37.camel@locutus> Message-ID: <1065016612.11530.101.camel@dhcp-116.surrey.redhat.com> On Wed, 2003-10-01 at 14:54, Bill Anderson wrote: > Does this mean we can now stop requiring kerberos in everything that can > have it required? I submit that the vast majority of Fedora target > "market"will not ever need krb in Fedora. Can we please make this > change? In the past the answer has always been "well enterprises and > medium sized businesses may need it". Well, they can buy RHEL now. > > Please let Fedora Core return to the non > massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in days. Then you won't have any Red Hat developers using it :) --- Bastien Nocera Her hair glistened in the rain like nose hair after a sneeze. From skvidal at phy.duke.edu Wed Oct 1 13:59:48 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Oct 2003 09:59:48 -0400 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065016443.6301.37.camel@locutus> References: <1065016443.6301.37.camel@locutus> Message-ID: <1065016788.32323.126.camel@binkley> On Wed, 2003-10-01 at 09:54, Bill Anderson wrote: > Does this mean we can now stop requiring kerberos in everything that can > have it required? I submit that the vast majority of Fedora target > "market"will not ever need krb in Fedora. Can we please make this > change? In the past the answer has always been "well enterprises and > medium sized businesses may need it". Well, they can buy RHEL now. > > Please let Fedora Core return to the non > massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in days. I'd like to offer that universities, in many cases, will not be able to afford RHEL and we do use and need kerberos. Not only that but if the packages from fedora find their way into rhel then the kerberos stuff will need to be there. It's shortsighted to not compile in kerberos and ldap support wherever possible. -sv From laroche at redhat.com Wed Oct 1 14:10:39 2003 From: laroche at redhat.com (Florian La Roche) Date: Wed, 1 Oct 2003 16:10:39 +0200 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065016443.6301.37.camel@locutus> References: <1065016443.6301.37.camel@locutus> Message-ID: <20031001141039.GA5485@dudweiler.stuttgart.redhat.com> > Please let Fedora Core return to the non > massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in days. You can use rpm flags at recompile time to throw many things out: - openldap - sasl - gdbm - tcp_wrappers - kerberos - pam I don't think it makes sense to pull these things out of Fedora, but it is true that from a source code level these things should be modular and thus optional. Small computers have 1000MHZ x86 CPUs and why not attach a 160GB IDE drive to them? greetings, Florian La Roche From veillard at redhat.com Wed Oct 1 14:20:29 2003 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 1 Oct 2003 10:20:29 -0400 Subject: For those with RHN applet rendering problems Message-ID: <20031001102029.J21529@redhat.com> Those who got hit by the "1 pixel wide" applet problem can test the 1.0.12 release which should incorporate a fix, if you still see the problem after upgrading and restarting the applet, please state so in bug #75225 : updated packages: http://people.redhat.com/~veillard/rhn-applet/ related bug: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75225 TIA, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From felipe_alfaro at linuxmail.org Wed Oct 1 14:23:17 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 01 Oct 2003 16:23:17 +0200 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065016443.6301.37.camel@locutus> References: <1065016443.6301.37.camel@locutus> Message-ID: <1065018196.2447.10.camel@teapot.felipe-alfaro.com> On Wed, 2003-10-01 at 15:54, Bill Anderson wrote: > Does this mean we can now stop requiring kerberos in everything that can > have it required? I would like to see more Kerberos support for Linux in general. I think Kerberos is a blessing. Just imagine logging onto the network and being able to ssh into any box, read your mail stored in a Cyrus-IMAPD server without supplying a password, modifying your contacts stored into a central LDAP server without supplying any credentials or DN, and so on. Kerberos is deployed all over my boxes and I find it a pleasure to use, although it can be a little tricky to set up. I would like to see far better and wider support for it. Don't know how people can still live with public keys and passwords when managing multiple servers. From sopwith at redhat.com Wed Oct 1 14:23:32 2003 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 1 Oct 2003 10:23:32 -0400 (EDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065016443.6301.37.camel@locutus> Message-ID: On 1 Oct 2003, Bill Anderson wrote: > Does this mean we can now stop requiring kerberos in everything that can > have it required? I submit that the vast majority of Fedora target > "market"will not ever need krb in Fedora. Can we please make this > change? In the past the answer has always been "well enterprises and > medium sized businesses may need it". Well, they can buy RHEL now. > > Please let Fedora Core return to the non > massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in > days. It's important for Fedora to be a technically featureful OS, and it's not clear why it's important to avoid Kerberos dependencies. Being able to do secure network-wide single sign-on is a cool feature! -- Elliot Individualists, unite! From axel at banzais.org Wed Oct 1 14:46:36 2003 From: axel at banzais.org (axel c) Date: Wed, 01 Oct 2003 16:46:36 +0200 Subject: PowerPC support In-Reply-To: References: <20030930102043.057EA3149B@neuromancer.voxel.net> <20030930194314.GA32555@iadonisi.to> <1064991517.6294.1.camel@mao.ikp.org> Message-ID: <1065019596.29355.4.camel@mao.ikp.org> On Wed, 2003-10-01 at 13:48, ne... wrote: > >I'm a bit confused by that bit. If Fedora is focused on the 'developer, > >hobbyist, enthusiast', does that mean there won't be a RedHat for the > >Basic, Unskilled, Clueless Joe Desktop User? > Don't be confused. See http://fedora.redhat.com/about/rhel.html > for what will be targeted towards what in terms of users. Also > take into consideration that Redhat is getting out of the consumer > retail market. I would say it is about time that poor Basic, > Unskilled, Clueless Joe Desktop User needs to start acquiring > some skills as cynical as that might sound. Hmmm. If that means my (mostly clueless) gf won't get an out of the box, 'just works' desktop system then i better start looking for another distro for her... Will fedora be broken into 'stable' and 'unstable' branches like debian? Or will it be something more like 'it's Rawhide but a bit less broken' ? Thanks -- axel c From Axel.Thimm at physik.fu-berlin.de Wed Oct 1 15:00:51 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 1 Oct 2003 18:00:51 +0300 Subject: Kind request: Set release version to "10" In-Reply-To: <20031001135624.338c54e7.ms-nospam-0306@arcor.de> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> Message-ID: <20031001150051.GB1777@pua.nirvana> On Wed, Oct 01, 2003 at 01:56:24PM +0200, Michael Schwendt wrote: > On Wed, 1 Oct 2003 12:12:47 +0300, Axel Thimm wrote: > > > With the Epoch: (which went from 0 to 1 on the redhat-release package), > > > everything works out fine and is rpm-increasing. > > You have to do it for each package in a multiple concurrent > > release supporting repo that exists for multiple releases of > > RH. Read up this thread for details and examples. > > How many packages would that be? How many? All the ones from my repo for instance. Same for other repos. Some of the repos have intertwining dependencies that would also need to be updated. No, I won't enter that epoch hell, and probably neither will any other repo maintainer. > Consider the package naming scheme of fedora.us which uses the > following target release tags: > > rh80 < rh90 < rh90.93 < 0.94 That's a kludge (BTW it should have been rh8.0 < rh9 < rh9.0.93). What about repos not using the rh tag and what about repos not willing to give up identification of the rpm as belonging to the rh family? What about Fedora Legacy, should part of it be distro-tagged and some not (like your example above)? > No problems during upgrades. The other example (kernel) doesn't hold > true for Fedora Core, because 0.94 contains a kernel version which is > higher than Red Hat Linux 9, 8.0 and older releases: > > 2.4.20-20.9 < 2.4.22-1.2061.nptl > 2.4.20-20.8 < 2.4.22-1.2061.nptl > 2.4.20-20.7 < 2.4.22-1.2061.nptl Of course it works when the package version is newer, I am talking of keeping the same package built for different releases (e.g. built form the same specfile). Version bumping is the reason, why RH didn't encounter that problem that often (other than the few common errata). > Even if there were a kernel upgrade for RHL<=9, I'm sure it would see > a lower package release version than what is in Fedora Core, e.g. > 2.4.22-2 in Fedora Core and 2.4.22-1.9 in Shrike Updates. Rawhide kernel specfile even has special precautions for RH7 (sevenexcompat macro), so the current intention obviously is to continue the common errata method, if the severn kernel turns out to be stable enough. I pitty the kernel rpm maintainer for having to come up with yet-another-custom-made-versioning-scheme. Even if this should not be the case with the kernel rpm, it was only a RH-internal example to visualize to RH devels what exists in numbers of several hunderds in other repos. Any kludgy version numbering trick for the next common kernel rpm release may work for that one package, but we need a solution covering the general case. -- 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 ted at cypress.com Wed Oct 1 15:27:53 2003 From: ted at cypress.com (Thomas Dodd) Date: Wed, 01 Oct 2003 10:27:53 -0500 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064418129.7990.86.camel@pc01.wks.enertronllc.com> References: <1064358482.26087.100.camel@icon.devel.redhat.com> <1064418129.7990.86.camel@pc01.wks.enertronllc.com> Message-ID: <3F7AF279.3060809@cypress.com> Sean Millichamp wrote: > on some machines. However, for at least half of the machines I manage > even RHEL Basic Edition will be too expensive on a per-year basis so I > know that I will have no choice but to be supporting at least Fedora. Red Hat could offer you a redistribution contract. You pay a fairly high fee for the right to redistribute the updates to you customers. It should be managed so that the per customer/system price you must charge is reasonable to the customer, say $50/year/system. You then setup you own RHN satellite server, that only your customers can access. I know Red Hat offers a satellite service of some sort, but I don't know the details. I this model _YOU_ are Red Hat's customer, not your customers. Every system you install/maintain is in the support contract you pay for (So 100 systems/month is ~1200 systems this year). You pay the fee for 1000+ systems, which includes discounts I'm sure, and resell to your customers. Any customers that have a large enought installation (say 100 or 250 systems) would be requred to purchase direct from Red Hat, posibly contracting you for performing the maintaince. -Thomas From akabi at speakeasy.net Wed Oct 1 15:33:28 2003 From: akabi at speakeasy.net (ne...) Date: Wed, 1 Oct 2003 11:33:28 -0400 (EDT) Subject: PowerPC support In-Reply-To: <1065019596.29355.4.camel@mao.ikp.org> References: <20030930102043.057EA3149B@neuromancer.voxel.net> <20030930194314.GA32555@iadonisi.to> <1064991517.6294.1.camel@mao.ikp.org> <1065019596.29355.4.camel@mao.ikp.org> Message-ID: On Oct 1, 2003 at 16:46, axel c in a maddening rage wrote: >On Wed, 2003-10-01 at 13:48, ne... wrote: > >> >I'm a bit confused by that bit. If Fedora is focused on the 'developer, >> >hobbyist, enthusiast', does that mean there won't be a RedHat for the >> >Basic, Unskilled, Clueless Joe Desktop User? >> Don't be confused. See http://fedora.redhat.com/about/rhel.html >> for what will be targeted towards what in terms of users. Also >> take into consideration that Redhat is getting out of the consumer >> retail market. I would say it is about time that poor Basic, >> Unskilled, Clueless Joe Desktop User needs to start acquiring >> some skills as cynical as that might sound. > >Hmmm. If that means my (mostly clueless) gf won't get an out of the box, >'just works' desktop system then i better start looking for another >distro for her... Will fedora be broken into 'stable' and 'unstable' >branches like debian? Or will it be something more like 'it's Rawhide >but a bit less broken' ? Thanks My take so far. Corrections from the authorities may be needed. Fedora Core is in Beta test mode right now. The stable version when it gets released will Fedora [Core] 1. This will be on par with previous Redhat releases 9, 8.0, 7.3, 7.2 etc. It won't be boxed by Redhat. You will be able to d'l it and burn etc. This will contain stuff that Redhat would legally, according to Redhat's legal team, be able to release in the US and elsewhere. If you need extras, Fedora Extras may provide this. If these extras contain stuff that the Redhat Legal Team deem cannot be provided by Redhat, Redhat will not link to these. Please remember that Redhat is a publicly traded company. They have legal responsibilities towards their shareholders. About ease of use for the clueless, if they have the skills to d'l and burn it, they should be able to install it with the usual caveats of course. If you have esoteric hardware, cross your fingers and your toes. 'Bout your gf, well you helping her should bring the two of you closer (-:. It will strive to be a release Redhat will be proud of, not something like Rawhide. Would it be like Debian??? Some aspects will, most won't. Expect yum to take the place of apt-get with the equivalent funtionality provided. Expect stables releases every 4-6 months. Expect still smoother upgrades. Regressions should be few and far between. TAFN. -- Registered Linux User # 125653 (http://counter.li.org) Switch to: http://www.speakeasy.net/refer/190653 Courage is your greatest present need. 11:14:27 up 37 days, 22:48, 3 users, load average: 0.00, 0.00, 0.00 From dax at gurulabs.com Wed Oct 1 15:43:51 2003 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 01 Oct 2003 09:43:51 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065016443.6301.37.camel@locutus> References: <1065016443.6301.37.camel@locutus> Message-ID: <1065023030.2568.24.camel@mentor.gurulabs.com> On Wed, 2003-10-01 at 07:54, Bill Anderson wrote: > Does this mean we can now stop requiring kerberos in everything that can > have it required? I submit that the vast majority of Fedora target > "market"will not ever need krb in Fedora. Can we please make this > change? In the past the answer has always been "well enterprises and > medium sized businesses may need it". Well, they can buy RHEL now. > > Please let Fedora Core return to the non > massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in days. Bill, what are your reasons? What concrete problems are you experiencing with kerberos support being compiled into software? Sometimes I hear, "but I have SSH, I don't need Kerberos". SSH narrowly targets (and solves) a single problem. Kerberos, while having similar goals as SSH, is a all encompassing solution. Ergo, for all the reasons someone would want SSH in an intra-net environment, they should also want Kerberos to an even stronger degree. Kerberos is a very good thing for organizations of all sizes and personnel of all types: For sysadmins: * Strong user authentication * Mutual client <-> server authentication (no man-in-the-middle attacks) * Encrypted replacements for common protocols * Kernel 2.6 with NFSv4 + Kerberos == No more NFS security/trust issues For users: * Single sign on The nirvana Linux network setup includes the following: * LDAP directory * Kerberos Authentication * Autofs for home directories * Kerberized NFSv4 Dax Kelson Guru Labs From ted at cypress.com Wed Oct 1 15:44:32 2003 From: ted at cypress.com (Thomas Dodd) Date: Wed, 01 Oct 2003 10:44:32 -0500 Subject: Fedora Project: Announcing New Direction In-Reply-To: <002301c3813e$16d921b0$735eee0c@C515816A> References: <002301c3813e$16d921b0$735eee0c@C515816A> Message-ID: <3F7AF660.4080404@cypress.com> Otto Haliburton wrote: >>One of the reasons would be trademark law. If free >>distribution of things with the Red Hat name and logo >>were allowed, the trademark would be invalid very >>quickly ... ;) > I think that's what I said in the previous email. They can't license and > patent a product that is freely distributed and their profit has been is in > support of the open source product and that has created a high degree of > instability for a commercial product. No it's not. And once again you talk of licening and patents. Total unrelated to trademark law. Don't confuse copyright, trademark, and patent laws. Once again RHEL is an open source product (at least mostly). Red Hat can not prevent you from redistributing it (GPL/BSD and other open liscense parts at least). Now if you excersice you rights under those liscenses, Red Hat is free to revoke you liscense for RHN service. Read the liscens agreement for RHEL/RHN. If you violate the terms (like not having all machines registered) Red Hat's recourse it to nolonger allow access to RHN and other support. -Thomas From ted at cypress.com Wed Oct 1 15:49:57 2003 From: ted at cypress.com (Thomas Dodd) Date: Wed, 01 Oct 2003 10:49:57 -0500 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064255806.15563.52.camel@icon.devel.redhat.com> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064255806.15563.52.camel@icon.devel.redhat.com> Message-ID: <3F7AF7A5.8060007@cypress.com> Havoc Pennington wrote: > On Mon, 2003-09-22 at 13:12, Jos Vos wrote: >>Related to "freely available": it's not completely clear what the >>"Licensing: open source" and the "Downloads: source only, or ..." >>in the Red Hat Enterprise Linux column on the above referred page >>*exactly* means w.r.t. what people/companies outside Red Hat may >>or mayt not do with it. I guess I have to read the trademark-related >>pages at the Red Hat site for that? > > You have to read the RHEL agreement, I can't find the link right now but I've read it. > My understanding is that you have the rights under the open source > licenses to use, modify, and distribute (we cannot and do not want to > remove these), but to get maintenance and support *from us* you have to > subscribe per-system. Exactly. and if you don't license per-system you loose maintance and support from Red Hat. > But of course I am not a lawyer or official spokesperson, you really > have to read the agreement and you may want to talk to the Red Hat > salespeople as they answer questions about this kind of thing all day. They won't answer that question. I've emailed sales and got no response. I think they are happy to not give a definitive answer, so the worry results in noone exercising there rights under the GPL (and others) and keeps RHEL from being redistributed due to FUD. -Thomas From otaylor at redhat.com Wed Oct 1 15:57:21 2003 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 01 Oct 2003 11:57:21 -0400 Subject: PowerPC support In-Reply-To: <1065019596.29355.4.camel@mao.ikp.org> References: <20030930102043.057EA3149B@neuromancer.voxel.net> <20030930194314.GA32555@iadonisi.to> <1064991517.6294.1.camel@mao.ikp.org> <1065019596.29355.4.camel@mao.ikp.org> Message-ID: <1065023841.11637.54.camel@poincare.devel.redhat.com> On Wed, 2003-10-01 at 10:46, axel c wrote: > On Wed, 2003-10-01 at 13:48, ne... wrote: > > > >I'm a bit confused by that bit. If Fedora is focused on the 'developer, > > >hobbyist, enthusiast', does that mean there won't be a RedHat for the > > >Basic, Unskilled, Clueless Joe Desktop User? > > Don't be confused. See http://fedora.redhat.com/about/rhel.html > > for what will be targeted towards what in terms of users. Also > > take into consideration that Redhat is getting out of the consumer > > retail market. I would say it is about time that poor Basic, > > Unskilled, Clueless Joe Desktop User needs to start acquiring > > some skills as cynical as that might sound. > > Hmmm. If that means my (mostly clueless) gf won't get an out of the box, > 'just works' desktop system then i better start looking for another > distro for her... Will fedora be broken into 'stable' and 'unstable' > branches like debian? Or will it be something more like 'it's Rawhide > but a bit less broken' ? Thanks The user interface goals of the desktop and installer for Fedora Core will continue to be very similar to those of Red Hat Linux. Simplicity and ease of use is a very big part of that. At least as far as Red Hat is concerned, trying to do one thing for RHEL and a different thing for Fedora would require effort that we'd rather not spend. So, Fedora should be roughly as easy to use as Red Hat Linux is now. Hopefully better, because we are always looking to improve in that area. I'd also expect (and hope) that Fedora releases will be reasonably non-buggy. There won't be so much emphasis on getting things "perfect", but there is a test release process, and any bugs that slip into the final release will presumably be quickly fixed by updates. What isn't going to be there is "stability" in the sense that you can just install a box with Fedora 1, train someone how to use it, and expect it to stay the exactly the same for 2 years, 3 years, etc. In summary, I think Fedora should be fine for your gf; it's not meant to be a hackers-only operating system. But it's not going to be the right choice for someone like your gf who doesn't have a local expert around to turn to if something does go wrong. Regards, Owen From smoogen at lanl.gov Wed Oct 1 15:58:50 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 01 Oct 2003 09:58:50 -0600 Subject: Fedora Project: Announcing New Direction In-Reply-To: <3F7AF7A5.8060007@cypress.com> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064255806.15563.52.camel@icon.devel.redhat.com> <3F7AF7A5.8060007@cypress.com> Message-ID: <1065023930.14565.12.camel@smoogen1.lanl.gov> On Wed, 2003-10-01 at 09:49, Thomas Dodd wrote: > > But of course I am not a lawyer or official spokesperson, you really > > have to read the agreement and you may want to talk to the Red Hat > > salespeople as they answer questions about this kind of thing all day. > > They won't answer that question. I've emailed sales and got no response. > I think they are happy to not give a definitive answer, so the worry > results in noone exercising there rights under the GPL (and others) and > keeps RHEL from being redistributed due to FUD. > You know they have very good medicines for paranoia these days. More than likely, they are waiting for legal to come up with a response that they can send you, and because they have 200 other people pestering them a day on things they dropped the ball. > -Thomas > > > -- > 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 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 notting at redhat.com Wed Oct 1 16:17:48 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Oct 2003 12:17:48 -0400 Subject: Kind request: Set release version to "10" In-Reply-To: <20031001091017.GG1876@pua.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Wed, Oct 01, 2003 at 12:10:17PM +0300 References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> Message-ID: <20031001121748.A10182@devserv.devel.redhat.com> Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > I'll also go with your suggestion, Rex. I'd call it the "it's written > rh10, but it is pronounced Fedora Core 1" idiom ... Now that's just patently misleading. It's *not* Red Hat Linux 10, it's Fedora Core 1. It's a shift in the development model, shifts in the goals of the release, and more. Hence, the new name, and new version. > By bumping all epochs of "Fedora Core" to ensure > upgradability, and maintaining unnecessary multiple specfiles? Huh? We aren't bumping all epochs of Fedora Core packages, and we don't have to to maintain upgradeability. > The alternative is to drop support for upgrading from RH <= 9 to FC, > which is even uglier. Uprgrades work... there were a couple hiccups in the test release, but by the time of the final release, I do believe there will only be epochs added to indexhtml and comps. Bill From otaylor at redhat.com Wed Oct 1 16:22:36 2003 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 01 Oct 2003 12:22:36 -0400 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065023030.2568.24.camel@mentor.gurulabs.com> References: <1065016443.6301.37.camel@locutus> <1065023030.2568.24.camel@mentor.gurulabs.com> Message-ID: <1065025356.11637.74.camel@poincare.devel.redhat.com> On Wed, 2003-10-01 at 11:43, Dax Kelson wrote: > The nirvana Linux network setup includes the following: > > * LDAP directory > * Kerberos Authentication > * Autofs for home directories > * Kerberized NFSv4 Thought question ... most of the above is present currently but takes a real expert to get going. What needs to be done to make it possible so that, given say, a network of 50 workstations, someone who has never done it before could get such a network going in a day? This almost certainly includes - Documentation - GUI setup and management tools (*) - Better configuration defaults It also might involve - Making things that require configuration currently "just work" though automatic detection. Not a question that really matters for large deployments, that *do* have experts, but quite important in other situations. Regards, Owen (*) The management part of it here is important. A GUI wizard that writes all the config files doesn't do any good if the first time you go to change something, you have to learn all the details that you avoided learning initially. It's not that it should *look* simple, it should *be* simple. From pekkas at netcore.fi Wed Oct 1 16:26:05 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 1 Oct 2003 19:26:05 +0300 (EEST) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065018196.2447.10.camel@teapot.felipe-alfaro.com> Message-ID: On Wed, 1 Oct 2003, Felipe Alfaro Solana wrote: > On Wed, 2003-10-01 at 15:54, Bill Anderson wrote: > > Does this mean we can now stop requiring kerberos in everything that can > > have it required? > > I would like to see more Kerberos support for Linux in general. I think > Kerberos is a blessing. Just imagine logging onto the network and being > able to ssh into any box, read your mail stored in a Cyrus-IMAPD server > without supplying a password, modifying your contacts stored into a > central LDAP server without supplying any credentials or DN, and so on. > > Kerberos is deployed all over my boxes and I find it a pleasure to use, > although it can be a little tricky to set up. I would like to see far > better and wider support for it. Don't know how people can still live > with public keys and passwords when managing multiple servers. I guess insecurity is usually easy to use ;-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jsmith at drgutah.com Wed Oct 1 16:35:12 2003 From: jsmith at drgutah.com (Jared Smith) Date: Wed, 01 Oct 2003 10:35:12 -0600 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065025356.11637.74.camel@poincare.devel.redhat.com> References: <1065016443.6301.37.camel@locutus> <1065023030.2568.24.camel@mentor.gurulabs.com> <1065025356.11637.74.camel@poincare.devel.redhat.com> Message-ID: <1065026112.14525.13.camel@banff.drgutah.com> On Wed, 2003-10-01 at 10:22, Owen Taylor wrote: > On Wed, 2003-10-01 at 11:43, Dax Kelson wrote: > > > The nirvana Linux network setup includes the following: > > > > * LDAP directory > > * Kerberos Authentication > > * Autofs for home directories > > * Kerberized NFSv4 > > Thought question ... most of the above is present currently > but takes a real expert to get going. > > What needs to be done to make it possible so that, given say, > a network of 50 workstations, someone who has never done > it before could get such a network going in a day? > [snip] In reading Dax's email (and personally knowing Dax to be a "real expert"), I had the same thought. I'd love to learn how to set this all up in a day. Even two or three days would be worth it. Anybody willing to contribute a "Quick and Dirty Guide to Network Nirvana in Three Days or Less"? Maybe just pointers to existing documentation? Places to start? Things to watch out for? Known gotchas? Jared Smith From icon at linux.duke.edu Wed Oct 1 16:36:34 2003 From: icon at linux.duke.edu (Konstantin Riabitsev) Date: 01 Oct 2003 12:36:34 -0400 Subject: Kind request: Set release version to "10" In-Reply-To: <20031001150051.GB1777@pua.nirvana> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> Message-ID: <1065026194.4814.11.camel@hagrid> On Wed, 2003-10-01 at 11:00, Axel Thimm wrote: > > How many packages would that be? > > How many? All the ones from my repo for instance. Same for other > repos. Some of the repos have intertwining dependencies that would > also need to be updated. Well, this is a piece of legacy that you have created for yourself. You have opted to use an unreliable way of providing "upgradeability" for the packages you ship that was never guaranteed to be a foolproof solution. It is not fair to demand that this system should be continued simply because you made a choice that might have seemed a good one in the past, but ended up creating unnecessary legacy out of which you cannot get out (or are unwilling). It was never guaranteed that the versioning of releases would remain consistent, and most packagers who have seen the jump from 8.0 to 9 have quickly realized that making the OS version part of their release is a very icky way of guaranteeing package upgradeability. You've dug this hole for yourself, and I do not think it is fair to expect us all to jump down it. Regards, -- Konstantin ("Icon") Riabitsev Duke Physics Sysadmin, RHCE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From smoogen at lanl.gov Wed Oct 1 16:40:50 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 01 Oct 2003 10:40:50 -0600 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065025356.11637.74.camel@poincare.devel.redhat.com> References: <1065016443.6301.37.camel@locutus> <1065023030.2568.24.camel@mentor.gurulabs.com> <1065025356.11637.74.camel@poincare.devel.redhat.com> Message-ID: <1065026449.14565.18.camel@smoogen1.lanl.gov> On Wed, 2003-10-01 at 10:22, Owen Taylor wrote: > On Wed, 2003-10-01 at 11:43, Dax Kelson wrote: > > > The nirvana Linux network setup includes the following: > > > > * LDAP directory > > * Kerberos Authentication > > * Autofs for home directories > > * Kerberized NFSv4 > > Thought question ... most of the above is present currently > but takes a real expert to get going. > > What needs to be done to make it possible so that, given say, > a network of 50 workstations, someone who has never done > it before could get such a network going in a day? > > This almost certainly includes > > - Documentation > - GUI setup and management tools (*) > - Better configuration defaults > > It also might involve > > - Making things that require configuration currently > "just work" though automatic detection. > > Not a question that really matters for large deployments, that > *do* have experts, but quite important in other situations. > Actually it may be a question for very large deployments where people have a large XP/2000 crowd running kerberos underneath AD and not knowing much about it. I dont know the answer myself yet. It needs to be done as it is on my list of things to learn this fiscal year.. and once I have caught up with that.. I might be able to help. -- 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 rdieter at math.unl.edu Wed Oct 1 16:49:34 2003 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 1 Oct 2003 11:49:34 -0500 Subject: Kind request: Set release version to "10" In-Reply-To: <20031001160012.31751.36262.Mailman@listman.back-rdu.redhat.com> References: <20031001160012.31751.36262.Mailman@listman.back-rdu.redhat.com> Message-ID: <200310011149.34950.rdieter@math.unl.edu> Axel wrote: > > I don't know about you Axel, but until I see a better alternative, > > I'll personally be inflating Fedora X.Y to rh(X+10)Y in the release > > tag of packages I maintain. The only other alternative is to simply > > increment Epoch for everything, which is yucky, yucky. > > Exaclty. As packagers we have been painfully tought not to use epochs > unless WW3 is about to emerge. > > I'll also go with your suggestion, Rex. I'd call it the "it's written > rh10, but it is pronounced Fedora Core 1" idiom ... Hmm, on further consideration, I think I'll probably cave in on using rh10 and instead go with fedora's guidelines, but only because I desperately want the packages I maintain to continue to be provided by fedora (and my packages will most likely be rejected if I don't "follow the rules"). In doing so, I'll still have to change my once relatively clean rpm macros from: %define rhversion %(perl -pe '/(\\d+)\\.?(\\d)?/; $_="$1".($2||0)' \ /etc/redhat-release) %define fedora_release .fdr.1.rh%{rhversion} ... Release: 0%{fedora_release} to something conditional like: %if "%(grep "Red Hat Linux" /etc/redhat-release )" != "%{nil}" # legacy Red Hat Linux releases %define rhrelease %(perl -pe '/(\\d+)\\.?(\\d+)?/; $_="$1".($2||0)' \ /etc/redhat-release ) %define release_tag .fdr.%{fedora_release}.rh%{rhrelease} %else # Fedora Core, etc... %define rhrelease %(perl -pe '/(\\d+)\\.?(\\d+)?/; \ $_="$1".(defined($2)&&".$2")' /etc/redhat-release ) %define release_tag .fdr.%{fedora_release}.%{rhrelease} %endif ... Release: 0%{release_tag} *Sigh*. -- Rex From skvidal at phy.duke.edu Wed Oct 1 16:53:27 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Oct 2003 12:53:27 -0400 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065025356.11637.74.camel@poincare.devel.redhat.com> References: <1065016443.6301.37.camel@locutus> <1065023030.2568.24.camel@mentor.gurulabs.com> <1065025356.11637.74.camel@poincare.devel.redhat.com> Message-ID: <1065027206.2146.1.camel@binkley> > Thought question ... most of the above is present currently > but takes a real expert to get going. > > What needs to be done to make it possible so that, given say, > a network of 50 workstations, someone who has never done > it before could get such a network going in a day? three items that would make a huge difference to me: 1. nfsv4 to be complete and in the kernel :) 2. kdcs not be such a nightmare to setup 3. kdcs not be such a nightmare to understand 4. ldap tweaking be documented a bit more (though I know dax kelson did a lot of documenting on openldap and it looks quite good - might want to include those somewhere in fedora-core) -sv From wcooley at nakedape.cc Wed Oct 1 17:00:07 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Wed, 01 Oct 2003 10:00:07 -0700 Subject: Kind request: Set release version to "10" In-Reply-To: <20031001121748.A10182@devserv.devel.redhat.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> Message-ID: <1065027607.2675.21.camel@denk.nakedape.priv> On Wed, 2003-10-01 at 09:17, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > > I'll also go with your suggestion, Rex. I'd call it the "it's written > > rh10, but it is pronounced Fedora Core 1" idiom ... > > Now that's just patently misleading. It's *not* Red Hat Linux 10, > it's Fedora Core 1. It's a shift in the development model, shifts > in the goals of the release, and more. Hence, the new name, and > new version. Yeah, but the actual collection of RPMs and installer aren't going to be completely new; in almost cases, they will just be upgrades. Versions ought apply to file releases, not development models, goals, names, ..., especially when there won't be a radical break in the actual conventions used with existing releases. (I.e., package files aren't going to be forced into 8.3 names or AIX-style names). Maybe if it were a true fork--a clean break started by a completely different set of people--resetting the version counter would be reasonable. But as it is, Fedora Core is still going to be under the auspices of Red Hat, Inc.--still subject to the good taste that Red Hat, Inc. has generally shown. For all intents and purposes, it's going to look like what "Red Hat Linux 10" would have looked like had Fedora not happened. 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 ms-nospam-0306 at arcor.de Wed Oct 1 17:19:08 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 1 Oct 2003 19:19:08 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031001150051.GB1777@pua.nirvana> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> Message-ID: <20031001191908.09b44222.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 1 Oct 2003 18:00:51 +0300, Axel Thimm wrote: > > How many packages would that be? > > How many? All the ones from my repo for instance. Same for other > repos. Some of the repos have intertwining dependencies that would > also need to be updated. A few observations: In your repository I don't see a consistent platform specific release tag scheme. The release tag scheme for RHL 7.3 and RHL 8.0 differs, e.g. rpm-4.2-1_15.rh7.3.at.src.rpm mplayer-0.90-0_16rh8.0at.src.rpm The mplayer package for Shrike doesn't have platform tag at all. Also note the higher package release: mplayer-0.90-18.athlon.rpm For Fedora Core, it seems to be %{version}-%{release}.rh9.0.94.at style again. Other packages don't have any such release tag at all, regardless of whether they are in RHL already or not. Your repository contains packages that override core components of RHL and don't allow for a clean upgrade path, e.g. bash-doc-2.05b-23.2.athlon.rpm Should have been something like bash-doc-2.05b-0.23.2.athlon.rpm so it is guaranteed that Red Hat's bash packages always are newer than yours. I'm not familiar with your repository. But it looks like one of your bigger problems is lack of a consistent and RH/Fedora compatible package release versioning scheme. > What about repos not using the rh tag and what about repos not willing > to give up identification of the rpm as belonging to the rh family? When either party is "not willing to give up" something, that sets off the alarm. ;) > What > about Fedora Legacy, should part of it be distro-tagged and some not > (like your example above)? I haven't seen any work on guidelines for Fedora Legacy yet. But it would sound reasonable, if 3rd party projects adapted Fedora's .fdr release tag and vepoch. > > 2.4.20-20.9 < 2.4.22-1.2061.nptl > > 2.4.20-20.8 < 2.4.22-1.2061.nptl > > 2.4.20-20.7 < 2.4.22-1.2061.nptl > > Of course it works when the package version is newer, I am talking of > keeping the same package built for different releases (e.g. built form > the same specfile). 2.4.20-20.9 = kernel for Shrike 2.4.20-20.8 = kernel for Psyche 2.4.20-20.7 = kernel for Valhalla doesn't differ much from 2.4.20-20.rh9 = kernel for Shrike 2.4.20-20.rh8 = kernel for Psyche 2.4.20-20.rh7 = kernel for Valhalla - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/ewyM0iMVcrivHFQRAsOwAJ9v/ES9VrnWofRvT8X+0BONgsLBWgCff1d4 3wFv+gL1hmufu3mXC6FYWX0= =IrlG -----END PGP SIGNATURE----- From elanthis at awesomeplay.com Wed Oct 1 17:23:09 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 01 Oct 2003 13:23:09 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065027607.2675.21.camel@denk.nakedape.priv> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> Message-ID: <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> On Wed, 2003-10-01 at 13:00, Wil Cooley wrote: > On Wed, 2003-10-01 at 09:17, Bill Nottingham wrote: > > Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > > > I'll also go with your suggestion, Rex. I'd call it the "it's written > > > rh10, but it is pronounced Fedora Core 1" idiom ... > > > > Now that's just patently misleading. It's *not* Red Hat Linux 10, > > it's Fedora Core 1. It's a shift in the development model, shifts > > in the goals of the release, and more. Hence, the new name, and > > new version. > > Yeah, but the actual collection of RPMs and installer aren't going to be > completely new; in almost cases, they will just be upgrades. Versions > ought apply to file releases, not development models, goals, names, ..., > especially when there won't be a radical break in the actual conventions > used with existing releases. (I.e., package files aren't going to be > forced into 8.3 names or AIX-style names). I'm still seriously confused what people are smoking. The only thing changing is the name of the distro, which isn't important for any package dependencies at all in any way except the distro-related packages like fedora-release, which third party packagers certainly aren't going to be providing as add-ons. *no* normal packages are changing versions from 9->1.0, and dependencies/versioning have absolutely no reason to care about the release version. it's user information only, not stuff software should care about - if the software does, then the software is broken. If your package needs to be compiled differently for different versions of Red Hat/Fedora, it's because packages in those releases are different - use *those* packages and *their* versions for your dependency tracking, *and* your release name - foo-rh8.0.i686.rpm is meaningless since those usually install and run on rh9 and fc1 anyhow. The real dependency is another package(-set), like gnome2.0 vs gnome2.4, or apache1.3 vs apache2 - depend on those, and use those in your package names if you need different packages (foo-gnome2.0.i686.rpm). Then you completely sidestep the distro versions, *which you should've done anyways*, since distro version is *completely meaningless* to anyone but a human. Or badly built packages. Packages depend on other packages, not the text in /etc/*-release. Fix your packages and move on to complain about real problems. ;-) > > Maybe if it were a true fork--a clean break started by a completely > different set of people--resetting the version counter would be > reasonable. But as it is, Fedora Core is still going to be under the > auspices of Red Hat, Inc.--still subject to the good taste that Red Hat, > Inc. has generally shown. For all intents and purposes, it's going to > look like what "Red Hat Linux 10" would have looked like had Fedora not > happened. > > Wil -- Sean Middleditch AwesomePlay Productions, Inc. From ted at cypress.com Wed Oct 1 17:23:24 2003 From: ted at cypress.com (Thomas Dodd) Date: Wed, 01 Oct 2003 12:23:24 -0500 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1065023930.14565.12.camel@smoogen1.lanl.gov> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064255806.15563.52.camel@icon.devel.redhat.com> <3F7AF7A5.8060007@cypress.com> <1065023930.14565.12.camel@smoogen1.lanl.gov> Message-ID: <3F7B0D8C.4000708@cypress.com> Stephen Smoogen wrote: > On Wed, 2003-10-01 at 09:49, Thomas Dodd wrote: > >>>But of course I am not a lawyer or official spokesperson, you really >>>have to read the agreement and you may want to talk to the Red Hat >>>salespeople as they answer questions about this kind of thing all day. >> >>They won't answer that question. I've emailed sales and got no response. >>I think they are happy to not give a definitive answer, so the worry >>results in noone exercising there rights under the GPL (and others) and >>keeps RHEL from being redistributed due to FUD. >> > > > You know they have very good medicines for paranoia these days. More Just because you're paranoid doesn't mean they're not out to get you :) > than likely, they are waiting for legal to come up with a response that > they can send you, and because they have 200 other people pestering them > a day on things they dropped the ball. I asked months ago. Several others have too. If they had ever answered one of us, I'm sure the response would have made it to the lists. If you get an answer, please let us know. -Thomas From pp at ee.oulu.fi Wed Oct 1 17:31:01 2003 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Wed, 1 Oct 2003 20:31:01 +0300 Subject: Idea for website Message-ID: <20031001173101.GB13124@ee.oulu.fi> After downloading a 32MB kernel .src.rpm for the n+1:th time just to look at a 4k patch, I came up with a pretty useful feature for the website. Basically a "rpm2html" thing (not the existing one, which does something different), which just basically lets you browse .src.rpm's in rawhide and grab invidual files from inside the archive. Or am I the only one who grabs .src.rpm's all the time to figure out what exactly have they done this time? :-) -- Pekka Pietikainen From skvidal at phy.duke.edu Wed Oct 1 17:33:05 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Oct 2003 13:33:05 -0400 Subject: Idea for website In-Reply-To: <20031001173101.GB13124@ee.oulu.fi> References: <20031001173101.GB13124@ee.oulu.fi> Message-ID: <1065029585.2146.7.camel@binkley> On Wed, 2003-10-01 at 13:31, Pekka Pietikainen wrote: > After downloading a 32MB kernel .src.rpm for the n+1:th time just > to look at a 4k patch, I came up with a pretty useful feature for > the website. Basically a "rpm2html" thing (not the existing one, which > does something different), which just basically lets you browse > .src.rpm's in rawhide and grab invidual files from inside the archive. > > Or am I the only one who grabs .src.rpm's all the time to figure out > what exactly have they done this time? :-) If ville skytta is listening to this PLEASE RELEASE YOUR mod_python apache rpm-browsing program. it's terribly cool -sv From chuckw at quantumlinux.com Wed Oct 1 17:36:57 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 1 Oct 2003 10:36:57 -0700 (PDT) Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065026112.14525.13.camel@banff.drgutah.com> Message-ID: > In reading Dax's email (and personally knowing Dax to be a "real > expert"), I had the same thought. I'd love to learn how to set this all > up in a day. Even two or three days would be worth it. > > Anybody willing to contribute a "Quick and Dirty Guide to Network > Nirvana in Three Days or Less"? Maybe just pointers to existing > documentation? Places to start? Things to watch out for? Known > gotchas? I think it's unrealistic to do that in a day if you aren't an expert. At best, it'd be by rote instructions. Any variance would send you spiraling into a weeks worth of troubleshooting (which IMHO is excellent practice). I'm always happy to let our junior sysadmins go down those trails, but time sensitive projects require experience. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From felipe_alfaro at linuxmail.org Wed Oct 1 17:48:10 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 01 Oct 2003 19:48:10 +0200 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065025356.11637.74.camel@poincare.devel.redhat.com> References: <1065016443.6301.37.camel@locutus> <1065023030.2568.24.camel@mentor.gurulabs.com> <1065025356.11637.74.camel@poincare.devel.redhat.com> Message-ID: <1065030489.2445.16.camel@teapot.felipe-alfaro.com> On Wed, 2003-10-01 at 18:22, Owen Taylor wrote: > > The nirvana Linux network setup includes the following: > > > > * LDAP directory > > * Kerberos Authentication > > * Autofs for home directories > > * Kerberized NFSv4 > > Thought question ... most of the above is present currently > but takes a real expert to get going. I don't consider myself a real expert or a genius and I've got Kerberized OpenLDAD, OpenSSH and Cyrus-IMAPD servers running at home. No need to additional passwords, no need for additional sign ons. Later, I'll try with Kerberized NFSv4 and Autofs. From felipe_alfaro at linuxmail.org Wed Oct 1 17:51:08 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 01 Oct 2003 19:51:08 +0200 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065026112.14525.13.camel@banff.drgutah.com> References: <1065016443.6301.37.camel@locutus> <1065023030.2568.24.camel@mentor.gurulabs.com> <1065025356.11637.74.camel@poincare.devel.redhat.com> <1065026112.14525.13.camel@banff.drgutah.com> Message-ID: <1065030667.2447.19.camel@teapot.felipe-alfaro.com> On Wed, 2003-10-01 at 18:35, Jared Smith wrote: > In reading Dax's email (and personally knowing Dax to be a "real > expert"), I had the same thought. I'd love to learn how to set this all > up in a day. Even two or three days would be worth it. > > Anybody willing to contribute a "Quick and Dirty Guide to Network > Nirvana in Three Days or Less"? Maybe just pointers to existing > documentation? Places to start? Things to watch out for? Known > gotchas? I'm working on it... It's pretty early, but I've already covered Kerberos V KDC installation (no kpropd still), OpenSSH integration and Cyrus-IMAPD. However, it still has some rough edges and needs a little polishing. Well, I hope I'll remember to post it up when I think it's ready :-) From heinlein at madboa.com Wed Oct 1 18:02:01 2003 From: heinlein at madboa.com (Paul Heinlein) Date: Wed, 1 Oct 2003 11:02:01 -0700 (PDT) Subject: Idea for website In-Reply-To: <20031001173101.GB13124@ee.oulu.fi> References: <20031001173101.GB13124@ee.oulu.fi> Message-ID: On Wed, 1 Oct 2003, Pekka Pietikainen wrote: > Or am I the only one who grabs .src.rpm's all the time to figure out > what exactly have they done this time? :-) I imagine that everyone on this list has done it, one time or another. It'd be pretty simple to architect: * are there any new .src.rpm packages? * oh, there are! cool: reposdir=/path/to/$ARCH/SRPMS htdocdir=/path/to/DocumentRoot/blah rpmqf='%{NAME}-%{VERSION}-%{RELEASE}' for pkg in $newsrcrpms; do newdir=$(rpm -q --qf "${htdocdir}/${rpmqf}" -p ${reposdir}/${pkg}) mkdir ${newdir} cd ${newdir} rpm2cpio ${reposdir}/${pkg} | cpio -id done :-) --Paul Heinlein From katzj at redhat.com Wed Oct 1 18:04:03 2003 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 01 Oct 2003 14:04:03 -0400 Subject: Idea for website In-Reply-To: <20031001173101.GB13124@ee.oulu.fi> References: <20031001173101.GB13124@ee.oulu.fi> Message-ID: <1065031442.5367.1.camel@mirkwood.devel.redhat.com> On Wed, 2003-10-01 at 13:31, Pekka Pietikainen wrote: > After downloading a 32MB kernel .src.rpm for the n+1:th time just > to look at a 4k patch, I came up with a pretty useful feature for > the website. Basically a "rpm2html" thing (not the existing one, which > does something different), which just basically lets you browse > .src.rpm's in rawhide and grab invidual files from inside the archive. All packages (well, most, there are a few exceptions still) are maintained in CVS and the plan is to get this moved external. Then you could either just anoncvs checkout the package (which then doesn't require pulling the tarball) or look at the cvsweb setup that will almost certainly happen at the same time. Cheers, Jeremy From johnsonm at redhat.com Wed Oct 1 18:16:13 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 1 Oct 2003 14:16:13 -0400 Subject: Idea for website In-Reply-To: <20031001173101.GB13124@ee.oulu.fi>; from pp@ee.oulu.fi on Wed, Oct 01, 2003 at 08:31:01PM +0300 References: <20031001173101.GB13124@ee.oulu.fi> Message-ID: <20031001141613.A22168@devserv.devel.redhat.com> On Wed, Oct 01, 2003 at 08:31:01PM +0300, Pekka Pietikainen wrote: > After downloading a 32MB kernel .src.rpm for the n+1:th time just > to look at a 4k patch, I came up with a pretty useful feature for > the website. Basically a "rpm2html" thing (not the existing one, which > does something different), which just basically lets you browse > .src.rpm's in rawhide and grab invidual files from inside the archive. > > Or am I the only one who grabs .src.rpm's all the time to figure out > what exactly have they done this time? :-) Once we have package metadata (including patches) in external CVS, then cvsweb will make this happen easily. (We already do this internally for our internal package CVS...) 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 ted at cypress.com Wed Oct 1 18:22:35 2003 From: ted at cypress.com (Thomas Dodd) Date: Wed, 01 Oct 2003 13:22:35 -0500 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064914777.26344.1.camel@faro.stuttgart.redhat.com> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064856132.25182.6.camel@guava.bamdad.org> <1064882050.30351.0.camel@binkley> <1064905782.28697.0.camel@guava.bamdad.org> <1064914777.26344.1.camel@faro.stuttgart.redhat.com> Message-ID: <3F7B1B6B.5000105@cypress.com> Harald Hoyer wrote: > Try to select the sentence word by word with the mouse :-) > > Am Di, 2003-09-30 um 09.09 schrieb Roozbeh Pournader: > >>On Tue, 2003-09-30 at 04:04, seth vidal wrote: >> >>>>But you may 'transcribe' it. Fedora may become '?????' in my language. >>> >>>Entirely unrelated - but evolution showed those fonts really well. >> >>Entirely related: it was written with Evolution also. Selects without changes in Mozilla :) double click gives: '????? higlighting gives: '?????' Appears to paste OK to. Scrolling through the characters is interesting (r->l issue?). -Thomas From otaylor at redhat.com Wed Oct 1 18:26:29 2003 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 01 Oct 2003 14:26:29 -0400 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: References: Message-ID: <1065032789.11637.179.camel@poincare.devel.redhat.com> On Wed, 2003-10-01 at 13:36, Chuck Wolber wrote: > > In reading Dax's email (and personally knowing Dax to be a "real > > expert"), I had the same thought. I'd love to learn how to set this all > > up in a day. Even two or three days would be worth it. > > > > Anybody willing to contribute a "Quick and Dirty Guide to Network > > Nirvana in Three Days or Less"? Maybe just pointers to existing > > documentation? Places to start? Things to watch out for? Known > > gotchas? > > I think it's unrealistic to do that in a day if you aren't an expert. At > best, it'd be by rote instructions. Any variance would send you spiraling > into a weeks worth of troubleshooting (which IMHO is excellent practice). > I'm always happy to let our junior sysadmins go down those trails, but > time sensitive projects require experience. That may be the case currently, but why does it have to be that way? What we are talking about is fundamentally pretty simple: - Central user database - Single sign-on passwords - Secure network exported home dirs I don't see why that has to be something that's going to take weeks or years of experience to know how to set up and get right. If we make the basics just work, then the experts can use their expertise to do more interesting things. Regards, Owen From hp at redhat.com Wed Oct 1 19:11:47 2003 From: hp at redhat.com (Havoc Pennington) Date: 01 Oct 2003 15:11:47 -0400 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065016443.6301.37.camel@locutus> References: <1065016443.6301.37.camel@locutus> Message-ID: <1065035507.26241.15.camel@icon.devel.redhat.com> On Wed, 2003-10-01 at 09:54, Bill Anderson wrote: > Does this mean we can now stop requiring kerberos in everything that can > have it required? I submit that the vast majority of Fedora target > "market"will not ever need krb in Fedora. Can we please make this > change? In the past the answer has always been "well enterprises and > medium sized businesses may need it". Well, they can buy RHEL now. > > Please let Fedora Core return to the non > massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in days. My view is the opposite, we need to be making single sign on more pervasive and more "just working"; it's an essential part of easy-to-use secure-out-of-the-box. _All_ apps that do authentication should work with Kerberos, out of the box. Mail clients, IMAP server, LDAP server, printing, Nautilus doing file transfer, thin client setup, X remote display, everything. Or if not Kerberos then some other equivalent technology, but Kerberos seems like the obvious choice. Pick one thing and make it work well and work everywhere. Havoc From ms-nospam-0306 at arcor.de Wed Oct 1 19:16:47 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 1 Oct 2003 21:16:47 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <20031001211647.57bce429.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 01 Oct 2003 13:23:09 -0400, Sean Middleditch wrote: > I'm still seriously confused what people are smoking. The only thing > changing is the name of the distro, which isn't important for any > package dependencies at all in any way except the distro-related > packages like fedora-release, which third party packagers certainly > aren't going to be providing as add-ons. > > *no* normal packages are changing versions from 9->1.0, and > dependencies/versioning have absolutely no reason to care about the > release version. it's user information only, not stuff software should > care about - if the software does, then the software is broken. [...] > Packages depend on other packages, not the text in /etc/*-release. Fix > your packages and move on to complain about real problems. ;-) Well, so far it has been easier to simply analyze /etc/redhat-release and add conditional code to spec files. Conditional code that toggles platform-specific patches, build requirements, source code configuration parameters, and things like that. What you're asking for is that a packager puts much more work into analyzing build requirements directly in order to determine the build platform. Effectively that would duplicate the work of a software's "configure" script. There must be a cheap way to determine the build platform. /etc/redhat-release or /etc/fedora-release is one and hopefully will stay one. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/eygf0iMVcrivHFQRAtyGAKCIjxHfl2Jg0R1Kf9AKJldSgNnmYwCeP3oC nbc2vZs8jmDkHkUCwU4+B/I= =oMGI -----END PGP SIGNATURE----- From smoogen at lanl.gov Wed Oct 1 19:21:30 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 01 Oct 2003 13:21:30 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065035507.26241.15.camel@icon.devel.redhat.com> References: <1065016443.6301.37.camel@locutus> <1065035507.26241.15.camel@icon.devel.redhat.com> Message-ID: <1065036090.14565.37.camel@smoogen1.lanl.gov> On Wed, 2003-10-01 at 13:11, Havoc Pennington wrote: > On Wed, 2003-10-01 at 09:54, Bill Anderson wrote: > > Does this mean we can now stop requiring kerberos in everything that can > > have it required? I submit that the vast majority of Fedora target > > "market"will not ever need krb in Fedora. Can we please make this > > change? In the past the answer has always been "well enterprises and > > medium sized businesses may need it". Well, they can buy RHEL now. > > > > Please let Fedora Core return to the non > > massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in days. > > My view is the opposite, we need to be making single sign on more > pervasive and more "just working"; it's an essential part of easy-to-use > secure-out-of-the-box. > > _All_ apps that do authentication should work with Kerberos, out of the > box. Mail clients, IMAP server, LDAP server, printing, Nautilus doing > file transfer, thin client setup, X remote display, everything. > > Or if not Kerberos then some other equivalent technology, but Kerberos > seems like the obvious choice. Pick one thing and make it work well and > work everywhere. > We are using GSSAPI which I think is a strata above Kerberos, but possibly could be used in many other things. I have been told by both the clustering and applications teams that they prefer using it over straight Kerberos. I will say that I am just a layman here.. I am only 1/10th through the new Kerberos O'Reilly book and also various Cryptography books. -- 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 elanthis at awesomeplay.com Wed Oct 1 19:34:32 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 01 Oct 2003 15:34:32 -0400 Subject: Kind request: fix your packages In-Reply-To: <20031001211647.57bce429.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> Message-ID: <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> On Wed, 2003-10-01 at 15:16, Michael Schwendt wrote: > > Packages depend on other packages, not the text in /etc/*-release. Fix > > your packages and move on to complain about real problems. ;-) > > Well, so far it has been easier to simply analyze /etc/redhat-release > and add conditional code to spec files. Conditional code that toggles > platform-specific patches, build requirements, source code > configuration parameters, and things like that. > > What you're asking for is that a packager puts much more work into > analyzing build requirements directly in order to determine the build > platform. Effectively that would duplicate the work of a software's > "configure" script. There must be a cheap way to determine the build > platform. /etc/redhat-release or /etc/fedora-release is one and > hopefully will stay one. No, you need to actually do the work of the configure script (perhaps you should actually use the app's configure script) - detect the individual bits in the system. Otherwise your package is broken. It's a lie to say that a package is an "RH8.0 package," because that's where you built it, when it runs on RH9 and FC1. Which is a very common case, I might note. If you take the cheap way out, then you have a poorly packaged application. You also completely defeat the entire purpose of using a package manager like RPM; you might as well just go to using Slackware .tgz files. If it *is* so hard to do the proper feature detection at RPM build-time, then perhaps some fixes to RPM are in order. If any fixing is going to be done, let's fix the *real* problem, not fix the workaround to the problem. ;-) Perhaps a comprehensive set of common system configuration checking macros, similar to how autoconf is built, would work well? So packagers can very very easily and cleanly detect which versions of major packages or subsystems are installed. If something like that existed and was well built, nobody would've even bothered using a broken hack like distro release checking to begin with. ^,^ -- Sean Middleditch AwesomePlay Productions, Inc. From hp at redhat.com Wed Oct 1 19:54:06 2003 From: hp at redhat.com (Havoc Pennington) Date: 01 Oct 2003 15:54:06 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <3F7AF7A5.8060007@cypress.com> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064255806.15563.52.camel@icon.devel.redhat.com> <3F7AF7A5.8060007@cypress.com> Message-ID: <1065038045.26241.51.camel@icon.devel.redhat.com> Hi, Setting reply-to to fedora-list, as this really isn't a development discussion. Please follow up to that list only. On Wed, 2003-10-01 at 11:49, Thomas Dodd wrote: > > My understanding is that you have the rights under the open source > > licenses to use, modify, and distribute (we cannot and do not want to > > remove these), but to get maintenance and support *from us* you have to > > subscribe per-system. > > Exactly. and if you don't license per-system you loose maintance and > support from Red Hat. As I understand it, that's because the cost of the Red Hat service product is N dollars per system. If you don't pay the cost of the services, you don't receive the services. As part of the service product, Red Hat distributes the software to you under the terms of its open source licenses. At that point you have the software forever. However, ongoing Red Hat services cost N dollars per system deployed with RHEL. The cost could have been N dollars absolute, or N dollars per employee, or whatever. Whatever the pricing, if you don't pay for the product then you can't use the product. The product in this case is services from Red Hat, not the software binaries. AFAIK there are no restrictions imposed other than that, it's just a matter of: this product costs . What you're funding when you pay the cost is not just support incidents, but maintaining updates for the 5-year lifetime, coordinating with OEMs and ISVs to be sure stuff works, roadmap and future progress/development, bandwidth to provide updates, marketing of Linux so it succeeds, QA, performance testing, all the things that Red Hat builds. You're paying to ensure an entire infrastructure that makes RHEL a long-term viable OS people can rely on. All of the above is only my personal take on it, the official statement is the legal agreement itself. > > But of course I am not a lawyer or official spokesperson, you really > > have to read the agreement and you may want to talk to the Red Hat > > salespeople as they answer questions about this kind of thing all day. > > They won't answer that question. I've emailed sales and got no response. > I think they are happy to not give a definitive answer, so the worry > results in noone exercising there rights under the GPL (and others) and > keeps RHEL from being redistributed due to FUD. I wish you had gotten a response. While it certainly isn't your responsibility to track down our salespeople, calling on the phone might be more effective. Havoc From smoogen at lanl.gov Wed Oct 1 19:59:02 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 01 Oct 2003 13:59:02 -0600 Subject: Kind request: fix your packages In-Reply-To: <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1065038342.14565.45.camel@smoogen1.lanl.gov> Since Red Hat will need to do this through all their spec files anyway, what will the ways that they will check for dependencies and such in files in the future. Sendmail is a common package that has a lot of dependency code in it with lines like: %if %{errata} <= 70 %define sendmailcf usr/lib/sendmail-cf %else %define sendmailcf usr/share/sendmail-cf %endif %if %{errata} >= 72 %define smshell /sbin/nologin %else %define smshell /dev/null %endif There is also code in one RPM I thought that compiles differnetly for RHEL over RHL and would I am guessing would soon need a check for FC. Since RH will need to maintain RPMS for RHEL, RHL<9 til Dec 31, and RHL 9 til Apr.. it might be a good idea to come up with a common syntax now that each of these RPMS could have at the top that would allow for these sort of defines to be done by the machine it is being built on. -- 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 bill at noreboots.com Wed Oct 1 20:32:00 2003 From: bill at noreboots.com (Bill Anderson) Date: 01 Oct 2003 14:32:00 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065016788.32323.126.camel@binkley> References: <1065016443.6301.37.camel@locutus> <1065016788.32323.126.camel@binkley> Message-ID: <1065040320.8017.12.camel@locutus> On Wed, 2003-10-01 at 07:59, seth vidal wrote: > On Wed, 2003-10-01 at 09:54, Bill Anderson wrote: > > Does this mean we can now stop requiring kerberos in everything that can > > have it required? I submit that the vast majority of Fedora target > > "market"will not ever need krb in Fedora. Can we please make this > > change? In the past the answer has always been "well enterprises and > > medium sized businesses may need it". Well, they can buy RHEL now. > > > > Please let Fedora Core return to the non > > massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in days. > > I'd like to offer that universities, in many cases, will not be able to > afford RHEL and we do use and need kerberos. >From the "what are going to do" "RH is abandoning us" posts from the edu peopel on these lists, I'd submit that their claims of "Fedora revs too quickly, we need something long term" is is apparently not being perceived as an option anyway. How much is Fedora really going to be an option if a few releases a year and 7-10 months maintenance way too short? Mind you, that's just from the posts of the people on here, but since nobody is posting how they are happy that they will "have to deal with" upgrading their boxen so many times a year, I'd say at this point it's a fairly reasonable judgement of opinion. > Not only that but if the packages from fedora find their way into rhel > then the kerberos stuff will need to be there. Somehow I doubt they'll be merely copied over. If RH is not committed to doing that level of testing/debug/work on those packages in Fedora, they'll have to do it for the packages in RHEL. Makes sense to me anyway. So I see this as a non-issue. > It's shortsighted to not compile in kerberos and ldap support wherever > possible. Sure, because we all know that all of us enthusiasts and hobbyists have fifty-machine networks in our homes that we are running these things on. I'd say Kerberos is a lot less prevalent than one would expect from reading what happens when someone suggest we not make everything depend on it. I've been an admin at HP, overseeing thousands and thousands of HPUX and Linux machines. No Kerberos whatsoever. In fact, of the dozens of companies, dozens of no-profs, and hundreds of people I've been involved with on a Linux level, not a single one of them is using Kerberos, or has any positive response in favor of doing that. Is Fedora a business-level distribution or not? If it is, then fine, leave it in. But if it isn't, let us at least be honest about how few people at home and small/medium organizations are using it and reconsider our fascination and dedication to it. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From bill at noreboots.com Wed Oct 1 20:34:31 2003 From: bill at noreboots.com (Bill Anderson) Date: 01 Oct 2003 14:34:31 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <20031001141039.GA5485@dudweiler.stuttgart.redhat.com> References: <1065016443.6301.37.camel@locutus> <20031001141039.GA5485@dudweiler.stuttgart.redhat.com> Message-ID: <1065040471.8034.16.camel@locutus> On Wed, 2003-10-01 at 08:10, Florian La Roche wrote: > > Please let Fedora Core return to the non > > massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in days. > > You can use rpm flags at recompile time to throw many things out: > - openldap > - sasl > - gdbm > - tcp_wrappers > - kerberos > - pam > > I don't think it makes sense to pull these things out of Fedora, but > it is true that from a source code level these things should be modular > and thus optional. > Small computers have 1000MHZ x86 CPUs and why not attach a 160GB IDE > drive to them? Because that's the minet found in Redmond. Memory is cheap, CPU is cheap, HD is cheap so to heck with coding decently, or in caring about how much HD we chew up. Why the heck would you put a 160GB drive on a firewall? Not every machine is a desktop. Indeed, in the Linux world, those are likely still the minority. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From bill at noreboots.com Wed Oct 1 20:39:39 2003 From: bill at noreboots.com (Bill Anderson) Date: 01 Oct 2003 14:39:39 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065018196.2447.10.camel@teapot.felipe-alfaro.com> References: <1065016443.6301.37.camel@locutus> <1065018196.2447.10.camel@teapot.felipe-alfaro.com> Message-ID: <1065040779.8022.22.camel@locutus> On Wed, 2003-10-01 at 08:23, Felipe Alfaro Solana wrote: > On Wed, 2003-10-01 at 15:54, Bill Anderson wrote: > > Does this mean we can now stop requiring kerberos in everything that can > > have it required? > > I would like to see more Kerberos support for Linux in general. I think > Kerberos is a blessing. Just imagine logging onto the network and being > able to ssh into any box, read your mail stored in a Cyrus-IMAPD server > without supplying a password, modifying your contacts stored into a > central LDAP server without supplying any credentials or DN, and so on. Why imagine it, I live it! Yet not using Kerberos to do it. Nor Cyrus, but that's a separate issue. > Kerberos is deployed all over my boxes and I find it a pleasure to use, > although it can be a little tricky to set up. I would like to see far > better and wider support for it. Don't know how people can still live > with public keys and passwords when managing multiple servers. We have infrastructures that accommodate it. Scripting/automation is king, baby. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From notting at redhat.com Wed Oct 1 20:43:33 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Oct 2003 16:43:33 -0400 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065040471.8034.16.camel@locutus>; from bill@noreboots.com on Wed, Oct 01, 2003 at 02:34:31PM -0600 References: <1065016443.6301.37.camel@locutus> <20031001141039.GA5485@dudweiler.stuttgart.redhat.com> <1065040471.8034.16.camel@locutus> Message-ID: <20031001164333.A10387@devserv.devel.redhat.com> Bill Anderson (bill at noreboots.com) said: > Why the heck would you put a 160GB drive on a firewall? Not every > machine is a desktop. Indeed, in the Linux world, those are likely still > the minority. Because, of course, Fedora *forces* you to have a 160GB install. You can install a firewall built from Genuine Fedora Parts easily for under 500 MB, and you can cut it down more than that without that much difficulty. Seriously, using things like kerberos and LDAP allow an OS to be used by a much greater potential pool of users than would be enabled by not including them. Moreover, their inclusion allows the development of new technologies such as single sign-on much earlier, and *that's* what Fedora is about - new technology development. Bill From bill at noreboots.com Wed Oct 1 21:03:33 2003 From: bill at noreboots.com (Bill Anderson) Date: 01 Oct 2003 15:03:33 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: References: Message-ID: <1065042213.8017.47.camel@locutus> On Wed, 2003-10-01 at 08:23, Elliot Lee wrote: > On 1 Oct 2003, Bill Anderson wrote: > > > Does this mean we can now stop requiring kerberos in everything that can > > have it required? I submit that the vast majority of Fedora target > > "market"will not ever need krb in Fedora. Can we please make this > > change? In the past the answer has always been "well enterprises and > > medium sized businesses may need it". Well, they can buy RHEL now. > > > > Please let Fedora Core return to the non > > massive-network-might-need-any-and-all-auth-options-so-we-build-them-all-in > > days. > > It's important for Fedora to be a technically featureful OS, and it's not > clear why it's important to avoid Kerberos dependencies. > > Being able to do secure network-wide single sign-on is a cool feature! So is socksified ssh, but we don't get that! I assert that more people use/need that than K support. Heck, nearly every single on of us at HPAQ need it. Not even runsocks is available unless we go elsewhere. And no, Kerberos won't solve that, ;^) I've got networks doing single-sign on using ldap/pam/nss/friends, no K needed. As someone mentioned, paraphrasing "setting up/understanding Kerberos is a nightmare". The tools to make this a reasonable expectation are simply not there. Until they are, and they work correctly, it will remain "The Great Evil that lives just outside of scanner range" (mmm Ur-Quan Masters ;) ). It's kinda funny. With so few exceptions that I can count them on one hand, I often ask people who say "Oh Kerberos is so awesome and useful!": "Are you using it?" Do you know how?" "Do you *need* it?. The answer to all three is "uhh no". By then maybe we're just so backward here int he Pacific NW/ROck Mountain area that our homes aren't filled with dozens of machines begging for this. "SSH is no replacement for Kerberos" Agreed. But then again, you can reverse that statement with no change in truth. Kerberos is not a replacement for SSH either. They are different tools for different things. Apples and Oranges. After all can you not use Kerberos authentication for ssh? "But Kerberos takes up so little HD space." Fine, so it won't "cost" that much to have a set of RPMS that are kerberized, and have it be and option. Geez, didn't know Kerberos was one of the Sacred Cows of RedHat err I mean Fedora. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From kaboom at gatech.edu Wed Oct 1 21:13:20 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 1 Oct 2003 15:13:20 -0600 (MDT) Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065032789.11637.179.camel@poincare.devel.redhat.com> References: <1065032789.11637.179.camel@poincare.devel.redhat.com> Message-ID: On Wed, 1 Oct 2003, Owen Taylor wrote: > That may be the case currently, but why does it have to be that > way? What we are talking about is fundamentally pretty simple: > > - Central user database > - Single sign-on passwords > - Secure network exported home dirs There's your problem. Secure distributed single sign-on protocols (like krb5) are NOT simple. Sure, more documentation is needed (there's only one in-print Kerberos book, and it doesn't really say a whole lot, for example) but documentation only gets you so far.... krb is inherently more involved to set up or trouble-shoot than, say, NIS, and that's not really changeable given krb's architecture (and any replacement protocol will likely have to be just as complex, given everything a secure distributed authentication protocol has to protect against). later, chris From kaboom at gatech.edu Wed Oct 1 21:16:27 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 1 Oct 2003 15:16:27 -0600 (MDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065036090.14565.37.camel@smoogen1.lanl.gov> References: <1065016443.6301.37.camel@locutus> <1065035507.26241.15.camel@icon.devel.redhat.com> <1065036090.14565.37.camel@smoogen1.lanl.gov> Message-ID: On Wed, 1 Oct 2003, Stephen Smoogen wrote: > We are using GSSAPI which I think is a strata above Kerberos, but > possibly could be used in many other things. I have been told by both > the clustering and applications teams that they prefer using it over > straight Kerberos. I will say that I am just a layman here.. I am only > 1/10th through the new Kerberos O'Reilly book and also various > Cryptography books. It's not really a matter of a strata above. Rather, GSSAPI is more similar to PAM. GSSAPI is a standardized API for client-server authentication. Kerberos supports GSSAPI. Rather than explicitly kerberizing your apps, your developers can GSSAPI them, and then they're automatically kerberized (but would also be usable with any other protocols which support GSSAPI) later, chris From ville.skytta at iki.fi Wed Oct 1 21:29:36 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 02 Oct 2003 00:29:36 +0300 Subject: xmms release number In-Reply-To: <1065013574.3f7ad1461b87e@webmail.welho.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1064975240.1954.48.camel@laptop> <1064975818.32323.26.camel@binkley> <1064976749.13480.108.camel@dhcppc3> <65274.12.224.134.103.1064978845.squirrel@webmail.parkrose.k12.or.us> <1064978968.32323.77.camel@binkley> <1064992220.3f7a7ddc7a2db@webmail.welho.com> <1065009776.32323.116.camel@binkley> <1065013574.3f7ad1461b87e@webmail.welho.com> Message-ID: <1065043776.2921.34.camel@bobcat.mine.nu> On Wed, 2003-10-01 at 16:06, Panu Matilainen wrote: > Quoting seth vidal : > > > > > > Synaptic uses (rpm) groups to organize the package tree view - typos in > > rpm > > > groups show up really nicely there :) Things like > > > > > > Application/Multimedia > > > + somedvdplayer > > > Applications/Multimedia > > > + multimediaplayer1 > > > + multimediaplayer2 > > > + ..etc > > > > > > > yah - the groups are fairly static wrt what rpmlint believes are > > 'correct' groups. > > ..except what rpmlint thinks are "correct" groups is miles longer a list than > what's in GROUPS as distributed with rpm. rpmlint thinks what you tell it to think in the config file :) For example, the default config in the fedora.us rpmlint package contains only the groups in /usr/share/doc/rpm-*/GROUPS, while the configuration we use in JPackage has the freshmeat.net categories. The vanilla upstream configuration as well as some other parts in rpmlint is in many regards Mandrake-specific, and should be tweaked according to what one considers "correct". From kaboom at gatech.edu Wed Oct 1 21:29:51 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 1 Oct 2003 15:29:51 -0600 (MDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065040320.8017.12.camel@locutus> References: <1065016443.6301.37.camel@locutus> <1065016788.32323.126.camel@binkley> <1065040320.8017.12.camel@locutus> Message-ID: On Wed, 1 Oct 2003, Bill Anderson wrote: > Sure, because we all know that all of us enthusiasts and hobbyists have > fifty-machine networks in our homes that we are running these things on. My home network is 8 boxes, and I use them there. Things like centralized address books are nice even on smaller networks. > I'd say Kerberos is a lot less prevalent than one would expect from > reading what happens when someone suggest we not make everything depend > on it. I've been an admin at HP, overseeing thousands and thousands of > HPUX and Linux machines. No Kerberos whatsoever. In fact, of the dozens > of companies, dozens of no-profs, and hundreds of people I've been > involved with on a Linux level, not a single one of them is using > Kerberos, or has any positive response in favor of doing that. Just because you don't encounter it in your experience doesn't mean its not widely used. As a counter-example, every organization I've ever worked for in the past decade now uses Kerberos to some extent. Heck, even my bank uses Kerberos (though they had to get MS to supply a custom build of 2000 for the AD realm once they got cross-realm authentication with their Unix realm going ;-) The bottom line, at least for me, is that removing it would inconvenience a lot of users who either now use it or might use it in the future, for very little gain later, chris From kaboom at gatech.edu Wed Oct 1 21:41:48 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 1 Oct 2003 15:41:48 -0600 (MDT) Subject: PDR -- Package development repostory to replace SRPM's? (fwd) Message-ID: Jeff posted this to rpm-list, but it seems of interest to many on here who might not be on the rpm list.... later, chris ---------- Forwarded message ---------- Date: Wed, 01 Oct 2003 15:59:56 -0400 From: Jeff Johnson Reply-To: rpm-list at redhat.com To: rpm-list at redhat.com Subject: PDR -- Package development repostory to replace SRPM's? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: PDR.announce URL: From ville.skytta at iki.fi Wed Oct 1 21:44:44 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 02 Oct 2003 00:44:44 +0300 Subject: Idea for website In-Reply-To: <1065029585.2146.7.camel@binkley> References: <20031001173101.GB13124@ee.oulu.fi> <1065029585.2146.7.camel@binkley> Message-ID: <1065044684.2921.40.camel@bobcat.mine.nu> On Wed, 2003-10-01 at 20:33, seth vidal wrote: > If ville skytta is listening to this PLEASE RELEASE YOUR mod_python > apache rpm-browsing program. http://sourceforge.net/projects/fancix/ There are some rough edges relating to the installation (as well as others here and there) which I haven't found time to clean up yet. Seth, I'd BTW be very grateful if you (or anyone else familiar with the rpm Python bindings) could review the rpm parts... Also, I suggest applying the "Significant performance improvements" patch to htmltmpl from http://sourceforge.net/tracker/index.php?func=detail&aid=794271&group_id=34229&atid=410249 Note: fancix requires the final version of mod_python 3, the CVS snapshot packaged in RH 8.0 won't work. From ms-nospam-0306 at arcor.de Wed Oct 1 21:46:12 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 1 Oct 2003 23:46:12 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 01 Oct 2003 15:34:32 -0400, Sean Middleditch wrote: > No, you need to actually do the work of the configure script (perhaps > you should actually use the app's configure script) - detect the > individual bits in the system. Otherwise your package is broken. What you describe is a maintenance nightmare. Assume an application wants aspell >= 0.50, but distribution B provides only aspell 0.30. A versioned build requirement on aspell >= 0.50 won't suffice, because the package won't build on B. But there is a configure switch to disable aspell support. So, what we can do is either examine aspell version somehow, e.g. with $(rpm -q --qf "%{version}" aspell) or check a file like redhat-release. You're asking for completely generic rpms where the user, who has upgraded a component way beyond the version which was shipped with the original distribution, does not need to supply optional rpmbuild parameters (such as --define _with_aspell=1) for a src.rpm to build _with_ support for that optional component. And what do you do when the user has upgraded aspell to a newer version that is incompatible? This is another unsupported case. Or maybe you want also backwards compatibility? A src.rpm for a new distribution release which examines the installed compiler and applies patches when it finds an older compiler? Another example, a bit closer to what you have in mind: Examining a build platform for decision on whether to apply patches or not. Fedora.us does that for a few packages with rpm -ql for openssl. It is checked whether openssl supports pkgconfig or not and in turn a patch is applied or not. Depending on how many things need to be checked, this can quickly result in nothing else than bloat and wasted effort. If a user has customized his installation a lot, there is no reason why he should not need to customize src.rpms at least a bit as well. Not even addressing the feasibility of some tests. E.g. checking whether additional libraries must be available and linked. Do you want spec files to become as large as the average configure script? Such configure scripts are included. The build requirements in a spec file only make sure that the dependencies are pulled in roughly. The configure script performs more detailed checks on whether everything works. > It's > a lie to say that a package is an "RH8.0 package," because that's where > you built it, when it runs on RH9 and FC1. Which is a very common case, > I might note. Who cares? Who does the testing? A package is built for and tested on a set of platforms. Packages are built for specific distributions or a somewhat compatible family of distribution releases. If a different platform happens to meet the package's requirements, consider yourself lucky. > If you take the cheap way out, then you have a poorly packaged > application. You also completely defeat the entire purpose of using a > package manager like RPM; you might as well just go to using Slackware > .tgz files. This I don't understand at all, I'm afraid. Slackware pkgs don't know dependencies like RPM does. Part of creating a src.rpm is devoted to making sure the build is working on the target distribution. > If it *is* so hard to do the proper feature detection at RPM build-time, > then perhaps some fixes to RPM are in order. If any fixing is going to > be done, let's fix the *real* problem, not fix the workaround to the > problem. ;-) It is wasted effort to check build requirements beyond package names, package versions or distribution version. If spec files contained build platform detection code in addition to a tarball's configure script, who would maintain all that? - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/e0sk0iMVcrivHFQRArjFAJ9u/kNskAyKCnGB0VfFakUiVOoRaACeMS2W PX8XJc+m9oDkXzYunc8euoQ= =ZVVz -----END PGP SIGNATURE----- From ville.skytta at iki.fi Wed Oct 1 21:47:35 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 02 Oct 2003 00:47:35 +0300 Subject: Idea for website In-Reply-To: <1065044684.2921.40.camel@bobcat.mine.nu> References: <20031001173101.GB13124@ee.oulu.fi> <1065029585.2146.7.camel@binkley> <1065044684.2921.40.camel@bobcat.mine.nu> Message-ID: <1065044855.2921.44.camel@bobcat.mine.nu> On Thu, 2003-10-02 at 00:44, Ville Skytt? wrote: > On Wed, 2003-10-01 at 20:33, seth vidal wrote: > > > If ville skytta is listening to this PLEASE RELEASE YOUR mod_python > > apache rpm-browsing program. > > http://sourceforge.net/projects/fancix/ > > There are some rough edges relating to the installation (as well as > others here and there) which I haven't found time to clean up yet. > Seth, I'd BTW be very grateful if you (or anyone else familiar with the > rpm Python bindings) could review the rpm parts... Forgot to say that ideas how to cleanly (ie. using the Python bindings) extract files from inside rpm's would be very much welcome too, I'd rather not go the rpm2cpio way. Oh, and RHL9 packages of fancix and dependencies can be found from http://cachalot.mine.nu/9/ and some from fedora.us. From Dax at GuruLabs.com Wed Oct 1 21:51:31 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Wed, 01 Oct 2003 15:51:31 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065042213.8017.47.camel@locutus> References: <1065042213.8017.47.camel@locutus> Message-ID: <1065045091.2847.53.camel@mentor.gurulabs.com> On Wed, 2003-10-01 at 15:03, Bill Anderson wrote: > ng able to do secure network-wide single sign-on is a cool feature! > > So is socksified ssh, but we don't get that! I assert that more people > use/need that than K support. Heck, nearly every single on of us at HPAQ > need it. Not even runsocks is available unless we go elsewhere. And no, > Kerberos won't solve that, ;^) Funny you mention that. I've been thinking about filing an RFE bug about that very topic. > I've got networks doing single-sign on using ldap/pam/nss/friends, no K > needed. Note that "single-sign on" is not the same as "same password everywhere". > "SSH is no replacement for Kerberos" > Agreed. But then again, you can reverse that statement with no change in > truth. Kerberos is not a replacement for SSH either. I disagree. I assert that in an kerberized intranet environment there is little to no need for SSH. Modulo all the wacky port-forwarding stuff and connecting to remote internet sites, Kerberos does provide the main feature of SSH, namely: * Strong Host authentication * Strong User authentication and passwordless logins * Drop-in replacements for r* utilities > "But Kerberos takes up so little HD space." Fine, so it won't "cost" > that much to have a set of RPMS that are kerberized, and have it be and > option. There are *already* kerberized RPMs for the server components and the command line utils. Are you arguing about the size of the Evolution 1.4 binary (and others) compiled with GSSAPI support versus not? From otaylor at redhat.com Wed Oct 1 22:04:48 2003 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 01 Oct 2003 18:04:48 -0400 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: References: <1065032789.11637.179.camel@poincare.devel.redhat.com> Message-ID: <1065045888.11637.264.camel@poincare.devel.redhat.com> On Wed, 2003-10-01 at 17:13, Chris Ricker wrote: > On Wed, 1 Oct 2003, Owen Taylor wrote: > > > That may be the case currently, but why does it have to be that > > way? What we are talking about is fundamentally pretty simple: > > > > - Central user database > > - Single sign-on passwords > > - Secure network exported home dirs > > There's your problem. Secure distributed single sign-on protocols (like > krb5) are NOT simple. Sure, more documentation is needed (there's only one > in-print Kerberos book, and it doesn't really say a whole lot, for example) > but documentation only gets you so far.... krb is inherently more involved > to set up or trouble-shoot than, say, NIS, and that's not really changeable > given krb's architecture (and any replacement protocol will likely have to > be just as complex, given everything a secure distributed authentication > protocol has to protect against). The fact that there is underlying complexity is not, in itself, a problem. Thinking about the desktop, to put up a button that says "Hello World" involves great underlying complexity in font selection, theme engines, X window system extensions, and all that. But all the developer writes is: gtk_button_new_with_label ("Hello World"); And all the user has to do is click on the button. If Kerberos is seemlessly integrated into the system, the concepts that a user should need to know are pretty small. Maybe they know that they have something called a "ticket" that expires after some time. But maybe they just know that if they work for 12 hours straight they'll get prompted again for their password at some point. And I don't see why the concepts that an admin needs to know are that much more complicated: - You configure one server as your "authentication server" - There is a nice GUI tool you run on that server (or run elsewhere and point to that server) to reset and configure user's passwords. - You point all the clients at the "authentication server" - When configuring a service that people log into, there is a process of generating a "service identity" that requires someone with admin access on the authentication server. Is that a gross (and factually inaccurate, since I'm not very familiar with Kerberos) simplication? Yes. But my contention would be that there are only a few basic important concepts to understand how Kerberos works; that knowing those concepts is sufficient for configuration of a small isolated network; that much of the learning barrier comes from handling of multiple realms, krb4 compatibility, and all sorts of other advanced irrelevant details; more of the learning barrier is obscure configuration files, obscure command line utilities, and poor defaults. Is someone going to be able to duplicate the MIT kerberos setup in a day/year/decade? No. But the fact that Gnumeric is amazingly complex doesn't mean that you can't get a basic GTK+ program going very quickly. Regards, Owen From katzj at redhat.com Wed Oct 1 22:05:43 2003 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 01 Oct 2003 18:05:43 -0400 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065042213.8017.47.camel@locutus> References: <1065042213.8017.47.camel@locutus> Message-ID: <1065045943.5367.89.camel@mirkwood.devel.redhat.com> On Wed, 2003-10-01 at 17:03, Bill Anderson wrote: > "But Kerberos takes up so little HD space." Fine, so it won't "cost" > that much to have a set of RPMS that are kerberized, and have it be and > option. Having two sets of identical packages just built with different configuration options is a nightmare from an installation point of view. And also quite confusing for the users. Plus, although *adding* Kerberos support doesn't take much space, duplicating everything that would use Kerberos is a lot more space (ie, having two copies of all of the packages that link against Kerberos; having two copies of evolution would take quite a bit of space :) Jeremy From felipe_alfaro at linuxmail.org Wed Oct 1 22:21:52 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 02 Oct 2003 00:21:52 +0200 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065045091.2847.53.camel@mentor.gurulabs.com> References: <1065042213.8017.47.camel@locutus> <1065045091.2847.53.camel@mentor.gurulabs.com> Message-ID: <1065046912.3897.12.camel@teapot.felipe-alfaro.com> On Wed, 2003-10-01 at 23:51, Dax Kelson wrote: > > "But Kerberos takes up so little HD space." Fine, so it won't "cost" > > that much to have a set of RPMS that are kerberized, and have it be and > > option. > > There are *already* kerberized RPMs for the server components and the > command line utils. Are you arguing about the size of the Evolution 1.4 > binary (and others) compiled with GSSAPI support versus not? Thanks god that Evolution has native support for GSSAPI! It's nice being able to access my IMAP mailbox with an automatic, secure, Kerberized login. All in all, I don't mind if Red Hat/Fedora removes Kerberos support. I would prefer for it to stay, but if it's removed, I'll grab it from MIT, compile and Kerberize all my apps. I have used to live with it that I can't live with it anymore. From Nicolas.Mailhot at laPoste.net Wed Oct 1 23:00:54 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Oct 2003 01:00:54 +0200 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065025356.11637.74.camel@poincare.devel.redhat.com> References: <1065016443.6301.37.camel@locutus> <1065023030.2568.24.camel@mentor.gurulabs.com> <1065025356.11637.74.camel@poincare.devel.redhat.com> Message-ID: <1065049254.2341.11.camel@rousalka.dyndns.org> Le mer 01/10/2003 ? 18:22, Owen Taylor a ?crit : > On Wed, 2003-10-01 at 11:43, Dax Kelson wrote: > > > The nirvana Linux network setup includes the following: > > > > * LDAP directory > > * Kerberos Authentication > > * Autofs for home directories > > * Kerberized NFSv4 > > Thought question ... most of the above is present currently > but takes a real expert to get going. > > What needs to be done to make it possible so that, given say, > a network of 50 workstations, someone who has never done > it before could get such a network going in a day? And I'd even add samba domain controller that uses the krb5+ldap setup as user database. Most small networks include at least a few legacy computers. This can be done and I even did a bastardised setup with a 7.3 server, but I can confirm it's a major PITA and most small businesses (which would kill for a setup) can not afford a software engineer to set it up. Biggers edus/corps will use custom setups anyway and single computer networks have no need of this, but any small 2-50 computer network would benefit from it. Really given how samba have matured a prebuild ldap+krb+nfs+samba combo should be possible nowadays. [ and I for one do not care about the gui stuff, if it's yet another wizard people have to work around I do not need it, however having the default config files working out of the box instead of having to master 4-5 howtows before the first login would be 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 Nicolas.Mailhot at laPoste.net Wed Oct 1 23:11:52 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Oct 2003 01:11:52 +0200 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065040320.8017.12.camel@locutus> References: <1065016443.6301.37.camel@locutus> <1065016788.32323.126.camel@binkley> <1065040320.8017.12.camel@locutus> Message-ID: <1065049912.2341.21.camel@rousalka.dyndns.org> Le mer 01/10/2003 ? 22:32, Bill Anderson a ?crit : > I'd say Kerberos is a lot less prevalent than one would expect from > reading what happens when someone suggest we not make everything depend > on it. I've been an admin at HP, overseeing thousands and thousands of > HPUX and Linux machines. No Kerberos whatsoever. In fact, of the dozens > of companies, dozens of no-profs, and hundreds of people I've been > involved with on a Linux level, not a single one of them is using > Kerberos, or has any positive response in favor of doing that. And why ? Because it's a PITA to setup. And it shouldn't have to. Really if people could remove all the nis/hesiod legacy and focus on making the "best" techs easy to use we wouldn't be there. It's very close to pre-HIG Gnome on that point : do everything, and do nothing good. Right now a RH/Fedora box can plug into lots of different networks but can drive none of them (easily) which kind of restricts its usage as a fringe tech in greater wholes managed by something else (and makes in a no-go fro small networks) (at least someone dumped the Novell integration at one point) -- 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 kaboom at gatech.edu Wed Oct 1 23:47:05 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 1 Oct 2003 17:47:05 -0600 (MDT) Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065045888.11637.264.camel@poincare.devel.redhat.com> References: <1065032789.11637.179.camel@poincare.devel.redhat.com> <1065045888.11637.264.camel@poincare.devel.redhat.com> Message-ID: On Wed, 1 Oct 2003, Owen Taylor wrote: > But my contention would be that there are only a few basic > important concepts to understand how Kerberos works; that > knowing those concepts is sufficient for configuration of > a small isolated network; that much of the learning barrier > comes from handling of multiple realms, krb4 compatibility, > and all sorts of other advanced irrelevant details; more > of the learning barrier is obscure configuration files, > obscure command line utilities, and poor defaults. Well, the problem here is that with Kerberos the complexity isn't in things like the configuration files or the commands -- it's the whole authentication process of principals getting ticket-granting tickets which allow them to get service tickets which they then present to the service to be authenticated and authorized to use it. To administer it, you have to understand the whole flow of all that at a conceptual level. If you look at, say, /etc/krb5.conf you'll find that the syntax is reasonably sane and that there's very little you normally change, barring rare complexities like setting up direct (non-hierarchical) cross-realm authentication. Even things as simple as authconfig mostly configure that right already. Similarly, the commands you use to generate principals and such aren't difficult. At least IMHO, it's the logic of "when do I need this command" that's the complex part, and that goes back to understanding the system, which goes back to docs. You'll see that if you look at the existing Kerberos GUIs, or at least the two I've used. Sun has gkadmin (usual Solaris Java applet mess) and MS has a whole slew of stuff for AD, and neither are really usable unless you know how the process works.... There are a few defaults in Red Hat which could be tuned better -- for example, last I looked, Red Hat randomly used a different default encryption for tickets than any other MIT-derived Kerberos, which makes things "fun" if you have, say, Solaris and Red Hat around. Good luck designing a GUI which can walk admins through diagnosing that ;-) later, chris From dkl at redhat.com Thu Oct 2 00:57:38 2003 From: dkl at redhat.com (Dave Lawrence) Date: Wed, 01 Oct 2003 20:57:38 -0400 Subject: Bugzilla System Back Message-ID: <1065040648.7690.22.camel@dhcp59-114.rdu.redhat.com> Due to technical failures, bugzilla.redhat.com was down for a period of time on Wednesday morning EST, Oct 1st. It has since been resolved and should be accessible again. Unfortunately there was some slight data loss involved. If you filed a bug report or made any bug changes from 4:00 am EST Sept 30th to 9:00 am Oct 1st, please refile them if possible. Sorry for the inconvenience. Thanks David Lawrence Red Hat, Inc. -- fedora-list mailing list fedora-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-list From riel at redhat.com Thu Oct 2 02:04:34 2003 From: riel at redhat.com (Rik van Riel) Date: Wed, 1 Oct 2003 22:04:34 -0400 (EDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <20031001164333.A10387@devserv.devel.redhat.com> Message-ID: On Wed, 1 Oct 2003, Bill Nottingham wrote: > Seriously, using things like kerberos and LDAP allow an OS to > be used by a much greater potential pool of users than would > be enabled by not including them. I wonder what would be required to have mechanisms like NIS and LDAP as optional plugins, instead of required dependencies ... -- "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 notting at redhat.com Thu Oct 2 02:15:03 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Oct 2003 22:15:03 -0400 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: ; from riel@redhat.com on Wed, Oct 01, 2003 at 10:04:34PM -0400 References: <20031001164333.A10387@devserv.devel.redhat.com> Message-ID: <20031001221502.C5105@devserv.devel.redhat.com> Rik van Riel (riel at redhat.com) said: > On Wed, 1 Oct 2003, Bill Nottingham wrote: > > > Seriously, using things like kerberos and LDAP allow an OS to > > be used by a much greater potential pool of users than would > > be enabled by not including them. > > I wonder what would be required to have mechanisms like > NIS and LDAP as optional plugins, instead of required > dependencies ... NIS is just a NSS module in glibc, it's not huge, and doesn't have extra libraries. LDAP has a nss/pam module package (nss_ldap); its requires are just glibc and the openldap libraries. As for the other requirements on openldap libraries, that's just for things that use LDAP for things you can't get via NSS. Bill From elanthis at awesomeplay.com Thu Oct 2 02:24:48 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 01 Oct 2003 22:24:48 -0400 Subject: Kind request: fix your packages In-Reply-To: <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> Message-ID: <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> On Wed, 2003-10-01 at 17:46, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 01 Oct 2003 15:34:32 -0400, Sean Middleditch wrote: > > > No, you need to actually do the work of the configure script (perhaps > > you should actually use the app's configure script) - detect the > > individual bits in the system. Otherwise your package is broken. > > What you describe is a maintenance nightmare. Assume an application > wants aspell >= 0.50, but distribution B provides only aspell 0.30. A > versioned build requirement on aspell >= 0.50 won't suffice, because > the package won't build on B. But there is a configure switch to > disable aspell support. So, what we can do is either examine aspell > version somehow, e.g. with > > $(rpm -q --qf "%{version}" aspell) > > or check a file like redhat-release. (pre-note: if I sound harsh, it's not personal - this whole problem itself is just amazingly infuriating, and isn't a result of any one person. my apologies afore-hand for a semi-heated email.) Which is broken. You are working around the problem instead of fixing it. Redhat-release doesn't tell you anything about the version of aspell installed. I quite often have tons of RPMs installed on a stock RH (or now Fedora) system; if I happen to upgrade aspell on my own, and your broken package is looking for my OS release instead of the actual aspell package... what then again is the point of actually having dependencies? Why not just make everything a "Distro-X.Y" package, and forget dependencies, since we know which software versions Distro-X.Y has? And no, installing new packages doesn't make me an "advanced user." Or, at least it shouldn't - I guess I have to be thanks to packages being made using a broken packaging method. Users should just be able to grab any package online they want, and install it. A friend points them to MagicFishSoftware.com and the cool nifty Swordfish Spreadsheet app there, they should just be able to click on the "Download Linux Package" link, and watch it install. Oh, it needs the new aspell? Great, it's grabbed automatically for them, and *boom*, they've got an upgraded aspell, and redhat-release is useless in that regard. Or, heck, the new Fedora policy states that security holes will often be fixed by providing a whole new version, not just backporting a fix. Is fedora-release now supposed to also list all the legitimate security patches it has so your can packages can have -fc1, -fc1-openssl4, -fc1-db5, -fc1-openssl4-db5 variants and so on? If the software can use aspell, but has a switch to disable it, the software is badly designed, because it creates an unfavorable situation. If aspell has different ABIs for different versions, but those versions can't be co-installed, then aspell is also broken. You, and other packagers, want to continue screwing over users with these insane/broken development and packaging policies, versus just fixing the problem once and being done with; libraries with changing ABIs need to be co-installable, and apps shouldn't have wildly different feature sets that can't be changed/detected at runtime. If the app does depend on libraries made by uncaring developers that can't keep a stable ABI, then package the library with the app, and save the user the pain of dealing with it; sure, it bloats the package size a bit, but that's the price to pay for using poorly managed libraries. If the app absolutely can't be packages without breaking all these rules of sane design, then perhaps it shouldn't be packaged - if the only people whom can install it easily are people who compile it, then it seems a bit of a waste of time to package it anyhow; I guess its your time to waste building 10 versions of a package that should only ever need just 1. If the app is compiled for an old aspell, but the user only has a newer, incompatible aspell, then the user should just install the old aspell. Some apps use the newer one, some the old - this is the wonder of versioned libraries, something we should be making use of, instead of banishing users to DLL^w.so hell. Fedora is about new technology, not continuing in the same nightmarish unuserfriendly broken hack technology. *please*, let's not do that to users, ok? :) -- Sean Middleditch AwesomePlay Productions, Inc. From behdad at cs.toronto.edu Thu Oct 2 03:04:41 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Wed, 1 Oct 2003 23:04:41 -0400 Subject: [OT] Re: redhat logo on gnome menu / menu bar. In-Reply-To: <1064923257.29356.14.camel@guava.bamdad.org> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064856132.25182.6.camel@guava.bamdad.org> <1064882050.30351.0.camel@binkley> <1064905782.28697.0.camel@guava.bamdad.org> <1064914777.26344.1.camel@faro.stuttgart.redhat.com> <1064922577.30351.18.camel@binkley> <1064923257.29356.14.camel@guava.bamdad.org> Message-ID: On Tue, 30 Sep 2003, Roozbeh Pournader wrote: > On Tue, 2003-09-30 at 15:19, seth vidal wrote: > > Yah - I noticed that too. But I wasn't familiar with the language to > > know if selecting only part of it changed the letter to be used. For > > example, korean changes the character dependent on what you type. > > This was the Persian language, written in the Arabic script. And yes, it > *does* have that "contextual shaping" behavior. But in no language in > the word should selecting (a read-only act) change the appearance > underlying text. But again, since this is a bidirectional script, so > getting things like this right is a little hard. First time I saw this behaviour was in mozilla. Right now I'm thinking that having such a *feature* may not be so bad some times. Consider selecting Arabic text when your font supports and you are seeing those nasty ligatures of three or more letters... > roozbeh From behdad at cs.toronto.edu Thu Oct 2 03:08:18 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Wed, 1 Oct 2003 23:08:18 -0400 Subject: xmms release number In-Reply-To: <20030930111405.J13840@devserv.devel.redhat.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> Message-ID: On Tue, 30 Sep 2003, Bill Nottingham wrote: > Nils Philippsen (nphilipp at redhat.com) said: > > > can't we name our release s.th. like -0.x for xmms, so that users can > > > use up2date and install the original xmms-xxx-1 from www.xmms.org with > > > MP3 support? > > > > I don't think this is necessary, as people easily can install xmms-mp3 > > packages from third parties on top of the Fedora xmms package. > > That was my initial reaction... do more people install xmms-mp3, > or the xmms.org packages? The problem for the past few days was that there were no xmms-mp3-1.2.8 around, all were for 1.2.7, but there was an xmms-1.2.8 on xmms.org. > Bill From skvidal at phy.duke.edu Thu Oct 2 03:24:04 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Oct 2003 23:24:04 -0400 Subject: xmms release number In-Reply-To: References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> Message-ID: <1065065044.3682.0.camel@binkley> > > The problem for the past few days was that there were no > xmms-mp3-1.2.8 around, all were for 1.2.7, but there was an > xmms-1.2.8 on xmms.org. > there has been one on rpm.livna.org this is, unofficially of course, where all the not-quite-so-legal fedora.us rpms have gone to. -sv From skvidal at phy.duke.edu Thu Oct 2 03:40:21 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Oct 2003 23:40:21 -0400 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065040320.8017.12.camel@locutus> References: <1065016443.6301.37.camel@locutus> <1065016788.32323.126.camel@binkley> <1065040320.8017.12.camel@locutus> Message-ID: <1065066020.3682.9.camel@binkley> > >From the "what are going to do" "RH is abandoning us" posts from the edu > peopel on these lists, I'd submit that their claims of "Fedora revs too > quickly, we need something long term" is is apparently not being > perceived as an option anyway. How much is Fedora really going to be an > option if a few releases a year and 7-10 months maintenance way too > short? > I think you're reading the wrong posts then :) I know some universities who are definitely going to watch what happens before making a decision one way or the other, but are probably going to look into helping extend the errata with fedora legacy. -sv From behdad at cs.toronto.edu Thu Oct 2 04:50:48 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Thu, 2 Oct 2003 00:50:48 -0400 Subject: grub.conf, please? In-Reply-To: <3F79D767.3030303@blixtra.org> References: <3F79D767.3030303@blixtra.org> Message-ID: On Tue, 30 Sep 2003, chris wrote: > Could someone kindly sed me their grub.conf file? Here is mine, for Fedora: # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd0,1) # kernel /boot/vmlinuz-version ro root=/dev/hda2 # initrd /boot/initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,1)/boot/grub/splash.xpm.gz password --md5 $1$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX title Fedora Core (2.4.22-1.2061.nptl) root (hd0,1) kernel /boot/vmlinuz-2.4.22-1.2061.nptl ro root=/dev/hda2 hdc=ide-scsi acpi=on idebus=66 resume=/dev/hda6 initrd /boot/initrd-2.4.22-1.2061.nptl.img title Legacy Proprietary Experimental Code Can rootnoverify (hd0,0) chainloader +1 > I made a booboo and installed a redhat test kernel rpm and when > uninstalling it I got this msg: > > grubby fatal error: unable to find a suitable template > > I got the same error when yumming the original kernel back in. > > thanks, > chris > > PS: Where can I find a fedora 2.6 test kernel? Arjan's is what they recommend to test themselves. But there are problems in up2date with that repo, so try downloading them handy. From behdad at cs.toronto.edu Thu Oct 2 04:58:55 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Thu, 2 Oct 2003 00:58:55 -0400 Subject: xmms release number In-Reply-To: <1065065044.3682.0.camel@binkley> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <20030930111405.J13840@devserv.devel.redhat.com> <1065065044.3682.0.camel@binkley> Message-ID: On Wed, 1 Oct 2003, seth vidal wrote: > > > > > The problem for the past few days was that there were no > > xmms-mp3-1.2.8 around, all were for 1.2.7, but there was an > > xmms-1.2.8 on xmms.org. > > > > there has been one on rpm.livna.org Thanks a lot for the link Seth. I was looking around for this place, but for I don't know what reason, I thought that noone's gonna shout it on the list. > this is, unofficially of course, where all the not-quite-so-legal > fedora.us rpms have gone to. > > -sv From felipe_alfaro at linuxmail.org Thu Oct 2 08:08:01 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 02 Oct 2003 10:08:01 +0200 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: References: <1065032789.11637.179.camel@poincare.devel.redhat.com> <1065045888.11637.264.camel@poincare.devel.redhat.com> Message-ID: <1065082080.1449.21.camel@teapot.felipe-alfaro.com> On Thu, 2003-10-02 at 01:47, Chris Ricker wrote: > On Wed, 1 Oct 2003, Owen Taylor wrote: > Well, the problem here is that with Kerberos the complexity isn't in things > like the configuration files or the commands -- it's the whole > authentication process of principals getting ticket-granting tickets which > allow them to get service tickets which they then present to the service to > be authenticated and authorized to use it. To administer it, you have to > understand the whole flow of all that at a conceptual level. I agree Kerberos is not child's toy, but if M$ has made it usable, it means that, besides its complexity, admin tools can be developed to make it more palatable to the unexperienced administrator. I think the idea is integrate tools like "libuser" to work against Kerberos: should an admin invoke "useradd", the corresponding entry should be created on the user repository (i.e. OpenLDAP) and the security principal on the Kerberos KDC. > If you look at, say, /etc/krb5.conf you'll find that the syntax is > reasonably sane and that there's very little you normally change, barring > rare complexities like setting up direct (non-hierarchical) cross-realm > authentication. Even things as simple as authconfig mostly configure that > right already. Similarly, the commands you use to generate principals and > such aren't difficult. At least IMHO, it's the logic of "when do I need this > command" that's the complex part, and that goes back to understanding the > system, which goes back to docs. I think Kerberos is complex, but many other things like IPSec and XFree86 are complex enough too and they work reliably and don't need a lot of tweaking and configuration. We need to work in order to develop more robust, out-of-the-box tools. For example, during installation, the /etc/krb5.conf could be automatically customized to change EXAMPLE.COM to a valid Kerberos V realm aligned with the DNS suffix. > You'll see that if you look at the existing Kerberos GUIs, or at least the > two I've used. Sun has gkadmin (usual Solaris Java applet mess) and MS has a > whole slew of stuff for AD, and neither are really usable unless you know > how the process works.... Haven't worked with any of them, but even on Windows, there is no Kerberos admin tool. It's nearly automatic and you have fallback authentication protocols like the weak NTLM. > There are a few defaults in Red Hat which could be tuned better -- for > example, last I looked, Red Hat randomly used a different default encryption > for tickets than any other MIT-derived Kerberos, which makes things "fun" if > you have, say, Solaris and Red Hat around. Good luck designing a GUI which > can walk admins through diagnosing that ;-) Don't know what are you talking about, but I've several boxes running on Red Hat (with MIT Kerberos) and two other with SuSE Linux 8.2 (running Heimdal) and they are totally and seamlessly interoperable. From nos at utel.no Thu Oct 2 08:48:37 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Thu, 02 Oct 2003 10:48:37 +0200 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <28a8d2be03077a07d3@[192.168.170.10]> References: <28a8d2be03077a07d3@[192.168.170.10]> Message-ID: <2cb259bc04082e07d3@[192.168.170.10]> On Wed, 2003-10-01 at 15:54, Bill Anderson wrote: > Does this mean we can now stop requiring kerberos in everything that can > have it required? I submit that the vast majority of Fedora target > "market"will not ever need krb in Fedora. Can we please make this > change? In the past the answer has always been "well enterprises and > medium sized businesses may need it". Well, they can buy RHEL now. I'd be very sad if this happend. We use ldap/kerberos at our office, and we really should have no need for RHEL to do that. I'd rather encourage the oposite. Intergrate kerberos/ldap everywhere, make it friendly, and a linux native alternative to active directory. From harald at redhat.com Thu Oct 2 10:39:24 2003 From: harald at redhat.com (Harald Hoyer) Date: Thu, 02 Oct 2003 12:39:24 +0200 Subject: xmms release number In-Reply-To: <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1065091163.6837.15.camel@faro.stuttgart.redhat.com> Well, browse www.xmms.org and search for xmms-mp3 .. haven't found it in the download section. Am Di, 2003-09-30 um 15.37 schrieb Nils Philippsen: > On Tue, 2003-09-30 at 12:55, Harald Hoyer wrote: > > can't we name our release s.th. like -0.x for xmms, so that users can > > use up2date and install the original xmms-xxx-1 from www.xmms.org with > > MP3 support? > > I don't think this is necessary, as people easily can install xmms-mp3 > packages from third parties on top of the Fedora xmms package. > > Nils -- Harald Hoyer, Senior Software Engineer Harald.Hoyer at redhat.de Red Hat GmbH Tel. : +49-711-96437-0 D-70178 Stuttgart, Germany Web : http://www.redhat.de gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542 -------------- 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 gavin.henry at magicfx.co.uk Thu Oct 2 11:12:40 2003 From: gavin.henry at magicfx.co.uk (Gavin Henry) Date: Thu, 2 Oct 2003 12:12:40 +0100 Subject: artwork project Message-ID: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> Are there any guides etc or suggestions on what tools to use for creating and editing artwork for fedora? -- Regards, Gavin Henry. Trying to be a RHCE..... http://www.magicfx.co.uk http://www.suretecsystems.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kaboom at gatech.edu Thu Oct 2 14:02:21 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 2 Oct 2003 08:02:21 -0600 (MDT) Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065082080.1449.21.camel@teapot.felipe-alfaro.com> References: <1065032789.11637.179.camel@poincare.devel.redhat.com> <1065045888.11637.264.camel@poincare.devel.redhat.com> <1065082080.1449.21.camel@teapot.felipe-alfaro.com> Message-ID: On Thu, 2 Oct 2003, Felipe Alfaro Solana wrote: > > There are a few defaults in Red Hat which could be tuned better -- for > > example, last I looked, Red Hat randomly used a different default encryption > > for tickets than any other MIT-derived Kerberos, which makes things "fun" if > > you have, say, Solaris and Red Hat around. Good luck designing a GUI which > > can walk admins through diagnosing that ;-) > > Don't know what are you talking about, but I've several boxes running on > Red Hat (with MIT Kerberos) and two other with SuSE Linux 8.2 (running > Heimdal) and they are totally and seamlessly interoperable. MIT Kerberos, as downloaded from MIT, uses des3-hmac-sha1 for key encryption, and that's what most other MIT derivatives (like Solaris) use. RH for some reason changes that to des-cbc-crc (which is a weaker encryption). Some things go "Boom!" when trying to interoperate between the two as a result. later, chris From heinlein at madboa.com Thu Oct 2 14:37:11 2003 From: heinlein at madboa.com (Paul Heinlein) Date: Thu, 2 Oct 2003 07:37:11 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065066020.3682.9.camel@binkley> References: <1065016443.6301.37.camel@locutus> <1065016788.32323.126.camel@binkley> <1065040320.8017.12.camel@locutus> <1065066020.3682.9.camel@binkley> Message-ID: On Wed, 1 Oct 2003, seth vidal wrote: > I know some universities who are definitely going to watch what > happens before making a decision one way or the other, but are > probably going to look into helping extend the errata with fedora > legacy. Seth and Duke are not alone in this venture. Once things settle down and the whole Fedore release-cycle routine becomes reality instead of conjecture, many of us will work to provide backported fixes needed to keep servers up without having to upgrade every six months. --Paul Heinlein From bill at noreboots.com Thu Oct 2 15:11:03 2003 From: bill at noreboots.com (Bill Anderson) Date: 02 Oct 2003 09:11:03 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065045091.2847.53.camel@mentor.gurulabs.com> References: <1065042213.8017.47.camel@locutus> <1065045091.2847.53.camel@mentor.gurulabs.com> Message-ID: <1065107463.14032.64.camel@locutus> On Wed, 2003-10-01 at 15:51, Dax Kelson wrote: > On Wed, 2003-10-01 at 15:03, Bill Anderson wrote: > > ng able to do secure network-wide single sign-on is a cool feature! > > > > So is socksified ssh, but we don't get that! I assert that more people > > use/need that than K support. Heck, nearly every single on of us at HPAQ > > need it. Not even runsocks is available unless we go elsewhere. And no, > > Kerberos won't solve that, ;^) > > Funny you mention that. I've been thinking about filing an RFE bug about > that very topic. Good luck. Seriously. > > "SSH is no replacement for Kerberos" > > Agreed. But then again, you can reverse that statement with no change in > > truth. Kerberos is not a replacement for SSH either. > > I disagree. I assert that in an kerberized intranet environment there is > little to no need for SSH. Kerberos does not do X11-forwarding, for example. Nor does Kerberos provide remote file copying (such as sftp and scp). Kerberos is authentication. SSH while possessing strong authentication is more than an authentication architecture. Thus, they are *different* and serve *different* purposes. > Modulo all the wacky port-forwarding stuff and connecting to remote > internet sites, Kerberos does provide the main feature of SSH, namely: Remove from app A what B doesn't do and call it the same? They do the same thing if you don't count the things they don't both do??? Sure, I see that. My Corvette can replace my Durango if you don't count that wacky 7 passenger seating, 4wd, lots of ground clearance, more expensive insurance, and significantly higher cargo capacity the Durango has/does. The main feature of SSH is that I can establish a secure connection from point a to point b, more than just secure authorization but having the entire session encrypted. Kerberos does not do that. It was not designed to. As I've said, Kerberos can be used to provide the authentication mechanism for SSH. This should be a hint that they are not replacements for each other. Indeed, one could have an SSH kerberized intranet that uses SSH as the remote login facility! I'd argue that SSH would be a massive need in that environment. To compare them is to compare apples to buffets. My point was that K and SSH are *not* replacements for each other. It still stands. They are different things with different purposes. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From sopwith at redhat.com Thu Oct 2 15:58:11 2003 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 2 Oct 2003 11:58:11 -0400 (EDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065107463.14032.64.camel@locutus> Message-ID: On 2 Oct 2003, Bill Anderson wrote: > Kerberos does not do X11-forwarding, for example. Nor does Kerberos > provide remote file copying (such as sftp and scp). Kerberos doesn't do these things itself, because Kerberos is just authentication. > authentication. SSH while possessing strong authentication is more than > an authentication architecture. Thus, they are *different* and serve > *different* purposes. ssh is a special-purpose authentication system accompanied by utilities that use that system. In the case of Kerberos, the analogues would be all the utilities and applications (such as krcp, XFree86, etc.) that have been Kerberized. So, it is possible to do the same things on a Kerberized system as with ssh, just not all with stuff included in Kerberos proper. -- Elliot Individualists, unite! From kaboom at gatech.edu Thu Oct 2 15:36:43 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 2 Oct 2003 09:36:43 -0600 (MDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065107463.14032.64.camel@locutus> References: <1065042213.8017.47.camel@locutus> <1065045091.2847.53.camel@mentor.gurulabs.com> <1065107463.14032.64.camel@locutus> Message-ID: On Thu, 2 Oct 2003, Bill Anderson wrote: > Kerberos does not do X11-forwarding, for example. Nor does Kerberos > provide remote file copying (such as sftp and scp). Kerberos is > authentication. SSH while possessing strong authentication is more than > an authentication architecture. Thus, they are *different* and serve > *different* purposes. Not exactly. You're right that Kerberos is an authentication protocol, but MIT Kerberos also includes encrypted replacements for many common applications: telnet ftp r* protocols If you're in a Kerberized environment, you can safely use Kerberos rcp, rsh, etc., be encrypted and securely authenticated, and not need SSH at all.... About all that SSH offers that the Kerberized apps don't are the "weird things" Dax mentioned, like port forwarding. later, chris From garrett at redhat.com Thu Oct 2 16:10:22 2003 From: garrett at redhat.com (Garrett LeSage) Date: Thu, 02 Oct 2003 12:10:22 -0400 Subject: artwork project In-Reply-To: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> Message-ID: <3F7C4DEE.2010705@redhat.com> Gavin Henry wrote: >Are there any guides etc or suggestions on what tools to use for creating and editing artwork for fedora? > > There are no guides yet. I use Illustrator on the Mac and the GIMP on my Linux box, so the artwork is currently in those formats (depending on what the art is). There is not really any decent vector editing program for Linux at the moment, unfortunately. (Yes, I know about Sketch, Sodipodi, etc.) There are a lot of things that can be done outside of Illustrator, however. Designing desktop backgrounds, making sure the themes work correctly, coming up with ideas for icons, suggesting requests, keeping track of wish lists, and... helping out with writing the guides (*smile*) are all quick examples of areas where participation would be greatly appreciated. Garrett From gavin.henry at magicfx.co.uk Thu Oct 2 16:29:15 2003 From: gavin.henry at magicfx.co.uk (G Henry) Date: Thu, 2 Oct 2003 17:29:15 +0100 Subject: artwork project In-Reply-To: <3F7C4DEE.2010705@redhat.com> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <3F7C4DEE.2010705@redhat.com> Message-ID: <200310021729.19728.gavin.henry@magicfx.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 02 Oct 2003 5:10 pm, Garrett LeSage wrote: > Gavin Henry wrote: > >Are there any guides etc or suggestions on what tools to use for creating > > and editing artwork for fedora? > > There are no guides yet. > > I use Illustrator on the Mac and the GIMP on my Linux box, so the > artwork is currently in those formats (depending on what the art is). > There is not really any decent vector editing program for Linux at the > moment, unfortunately. (Yes, I know about Sketch, Sodipodi, etc.) > > There are a lot of things that can be done outside of Illustrator, > however. Designing desktop backgrounds, making sure the themes work > correctly, coming up with ideas for icons, suggesting requests, keeping > track of wish lists, and... helping out with writing the guides > (*smile*) are all quick examples of areas where participation would be > greatly appreciated. Gimp is tough going sometimes, as it's all over the place (My opinion), I was just wondering if there were some I haven't heard of. Have you got any guides started? I would like to do what I can. > Garrett > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list - -- Regards Trying to be a RHCE http://www.magicfx.co.uk http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fFJegNqd7Kng8UoRAj1+AJ4jNnfZ0mVPcoRg026jDRZ0THpErwCgmp/+ UzplpYXxqX9Fbobt8jOs90Q= =TlR8 -----END PGP SIGNATURE----- From smoogen at lanl.gov Thu Oct 2 17:08:25 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 02 Oct 2003 11:08:25 -0600 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: References: <1065032789.11637.179.camel@poincare.devel.redhat.com> <1065045888.11637.264.camel@poincare.devel.redhat.com> <1065082080.1449.21.camel@teapot.felipe-alfaro.com> Message-ID: <1065114505.16652.8.camel@smoogen1.lanl.gov> On Thu, 2003-10-02 at 08:02, Chris Ricker wrote: > On Thu, 2 Oct 2003, Felipe Alfaro Solana wrote: > > > > There are a few defaults in Red Hat which could be tuned better -- for > > > example, last I looked, Red Hat randomly used a different default encryption > > > for tickets than any other MIT-derived Kerberos, which makes things "fun" if > > > you have, say, Solaris and Red Hat around. Good luck designing a GUI which > > > can walk admins through diagnosing that ;-) > > > > Don't know what are you talking about, but I've several boxes running on > > Red Hat (with MIT Kerberos) and two other with SuSE Linux 8.2 (running > > Heimdal) and they are totally and seamlessly interoperable. > > MIT Kerberos, as downloaded from MIT, uses des3-hmac-sha1 for key > encryption, and that's what most other MIT derivatives (like Solaris) use. > RH for some reason changes that to des-cbc-crc (which is a weaker > encryption). Some things go "Boom!" when trying to interoperate between the > two as a result. > I think there is a lower amount of paperwork (or there was) for shipping with des-cbc-crc than des3-hmac-sha1 -- 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 pcompton at proteinmedia.com Thu Oct 2 17:10:39 2003 From: pcompton at proteinmedia.com (Phillip Compton) Date: Thu, 02 Oct 2003 13:10:39 -0400 Subject: artwork project In-Reply-To: <200310021729.19728.gavin.henry@magicfx.co.uk> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <3F7C4DEE.2010705@redhat.com> <200310021729.19728.gavin.henry@magicfx.co.uk> Message-ID: <1065114639.3057.2.camel@GreenTea> On Thu, 2003-10-02 at 12:29, G Henry wrote: > > Gimp is tough going sometimes, as it's all over the place (My opinion), I was > just wondering if there were some I haven't heard of. > Have you tried the development branch? 1.3.20 works great for me. It's available from the fedora.us repo (unstable although w/ the upcoming pre-releases it will probably move to testing). It's named gimp2, so it can safely be installed along side the stable branch. Phil From gavin.henry at magicfx.co.uk Thu Oct 2 17:22:24 2003 From: gavin.henry at magicfx.co.uk (G Henry) Date: Thu, 2 Oct 2003 18:22:24 +0100 Subject: artwork project In-Reply-To: <1065114639.3057.2.camel@GreenTea> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <200310021729.19728.gavin.henry@magicfx.co.uk> <1065114639.3057.2.camel@GreenTea> Message-ID: <200310021822.25961.gavin.henry@magicfx.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 02 Oct 2003 6:10 pm, Phillip Compton wrote: > On Thu, 2003-10-02 at 12:29, G Henry wrote: > > Gimp is tough going sometimes, as it's all over the place (My opinion), I > > was just wondering if there were some I haven't heard of. > > Have you tried the development branch? 1.3.20 works great for me. It's > available from the fedora.us repo (unstable although w/ the upcoming > pre-releases it will probably move to testing). It's named gimp2, so it > can safely be installed along side the stable branch. > > > Phil > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list Will give it a shot. Is it rpm and does it install on RH9, as I have got fedora installed yet. (Don't ask, I know, strange when I want to help the project) - -- Regards Trying to be a RHCE http://www.magicfx.co.uk http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fF7QgNqd7Kng8UoRAqtEAJwLIhw2wCqwLX0P+wgIQzYerZAx9ACfZddz vFI/In/fFLLTqvqAIlLbzE8= =5sal -----END PGP SIGNATURE----- From pcompton at proteinmedia.com Thu Oct 2 17:31:22 2003 From: pcompton at proteinmedia.com (Phillip Compton) Date: Thu, 02 Oct 2003 13:31:22 -0400 Subject: artwork project In-Reply-To: <200310021822.25961.gavin.henry@magicfx.co.uk> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <200310021729.19728.gavin.henry@magicfx.co.uk> <1065114639.3057.2.camel@GreenTea> <200310021822.25961.gavin.henry@magicfx.co.uk> Message-ID: <1065115882.3057.7.camel@GreenTea> On Thu, 2003-10-02 at 13:22, G Henry wrote: > > Have you tried the development branch? 1.3.20 works great for me. It's > > available from the fedora.us repo (unstable although w/ the upcoming > > pre-releases it will probably move to testing). It's named gimp2, so it > > can safely be installed along side the stable branch. > > Will give it a shot. Is it rpm and does it install on RH9, as I have got > fedora installed yet. (Don't ask, I know, strange when I want to help the > project) > The RH9 repo has: http://download.fedora.us/fedora/redhat/9/i386/RPMS.unstable/gimp2-1.3.18-0.fdr.5.rh90.i386.rpm Severn1 repo has: http://download.fedora.us/fedora/redhat/9.0.93/i386/RPMS.unstable/gimp2-1.3.20-0.fdr.1.rh90.93.i386.rpm and hopefully, it will be recompiled shortly for the Severn2 repo. Phil From ted at cypress.com Thu Oct 2 17:42:37 2003 From: ted at cypress.com (Thomas Dodd) Date: Thu, 02 Oct 2003 12:42:37 -0500 Subject: Kind request: fix your packages In-Reply-To: <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> Message-ID: <3F7C638D.7050206@cypress.com> Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 01 Oct 2003 15:34:32 -0400, Sean Middleditch wrote: > > >>No, you need to actually do the work of the configure script (perhaps >>you should actually use the app's configure script) - detect the >>individual bits in the system. Otherwise your package is broken. > > > What you describe is a maintenance nightmare. Assume an application > wants aspell >= 0.50, but distribution B provides only aspell 0.30. A > versioned build requirement on aspell >= 0.50 won't suffice, because > the package won't build on B. But there is a configure switch to > disable aspell support. So, what we can do is either examine aspell > version somehow, e.g. with > > $(rpm -q --qf "%{version}" aspell) > > or check a file like redhat-release. > > You're asking for completely generic rpms where the user, who has > upgraded a component way beyond the version which was shipped with the > original distribution, does not need to supply optional rpmbuild > parameters (such as --define _with_aspell=1) for a src.rpm to build > _with_ support for that optional component. Add macros to the spec near the begining for the distros/version _you_support. Then include usage in the instruction on building your opackage. so they need only '--define RHL7.3=1' , '--define RHEL3=1', or '--define MDK9=1'. That give you the same result of using redhat-release, package or file, and the ability to support more distributions at the same time. Each of the above defines set orther such as _with_aspell_0.3, or _with_aspell_0.5. These can then be overridden but the user easily as well. So you could more easily build for an older distro with a newer version of library. I think Mike Harris does a really good job of this for XFree86, and the kernel spec is getting there. The spec file should not be doing RPM querries or checking files. Perhaps I want to build a RHL7.3 RPM on my RHL9 box? If /etc/redhat-release is used, I get RHL9 versions regardless. If macros are used I can tell rpm easily to default to RHL7.3, use adifferent gcc, and alrternate libs as desired. -Thomas From jgreen at shell.datasync.com Thu Oct 2 18:16:43 2003 From: jgreen at shell.datasync.com (Jim) Date: Thu, 2 Oct 2003 13:16:43 -0500 (CDT) Subject: alpha architecture Message-ID: I have the HP edition of RH7.2 installed on a 21164 533Mhz pc164lx. All is well with the system and I have had no problems except that there are no software updates/upgrades to the latest versions of applications I need such as postgresql/php/apache/ssl etc. Then I ran across the Fedora project and noticed that the latest alpha rpm's for these applications were availible for download. The problem is that they don't work on the 7.2 release and rpm -Uvh for the packages I need give me countless failed deps as I expected they would. Will there be an upcomming alpha iso release for the latest redhat version? If not, I would like to port an updated rh release for the alpha architecture. If any one is doing this already or if anybody needs help doing this I'd be pleased to help out. If someone is already doing this could you please point me in the right direction? Thanks, Jimmy Green From tfox at redhat.com Thu Oct 2 18:45:38 2003 From: tfox at redhat.com (Tammy Fox) Date: Thu, 2 Oct 2003 14:45:38 -0400 Subject: Developer's Guide In-Reply-To: <1064520797.28962.28.camel@guava.bamdad.org> References: <1064520797.28962.28.camel@guava.bamdad.org> Message-ID: <20031002184538.GD21640@redhat.com> I applied most of your changes. The one I didn't apply was the one about CVS. Since we don't have the infrastructure to give external users accounts on CVS yet, I don't want to imply that in the docs. Instead, I added a note that says anonymous access does not give you write permissions. The changes should appear on the website shortly. Thanks for the patch, Tammy On Thu, Sep 25, 2003 at 11:43:18PM +0330, Roozbeh Pournader wrote: > Attached is a suggested patch for the Developer's Guide document, > against the current version in CVS. > > One issue I didn't patch, is that 'epoch' is never explained in the > document, although it's referenced twice. It certainly needs to be > written about, since there are people who don't know what it is (I > didn't). > > Changes are: > > 1. Fixed a typo in the legal notice. > 2. Explained that anonymous access, as specified in the CVS guidelines, > is not enough for changing the files on the server. > 3. Mentioned that the Guidelines on RPM should be used as a checklist > (almost all of its items were already explained elsewhere). > 4. Mentioned that 'all' of the criteria should be met for a Beta > Exception (was I right?) > > roozbeh > -- From garrett at redhat.com Thu Oct 2 19:03:15 2003 From: garrett at redhat.com (Garrett LeSage) Date: Thu, 02 Oct 2003 15:03:15 -0400 Subject: artwork project In-Reply-To: <1065114639.3057.2.camel@GreenTea> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <3F7C4DEE.2010705@redhat.com> <200310021729.19728.gavin.henry@magicfx.co.uk> <1065114639.3057.2.camel@GreenTea> Message-ID: <3F7C7673.9030807@redhat.com> Phillip Compton wrote: >On Thu, 2003-10-02 at 12:29, G Henry wrote: > > >>Gimp is tough going sometimes, as it's all over the place (My opinion), I was >>just wondering if there were some I haven't heard of. >> >> > >Have you tried the development branch? 1.3.20 works great for me. It's >available from the fedora.us repo (unstable although w/ the upcoming >pre-releases it will probably move to testing). It's named gimp2, so it >can safely be installed along side the stable branch. > > It took me a while to switch to Gimp 1.3.x (from Gimp 1.2.x), but I'm finally using it despite a number of quirks. It's pretty nice, and getting better. It's great that it is available in the fedora.us repo. Garrett From garrett at redhat.com Thu Oct 2 19:03:37 2003 From: garrett at redhat.com (Garrett LeSage) Date: Thu, 02 Oct 2003 15:03:37 -0400 Subject: artwork project In-Reply-To: <200310021729.19728.gavin.henry@magicfx.co.uk> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <3F7C4DEE.2010705@redhat.com> <200310021729.19728.gavin.henry@magicfx.co.uk> Message-ID: <3F7C7689.3020009@redhat.com> G Henry wrote: > Gimp is tough going sometimes, as it's all over the place (My > opinion), I was > just wondering if there were some I haven't heard of. For Linux, basically, there's GIMP and only GIMP. It's actually a great program, once you get used to the quirks. I've been using it for a number of years now (since around 1995 really). The way I cope with the GIMP's UI is by opening it on its own virtual workspace and using sloppy focus. I also have a few custom keybindings to often used things to help speed up the process (and to avoid the multi-nested right-mouse menus a little bit). Also, having a tablet can help with some procedures, although I need to get mine working again (upgrading the kernel or XFree86 often breaks support unfortunately, as the kernel driver does things it shouldn't do, for no reason). > Have you got any guides started? Nope; not yet. > I would like to do what I can. Thanks! Garrett From goeran at uddeborg.se Thu Oct 2 19:33:13 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Thu, 2 Oct 2003 21:33:13 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> Message-ID: <16252.32121.603795.514394@uebn.uddeborg.se> Sean Middleditch writes: > Redhat-release doesn't tell you anything about the version of > aspell installed. ... > if I happen to upgrade aspell on my own, and > your broken package is looking for my OS release instead of the actual > aspell package... what then again is the point of actually having > dependencies? Why not just make everything a "Distro-X.Y" package, and > forget dependencies, since we know which software versions Distro-X.Y > has? I agree that relying on redhat-release for anything seems rather dangerous. Not much would break if I removed the package altogether; a little piece in rc.sysinit would give an error message, that's all. Dependencies should accurately reflect what actually is needed, not the bundling of versions in a particular release. > If the software can use aspell, but has a switch to disable it, the > software is badly designed, because it creates an unfavorable > situation. I want to disagree a bit there. There could be good reasons to make it possible to compile with and without a feature to support different environments. The software maybe uses aspell only for some marginal feature, and has a lot of uses without it. In that case, it could make sense to have two different branches of packages, one with and one without aspell dependency. Then the package name should reflect the real difference, aspell or no aspell. If it does, I know that is the point, and I can make a decision if I want to upgrade aspell to a version from a more recent distribution, consider what other dependencies that would affect, or if I want to go for the version with a somewhat reduced functionality. If the package branches instead point at two versions of RH/FC which just happen to be before and after apsell was upgraded, I won't know this. I won't know what the difference in functionality is, and I won't have the information for a logical decision. From jjneely at pams.ncsu.edu Thu Oct 2 19:38:55 2003 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 2 Oct 2003 15:38:55 -0400 Subject: I volunteer In-Reply-To: <20030925214200.GY26859@anduril.pams.ncsu.edu> References: <20030925170103.GS26859@anduril.pams.ncsu.edu> <1064510855.24505.113.camel@opus> <20030925164654.D1425@devserv.devel.redhat.com> <1064523081.24505.143.camel@opus> <20030925214200.GY26859@anduril.pams.ncsu.edu> Message-ID: <20031002193855.GK26859@anduril.pams.ncsu.edu> Folks, So I'm still confused about this? Am I misunderstanding something? Do I need to clarify? Jack Neely > > So I have a question about the package naming guidelines. > > I'm using yum. > > A common thing is to push out a new kernel update for security reason 42 > and in the same push push out a complete set of openafs-* packages. The > new openafs-kernel packages work with the new kernel and require that > kernel version. > > With the Fedora naming scheme the openafs-kernel packages turn into > kernel-module-openafs-2.4.20-19.9 and do not require a kernel version. > > So unless there's another requires somewhere to require the provided > kernel-module-openafs = %{epoch}:%{version}-%{release} how does the new > OpenAFS package get upgraded? > > I guess in my case I can have openafs-client do the above require. > (Right now it only requires %{version}.) > > What if I was shipping something that was just a kernel module and not > other accompanying packages? > > Jack Neely > > > -- > Jack Neely > Realm Linux Administration and Development > PAMS Computer Operations at NC State University > GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From ms-nospam-0306 at arcor.de Thu Oct 2 20:17:06 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 2 Oct 2003 22:17:06 +0200 Subject: Kind request: fix your packages In-Reply-To: <3F7C638D.7050206@cypress.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <3F7C638D.7050206@cypress.com> Message-ID: <20031002221706.12b0585e.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 02 Oct 2003 12:42:37 -0500, Thomas Dodd wrote: > Add macros to the spec near the begining for the distros/version > _you_support. Then include usage in the instruction on building your > opackage. so they need only '--define RHL7.3=1' , '--define RHEL3=1', > or '--define MDK9=1'. That give you the same result of using > redhat-release, package or file, and the ability to support more > distributions at the same time. > The spec file should not be doing RPM querries or checking files. > Perhaps I want to build a RHL7.3 RPM on my RHL9 box? With the added problem of how to automate the builds? And what if a user doesn't define any variable at all? Would the build fail or default to the wrong target platform? I still think the better approach is to move conditional code as much as possible out of the spec file. Instead of building a binary rpm with --define RHEL3=1, you would set BUILD_RHEL3=1 and "rpmbuild --rebuild foo.src.rpm" as usual. The spec file would call an external script that either evaluates the BUILD_RHEL3 variable or falls back to evaluating /etc/redhat-release as a default. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fIfC0iMVcrivHFQRAtVFAJ0V/eEErCZdNbzQNUZ5aAQVwtdPigCfdnty Mn7voxQr/GCwyJH0ge/ZpvQ= =oBND -----END PGP SIGNATURE----- From elanthis at awesomeplay.com Thu Oct 2 20:17:40 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Thu, 02 Oct 2003 16:17:40 -0400 Subject: Kind request: fix your packages In-Reply-To: <16252.32121.603795.514394@uebn.uddeborg.se> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <16252.32121.603795.514394@uebn.uddeborg.se> Message-ID: <1065125860.3028.96.camel@support02.civic.twp.ypsilanti.mi.us> On Thu, 2003-10-02 at 15:33, G??ran Uddeborg wrote: > Sean Middleditch writes: > > If the software can use aspell, but has a switch to disable it, the > > software is badly designed, because it creates an unfavorable > > situation. > > I want to disagree a bit there. There could be good reasons to make > it possible to compile with and without a feature to support different > environments. The software maybe uses aspell only for some marginal > feature, and has a lot of uses without it. If it's a user-oriented feature, then it needs to be run-time configured, not compile-time configured. Users don't recompile apps, just admins and developers. (And those nuts using Gentoo ;-) In the event of portability, i.e., the package is intended to work on platforms that can't use aspell... well, that's not an issue for RPM packages for Linux. If the app can use aspell, and a user would expect that feature, or a user could feasibly want that feature, then it needs to be enabled, and the proper dependency made. If aspell can't have multiple incompatible versions simultaneously installed, package aspell with the app, or go help the the upstream authors learn how to develop software properly. (note: i'm not saying aspell is badly developed, as I don't know if it actually suffers from this problem; this discussion is hypothetical from my point of view.) > > In that case, it could make sense to have two different branches of > packages, one with and one without aspell dependency. Then the > package name should reflect the real difference, aspell or no aspell. > If it does, I know that is the point, and I can make a decision if I > want to upgrade aspell to a version from a more recent distribution, > consider what other dependencies that would affect, or if I want to go > for the version with a somewhat reduced functionality. This is still user hell. A user should never ever have to deal with this kind of non-sense. If a feature is optional, it needs to be run-time optional. Otherwise, we end up with a piece of software either having 20 different versions of the package for every set of possible options, or broken hacks like distro-release dependent packages. In situations like this, plugins are the way to go, or package add-ons, not two conflicting packages that are the exact same thing save one little piece. Yes, there are probably broken poorly developed libraries and broken poorly developed apps that depend on those, and yes, there are people who probably want those packaged. I dare hope those are the exception and not the rule; otherwise, we're all pretty much screwed so far as usability goes. ~,^ > > If the package branches instead point at two versions of RH/FC which > just happen to be before and after apsell was upgraded, I won't know > this. I won't know what the difference in functionality is, and I > won't have the information for a logical decision. > > > -- > 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 felipe_alfaro at linuxmail.org Thu Oct 2 21:01:41 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 02 Oct 2003 23:01:41 +0200 Subject: up2date: Too many open files? Message-ID: <1065128500.1401.7.camel@teapot.felipe-alfaro.com> I see the following errors when invoking up2date on a vanilla Fedora Core Test 2 subscribed to RHN (Severn Beta 2 and Severn Beta 2 Update channels): (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' New Up2date available Restarting up2date (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' (up2date:1432): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or directory (up2date:1432): libglade-WARNING **: could not convert string to type `GdkPixbuf' for property `logo' Traceback (most recent call last): File "/usr/share/rhn/up2date_client/gui.py", line 1865, in doRetrieval self.setRetrievalProgress) File "/usr/share/rhn/up2date_client/up2date.py", line 176, in getPackage buffer = rpcServer.doCall(repos.getPackage, pkg, msgCallback, progressCallback) File "/usr/share/rhn/up2date_client/rpcServer.py", line 143, in doCall up2dateAuth.updateLoginInfo() File "/usr/share/rhn/up2date_client/up2dateAuth.py", line 139, in updateLoginInfo loginInfo = login() File "/usr/share/rhn/up2date_client/up2dateAuth.py", line 112, in login loginInfo = rpcServer.doCall(server.up2date.login, systemId) File "/usr/share/rhn/up2date_client/rpcServer.py", line 117, in doCall log.log_me("A socket error occurred: %s, attempt #%s" % ( File "/usr/share/rhn/up2date_client/up2dateLog.py", line 31, in log_me self.write_log(s) File "/usr/share/rhn/up2date_client/up2dateLog.py", line 42, in write_log log_file = open(log_name, 'a') IOError: [Errno 24] Too many open files: '/var/log/up2date' These errors appear after up2date has upgraded itself to a newer version than the one that comes with plain Fedora Core Test 2. Then, up2date hangs. Any ideas? Should I bug a report? From ms-nospam-0306 at arcor.de Thu Oct 2 21:15:26 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 2 Oct 2003 23:15:26 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> Message-ID: <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 01 Oct 2003 22:24:48 -0400, Sean Middleditch wrote: > > $(rpm -q --qf "%{version}" aspell) > > > > or check a file like redhat-release. > > (pre-note: if I sound harsh, it's not personal - this whole problem > itself is just amazingly infuriating, and isn't a result of any one > person. my apologies afore-hand for a semi-heated email.) > > Which is broken. You are working around the problem instead of fixing > it. Redhat-release doesn't tell you anything about the version of > aspell installed. I quite often have tons of RPMs installed on a stock > RH (or now Fedora) system; if I happen to upgrade aspell on my own, and > your broken package is looking for my OS release instead of the actual > aspell package... what then again is the point of actually having > dependencies? Predictable builds. On the contrary, you aim at build sources which just pick up what's there, resulting in unpredictable, untested builds. > Why not just make everything a "Distro-X.Y" package, and > forget dependencies, since we know which software versions Distro-X.Y > has? You would still need a list of build requirements, so missing dependencies can be installed in incomplete build environments. Not everyone installs everything. > And no, installing new packages doesn't make me an "advanced user." Or, > at least it shouldn't - I guess I have to be thanks to packages being > made using a broken packaging method. Users should just be able to grab > any package online they want, and install it. This seems to refer to prebuilt (binary) packages and is an entirely different matter. > Or, heck, the new Fedora policy states that security holes will often be > fixed by providing a whole new version, not just backporting a fix. Is > fedora-release now supposed to also list all the legitimate security > patches it has so your can packages can have -fc1, -fc1-openssl4, > -fc1-db5, -fc1-openssl4-db5 variants and so on? No, fedora-release won't cover that. But build dependencies will need to deal with that. A security or bug-fix update, which is a new version instead of a backported fix, can require dependencies to be rebuilt and shipped as additional updates. Of course, all rebuilt packages will need to see new testing. > If the software can use aspell, but has a switch to disable it, the > software is badly designed, because it creates an unfavorable > situation. Why? Assume aspell support is truely optional. > If aspell has different ABIs for different versions, but > those versions can't be co-installed, then aspell is also broken. Depends on how early in the development stage of aspell we are. > You, > and other packagers, Side-note: I don't consider myself a packager. ;) > want to continue screwing over users with these > insane/broken development and packaging policies, versus just fixing the > problem once and being done with; libraries with changing ABIs need to > be co-installable, Hardly anyone prevents co-installation like libfoo 0.10 => package name "libfoo10", root directory /usr/lib/libfoo10 libfoo 0.20 => package name "libfoo20", root directory /usr/lib/libfoo20 when it is necessary and there are soname conflicts. It can be necessary when some dependencies stick to libfoo 0.10 while others require the newer libfoo 0.20. > and apps shouldn't have wildly different feature sets > that can't be changed/detected at runtime. If the app does depend on > libraries made by uncaring developers that can't keep a stable ABI, then > package the library with the app, and save the user the pain of dealing > with it; sure, it bloats the package size a bit, but that's the price to > pay for using poorly managed libraries. It is clever to share components where components can be shared. > If the app is compiled for an old aspell, but the user only has a newer, > incompatible aspell, then the user should just install the old aspell. ?? Automatic package dependencies enforce that. > Some apps use the newer one, some the old - this is the wonder of > versioned libraries, something we should be making use of, instead of > banishing users to DLL^w.so hell. Same here. If a binary package requires libfoo.so.2, the user just needs a package which provides libfoo.so.2. It doesn't matter whether the package is called foolib or libfoo or foo. It must contain/provide libfoo.so.2 and neither libfoo.so.1 nor libfoo.so.3. What you seem to refer to are broken explicit package dependencies where the packager was overambitious and added lots of package requirements explicitly instead of letting RPM determine dependencies automatically. That's causing Linux newbies to fail. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fJVu0iMVcrivHFQRAtapAJ0ci2OYYX15LDLgAxcin/PsK6rziACfX4uJ L84Qzce66QEwQ6nrp2/TPdM= =+WQ7 -----END PGP SIGNATURE----- From bill at noreboots.com Thu Oct 2 21:25:13 2003 From: bill at noreboots.com (Bill Anderson) Date: 02 Oct 2003 15:25:13 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: References: <1065042213.8017.47.camel@locutus> <1065045091.2847.53.camel@mentor.gurulabs.com> <1065107463.14032.64.camel@locutus> Message-ID: <1065129913.15489.27.camel@locutus> On Thu, 2003-10-02 at 09:36, Chris Ricker wrote: > On Thu, 2 Oct 2003, Bill Anderson wrote: > > > Kerberos does not do X11-forwarding, for example. Nor does Kerberos > > provide remote file copying (such as sftp and scp). Kerberos is > > authentication. SSH while possessing strong authentication is more than > > an authentication architecture. Thus, they are *different* and serve > > *different* purposes. > > Not exactly. You're right that Kerberos is an authentication protocol, but > MIT Kerberos also includes encrypted replacements for many common > applications: Those are apps that have been compiled/built to support Kerberos, they are not the same thing. CVS supports using SSH as a transport, does that mean CVS is part of SSH? Nope. rsync support using SSH as the transport as well. Again, that doesn't mean rsyn is a part of SSH. Of course, no ectra libraries are needed for rsync and cvs to use ssh as a transport, so you can install them with or w/o ssh. Only if you want to use it do you need to install it. ;^) > telnet > ftp > r* protocols > > If you're in a Kerberized environment, you can safely use Kerberos rcp, rsh, > etc., be encrypted and securely authenticated, and not need SSH at all.... No, only if you are in a kerberized environment that uses those kerberized apps. AS I have said, and the two of you apparently refuse to realize, is that SSH can utilize kerberos as well. You are implicitly saying that rcp/rsh/telnet for example are a mandatory part of kerberos utilizing networks. That is factually and materially incorrect. > About all that SSH offers that the Kerberized apps don't are the "weird > things" Dax mentioned, like port forwarding. Note, those are *apps* not kerberos supplying those. Use a kerberized ssh and you have no need for telnet, ssh, ftp, rlogin. rcp, et al.. And on top of it you get all the other nice things that SSH does. Mayeb it's me but I don't consider being able to log into a remote machine, launch a graphical app and have it display on my screen weird. Even if that machine is through several other "hops" of machines. I also don't consider scp and sftp weird. Nor do I consider beign able to use command line completion over an scp link weird. Maybe you do. So be it. But then, maybe we should just consider each other weird then. ;^) but again, "well if you don't count those other things, this does everything that other thing does" is not exactly intellectually honest. After all ... if you don't consider all exploits, holes, and insecure settings and design choices of Windows, it's just as secure as Linux. Or if you took away all the oppressive laws of Iran it's just as free as the US. Kerberos and SSh are not the same, and do not provide the same things, thus they are not replacements for each other. Unless, of course, you want to split hairs over the meaning of "is". ;) -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From gavin.henry at magicfx.co.uk Thu Oct 2 22:26:00 2003 From: gavin.henry at magicfx.co.uk (G Henry) Date: Thu, 2 Oct 2003 23:26:00 +0100 Subject: artwork project In-Reply-To: <1065115882.3057.7.camel@GreenTea> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <200310021822.25961.gavin.henry@magicfx.co.uk> <1065115882.3057.7.camel@GreenTea> Message-ID: <200310022326.01952.gavin.henry@magicfx.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 02 Oct 2003 6:31 pm, Phillip Compton wrote: > On Thu, 2003-10-02 at 13:22, G Henry wrote: > > > Have you tried the development branch? 1.3.20 works great for me. It's > > > available from the fedora.us repo (unstable although w/ the upcoming > > > pre-releases it will probably move to testing). It's named gimp2, so it > > > can safely be installed along side the stable branch. > > > > Will give it a shot. Is it rpm and does it install on RH9, as I have got > > fedora installed yet. (Don't ask, I know, strange when I want to help the > > project) > > The RH9 repo has: > http://download.fedora.us/fedora/redhat/9/i386/RPMS.unstable/gimp2-1.3.18-0 >.fdr.5.rh90.i386.rpm > > Severn1 repo has: > http://download.fedora.us/fedora/redhat/9.0.93/i386/RPMS.unstable/gimp2-1.3 >.20-0.fdr.1.rh90.93.i386.rpm > > and hopefully, it will be recompiled shortly for the Severn2 repo. > > > Phil > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list thanks, trying now. - -- Regards Trying to be a RHCE http://www.magicfx.co.uk http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fKX4gNqd7Kng8UoRAucpAKCBqCb8qBksEBB7/mfoOftv6WVRGACfR4Ql nEIiMhzuXjQFar2GpczJdmo= =Juvn -----END PGP SIGNATURE----- From Dax at GuruLabs.com Thu Oct 2 22:43:15 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Thu, 02 Oct 2003 16:43:15 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065129913.15489.27.camel@locutus> References: <1065042213.8017.47.camel@locutus> <1065045091.2847.53.camel@mentor.gurulabs.com> <1065107463.14032.64.camel@locutus> <1065129913.15489.27.camel@locutus> Message-ID: <1065134595.3164.79.camel@mentor.gurulabs.com> On Thu, 2003-10-02 at 15:25, Bill Anderson wrote: > Kerberos and SSh are not the same, and do not provide the same things, > thus they are not replacements for each other. Unless, of course, you > want to split hairs over the meaning of "is". ;) We seem to be going in circles here. Let me put it another way: A Kerberized environment provides 90% of the functionality of SSH. The "most common use" of SSH is 100% covered by Kerberos. The reverse is not true (SSH cannot replace 90% of Kerberos). "most common use" == "secure replacement" for telnet, r*, and ftp "secure replacement" == Encryption and Authentication (host and user) In other words, a Kerberized environment provides all the commonly used functionality of SSH on an intranet plus a whole whole lot more. The kerberized telnet/r*/ftp apps are part of and included with Kerberos. Nobody sets up Kerberos and then uses no Kerberized clients and daemons. I'm not saying ban SSH when Kerberos is in use, what I am saying is this: * "I don't need Kerberos 'cause I've got SSH" argument is a non-starter (I'm not saying you said this) * The need for SSH in a Kerberos environment is greatly diminished (this seems to be the current point of contention) * You pleaded to be able to install a kerberos-less install. Please quantify (guestimate is OK) what you except the gains to be. (going back to your original statement) Dax Kelson From blizzard at redhat.com Thu Oct 2 22:38:17 2003 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 02 Oct 2003 18:38:17 -0400 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <3F7CA8D9.20309@redhat.com> Cosmic Flo wrote: > - mozilla is only configured for US (language for web page, interface), > the selected language at install have no importance. Right now I don't have any of the translations included in the 1.4 build in fedora. Looking to fix that very soon. --Chris From behdad at cs.toronto.edu Thu Oct 2 22:54:04 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Thu, 2 Oct 2003 18:54:04 -0400 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: <1065027206.2146.1.camel@binkley> References: <1065016443.6301.37.camel@locutus> <1065023030.2568.24.camel@mentor.gurulabs.com> <1065025356.11637.74.camel@poincare.devel.redhat.com> <1065027206.2146.1.camel@binkley> Message-ID: On Wed, 1 Oct 2003, seth vidal wrote: > > > Thought question ... most of the above is present currently > > but takes a real expert to get going. > > > > What needs to be done to make it possible so that, given say, > > a network of 50 workstations, someone who has never done > > it before could get such a network going in a day? > > three items that would make a huge difference to me: > > 1. nfsv4 to be complete and in the kernel :) > 2. kdcs not be such a nightmare to setup > 3. kdcs not be such a nightmare to understand > 4. ldap tweaking be documented a bit more (though I know dax kelson did > a lot of documenting on openldap and it looks quite good - might want to > include those somewhere in fedora-core) Perhaps one more: 5. have spell-checkers correct the number of items in the list. > -sv From skvidal at phy.duke.edu Thu Oct 2 23:34:14 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Oct 2003 19:34:14 -0400 Subject: Network nirvana [Re: Since Fedora is not aimed at enterpise/business ..] In-Reply-To: References: <1065016443.6301.37.camel@locutus> <1065023030.2568.24.camel@mentor.gurulabs.com> <1065025356.11637.74.camel@poincare.devel.redhat.com> <1065027206.2146.1.camel@binkley> Message-ID: <1065137653.8601.0.camel@binkley> On Thu, 2003-10-02 at 18:54, Behdad Esfahbod wrote: > On Wed, 1 Oct 2003, seth vidal wrote: > Perhaps one more: > > 5. have spell-checkers correct the number of items in the list. > hehe. -sv From kaboom at gatech.edu Thu Oct 2 21:12:57 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 2 Oct 2003 15:12:57 -0600 (MDT) Subject: up2date: Too many open files? In-Reply-To: <1065128500.1401.7.camel@teapot.felipe-alfaro.com> References: <1065128500.1401.7.camel@teapot.felipe-alfaro.com> Message-ID: On Thu, 2 Oct 2003, Felipe Alfaro Solana wrote: > I see the following errors when invoking up2date on a vanilla Fedora > Core Test 2 subscribed to RHN (Severn Beta 2 and Severn Beta 2 Update > channels): > > (up2date:1432): libglade-WARNING **: Error loading image: Failed to open > file '/usr/share/pixmaps/redhat/shadowman-round-48.png': No such file or > directory > These errors appear after up2date has upgraded itself to a newer version > than the one that comes with plain Fedora Core Test 2. Then, up2date > hangs. > > Any ideas? Should I bug a report? 105677 It's not too many open files, it's a missing (well, moved) file later, chris From roozbeh at sharif.edu Fri Oct 3 00:51:50 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Fri, 03 Oct 2003 04:21:50 +0330 Subject: Developer's Guide In-Reply-To: <20031002184538.GD21640@redhat.com> References: <1064520797.28962.28.camel@guava.bamdad.org> <20031002184538.GD21640@redhat.com> Message-ID: <1065142309.12872.10.camel@guava.bamdad.org> On Thu, 2003-10-02 at 22:15, Tammy Fox wrote: > I applied most of your changes. The one I didn't apply was the one > about CVS. Since we don't have the infrastructure to give external > users accounts on CVS yet, I don't want to imply that in the > docs. Instead, I added a note that says anonymous access does not give > you write permissions. But the translators get CVS accounts... roozbeh From elanthis at awesomeplay.com Fri Oct 3 01:49:23 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Thu, 02 Oct 2003 21:49:23 -0400 Subject: Kind request: fix your packages In-Reply-To: <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> Message-ID: <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> On Thu, 2003-10-02 at 17:15, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 01 Oct 2003 22:24:48 -0400, Sean Middleditch wrote: > > > > $(rpm -q --qf "%{version}" aspell) > > > > > > or check a file like redhat-release. > > > > (pre-note: if I sound harsh, it's not personal - this whole problem > > itself is just amazingly infuriating, and isn't a result of any one > > person. my apologies afore-hand for a semi-heated email.) > > > > Which is broken. You are working around the problem instead of fixing > > it. Redhat-release doesn't tell you anything about the version of > > aspell installed. I quite often have tons of RPMs installed on a stock > > RH (or now Fedora) system; if I happen to upgrade aspell on my own, and > > your broken package is looking for my OS release instead of the actual > > aspell package... what then again is the point of actually having > > dependencies? > > Predictable builds. > > On the contrary, you aim at build sources which just pick up what's > there, resulting in unpredictable, untested builds. > > > Why not just make everything a "Distro-X.Y" package, and > > forget dependencies, since we know which software versions Distro-X.Y > > has? > > You would still need a list of build requirements, so missing > dependencies can be installed in incomplete build environments. Not > everyone installs everything. Right. But then you still can't detect errata packages and such when building based only on /etc/release. > > > And no, installing new packages doesn't make me an "advanced user." Or, > > at least it shouldn't - I guess I have to be thanks to packages being > > made using a broken packaging method. Users should just be able to grab > > any package online they want, and install it. > > This seems to refer to prebuilt (binary) packages and is an entirely > different matter. This then might be a source of our disagreement - I couldn't care less abotu building packages, I only care about the actual users installing them. ;-) > > > Or, heck, the new Fedora policy states that security holes will often be > > fixed by providing a whole new version, not just backporting a fix. Is > > fedora-release now supposed to also list all the legitimate security > > patches it has so your can packages can have -fc1, -fc1-openssl4, > > -fc1-db5, -fc1-openssl4-db5 variants and so on? > > No, fedora-release won't cover that. But build dependencies will need > to deal with that. A security or bug-fix update, which is a new > version instead of a backported fix, can require dependencies to be > rebuilt and shipped as additional updates. Of course, all rebuilt > packages will need to see new testing. Which is silly. If a library/component is upgraded, it must either be binary compatible (and thus not need rebuilt applications) or be co-installable (in which case a backported fix for the old library would be mandatory for a secure OS, but that's life.) If you really want to have to rebuild the system everytime the user coughs, perhaps you should be using Gentoo instead of Fedora... ;-) > > > If the software can use aspell, but has a switch to disable it, the > > software is badly designed, because it creates an unfavorable > > situation. > > Why? Assume aspell support is truely optional. Because it's completely insane to have to reinstall a whole different version of the app to 'enable' a feature. It's a lot less to do with technically possible or code correct, and a lot more to do with just it being a completely stupid way to design anything. If it's optional, make it a plugin or add-on, not something that conditionally built into or outof the app. It's like the difference between a wholly monolithic kernel or a kernel with modules. *yes*, there are cases the monolithic kernel is a better choice (embedded systems, say) but those aren't end-user systems like Fedora - they're built once and don't change. Apps aren't any different - if the app takes a monolithic approach, its design is broken. > > > If aspell has different ABIs for different versions, but > > those versions can't be co-installed, then aspell is also broken. > > Depends on how early in the development stage of aspell we are. This is true. But then, as a library author, if you know you have tons of apps depending on your ABI, it's rather good form to go thru the extra effort to keep it stable. You can add newer API's without removing old, and flush the deprecated stuff out every several releases, and move the soversion up while you're at it. You can have a pre-1.0 app with a soversion of 23.4.6; the soversion has *nothing* to do with release version of stability, only with interface version. > > > You, > > and other packagers, > > Side-note: I don't consider myself a packager. ;) Heheh, righty. On the same hand, I don't really consider myself a normal user, so we're evenly mismatched in this debate. ^,^ > > > want to continue screwing over users with these > > insane/broken development and packaging policies, versus just fixing the > > problem once and being done with; libraries with changing ABIs need to > > be co-installable, > > Hardly anyone prevents co-installation like > > libfoo 0.10 => package name "libfoo10", root directory /usr/lib/libfoo10 > libfoo 0.20 => package name "libfoo20", root directory /usr/lib/libfoo20 > > when it is necessary and there are soname conflicts. It can be > necessary when some dependencies stick to libfoo 0.10 while others > require the newer libfoo 0.20. Right... which is the solution to your "version of package depends on OS release" argument. If we both recognize the solution, what are we debating? ;-) > > > and apps shouldn't have wildly different feature sets > > that can't be changed/detected at runtime. If the app does depend on > > libraries made by uncaring developers that can't keep a stable ABI, then > > package the library with the app, and save the user the pain of dealing > > with it; sure, it bloats the package size a bit, but that's the price to > > pay for using poorly managed libraries. > > It is clever to share components where components can be shared. Where they *can*, yes. When they can't be shared, because sharing destabilizes the system, then its clever not to break things by sharing. ;-) > > > If the app is compiled for an old aspell, but the user only has a newer, > > incompatible aspell, then the user should just install the old aspell. > > ?? Automatic package dependencies enforce that. Right. > > > Some apps use the newer one, some the old - this is the wonder of > > versioned libraries, something we should be making use of, instead of > > banishing users to DLL^w.so hell. > > Same here. If a binary package requires libfoo.so.2, the user just > needs a package which provides libfoo.so.2. It doesn't matter whether > the package is called foolib or libfoo or foo. It must contain/provide > libfoo.so.2 and neither libfoo.so.1 nor libfoo.so.3. What you seem to > refer to are broken explicit package dependencies where the packager > was overambitious and added lots of package requirements explicitly > instead of letting RPM determine dependencies automatically. That's > causing Linux newbies to fail. Right, I was going off a bit on a tangent from the original discussion. Sorry. ^^; (Once I start, I never realize when I need to stop again.) > > - -- > Michael, who doesn't reply to top posts and complete quotes anymore. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQE/fJVu0iMVcrivHFQRAtapAJ0ci2OYYX15LDLgAxcin/PsK6rziACfX4uJ > L84Qzce66QEwQ6nrp2/TPdM= > =+WQ7 > -----END PGP SIGNATURE----- > > > -- > 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 jeff.johnson at wsm.com Fri Oct 3 02:39:50 2003 From: jeff.johnson at wsm.com (Jeff Johnson) Date: 02 Oct 2003 19:39:50 -0700 Subject: creating kernel-source rpm? Message-ID: <1065148790.30961.11.camel@eljefe.wsm.com> Greetings, I am building custom kernel rpms using the kernel-src rpm. I have added patches, edited the spec file and am able to make i686 kernel rpms with no problems. I am unable to discover how to create the corresponding kernel-source rpm to the i686 version built. For my purposes I need to create both. If I do (from /usr/src/redhat) rpmbuild -ba --target=i686 SPECS/mykernel.spec I get RPMS/i686/kernel-mykernel-i686.rpm SRPMS/kernel-mykernel-src.rpm Can anyone tell me how the corresponding kernel-source-mykernel.rpm can be generated? Thanks! Jeff -- Jeff Johnson Western Scientific, Inc "Rome did not create a great Empire by holding meetings. They did it by killing all those who opposed them." From nando at ccrma.Stanford.EDU Fri Oct 3 02:48:49 2003 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 02 Oct 2003 19:48:49 -0700 Subject: creating kernel-source rpm? In-Reply-To: <1065148790.30961.11.camel@eljefe.wsm.com> References: <1065148790.30961.11.camel@eljefe.wsm.com> Message-ID: <1065149329.16415.121.camel@cmn37.stanford.edu> > If I do (from /usr/src/redhat) > > rpmbuild -ba --target=i686 SPECS/mykernel.spec > > I get RPMS/i686/kernel-mykernel-i686.rpm > SRPMS/kernel-mykernel-src.rpm > > Can anyone tell me how the corresponding kernel-source-mykernel.rpm can > be generated? rpmbuild -ba SPECS/mykernel.spec This will generate an i386 kernel, docs and the kernel-source package. -- Fernando From axel at banzais.org Fri Oct 3 08:29:07 2003 From: axel at banzais.org (axel c) Date: Fri, 03 Oct 2003 10:29:07 +0200 Subject: video player in fedora? In-Reply-To: <1065091163.6837.15.camel@faro.stuttgart.redhat.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <1065091163.6837.15.camel@faro.stuttgart.redhat.com> Message-ID: <1065169747.4156.2.camel@mao.ikp.org> I noticed there's currently no video player available in fedora. I was wondering if i could make packages for xine or mplayer, but since these packages have a shitload of optional dependencies, i'd like to know what is the policy for 'hard' and 'soft' dependencies in packages. Also, do these programs bring licensing issues? (iirc mplayer and xine use win32 video codecs for DivX/etc decompression). Thanks -- axel c From buildsys at porkchop.devel.redhat.com Fri Oct 3 09:00:05 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Fri, 3 Oct 2003 05:00:05 -0400 Subject: rawhide report: 20031003 changes Message-ID: <200310030900.h93905n31146@porkchop.devel.redhat.com> From matthias at rpmforge.net Fri Oct 3 10:12:13 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Fri, 3 Oct 2003 12:12:13 +0200 Subject: rawhide report: 20031003 changes In-Reply-To: <200310030900.h93905n31146@porkchop.devel.redhat.com> References: <200310030900.h93905n31146@porkchop.devel.redhat.com> Message-ID: <20031003121213.17827320.matthias@rpmforge.net> Build System wrote : > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list I can't help myself finding this report kind of terse :-) Good idea though, I hope it'll be working soon! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 0.94 (Severn) - Linux kernel 2.4.22-20.1.2024.2.36.nptl Load : 0.09 0.08 0.09 From kmaraas at broadpark.no Fri Oct 3 12:36:33 2003 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Fri, 03 Oct 2003 14:36:33 +0200 Subject: New locale for Norwegian =?ISO-8859-1?Q?bokm=E5l?= Message-ID: <1065184592.3469.2.camel@localhost.localdomain> Hi. We've had a report in bugzilla for some time now where we request a new locale being added for Norwegian bokm??l. We currently have no_NO which is being replaced with nb_NO. The bugreport is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83276 Any chance of getting this in during this cycle so I can start moving the translations to nb_NO as soon as possible? I'd appreciate help with renaming the files in CVS as well to ease the transition. Cheers Kjartan From ms-nospam-0306 at arcor.de Fri Oct 3 13:41:57 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 3 Oct 2003 15:41:57 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> Message-ID: <20031003154157.75e46420.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 02 Oct 2003 21:49:23 -0400, Sean Middleditch wrote: > > Predictable builds. > > > > On the contrary, you aim at build sources which just pick up what's > > there, resulting in unpredictable, untested builds. > > > > > Why not just make everything a "Distro-X.Y" package, and > > > forget dependencies, since we know which software versions Distro-X.Y > > > has? > > > > You would still need a list of build requirements, so missing > > dependencies can be installed in incomplete build environments. Not > > everyone installs everything. > > Right. But then you still can't detect errata packages and such when > building based only on /etc/release. Not necessary, because errata packages are backported fixes, not feature upgrades. > > This seems to refer to prebuilt (binary) packages and is an entirely > > different matter. > > This then might be a source of our disagreement - I couldn't care less > abotu building packages, I only care about the actual users installing > them. ;-) Doesn't matter. It's the packager's (distributor's) responsibility to provide a working set of dependencies. Those people, who send newbies to rpmseek.com where the newbies chooses a prebuilt package for an arbitrary distribution and fails to locate missing dependencies, are nuts and are not helpful. It is much more helpful to point newbies to repositories and tools like Synaptic. > > > Or, heck, the new Fedora policy states that security holes will often be > > > fixed by providing a whole new version, not just backporting a fix. Is > > > fedora-release now supposed to also list all the legitimate security > > > patches it has so your can packages can have -fc1, -fc1-openssl4, > > > -fc1-db5, -fc1-openssl4-db5 variants and so on? > > > > No, fedora-release won't cover that. But build dependencies will need > > to deal with that. A security or bug-fix update, which is a new > > version instead of a backported fix, can require dependencies to be > > rebuilt and shipped as additional updates. Of course, all rebuilt > > packages will need to see new testing. > > Which is silly. If a library/component is upgraded, it must either be > binary compatible (and thus not need rebuilt applications) or be > co-installable (in which case a backported fix for the old library would > be mandatory for a secure OS, but that's life.) That contradicts itself. Why would you leave around the old library version if there is security hole in it? No need to keep the old one and co-install the new one. The security hole must be fixed, no matter how. Whether fixes are backported or applied as version upgrades, is a matter of feasibility. > If you really want to have to rebuild the system everytime the user > coughs, perhaps you should be using Gentoo instead of Fedora... ;-) You're exaggerating. Smiley noted. > > > If the software can use aspell, but has a switch to disable it, the > > > software is badly designed, because it creates an unfavorable > > > situation. > > > > Why? Assume aspell support is truely optional. > > Because it's completely insane to have to reinstall a whole different > version of the app to 'enable' a feature. Depends on whether this "aspell support" is a completely separate plug-in or whether it is tied into the application. In either case, it likely comes together with the source code for the application and is built from within the same src.rpm. If the target platform doesn't suffice, you can either disable optional features or not build the app at all. > It's a lot less to do with > technically possible or code correct, and a lot more to do with just it > being a completely stupid way to design anything. If it's optional, > make it a plugin or add-on, not something that conditionally built into > or outof the app. See above. You can only build that feature if build requirements are met. > [...] But then, as a library author, if you know you have tons > of apps depending on your ABI, it's rather good form to go thru the > extra effort to keep it stable. You can add newer API's without > removing old, and flush the deprecated stuff out every several releases, > and move the soversion up while you're at it. This doesn't change a thing. The case we're discussing is a new app which uses the new API and doesn't build with the old API. It requires the new app to be backwards compatible, too, i.e. to use the old deprecated API. And at some point in time, the API user needs to switch to the current interface, because the old API is dropped. > You can have a pre-1.0 > app with a soversion of 23.4.6; the soversion has *nothing* to do with > release version of stability, only with interface version. Tell that the typical rpm-dependency-hell troll. ;o) - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fXyl0iMVcrivHFQRAkpgAJ9c4RcluvA0ig6LrlXqWmsokoMo8wCdHQd3 9d8XAAJtG9QdugqdUyFQBEw= =fmQY -----END PGP SIGNATURE----- From johnsonm at redhat.com Fri Oct 3 13:53:34 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 3 Oct 2003 09:53:34 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065125860.3028.96.camel@support02.civic.twp.ypsilanti.mi.us>; from elanthis@awesomeplay.com on Thu, Oct 02, 2003 at 04:17:40PM -0400 References: <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <16252.32121.603795.514394@uebn.uddeborg.se> <1065125860.3028.96.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <20031003095334.B13926@devserv.devel.redhat.com> On Thu, Oct 02, 2003 at 04:17:40PM -0400, Sean Middleditch wrote: > If it's a user-oriented feature, then it needs to be run-time > configured, not compile-time configured. I'd like to follow up to say that this statement expresses very well the "Red Hat Way", a gestalt that we're still striving for 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 otaylor at redhat.com Fri Oct 3 14:01:14 2003 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 03 Oct 2003 10:01:14 -0400 Subject: New locale for Norwegian =?ISO-8859-1?Q?bokm=E5l?= In-Reply-To: <1065184592.3469.2.camel@localhost.localdomain> References: <1065184592.3469.2.camel@localhost.localdomain> Message-ID: <1065189673.12331.33.camel@poincare.devel.redhat.com> On Fri, 2003-10-03 at 08:36, Kjartan Maraas wrote: > Hi. > > We've had a report in bugzilla for some time now where we request a new > locale being added for Norwegian bokm?l. We currently have no_NO which > is being replaced with nb_NO. The bugreport is here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83276 > > Any chance of getting this in during this cycle so I can start moving > the translations to nb_NO as soon as possible? I'd appreciate help with > renaming the files in CVS as well to ease the transition. I'd suggest that this really needs to be resolved upstream first; once changes are made upstream, it should be easy to get Jakub to backport them into our package, but deviation from upstream would be bad. If things are still undecided at the upstream level, another reminder mail to libc-alpha might help. Regards, Owen From elanthis at awesomeplay.com Fri Oct 3 14:11:46 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 03 Oct 2003 10:11:46 -0400 Subject: Kind request: fix your packages In-Reply-To: <20031003154157.75e46420.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> Message-ID: <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2003-10-03 at 09:41, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 02 Oct 2003 21:49:23 -0400, Sean Middleditch wrote: > > Right. But then you still can't detect errata packages and such when > > building based only on /etc/release. > > Not necessary, because errata packages are backported fixes, not > feature upgrades. Not in Fedora. It's been mentioned several times on the list, and on the site iirc, that security updates will simply be new packaged versions of the upstream packages. If the only security update for a package involves a bunch of other changes as well, then you get those as well. > > > > This seems to refer to prebuilt (binary) packages and is an entirely > > > different matter. > > > > This then might be a source of our disagreement - I couldn't care less > > abotu building packages, I only care about the actual users installing > > them. ;-) > > Doesn't matter. It's the packager's (distributor's) responsibility to > provide a working set of dependencies. Those people, who send newbies > to rpmseek.com where the newbies chooses a prebuilt package for an > arbitrary distribution and fails to locate missing dependencies, are > nuts and are not helpful. It is much more helpful to point newbies to > repositories and tools like Synaptic. The only reason its "nuts" is because packages are made with no thought of real users. It shouldn't have to be nuts. It should just up and work. It's definitely possible to do, if people bother putting forth the effort instead of taking the cheap way out packaging. Take a look at the autopackage system, its rather amazing, and is sort of working proof that it's possible. ~,^ > > Which is silly. If a library/component is upgraded, it must either be > > binary compatible (and thus not need rebuilt applications) or be > > co-installable (in which case a backported fix for the old library would > > be mandatory for a secure OS, but that's life.) > > That contradicts itself. Why would you leave around the old library > version if there is security hole in it? No need to keep the old one > and co-install the new one. The security hole must be fixed, no matter > how. Whether fixes are backported or applied as version upgrades, is a > matter of feasibility. My point is, if you need to get a new library, it should *never* break anything. It's either compatible, in which case its a waste of time to rebuild packages for it, or its not compatible, in which case you'd need to modify the code for the app and release a new version, which isn't a packaging issue. > > > If you really want to have to rebuild the system everytime the user > > coughs, perhaps you should be using Gentoo instead of Fedora... ;-) > > You're exaggerating. Smiley noted. Yes, but only slightly :P > > > > > If the software can use aspell, but has a switch to disable it, the > > > > software is badly designed, because it creates an unfavorable > > > > situation. > > > > > > Why? Assume aspell support is truely optional. > > > > Because it's completely insane to have to reinstall a whole different > > version of the app to 'enable' a feature. > > Depends on whether this "aspell support" is a completely separate > plug-in or whether it is tied into the application. In either case, it > likely comes together with the source code for the application and is > built from within the same src.rpm. If the target platform doesn't > suffice, you can either disable optional features or not build the app > at all. This is honestly something more in the realm of application design that packaging, I'll admit - packagers shouldn't encourage sloppy design, tho. ;-) A single source set *can* be made into several RPMs. I'm not sure how well RPM supports file over-rides, but some clever packaging could avoid the problem for users even when the app was designed by someone who enjoys watching users cry. ;-) > > > It's a lot less to do with > > technically possible or code correct, and a lot more to do with just it > > being a completely stupid way to design anything. If it's optional, > > make it a plugin or add-on, not something that conditionally built into > > or outof the app. > > See above. You can only build that feature if build requirements are > met. As you've noted, users can always install dependencies. So can developers. Developers are probably more capable of it. So your package depends on something only in RH8+, but you want it to work in RH7 too? Just depend on the devel files for the newer version. People building on RH7 can grab it and build on in bliss, and you as a packager don't need to waste time making silly hacks. ^,^ > > > [...] But then, as a library author, if you know you have tons > > of apps depending on your ABI, it's rather good form to go thru the > > extra effort to keep it stable. You can add newer API's without > > removing old, and flush the deprecated stuff out every several releases, > > and move the soversion up while you're at it. > > This doesn't change a thing. The case we're discussing is a new app > which uses the new API and doesn't build with the old API. It requires > the new app to be backwards compatible, too, i.e. to use the old > deprecated API. And at some point in time, the API user needs to > switch to the current interface, because the old API is dropped. Eh? This is not at all how this works... take a look at the GNOME libraries. GNOME2.4 libs support GNOME2.0, GNOME2.2, and GNOME2.4 interfaces. An app made for GNOME2.0 runs just fine on GNOME2.4, altho an app written for GNOME2.4 may make use of the newer versions of the APIs, and thus not run on 2.0 or 2.2. Older APIs are deprecated in newer releases, meaning they are still available, but generate warning when used. When GNOME3.0 comes out, all the deprecated APIs will be dropped - older apps can simply depend on the GNOME2.x libs, which will be coinstallable with GNOME3 (just like GNOME1.x apps can depend on GNOME1.x libs, which are co-installable with GNOME2). This is all just sane development practice. There is nothing stopping people from doing this other than ignorance and sloth. ;-) > > > You can have a pre-1.0 > > app with a soversion of 23.4.6; the soversion has *nothing* to do with > > release version of stability, only with interface version. > > Tell that the typical rpm-dependency-hell troll. ;o) RPM Dependency hell exists from two things - dependencies that never work out, because poorly made packages make it so some apps need one version, and other apps need another version, resulting in a situation where its impossible to install both sets of apps without rebuilding everything. The second situation is lack of an easy way to get dependencies; RH/FC has up2date, with up2date servers, apt servers, and yum servers. Those solve the second problem, assuming they don't make the first problem worse - which can only be solved by good packaging policies. This is something where I'd *love* to see an "official" RPM packaging policy similar to Debian. Debian isn't perfect by a long shot, but even with their 3,000+ packagers and 10,000+ packages they manage to avoid a lot of these problems, and that's including not only Debian, but all the highly modified Debian-based offsprings as well. it's not because dpkg is magic, but just because the packages are (usually) very well built. > > - -- > Michael, who doesn't reply to top posts and complete quotes anymore. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQE/fXyl0iMVcrivHFQRAkpgAJ9c4RcluvA0ig6LrlXqWmsokoMo8wCdHQd3 > 9d8XAAJtG9QdugqdUyFQBEw= > =fmQY > -----END PGP SIGNATURE----- > > > -- > 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 notting at redhat.com Fri Oct 3 14:56:10 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Oct 2003 10:56:10 -0400 Subject: rawhide report: 20031003 changes In-Reply-To: <20031003121213.17827320.matthias@rpmforge.net>; from matthias@rpmforge.net on Fri, Oct 03, 2003 at 12:12:13PM +0200 References: <200310030900.h93905n31146@porkchop.devel.redhat.com> <20031003121213.17827320.matthias@rpmforge.net> Message-ID: <20031003105610.C20364@devserv.devel.redhat.com> Matthias Saou (matthias at rpmforge.net) said: > I can't help myself finding this report kind of terse :-) > > Good idea though, I hope it'll be working soon! Well, it sent the diff between the last tree and the current tree. Of course, it broke and didn't build a current tree. So, no diff! :) Bill From Nicolas.Mailhot at laPoste.net Fri Oct 3 15:05:51 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 03 Oct 2003 17:05:51 +0200 Subject: rawhide report: 20031003 changes In-Reply-To: <20031003105610.C20364@devserv.devel.redhat.com> References: <200310030900.h93905n31146@porkchop.devel.redhat.com> <20031003121213.17827320.matthias@rpmforge.net> <20031003105610.C20364@devserv.devel.redhat.com> Message-ID: <1065193551.7603.0.camel@ulysse.olympe.o2t> Le ven 03/10/2003 ? 16:56, Bill Nottingham a ?crit : > Matthias Saou (matthias at rpmforge.net) said: > > I can't help myself finding this report kind of terse :-) > > > > Good idea though, I hope it'll be working soon! > > Well, it sent the diff between the last tree and the current tree. > Of course, it broke and didn't build a current tree. So, no diff! :) Do you mean the last tree also broke ? -- 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 wfm3 at hotmail.com Fri Oct 3 15:16:42 2003 From: wfm3 at hotmail.com (w fm3) Date: Fri, 03 Oct 2003 15:16:42 +0000 Subject: Open Office 1.1 suggestion Message-ID: It would be really cool if the standard install package could include something like the below by default http://www.kde-look.org/content/show.php?content=7131 just my .02 _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From ms-nospam-0306 at arcor.de Fri Oct 3 15:36:21 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 3 Oct 2003 17:36:21 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 03 Oct 2003 10:11:46 -0400, Sean Middleditch wrote: > > > Right. But then you still can't detect errata packages and such when > > > building based only on /etc/release. > > > > Not necessary, because errata packages are backported fixes, not > > feature upgrades. > > Not in Fedora. It's been mentioned several times on the list, and on > the site iirc, that security updates will simply be new packaged > versions of the upstream packages. Deadlock. I've commented on that earlier. Do you realize that when you fix security bugs with the release of new software versions it can make it necessary to rebuild dependencies? Whether or not that will be required depends on how compatible the new software version is (with regard to API and ABI, but also wrt details such as userspace file locations). > > It's the packager's (distributor's) responsibility to > > provide a working set of dependencies. Those people, who send newbies > > to rpmseek.com where the newbies chooses a prebuilt package for an > > arbitrary distribution and fails to locate missing dependencies, are > > nuts and are not helpful. It is much more helpful to point newbies to > > repositories and tools like Synaptic. > > The only reason its "nuts" is because packages are made with no thought > of real users. It shouldn't have to be nuts. It should just up and > work. Impossible mission. An individual package will never know *where* to get dependencies. It only knows *what* is missing. However, if the user makes use of package tools, the problem is solved. Back to your example, of a package requiring libfoo.so.23.4.6 (or similar), it will be entertaining to make the newbie understand that the file is provided by package libfoo-1.0 and not libfoo-0.9 or libfoo-2.0. > My point is, if you need to get a new library, it should *never* break > anything. It's either compatible, in which case its a waste of time to > rebuild packages for it, or its not compatible, in which case you'd need > to modify the code for the app and release a new version, which isn't a > packaging issue. Returning to backporting security-fixes in libraries, eh? Another loop in this discussion. It all boils down to feasibility of doing version upgrades of core components. > A single source set *can* be made into several RPMs. Happens often. > I'm not sure how > well RPM supports file over-rides, but some clever packaging could avoid > the problem for users even when the app was designed by someone who > enjoys watching users cry. ;-) Still, the app doesn't build if its build requirements aren't satisfied. Another loop in the discussion. > As you've noted, users can always install dependencies. So can > developers. Developers are probably more capable of it. So your > package depends on something only in RH8+, but you want it to work in > RH7 too? Just depend on the devel files for the newer version. People > building on RH7 can grab it and build on in bliss, and you as a packager > don't need to waste time making silly hacks. ^,^ With current tools and implementation of explicit versioned build requirements, that would cause the application to not build at all on an unmodified RH7 unless the src.rpm examines in detail what's there and what's not. Maybe we should go back to the early mails and restart there. ;) > > This doesn't change a thing. The case we're discussing is a new app > > which uses the new API and doesn't build with the old API. It requires > > the new app to be backwards compatible, too, i.e. to use the old > > deprecated API. And at some point in time, the API user needs to > > switch to the current interface, because the old API is dropped. > > Eh? This is not at all how this works... take a look at the GNOME > libraries. GNOME2.4 libs support GNOME2.0, GNOME2.2, and GNOME2.4 > interfaces. An app made for GNOME2.0 runs just fine on GNOME2.4, altho > an app written for GNOME2.4 may make use of the newer versions of the > APIs, and thus not run on 2.0 or 2.2. Only the latter case is relevant to this discussion. Assume parts of the app require GNOME 2.4, but the main part of the app doesn't depend on GNOME 2.x at all. The app will build and run everywhere except for the part that requires GNOME 2.4. Now make a package for all known target platforms, which builds automatically and enables/disables optional features depending on what build requirements are available. The fun starts when this requires more than simple checks of installed package versions (as outlined earlier). > RPM Dependency hell exists from two things - dependencies that never > work out, because poorly made packages make it so some apps need one > version, and other apps need another version, resulting in a situation > where its impossible to install both sets of apps without rebuilding > everything. Bring it to the point: _poorly made packages_, not just due to versioned dependencies, but also due to custom and distribution specific package names. > This is something where I'd *love* to see an "official" RPM packaging > policy similar to Debian. Debian isn't perfect by a long shot, but even > with their 3,000+ packagers and 10,000+ packages they manage to avoid a > lot of these problems, and that's including not only Debian, but all the > highly modified Debian-based offsprings as well. it's not because dpkg > is magic, but just because the packages are (usually) very well built. This would be good, but would require the major distributors to collaborate and adhere to such packaging policies also at the level of what compiler version to use and when to package what software versions. Sounds like impossible mission again. ;) There are more major distributions which use RPM, and which are not derived from eachother, than minor Debian derivatives. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD4DBQE/fZd10iMVcrivHFQRAkjZAJinTgHKhDsT7caqu0EUqmA3fIZHAJ9LT6o/ xjIfdBmrazD4sHk8iUd3XQ== =6px4 -----END PGP SIGNATURE----- From jensknutson at yahoo.com Fri Oct 3 15:53:22 2003 From: jensknutson at yahoo.com (Jens Knutson) Date: Fri, 3 Oct 2003 08:53:22 -0700 (PDT) Subject: Open Office 1.1 suggestion In-Reply-To: Message-ID: <20031003155322.99381.qmail@web14205.mail.yahoo.com> --- w fm3 wrote: > It would be really cool if the standard install package could include > > something like the below by default At the very least, what are the odds of including Ximian's nice icon set? - jck __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From elanthis at awesomeplay.com Fri Oct 3 16:04:35 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 03 Oct 2003 12:04:35 -0400 Subject: Kind request: fix your packages In-Reply-To: <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> Message-ID: <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2003-10-03 at 11:36, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 03 Oct 2003 10:11:46 -0400, Sean Middleditch wrote: > > > > > Right. But then you still can't detect errata packages and such when > > > > building based only on /etc/release. > > > > > > Not necessary, because errata packages are backported fixes, not > > > feature upgrades. > > > > Not in Fedora. It's been mentioned several times on the list, and on > > the site iirc, that security updates will simply be new packaged > > versions of the upstream packages. > > Deadlock. I've commented on that earlier. Do you realize that when you > fix security bugs with the release of new software versions it can > make it necessary to rebuild dependencies? Whether or not that will be > required depends on how compatible the new software version is (with > regard to API and ABI, but also wrt details such as userspace file > locations). I agree backported fixes would be absolutely great, but if they're not available... It really falls on upstream to handle this in any case. If you release a buggy library 0.1 and later on have a 0.3 that fixes a security hole you found, if people are using 0.1 its upstreams responsibility to release 0.1b (or whatever). In which case, packaging goes on as before, with two versions of the library packaged, and apps never need worry about it. In the event the library is incompatible and no backported fixes are available, the app needs a *code change*, which is no longer a packaging problem, it's an upstream problem with the application itself. A new release of the app that compiles with the new lib would of course result in a whole new package and new version, which would then be available as an upgrade. > > > > It's the packager's (distributor's) responsibility to > > > provide a working set of dependencies. Those people, who send newbies > > > to rpmseek.com where the newbies chooses a prebuilt package for an > > > arbitrary distribution and fails to locate missing dependencies, are > > > nuts and are not helpful. It is much more helpful to point newbies to > > > repositories and tools like Synaptic. > > > > The only reason its "nuts" is because packages are made with no thought > > of real users. It shouldn't have to be nuts. It should just up and > > work. > > Impossible mission. An individual package will never know *where* to > get dependencies. It only knows *what* is missing. However, if the > user makes use of package tools, the problem is solved. Back to your > example, of a package requiring libfoo.so.23.4.6 (or similar), it will > be entertaining to make the newbie understand that the file is > provided by package libfoo-1.0 and not libfoo-0.9 or libfoo-2.0. Nonsense, package networks already exist today. I almost never manually download individual dependencies anymore. Let the package network tool handle the dependency fetching. It's also useful to use user-visible names and not cryptic release names. If the packager had sane errors like "You need Version 2.0 of LibFoo", the user could easily find on the lib's website "Version 1.0 packages, Version 2.0 packages, and Version 3.0 packages." Certainly not always the case, but that doesn't mean the packager should throw up his hands and give up hope. ;-) > > > My point is, if you need to get a new library, it should *never* break > > anything. It's either compatible, in which case its a waste of time to > > rebuild packages for it, or its not compatible, in which case you'd need > > to modify the code for the app and release a new version, which isn't a > > packaging issue. > > Returning to backporting security-fixes in libraries, eh? Another loop > in this discussion. It all boils down to feasibility of doing version > upgrades of core components. I've gone over this already; if I haven't made my point here yet, then I give up. > > > A single source set *can* be made into several RPMs. > > Happens often. > > > I'm not sure how > > well RPM supports file over-rides, but some clever packaging could avoid > > the problem for users even when the app was designed by someone who > > enjoys watching users cry. ;-) > > Still, the app doesn't build if its build requirements aren't > satisfied. Another loop in the discussion. So satisfy it. The developer can fricken download the dependency. Problem solved. If the person building the package can't download the dependency, what in the nine hells is he doing building packages? ;-) > > > As you've noted, users can always install dependencies. So can > > developers. Developers are probably more capable of it. So your > > package depends on something only in RH8+, but you want it to work in > > RH7 too? Just depend on the devel files for the newer version. People > > building on RH7 can grab it and build on in bliss, and you as a packager > > don't need to waste time making silly hacks. ^,^ > > With current tools and implementation of explicit versioned build > requirements, that would cause the application to not build at all on > an unmodified RH7 unless the src.rpm examines in detail what's there > and what's not. Maybe we should go back to the early mails and restart > there. ;) The problem needs to be fixed in RPM then, and not have Fedora let you continue hacking around the problem using etc/release. Like I said the first around, *fix the problem*, don't fix the *hack* for the problem. > > > > This doesn't change a thing. The case we're discussing is a new app > > > which uses the new API and doesn't build with the old API. It requires > > > the new app to be backwards compatible, too, i.e. to use the old > > > deprecated API. And at some point in time, the API user needs to > > > switch to the current interface, because the old API is dropped. > > > > Eh? This is not at all how this works... take a look at the GNOME > > libraries. GNOME2.4 libs support GNOME2.0, GNOME2.2, and GNOME2.4 > > interfaces. An app made for GNOME2.0 runs just fine on GNOME2.4, altho > > an app written for GNOME2.4 may make use of the newer versions of the > > APIs, and thus not run on 2.0 or 2.2. > > Only the latter case is relevant to this discussion. Assume parts of > the app require GNOME 2.4, but the main part of the app doesn't depend > on GNOME 2.x at all. The app will build and run everywhere except for > the part that requires GNOME 2.4. Now make a package for all known > target platforms, which builds automatically and enables/disables > optional features depending on what build requirements are available. > The fun starts when this requires more than simple checks of installed > package versions (as outlined earlier). Again, optional fetures should *never* be compile time. That's horrible, broken design, and any app doing that has no business being ona user's desktop to begin with. Compile the app will all features turned on, and the users can just install the dependencies. Otherwise, the app is broken from a user perspective. You really need to start looking at this from a users' point of view, and not a easily-packaged point of view. ;-) > > > RPM Dependency hell exists from two things - dependencies that never > > work out, because poorly made packages make it so some apps need one > > version, and other apps need another version, resulting in a situation > > where its impossible to install both sets of apps without rebuilding > > everything. > > Bring it to the point: _poorly made packages_, not just due to > versioned dependencies, but also due to custom and distribution > specific package names. Which is also horrible, now that you mention it - see my comment below about policy. ^,^ > > > This is something where I'd *love* to see an "official" RPM packaging > > policy similar to Debian. Debian isn't perfect by a long shot, but even > > with their 3,000+ packagers and 10,000+ packages they manage to avoid a > > lot of these problems, and that's including not only Debian, but all the > > highly modified Debian-based offsprings as well. it's not because dpkg > > is magic, but just because the packages are (usually) very well built. > > This would be good, but would require the major distributors to > collaborate and adhere to such packaging policies also at the level of > what compiler version to use and when to package what software > versions. Sounds like impossible mission again. ;) There are more > major distributions which use RPM, and which are not derived from > eachother, than minor Debian derivatives. Don't just assume that's impossible. It hasn't been tried to my knowledge, which is the only reason anyone can claim so far that its failed. ;-) Other things can be glossed over to a degree. Compiler version really (mostly) only affected C++ stuff, and that's history now. Yes, it sucks, and yes, older distro releases are rather screwed, but then Fedora isn't about legacy cruft, it's about moving forward. If we worry about how screwed up the compiler ABI was, versus how its now standards comformant, we might as well also start worrying about the old lib5 stuff too - better make sure all our software compiles/runs with it! Someone might be using Red Hat 4! ;-) (one might argue that if the ABI of core libs like libstdc++, or glibc, changes, it's no longer the same base platform. we're not just talking about 'linux', where're talking about the platform made by 'linux/processor/corelibs', such that linux on x86 w/ an old lib ABI is as different from linux on x86 w/ the new ABI as it is with Solaris on SPARC - there's no avoiding the need for different packages then, no matter how much it sucks. ~,^) > > - -- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD4DBQE/fZd10iMVcrivHFQRAkjZAJinTgHKhDsT7caqu0EUqmA3fIZHAJ9LT6o/ > xjIfdBmrazD4sHk8iUd3XQ== > =6px4 > -----END PGP SIGNATURE----- > > > -- > 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 hp at redhat.com Fri Oct 3 16:05:30 2003 From: hp at redhat.com (Havoc Pennington) Date: 03 Oct 2003 12:05:30 -0400 Subject: Open Office 1.1 suggestion In-Reply-To: References: Message-ID: <1065197129.23978.6.camel@icon.devel.redhat.com> On Fri, 2003-10-03 at 11:16, w fm3 wrote: > It would be really cool if the standard install package could include > something like the below by default > > http://www.kde-look.org/content/show.php?content=7131 > It'd be even better if OO.org automatically picked up the current icon theme... ;-) I'm not sure whether this is working in the current Debian/Novell/etc. patch set on ooo.ximian.com or not. We'll probably be using that patch set though. Havoc From buildsys at porkchop.devel.redhat.com Fri Oct 3 16:09:57 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Fri, 3 Oct 2003 12:09:57 -0400 Subject: rawhide report: 20031003 changes Message-ID: <200310031609.h93G9v819695@porkchop.devel.redhat.com> Updated Packages: * ORBit2-2.8.1-1 * Fri Oct 03 2003 Alexander Larsson 2.8.1-1 - 2.8.1 - BuildRequire a newer gtk-doc * XFree86-4.3.0-35 * Thu Oct 02 2003 Mike A. Harris 4.3.0-35 - Updated to XFree86-4.3.0-xf-4_3-branch-2003-10-02.patch to pick up latest fixes in the XFree86 4.3.x stable branch including: - xdm build fixes from previous security update - Use pam_strerror() to print an error message after pam_setcred() fails, C style unification - xdm portability fix - Added XFree86-4.3.0-Xlib-XIM-bugfix-from-XFree86-bugzilla.patch to fix an XIM bug introduced into XFree86 CVS in late August, reported in XFree86 bugzilla, fixed in the trunk but not the 4.3 branch yet. (#106058) - The XIM bug above was introduced in XFree86-4.3.0-xf-4_3-branch-2003-09-11.patch which the spec file claims I added Sat Sep 6, 2003 in version 4.3.0-30, which would mean that release was affected also, however this isn't the case. A deeper investigation shows that the changelog got the patch added, but the actual patch got misplaced somehow, so didn't get applied until 4.3.0-32. As such, I'm adding an updated comment to the 4.3.0-32 changelog entry to reflect this goofup. * Mon Sep 29 2003 Mike A. Harris 4.3.0-34.2 - Made 'hostname' use -f in BuilderString, so that the FQDN of the buildhost is present in X server startup log info - Updated server startup vendorstring for Fedora Core, RHEL, and to indicate Red Hat Linux distro releases 8.0 and 9 * Thu Sep 25 2003 Mike A. Harris 4.3.0-34.1 - Added XFree86-4.3.0-savage-scaling-bz274.patch to fix (XF86 #274) - Added XFree86-4.3.0-savage-memleak-plug-bz278.patch to plug memory leak in the savage driver (XF86 #278) - Added XFree86-4.3.0-savage-memleak-plug-bz279.patch to plug memory leak in the savage driver (XF86 #279) * anaconda-9.0.95-0.20031002163738 * Thu Oct 02 2003 Anaconda team - built new version from CVS * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 * Mon Sep 09 2002 Jeremy Katz - can't buildrequire dietlibc and kernel-pcmcia-cs since they don't always exist * Wed Aug 21 2002 Jeremy Katz - added URL * Thu May 23 2002 Jeremy Katz - add require and buildrequire on rhpl * Tue Apr 02 2002 Michael Fulbright - added some more docs * Fri Feb 22 2002 Jeremy Katz - buildrequire kernel-pcmcia-cs as we've sucked the libs the loader needs to there now * Thu Feb 07 2002 Michael Fulbright - goodbye reconfig * Thu Jan 31 2002 Jeremy Katz - update the BuildRequires a bit * Fri Jan 04 2002 Jeremy Katz - ddcprobe is now done from kudzu * Wed Jul 18 2001 Jeremy Katz - own /usr/lib/anaconda and /usr/share/anaconda * Fri Jan 12 2001 Matt Wilson - sync text with specspo * Thu Aug 10 2000 Matt Wilson - build on alpha again now that I've fixed the stubs * Wed Aug 09 2000 Michael Fulbright - new build * Fri Aug 04 2000 Florian La Roche - allow also subvendorid and subdeviceid in trimpcitable * Fri Jul 14 2000 Matt Wilson - moved init script for reconfig mode to /etc/init.d/reconfig - move the initscript back to /etc/rc.d/init.d - Prereq: /etc/init.d * Thu Feb 03 2000 Michael Fulbright - strip files - add lang-table to file list * Wed Jan 05 2000 Michael Fulbright - added requirement for rpm-python * Mon Dec 06 1999 Michael Fulbright - rename to 'anaconda' instead of 'anaconda-reconfig' * Fri Dec 03 1999 Michael Fulbright - remove ddcprobe since we don't do X configuration in reconfig now * Tue Nov 30 1999 Michael Fulbright - first try at packaging reconfiguration tool * apr-0.9.4-2 * Fri Oct 03 2003 Joe Orton 0.9.4-2 - disable tests on x86_64 (#97611) * Fri Oct 03 2003 Joe Orton 0.9.4-1 - update to 0.9.4, enable tests - ensure that libresolv is not used * at-spi-1.3.7-1 * Thu Oct 02 2003 Jonathan Blandford 1.3.7-1 - new version * cadaver-0.22.0-1 * Fri Oct 03 2003 Joe Orton 0.22.0-1 - update to 0.22.0; use system neon * coreutils-5.0-20 * Fri Oct 03 2003 Tim Waugh 5.0-20 - Restrict ACL support to only those programs needing it (bug #106141). - Fix default PATH for LSB (bug #102567). * Thu Sep 11 2003 Dan Walsh 5.0-19 - Turn off SELinux * Wed Sep 10 2003 Dan Walsh 5.0-18.sel - Turn on SELinux * Fri Sep 05 2003 Dan Walsh 5.0-17 - Turn off SELinux * Tue Sep 02 2003 Dan Walsh 5.0-16.sel - Only call getfilecon if the user requested it. - build with selinux * cups-1.1.19-13 * Thu Oct 02 2003 Tim Waugh 1:1.1.19-13 - Apply patch from STR 226 to make CUPS reload better behaved (bug #101507). * eog-2.4.0-1 * Fri Oct 03 2003 Alexander Larsson 2.4.0-1 - 2.4.0 * fedora-release-0.94-2 * file-roller-2.4.0.1-1 * Fri Oct 03 2003 Alexander Larsson 2.4.0.1-1 - 2.4.0.1 * gail-1.4.0-1 * Thu Oct 02 2003 Jonathan Blandford 1.4.0-1 - update version * gaim-0.70-1 * Mon Sep 29 2003 Christopher Blizzard 1:0.70-0 - Update to 0.70 * gconf-editor-2.4.0-1 * Fri Oct 03 2003 Alexander Larsson 2.4.0-1 - 2.4.0 * gdm-2.4.4.3-1 * Thu Oct 02 2003 Havoc Pennington 1:2.4.4.3-1 - 2.4.4.3 - --without-selinux for now, since libselinux not in the buildroot * Mon Sep 08 2003 Dan Walsh 1:2.4.4.0-4 - turn off SELinux * Fri Sep 05 2003 Dan Walsh 1:2.4.4.0-3.sel - turn on SELinux * gedit-2.4.0-1 * Fri Oct 03 2003 Alexander Larsson 1:2.4.0-1 - 2.4.0 * ggv-2.4.0.1-1 * Fri Oct 03 2003 Alexander Larsson 2.4.0.1-1 - 2.4.0.1 * gmp-4.1.2-7 * Thu Oct 02 2003 Florian La Roche - enable mpfr #104395 - enable cxx #80195 - add COPYING.LIB - add fixes from gmp web-site - remove some cruft patches for older libtool releases * gnome-applets-2.4.1-1 * Fri Oct 03 2003 Alexander Larsson 1:2.4.1-1 - 2.4.1 * gnome-games-2.4.0-2 * Fri Oct 03 2003 Alexander Larsson 1:2.4.0-2 - 2.4.0 * gnome-icon-theme-1.0.9-1 * Fri Oct 03 2003 Alexander Larsson 1.0.9-1 - update to 1.0.9 * gnome-mag-0.10.3-1 * Thu Oct 02 2003 Jonathan Blandford 0.10.3-1 - new version * gnome-mime-data-2.4.0-1 * Fri Oct 03 2003 Alexander Larsson 2.4.0-1 - update to 2.4.0 * gnome-python2-2.0.0-2 * Thu Oct 02 2003 Matt Wilson 2.0.0-2 - fix segv in gnome.ui.About() (#104396) * gnome-speech-0.2.7-1 * Thu Oct 02 2003 Jonathan Blandford 0.2.7-1 - new version * gnome-system-monitor-2.4.0-1 * Fri Oct 03 2003 Alexander Larsson 2.4.0-1 - 2.4.0 * kdelibs-3.1.4-2 * Thu Oct 02 2003 Than Ngo 6:3.1.4-2 - rebuild against new gcc-3.3.1-6, fixed miscompiled code on IA-32 * kdenetwork-3.1.4-1 * Tue Sep 30 2003 Than Ngo 7:3.1.4-1 - 3.1.4 * kernel-2.4.22-1.2084.nptl * Wed Oct 01 2003 Dave Jones - Include hack to improve firewire hotplug. - More merges from upstream 2.4.23pre - deal with lack of acpi prt entries gracefully - [IPV4]: In arp_rcv() do not inspect ARP header until packet length and linearity is verified. - [NET]: Fix HW_FLOWCONTROL on SMP. - Update various ACPI patches to follow mainline. * kudzu-1.1.30-1 * Thu Oct 02 2003 Bill Notitngham 1.1.30-1 - resurrect PCI disabled probe for video cards (#91265, #106030) - don't probe PS/2 mice if we appear to be running on a local X display * libgnomeui-2.4.0.1-1 * Fri Oct 03 2003 Alexander Larsson 2.4.0.1-1 - 2.4.0.1 * libtool-1.5-6 * Thu Oct 02 2003 Florian La Roche - rebuild * libwnck-2.4.0.1-1 * Fri Oct 03 2003 Alexander Larsson 2.4.0.1-1 - 2.4.0.1 * mkinitrd-3.5.14-1 * Thu Oct 02 2003 Jeremy Katz 3.5.14-1 - fix dependency on /usr/bin/tail and /usr/bin/id * Tue Sep 30 2003 Florian La Roche - remove one more mktemp dir for "all loopback devices in use" case * mozilla-1.4.1-3 * Thu Oct 02 2003 Than Ngo 37:1.4.1-2 - fix desktop file issues, icon is showed correct in KDE start menus (bug #105650) - install desktop files in correct directory * Wed Oct 01 2003 Chris Blizzard 37:1.4.1-1 - Add patch from 3.0 branch that disables some optimization of prdtoa.c * Wed Oct 01 2003 Chris Blizzard 37:1.4.1-1 - Add patch that gets nss building on ppc64 * Tue Sep 30 2003 Chris Blizzard 37:1.4.1-1 - Add patches to fix mouseout events and some embedding crashes * Mon Sep 29 2003 Chris Blizzard 37:1.4.1-1 - Add patch that fixes key input in some locales * Tue Aug 19 2003 Chris Blizzard 37:1.4-13 - Fix copyright * Mon Jun 30 2003 Chris Blizzard 37:1.4-10 - final 1.4 release * Tue Jun 03 2003 Jeff Johnson - add explicit epoch's where needed. * Thu Feb 27 2003 Thomas Woerner 35:1.2.1-27 - enabled mozilla-gcc-3.2-libs.tar.bz2 for x86_64 * Tue Feb 25 2003 Christopher Blizzard 35:1.2.1-26 - Updated es-ES pack * Mon Feb 24 2003 Elliot Lee - rebuilt * Fri Feb 21 2003 Christopher Blizzard 35:1.2.1-24 - Include /usr/lib/mozilla/plugins * Fri Feb 21 2003 Christopher Blizzard 35:1.2.1-23 - Try to fix reloc errors on x86_64 * Fri Feb 21 2003 Christopher Blizzard 35:1.2.1-22 - Add notting's patch for respecting LANG at startup * Thu Feb 06 2003 Christopher Blizzard 35:1.2.1-20 - fix infinite-galeon-windows-of-doom * Mon Feb 03 2003 Christopher Blizzard 35:1.2.1-19 - Build on ppc * Sun Feb 02 2003 Christopher Blizzard 35:1.2.1-18 - Remove devnet from the default bookmarks * Fri Jan 31 2003 Matt Wilson 35:1.2.1-17 - add x86_64 port from Mandrake - modify all /usr/lib paths to use %{_libdir] * Tue Jan 28 2003 Christopher Blizzard 1.2.1-15 - use ifarch instead of gcc_32_libs in defines * Mon Jan 27 2003 Christopher Blizzard 1.2.1-14 - Add XUL.mfasl corruption fix * Wed Jan 22 2003 Tim Powers - rebuilt * Wed Jan 22 2003 Christopher Blizzard 1.2.1-12 - Only build gcc-3.2-specific libs on i386 * Wed Jan 22 2003 Phil Knirsch 1.2.1-11 - Make s390 and s390x compile and work with xpcom. * Mon Jan 20 2003 Christopher Blizzard 1.2.1-9 - Moz doesn't build with gcc 3.2 on alpha. *gurgle* Back to just i386. * Sun Jan 19 2003 Christopher Blizzard 1.2.1-9 - Include gcc3.2-compiled version for OOo. * Fri Jan 17 2003 Christopher Blizzard 1.2.1-8 - It might help if patch18 were actually _applied_. * Tue Jan 14 2003 Christopher Blizzard 1.2.1-7 - Include the right installed-chrome.txt file * Mon Jan 13 2003 Christopher Blizzard 1.2.1-6 - Translations * Thu Jan 02 2003 Christopher Blizzard 1.2.1-5 - New lang architecture * Mon Dec 23 2002 Christopher Blizzard 1.2.1-4 - Forgot to include calls to killall in case regxpcom or regchrome hang on install. * Wed Dec 18 2002 Christopher Blizzard 1.2.1-3 - change patch to also allow us to set the UI font height in points * Tue Dec 17 2002 Christopher Blizzard 1.2.1-1 - add patch that allows us to set the UI font name * Mon Dec 16 2002 Christopher Blizzard 1.2.1-0 - ExlusiveArch for i386 and alpha. * Wed Jul 10 2002 Christopher Blizzard - Use the components/*.dat files instead of component.reg both in rebuild-databases.pl and in packaging. * Mon Jul 01 2002 Chris Blizzard - Move libs into the system that need to be there * Tue Jun 25 2002 Christopher Blizzard - Change mozilla-rebuild-databases.pl to remove compreg.dat as well as component.reg. * Sun Jun 23 2002 Chris Blizzard - Move nspr + nss back into /usr/lib * Thu Jun 20 2002 Christopher Blizzard - Time for a new changelog. * nautilus-2.4.0-5 * Fri Oct 03 2003 Alexander Larsson 2.4.0-5 - Update cvs backport, now have the better desktop icon layout * procps-2.0.17-1 * Fri Oct 03 2003 Alexander Larsson 2.0.17-1 - Update to 2.0.17, drop upstream patches, forward port remaining patches * Fri Sep 05 2003 Dan Walsh 2.0.13-11 - Turn off selinux * Thu Aug 28 2003 Dan Walsh 2.0.13-10.sel - Add -Z switch for SELinux * Sun Aug 17 2003 Doug Ledford 2.0.13-9E - Add patch to recognize irq and softirq time accounting in kernels that support this feature * rawhide-release-20031003-1 * rhpl-0.116-1 * Thu Oct 02 2003 Brent Fox 0.116-1 - videocard.py: added pci busID functions * rsh-0.17-18 * Thu Oct 02 2003 Phil Knirsch 0.17-18 - Fixed YAT (#79391). - Included feature request #105733 (-D option). From hp at redhat.com Fri Oct 3 16:11:39 2003 From: hp at redhat.com (Havoc Pennington) Date: 03 Oct 2003 12:11:39 -0400 Subject: video player in fedora? In-Reply-To: <1065169747.4156.2.camel@mao.ikp.org> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <1065091163.6837.15.camel@faro.stuttgart.redhat.com> <1065169747.4156.2.camel@mao.ikp.org> Message-ID: <1065197499.23978.13.camel@icon.devel.redhat.com> On Fri, 2003-10-03 at 04:29, axel c wrote: > Also, do > these programs bring licensing issues? Do they ever. I don't think you can play many of the interesting video formats without issues. (See one of the dozens of HUGE threads on this list, and many other Red Hat lists, in the past. And no we can't include the stuff with licensing issues and this will not change, again, see those threads.) For video player in Core, I'd like to see one of the toolkit-based players (either GTK+ or Qt). See http://fedora.redhat.com/projects/desktop/defaults.html The general approach should be to have a player that uses a generic media framework such as gstreamer; and then third parties can add plugins. A player that has to link to plugins directly or via non-generic interfaces will not permit third party plugins. Havoc From Nicolas.Mailhot at laPoste.net Fri Oct 3 16:24:15 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 03 Oct 2003 18:24:15 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1065198255.7980.5.camel@ulysse.olympe.o2t> Le ven 03/10/2003 ? 18:04, Sean Middleditch a ?crit : > On Fri, 2003-10-03 at 11:36, Michael Schwendt wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Fri, 03 Oct 2003 10:11:46 -0400, Sean Middleditch wrote: > > > This is something where I'd *love* to see an "official" RPM packaging > > > policy similar to Debian. Debian isn't perfect by a long shot, but even > > > with their 3,000+ packagers and 10,000+ packages they manage to avoid a > > > lot of these problems, and that's including not only Debian, but all the > > > highly modified Debian-based offsprings as well. it's not because dpkg > > > is magic, but just because the packages are (usually) very well built From ms-nospam-0306 at arcor.de Fri Oct 3 17:52:45 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 3 Oct 2003 19:52:45 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 03 Oct 2003 12:04:35 -0400, Sean Middleditch wrote: > > > > It's the packager's (distributor's) responsibility to > > > > provide a working set of dependencies. Those people, who send newbies > > > > to rpmseek.com where the newbie chooses a prebuilt package for an > > > > arbitrary distribution and fails to locate missing dependencies, are > > > > nuts and are not helpful. It is much more helpful to point newbies to > > > > repositories and tools like Synaptic. > > > > > > The only reason its "nuts" is because packages are made with no thought > > > of real users. It shouldn't have to be nuts. It should just up and > > > work. > > > > Impossible mission. An individual package will never know *where* to > > get dependencies. It only knows *what* is missing. However, if the > > user makes use of package tools, the problem is solved. Back to your > > example, of a package requiring libfoo.so.23.4.6 (or similar), it will > > be entertaining to make the newbie understand that the file is > > provided by package libfoo-1.0 and not libfoo-0.9 or libfoo-2.0. > > Nonsense, package networks already exist today. I almost never manually > download individual dependencies anymore. Let the package network tool > handle the dependency fetching. Apparently, you need longer quotes in order to not kill the context and misunderstand comments. Notice the comment on _package tools_ compared with picking individual packages at rpmseek.com/rpmfind.net. You're creating endless loops in this discussion. > > > I'm not sure how > > > well RPM supports file over-rides, but some clever packaging could avoid > > > the problem for users even when the app was designed by someone who > > > enjoys watching users cry. ;-) > > > > Still, the app doesn't build if its build requirements aren't > > satisfied. Another loop in the discussion. > > So satisfy it. The developer can fricken download the dependency. > Problem solved. If the person building the package can't download the > dependency, what in the nine hells is he doing building packages? ;-) *sigh* He isn't. It is _you_ who wants the src.rpms be much more flexible than what we have presently. My arbitrary example -- and even a very basic one -- with aspell and one src.rpm for multiple platforms still holds true. The "real user" (adapting your terminology) works with prebuilt binary packages and not src.rpms. Packagers aim at creating high-quality binary packages for "real users" while at the same time keeping the maintenance requirements low. Clean src.rpms are an added thing and allow the average user to rebuild stuff from source without big problems. Let the rare user with an exotic installation and configuration adjust the src.rpm if need be. > > > As you've noted, users can always install dependencies. So can > > > developers. Developers are probably more capable of it. So your > > > package depends on something only in RH8+, but you want it to work in > > > RH7 too? Just depend on the devel files for the newer version. People > > > building on RH7 can grab it and build on in bliss, and you as a packager > > > don't need to waste time making silly hacks. ^,^ > > > > With current tools and implementation of explicit versioned build > > requirements, that would cause the application to not build at all on > > an unmodified RH7 unless the src.rpm examines in detail what's there > > and what's not. Maybe we should go back to the early mails and restart > > there. ;) > > The problem needs to be fixed in RPM then, and not have Fedora let you > continue hacking around the problem using etc/release. Like I said the > first around, *fix the problem*, don't fix the *hack* for the problem. I give up here. Sorry. Going on with this "discussion" is wasted time as long as you don't propose a solution. A sentence like "*fix the problem*, don't fix the *hack* for the problem" is written quickly. It wipes away everything which has been commented on earlier. Maybe we should pick a single topic (like automated detection of build requirements) and beat that one to death. But the current discussion touches too many topics at once and is fruitless. You won't get any packagers to prepare src.rpms for unknown target platforms by duplicating the work of "configure" scripts where a straight-forward detection of available packages and package versions wouldn't suffice. You would deal with things like detecting inter-library dependencies, compiler features/bugs, linker tests, and things like that. > Again, optional fetures should *never* be compile time. That's > horrible, broken design, and any app doing that has no business being > ona user's desktop to begin with. Compile the app will all features > turned on, Usually, this requires build dependencies to be available beforehand and fails where optional build dependencies are unavailable, and e.g. a plug-in cannot be built. I've seen Michael K. Johnson's comment on run-time configuration as opposed to compile-time configuration, but that refers to something else. In order to build an optional run-time configurable part of an app, you need to build it from source code at some point im time. This requires build dependencies to be available. > and the users can just install the dependencies. Otherwise, > the app is broken from a user perspective. You really need to start > looking at this from a users' point of view, and not a easily-packaged > point of view. ;-) You fail to understand the implications of build requirements. ["official" RPM packaging policy ] > Other things can be glossed over to a degree. Compiler version really > (mostly) only affected C++ stuff, and that's history now. No one still using GCC 2.95.x or GCC 2.96 or early GCC 3 release and needs patches? What about glibc, Perl, Python? Also, do SuSE still use RPM 3.x? ;) - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fbdt0iMVcrivHFQRAri9AJwPF+Iy1S3tlnvfriSAv8aceUY3uQCggQz5 kw5PZq7Xb41MohP/IsvekmI= =gEMR -----END PGP SIGNATURE----- From matthias at rpmforge.net Fri Oct 3 18:07:52 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Fri, 3 Oct 2003 20:07:52 +0200 Subject: rawhide report: 20031003 changes In-Reply-To: <200310031609.h93G9v819695@porkchop.devel.redhat.com> References: <200310031609.h93G9v819695@porkchop.devel.redhat.com> Message-ID: <20031003200752.557db910.matthias@rpmforge.net> Build System wrote : > Updated Packages: > [...] This is really neat and incredibly useful, thanks a lot to whoever implemented it at last. Bill, you made a typo in the last kudzu %changelog entry, should I bugzilla it? ;-)))))))) Matthias, week-end at last... -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20031002 - Linux kernel 2.4.22-20.1.2024.2.36.nptl Load : 0.19 0.24 0.35 From dcbw at redhat.com Fri Oct 3 18:12:43 2003 From: dcbw at redhat.com (Dan Williams) Date: Fri, 03 Oct 2003 14:12:43 -0400 Subject: Open Office 1.1 suggestion In-Reply-To: <20031003155322.99381.qmail@web14205.mail.yahoo.com> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> Message-ID: <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> I really would like to put in some nice looking icons. There are a couple options: 1) The ximian set. These are high-quality 32-bit RGBA icons, but require that a number of patches to support RGBA bitmaps be applied to OOo. These aren't trivial patches, but of course Ximian has been using them for a while. There are a lot of icons here too. 2) The kdelook.org ones. These are very nice-looking too, and fairly simple to install, though it does require tcl as a prerequisite for the bundled scripts. There also is to my knowledge no nice way to change toolbar sets with the included scripts except through the command-line, though this could be created. There also aren't as many icons here as the Ximian icons. So to do this, we'd need to (1) determine which icon set to use, and (2) if using the KDE ones determine how the user would switch icons sets, or (2a) determine whether we should simply pick a set and screw the rest, and then (3) make it work. I'm busy putting together a 1.1 package for Fedora now, and after I get the first cut done then I'm going to be bringing in more and more patches that seem useful. So icons probably won't get in the first release of the package, but definitely could come in later. Dan On Fri, 2003-10-03 at 11:53, Jens Knutson wrote: > --- w fm3 wrote: > > It would be really cool if the standard install package could include > > > > something like the below by default > > At the very least, what are the odds of including Ximian's nice icon > set? > > - jck > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From elanthis at awesomeplay.com Fri Oct 3 18:28:42 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 03 Oct 2003 14:28:42 -0400 Subject: Kind request: fix your packages In-Reply-To: <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> Message-ID: <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2003-10-03 at 13:52, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 03 Oct 2003 12:04:35 -0400, Sean Middleditch wrote: > > Nonsense, package networks already exist today. I almost never manually > > download individual dependencies anymore. Let the package network tool > > handle the dependency fetching. > > Apparently, you need longer quotes in order to not kill the context > and misunderstand comments. Notice the comment on _package tools_ > compared with picking individual packages at rpmseek.com/rpmfind.net. > You're creating endless loops in this discussion. This happens, yes - my apologies. My memory tends not to go back further than about 30 seconds. ~,^ Psychologists would call it goldfish syndrome if they knew about me. ;-) Reading back a little ways, I'm now rather confused what your whole paragraph was about - we have the tools/networks, so newbies don't have to worry about libfoo-1.0 vs libfoo-0.9 and so on. > > > > > I'm not sure how > > > > well RPM supports file over-rides, but some clever packaging could avoid > > > > the problem for users even when the app was designed by someone who > > > > enjoys watching users cry. ;-) > > > > > > Still, the app doesn't build if its build requirements aren't > > > satisfied. Another loop in the discussion. > > > > So satisfy it. The developer can fricken download the dependency. > > Problem solved. If the person building the package can't download the > > dependency, what in the nine hells is he doing building packages? ;-) > > *sigh* He isn't. It is _you_ who wants the src.rpms be much more > flexible than what we have presently. My arbitrary example -- and even > a very basic one -- with aspell and one src.rpm for multiple platforms > still holds true. The "real user" (adapting your terminology) works > with prebuilt binary packages and not src.rpms. Packagers aim at > creating high-quality binary packages for "real users" while at the > same time keeping the maintenance requirements low. Clean src.rpms are > an added thing and allow the average user to rebuild stuff from source > without big problems. Let the rare user with an exotic installation > and configuration adjust the src.rpm if need be. No, your packaging method wants to screw over users, by making packages that are not easy or sane to use, as the features and dependencies present end up being based on silly things like where the packager built them, versus the place the user is installing them. The "low maintenance" of the packages results in "low flexibility" for the user, since they can no longer "just install" an app, but then become dependent on knowing things like which errata they have installed, which distro they have (most Windows users aren't even sure which of 4 versions of Windows they have, as a point of how bad it is to make a user know this stuff), etc. Instead of fixing the problem, you're arguing about Fedora breaking the packaging habits you've been forced to develop to hack around the problem. > > > > > As you've noted, users can always install dependencies. So can > > > > developers. Developers are probably more capable of it. So your > > > > package depends on something only in RH8+, but you want it to work in > > > > RH7 too? Just depend on the devel files for the newer version. People > > > > building on RH7 can grab it and build on in bliss, and you as a packager > > > > don't need to waste time making silly hacks. ^,^ > > > > > > With current tools and implementation of explicit versioned build > > > requirements, that would cause the application to not build at all on > > > an unmodified RH7 unless the src.rpm examines in detail what's there > > > and what's not. Maybe we should go back to the early mails and restart > > > there. ;) > > > > The problem needs to be fixed in RPM then, and not have Fedora let you > > continue hacking around the problem using etc/release. Like I said the > > first around, *fix the problem*, don't fix the *hack* for the problem. > > I give up here. Sorry. Going on with this "discussion" is wasted time > as long as you don't propose a solution. A sentence like "*fix the > problem*, don't fix the *hack* for the problem" is written quickly. It > wipes away everything which has been commented on earlier. Solution I've mentioned before - the applications are simply built one way, the way that makes most sense for the user, and not on local build location dependencies. Let the package system deal with both runtime and buildtime dependencies, don't just randmly apply patches or remove features because the person building the package is too lazy to download the dependency. There's you fix, as I've said before. If it is too hard to do this, then this maybe needs to move to the RPM list, instead of just saying "oh well" and continuing to screw over the users. I've packaged for Debian before, but never an RPM distro - if it really is so much harder to do with spec files what is dead simple in a dpkg, then RPM needs work ("the problem"), versus ignoring it and using /etc/release to avoid use of real dependencies ("the hack"). > > Maybe we should pick a single topic (like automated detection of build > requirements) and beat that one to death. But the current discussion > touches too many topics at once and is fruitless. You won't get any This I agree on. Sorry for my rambling nature. ^^; > packagers to prepare src.rpms for unknown target platforms by > duplicating the work of "configure" scripts where a straight-forward > detection of available packages and package versions wouldn't suffice. > You would deal with things like detecting inter-library dependencies, > compiler features/bugs, linker tests, and things like that. Correct; which again needs to be brought up on the RPM list, not complaining abou tit on the fedora list. ~,^ > > > Again, optional fetures should *never* be compile time. That's > > horrible, broken design, and any app doing that has no business being > > ona user's desktop to begin with. Compile the app will all features > > turned on, > > Usually, this requires build dependencies to be available beforehand and > fails where optional build dependencies are unavailable, and e.g. a > plug-in cannot be built. I've seen Michael K. Johnson's comment on > run-time configuration as opposed to compile-time configuration, but > that refers to something else. In order to build an optional run-time For a user-oriented app, enabling or disabling a feature is configuration. Different terms, exact same end-result tho. > configurable part of an app, you need to build it from source code at > some point im time. This requires build dependencies to be available. Which anyone building the RPMs are free to install if they want to build it, of course. > > > and the users can just install the dependencies. Otherwise, > > the app is broken from a user perspective. You really need to start > > looking at this from a users' point of view, and not a easily-packaged > > point of view. ;-) > > You fail to understand the implications of build requirements. > Not sure what you mean here; a package has requirements, you install them before building. If you don't, it doesn't build. Just like any other piece of software. What "implications" am I missing? (seriously - I don't enjoy being clueless if I can help it ;-) > > ["official" RPM packaging policy ] > > > Other things can be glossed over to a degree. Compiler version really > > (mostly) only affected C++ stuff, and that's history now. > > No one still using GCC 2.95.x or GCC 2.96 or early GCC 3 release and > needs patches? What about glibc, Perl, Python? Also, do SuSE still use > RPM 3.x? ;) Legacy cruft isn't really a part of Fedora's goals, so I don't see Fedora bending over backwards to support it. ;-) And, since there really isn't any kind of standard yet, we can gloss over legacy since it never claimed to be a part of the standard. ^,^ I'd say its perfectly acceptable to state that packages only work on "RPM Policy 1.0 compliant operating systems"; packages for legacy systems, which will fade out soon enough (speaking in computer time anyways) will still be a pain, but what is one to do? Moving forward sucks sometimes, but it's sure as hell better than never progressing. :P Perl/Python are co-installable with different versions, and thus are a different issue. Distros based on 2.96 were inherently broken anyhow, and 2.95 is history. In any event, this is off on a tangent from the original discussion. ;-) I'll have to bring this up somewhere more relevant. ^,^ > > - -- > Michael, who doesn't reply to top posts and complete quotes anymore. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQE/fbdt0iMVcrivHFQRAri9AJwPF+Iy1S3tlnvfriSAv8aceUY3uQCggQz5 > kw5PZq7Xb41MohP/IsvekmI= > =gEMR > -----END PGP SIGNATURE----- > > > -- > 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 hp at redhat.com Fri Oct 3 18:31:31 2003 From: hp at redhat.com (Havoc Pennington) Date: 03 Oct 2003 14:31:31 -0400 Subject: Open Office 1.1 suggestion In-Reply-To: <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> Message-ID: <1065205891.25063.36.camel@icon.devel.redhat.com> Hi, On Fri, 2003-10-03 at 14:12, Dan Williams wrote: > I really would like to put in some nice looking icons. There are a > couple options: > There's a freedesktop.org spec for icon themes, so the ideal course of action is simply to make OO.org read the current icon theme, rather than trying to pick some hardcoded set. The icon theme spec is not 100% trivial to implement so the simplest way to do so may be to use the implementation in upcoming GTK+ 2.4. If we pick a hardcoded set, it should be the Bluecurve icon style; Garrett can fill in missing icons in the Fedora Core 2 timeframe probably. Havoc From dcbw at redhat.com Fri Oct 3 18:36:58 2003 From: dcbw at redhat.com (Dan Williams) Date: Fri, 03 Oct 2003 14:36:58 -0400 Subject: Open Office 1.1 suggestion In-Reply-To: <1065205891.25063.36.camel@icon.devel.redhat.com> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> Message-ID: <1065206218.2080.14.camel@dhcp64-175.boston.redhat.com> Havoc, This would be ideal of course, but it would take a bit of work. The icons are specified in configuration files in OOo and are _not_ dynamically found in any way. A good amount of surgery would be required to get them to see the freedesktop.org ones. Perhaps a better solution would be to an Icon Set Framework allowing arbitrary collections of icons to be used, along with a UI for changing the set or setting it to the "System Default", taken from the current theme. This too would take yet more surgery. Dan On Fri, 2003-10-03 at 14:31, Havoc Pennington wrote: > Hi, > > On Fri, 2003-10-03 at 14:12, Dan Williams wrote: > > I really would like to put in some nice looking icons. There are a > > couple options: > > > > There's a freedesktop.org spec for icon themes, so the ideal course of > action is simply to make OO.org read the current icon theme, rather than > trying to pick some hardcoded set. The icon theme spec is not 100% > trivial to implement so the simplest way to do so may be to use the > implementation in upcoming GTK+ 2.4. > > If we pick a hardcoded set, it should be the Bluecurve icon style; > Garrett can fill in missing icons in the Fedora Core 2 timeframe > probably. > > Havoc > > > > -- > 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 Fri Oct 3 18:57:04 2003 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 03 Oct 2003 14:57:04 -0400 Subject: Open Office 1.1 suggestion In-Reply-To: <1065206218.2080.14.camel@dhcp64-175.boston.redhat.com> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> <1065206218.2080.14.camel@dhcp64-175.boston.redhat.com> Message-ID: <1065207424.12331.157.camel@poincare.devel.redhat.com> On Fri, 2003-10-03 at 14:36, Dan Williams wrote: > Havoc, > > This would be ideal of course, but it would take a bit of work. The > icons are specified in configuration files in OOo and are _not_ > dynamically found in any way. A good amount of surgery would be > required to get them to see the freedesktop.org ones. Perhaps a better > solution would be to an Icon Set Framework allowing arbitrary > collections of icons to be used, along with a UI for changing the set or > setting it to the "System Default", taken from the current theme. This > too would take yet more surgery. Conceptually the right thing to do is to have OpenOffice internally have a concept of "named icon resources". Then you would have: A) The default cross-platform way of doing named icon resource => icon lookups. B) The freedesktop way of doing the translation which involves 1) converting the OO.org name into a freedesktop name for the icon if necessary 2) looking up the freedesktop name via the icon theme spec. C) Other platform specific ways, if useful. Although making the default way allow switching between sets might be a good way of "sugar coating" the necessary code changes, it isn't directly useful for OO.org within GNOME or KDE. When running on a freedesktop.org platform, OO.org should be using the freedesktop.org icon mechanism. Lots of work there, though. Regards, Owen From garrett at redhat.com Fri Oct 3 18:59:48 2003 From: garrett at redhat.com (Garrett LeSage) Date: Fri, 03 Oct 2003 14:59:48 -0400 Subject: Open Office 1.1 suggestion In-Reply-To: <1065205891.25063.36.camel@icon.devel.redhat.com> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> Message-ID: <3F7DC724.3080405@redhat.com> Havoc Pennington wrote: >Hi, > >On Fri, 2003-10-03 at 14:12, Dan Williams wrote: > > >>I really would like to put in some nice looking icons. There are a >>couple options: >> >> > > >If we pick a hardcoded set, it should be the Bluecurve icon style; >Garrett can fill in missing icons in the Fedora Core 2 timeframe >probably. > > Yeah, I have talked to a few people around here about that. I think it's possible to do. It is a bunch of icons but, when finished, OOo will look quite nice and it will more-or-less match the entire desktop's feel (with the exception of the widgets looking just the same, unless someone has some magic up their sleeves). I'm looking forward to it. The office suite is a highly visible app, so it should look (and act) nice. Garrett From mharris at redhat.com Fri Oct 3 19:01:30 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 3 Oct 2003 15:01:30 -0400 (EDT) Subject: alpha architecture In-Reply-To: References: Message-ID: On Thu, 2 Oct 2003, Jim wrote: >I have the HP edition of RH7.2 installed on a 21164 533Mhz pc164lx. All >is well with the system and I have had no problems except that there are >no software updates/upgrades to the latest versions of applications I need >such as postgresql/php/apache/ssl etc. Then I ran across the Fedora >project and noticed that the latest alpha rpm's for these applications >were availible for download. The problem is that they don't work on the >7.2 release and rpm -Uvh for the packages I need give me countless failed >deps as I expected they would. Will there be an upcomming alpha iso >release for the latest redhat version? If not, I would like to port >an updated rh release for the alpha architecture. If any one is doing >this already or if anybody needs help doing this I'd be pleased to help >out. If someone is already doing this could you please point me in the >right direction? Myself, Jeff Garzik, Richard Henderson, Phil "Bryce" Copeland and various people from DEC/COMPAQ/HP have been slowly making evil plans to work on an alpha port of the current distribution sometime soon. We have no details as of yet, but once we are ready to start building and pushing packages we'll let people know here. The intent is to make a Fedora/Alpha distribution. That is all the detail I have for now. When there is more information, we will announce it here. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From notting at redhat.com Fri Oct 3 19:18:46 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Oct 2003 15:18:46 -0400 Subject: rawhide report: 20031003 changes In-Reply-To: <20031003200752.557db910.matthias@rpmforge.net>; from matthias@rpmforge.net on Fri, Oct 03, 2003 at 08:07:52PM +0200 References: <200310031609.h93G9v819695@porkchop.devel.redhat.com> <20031003200752.557db910.matthias@rpmforge.net> Message-ID: <20031003151846.E1566@devserv.devel.redhat.com> Matthias Saou (matthias at rpmforge.net) said: > > Updated Packages: > > > [...] > > This is really neat and incredibly useful, thanks a lot to whoever > implemented it at last. No problem. There will probably be some tweaks to it over time. > Bill, you made a typo in the last kudzu %changelog entry, should I bugzilla > it? ;-)))))))) Yeah yeah, fixed. Bill From dcbw at redhat.com Fri Oct 3 19:25:35 2003 From: dcbw at redhat.com (Dan Williams) Date: Fri, 03 Oct 2003 15:25:35 -0400 Subject: Open Office 1.1 suggestion In-Reply-To: <3F7DC724.3080405@redhat.com> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> <3F7DC724.3080405@redhat.com> Message-ID: <1065209134.2080.22.camel@dhcp64-175.boston.redhat.com> On Fri, 2003-10-03 at 14:59, Garrett LeSage wrote: > feel (with the exception of the widgets looking just the same, unless > someone has some magic up their sleeves). Haha, and do I. Its a hack right now but will get there in a few months. http://www.bigw.org/~dan/nwscreen.png Dan From garrett at redhat.com Fri Oct 3 19:44:23 2003 From: garrett at redhat.com (Garrett LeSage) Date: Fri, 03 Oct 2003 15:44:23 -0400 Subject: Open Office 1.1 suggestion In-Reply-To: <1065209134.2080.22.camel@dhcp64-175.boston.redhat.com> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> <3F7DC724.3080405@redhat.com> <1065209134.2080.22.camel@dhcp64-175.boston.redhat.com> Message-ID: <3F7DD197.2070401@redhat.com> Dan Williams wrote: >On Fri, 2003-10-03 at 14:59, Garrett LeSage wrote: > > >>feel (with the exception of the widgets looking just the same, unless >>someone has some magic up their sleeves). >> >> > >Haha, and do I. Its a hack right now but will get there in a few >months. > >http://www.bigw.org/~dan/nwscreen.png > > Woohoo. Looks very promising so far. (: I'm guessing that the concept being used is similar to the way Mozilla does it? Is OOo going to eventually pull in the system fonts for use in widgets as well? Garrett From ms-nospam-0306 at arcor.de Fri Oct 3 20:11:16 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 3 Oct 2003 22:11:16 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 03 Oct 2003 14:28:42 -0400, Sean Middleditch wrote: > Reading back a little ways, I'm now rather confused what your whole > paragraph was about - we have the tools/networks, so newbies don't have > to worry about libfoo-1.0 vs libfoo-0.9 and so on. Let's see. Quoting you: > > Users should just be able to grab any package online they want, > and install it. Do you see rpm-dep-hell complaints from apt/yum/up2date users? I don't. But rpmfind.net/rpmseek.com users complain regularly. This is the context of the reply to your comment. > No, your packaging method wants to screw over users, by making packages > that are not easy or sane to use, as the features and dependencies > present end up being based on silly things like where the packager built > them, versus the place the user is installing them. Far from it. The binary packages are easy to use while the src.rpms may need a few adjustments (sort of --define value) before they adapt to altered build environments. > The "low > maintenance" of the packages results in "low flexibility" for the user, > since they can no longer "just install" an app, but then become > dependent on knowing things like which errata they have installed, which > distro they have (most Windows users aren't even sure which of 4 > versions of Windows they have, as a point of how bad it is to make a > user know this stuff), etc. You're exaggerating again, a lot. > Instead of fixing the problem, you're arguing about Fedora breaking the > packaging habits you've been forced to develop to hack around the > problem. Huh? You you sure you don't confuse me with anyone else? > > I give up here. Sorry. Going on with this "discussion" is wasted time > > as long as you don't propose a solution. A sentence like "*fix the > > problem*, don't fix the *hack* for the problem" is written quickly. It > > wipes away everything which has been commented on earlier. > > Solution I've mentioned before - the applications are simply built one > way, the way that makes most sense for the user, and not on local build > location dependencies. Let the package system deal with both runtime > and buildtime dependencies, don't just randmly apply patches or remove > features because the person building the package is too lazy to download > the dependency. There's you fix, as I've said before. Insufficient since the packager needs to adapt to the software, not vice versa. But as I've said, it is beyond my time to try to rephrase again and again in the hope that you'll understand my point of view. > > > and the users can just install the dependencies. Otherwise, > > > the app is broken from a user perspective. You really need to start > > > looking at this from a users' point of view, and not a easily-packaged > > > point of view. ;-) > > > > You fail to understand the implications of build requirements. > > > > Not sure what you mean here; a package has requirements, you install > them before building. If you don't, it doesn't build. Just like any > other piece of software. What "implications" am I missing? (seriously > - I don't enjoy being clueless if I can help it ;-) _Optional_ features have _optional_ build dependencies. You can't depend on stuff that _is simply not available_. You can't install it because it's not available anywhere unless someone provides in in form of packages again. Now make the same unmodified src.rpm compile on multiple platforms, where a different set of build requirements is available and possibly a different set of patches may need to be applied. This is the scenario of my initial comments. > Perl/Python are co-installable with different versions, and thus are a > different issue. Oh, great, a second Perl installation. As if Python/Python2 wouldn't be enough already. > Distros based on 2.96 were inherently broken anyhow, http://www.redhat.com/advice/speaks_gcc.html - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fdfk0iMVcrivHFQRAn5NAJ9ur6hZrTpasZLXrZaOenjLbO0NvACfaQRD h9VyPBaGSCEkBoaUeRFn9lM= =pkYV -----END PGP SIGNATURE----- From crandall at redhat.com Fri Oct 3 20:47:16 2003 From: crandall at redhat.com (Ken Crandall) Date: 03 Oct 2003 13:47:16 -0700 Subject: GUI xml-rpc bugzilla tool In-Reply-To: <1064862023.17437.29.camel@smoogen1.lanl.gov> References: <1064822624.20124.10.camel@localhost.localdomain> <20030929140836.A446@redhat.com> <20030929184945.GD11899@thyrsus.com> <1064862023.17437.29.camel@smoogen1.lanl.gov> Message-ID: <1065214035.1268.61.camel@magellan.laptop> Heh, It pretty much scared me that I knew the origin of the name of this utility... ...glad to know I'm not alone. Ken On Mon, 2003-09-29 at 12:00, Stephen Smoogen wrote: > And for all those interested in the US.. the Godzuki movie seems to be > available at Walmarts far and wide right now. You too can see a proud > Godzilla help his son make smoke rings while a little child in shorts > beats up bullies. > > On Mon, 2003-09-29 at 12:49, Eric S. Raymond wrote: > > Adrian Likins : > > > And on a similar note, `bugzuki` is a commandline tool using > > > the same interfaces... > > > > > > see http://people.redhat.com/alikins/repo/RPMS/ > > > > Bugzuki is interesting. If the XML-RPC stuff becomes part of stock > > Bugilla I would reallyu like to see it ship generally with Bugzilla. > > I'd switch over the fedora-submit tool I'm planning to do to using it. -- Ken Crandall Red Hat, Inc. From julo at altern.org Fri Oct 3 20:59:34 2003 From: julo at altern.org (Julien Olivier) Date: Fri, 03 Oct 2003 21:59:34 +0100 Subject: video player in fedora? In-Reply-To: <1065197499.23978.13.camel@icon.devel.redhat.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <1065091163.6837.15.camel@faro.stuttgart.redhat.com> <1065169747.4156.2.camel@mao.ikp.org> <1065197499.23978.13.camel@icon.devel.redhat.com> Message-ID: <1065214774.3614.10.camel@localhost.localdomain> On Fri, 2003-10-03 at 17:11, Havoc Pennington wrote: > On Fri, 2003-10-03 at 04:29, axel c wrote: > > Also, do > > these programs bring licensing issues? > > Do they ever. I don't think you can play many of the interesting video > formats without issues. (See one of the dozens of HUGE threads on this > list, and many other Red Hat lists, in the past. And no we can't include > the stuff with licensing issues and this will not change, again, see > those threads.) > > For video player in Core, I'd like to see one of the toolkit-based > players (either GTK+ or Qt). > See http://fedora.redhat.com/projects/desktop/defaults.html > > The general approach should be to have a player that uses a generic > media framework such as gstreamer; and then third parties can add > plugins. A player that has to link to plugins directly or via > non-generic interfaces will not permit third party plugins. > >From the legal point of view, would it be possible to have gstreamer automatically download missing plugins (even non-free/patented ones) ? That would of course mean that Fedora would have to have a list of repositories possibly containing packages with legal issues, even if none of those packages would be installed by default. Note that I don't care, for the moment, whether it's _technically_ possible or not. > Havoc > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From elanthis at awesomeplay.com Fri Oct 3 20:39:48 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 03 Oct 2003 16:39:48 -0400 Subject: Kind request: fix your packages In-Reply-To: <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> Message-ID: <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2003-10-03 at 16:11, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 03 Oct 2003 14:28:42 -0400, Sean Middleditch wrote: > > > Reading back a little ways, I'm now rather confused what your whole > > paragraph was about - we have the tools/networks, so newbies don't have > > to worry about libfoo-1.0 vs libfoo-0.9 and so on. > > Let's see. Quoting you: > > > > Users should just be able to grab any package online they want, > > and install it. > > Do you see rpm-dep-hell complaints from apt/yum/up2date users? > I don't. But rpmfind.net/rpmseek.com users complain regularly. > This is the context of the reply to your comment. Ah, you mean tools that don't grab dependencies on install. Those are a pain, aren't they? Whether you do "apt-get install foo" or "apt-get install ./foo.i386.rpm", either way depends should be grabbed and the package installed. Should be, anyways, they probably don't, do they? (that 30 second memory is kicking in again ;-) > > > No, your packaging method wants to screw over users, by making packages > > that are not easy or sane to use, as the features and dependencies > > present end up being based on silly things like where the packager built > > them, versus the place the user is installing them. > > Far from it. The binary packages are easy to use while the src.rpms > may need a few adjustments (sort of --define value) before they adapt > to altered build environments. I have a nifty idea. ^,^ Can you give me an example package where build depends are different per platform, but the resultant package is more or less the exact same (exact same feature set, exact same runtime dependencies) ? This hypothetical discussion is starting to loose focus of real issues versus imaginary ones. ;-) > > > The "low > > maintenance" of the packages results in "low flexibility" for the user, > > since they can no longer "just install" an app, but then become > > dependent on knowing things like which errata they have installed, which > > distro they have (most Windows users aren't even sure which of 4 > > versions of Windows they have, as a point of how bad it is to make a > > user know this stuff), etc. > > You're exaggerating again, a lot. You specifically said that packages are only intended to work on the platform they are built for, and working on anything else is just dumb luck. That's no fun. > > > Instead of fixing the problem, you're arguing about Fedora breaking the > > packaging habits you've been forced to develop to hack around the > > problem. > > Huh? You you sure you don't confuse me with anyone else? I don't think so - you're arguing for having Fedora avoid a perfectly legitimate change of the release version solely for the sake package dependencies, yes? > > > > I give up here. Sorry. Going on with this "discussion" is wasted time > > > as long as you don't propose a solution. A sentence like "*fix the > > > problem*, don't fix the *hack* for the problem" is written quickly. It > > > wipes away everything which has been commented on earlier. > > > > Solution I've mentioned before - the applications are simply built one > > way, the way that makes most sense for the user, and not on local build > > location dependencies. Let the package system deal with both runtime > > and buildtime dependencies, don't just randmly apply patches or remove > > features because the person building the package is too lazy to download > > the dependency. There's you fix, as I've said before. > > Insufficient since the packager needs to adapt to the software, not > vice versa. But as I've said, it is beyond my time to try to rephrase > again and again in the hope that you'll understand my point of view. yes, im feeling the same way. aren't opinions fun? you can never win. ~,^ > > > > > and the users can just install the dependencies. Otherwise, > > > > the app is broken from a user perspective. You really need to start > > > > looking at this from a users' point of view, and not a easily-packaged > > > > point of view. ;-) > > > > > > You fail to understand the implications of build requirements. > > > > > > > Not sure what you mean here; a package has requirements, you install > > them before building. If you don't, it doesn't build. Just like any > > other piece of software. What "implications" am I missing? (seriously > > - I don't enjoy being clueless if I can help it ;-) > > _Optional_ features have _optional_ build dependencies. You can't > depend on stuff that _is simply not available_. You can't install it > because it's not available anywhere unless someone provides in in form > of packages again. Now make the same unmodified src.rpm compile on And what is the problem with getting the packages for the build dependency? > multiple platforms, where a different set of build requirements is > available and possibly a different set of patches may need to be > applied. This is the scenario of my initial comments. Which if true is a serious problem, as I see it. Different flavours of Linux shouldn't need hugely different compilation options. Grab the stuff the package needs, build it, test it, done. If something else is needed based on something so silly as RH 8 vs RH 9 vs FC 1, something is wrong somewhere. > > > Perl/Python are co-installable with different versions, and thus are a > > different issue. > > Oh, great, a second Perl installation. As if Python/Python2 wouldn't > be enough already. If that's what it takes to make things work, then that's what it takes. I didn't say it was perfect, just that it solves the problem that users shouldn't ever have to rebuild to software, and users shouldn't have to run around figuring out what their system is to find the right package and deal with that mess. In a truly ideal world, Perl/Python/etc. wouldn't keep breaking compatibility so often. ~,^ Since that's *not* reality, the only solution left for sane packages (form a user's point of view again) is to let any necessary versions be installed so the user's apps just work and the user doesn't even have to think about OS versions or dependencies. > > > Distros based on 2.96 were inherently broken anyhow, > > http://www.redhat.com/advice/speaks_gcc.html As a developer who had to, and even recently still had to, explain to users why software didn't compile/work on RH7 (even tho it worked fine with both gcc 2.95 and gcc 3.2), that explanation has and still does fall very short. Even now, it's a pain, because it still kills intelligent packaging efforts for people who need to support those OS releases. Thank Red Hat. ;-) > > > - -- > Michael, who doesn't reply to top posts and complete quotes anymore. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQE/fdfk0iMVcrivHFQRAn5NAJ9ur6hZrTpasZLXrZaOenjLbO0NvACfaQRD > h9VyPBaGSCEkBoaUeRFn9lM= > =pkYV > -----END PGP SIGNATURE----- > > > -- > 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 julo at altern.org Fri Oct 3 21:07:33 2003 From: julo at altern.org (Julien Olivier) Date: Fri, 03 Oct 2003 22:07:33 +0100 Subject: Mozilla icons [was: Open Office 1.1 suggestion] In-Reply-To: <1065205891.25063.36.camel@icon.devel.redhat.com> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> Message-ID: <1065215253.3614.14.camel@localhost.localdomain> On Fri, 2003-10-03 at 19:31, Havoc Pennington wrote: > Hi, > > On Fri, 2003-10-03 at 14:12, Dan Williams wrote: > > I really would like to put in some nice looking icons. There are a > > couple options: > > > > There's a freedesktop.org spec for icon themes, so the ideal course of > action is simply to make OO.org read the current icon theme, rather than > trying to pick some hardcoded set. The icon theme spec is not 100% > trivial to implement so the simplest way to do so may be to use the > implementation in upcoming GTK+ 2.4. > > If we pick a hardcoded set, it should be the Bluecurve icon style; > Garrett can fill in missing icons in the Fedora Core 2 timeframe > probably. > While we are talking about applications not respecting the icon theme spec, what about Mozilla ? Are there any plans to make it respect the icon theme ? Or, at the very least, do you plan to use the MozCurveBlue theme (http://www.users.bigpond.net.au/gavindi/) by default on Fedora Core ? > Havoc > > > > -- > 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 Fri Oct 3 21:31:31 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 03 Oct 2003 23:31:31 +0200 Subject: Kind request: fix your packages In-Reply-To: <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> Message-ID: <1065216691.3337.11.camel@rousalka.dyndns.org> Le ven 03/10/2003 ? 22:11, Michael Schwendt a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 03 Oct 2003 14:28:42 -0400, Sean Middleditch wrote: > > > Reading back a little ways, I'm now rather confused what your whole > > paragraph was about - we have the tools/networks, so newbies don't have > > to worry about libfoo-1.0 vs libfoo-0.9 and so on. > > Let's see. Quoting you: > > > > Users should just be able to grab any package online they want, > > and install it. > > Do you see rpm-dep-hell complaints from apt/yum/up2date users? > I don't. I do but that's for stupid non-free jvms stuff we decided to distribute on nosrc.rpm form only at jpackage. A working gcj with the right provides would actually mean all the jakarta stuff could be cleanly distributed via apt/yum/whatever. 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 notting at redhat.com Fri Oct 3 21:41:07 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Oct 2003 17:41:07 -0400 Subject: video player in fedora? In-Reply-To: <1065214774.3614.10.camel@localhost.localdomain>; from julo@altern.org on Fri, Oct 03, 2003 at 09:59:34PM +0100 References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> <1065091163.6837.15.camel@faro.stuttgart.redhat.com> <1065169747.4156.2.camel@mao.ikp.org> <1065197499.23978.13.camel@icon.devel.redhat.com> <1065214774.3614.10.camel@localhost.localdomain> Message-ID: <20031003174106.B21447@devserv.devel.redhat.com> Julien Olivier (julo at altern.org) said: > From the legal point of view, would it be possible to have gstreamer > automatically download missing plugins (even non-free/patented ones) ? > That would of course mean that Fedora would have to have a list of > repositories possibly containing packages with legal issues, even if > none of those packages would be installed by default. No. Bill From ms-nospam-0306 at arcor.de Fri Oct 3 22:09:46 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 4 Oct 2003 00:09:46 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <20031004000946.0b045708.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 03 Oct 2003 16:39:48 -0400, Sean Middleditch wrote: > > Let's see. Quoting you: > > > > > > Users should just be able to grab any package online they want, > > > and install it. > > > > Do you see rpm-dep-hell complaints from apt/yum/up2date users? > > I don't. But rpmfind.net/rpmseek.com users complain regularly. > > This is the context of the reply to your comment. > > Ah, you mean tools that don't grab dependencies on install. Those are a > pain, aren't they? You do know what rpmfind.net and rpmseek.com are, don't you? > I have a nifty idea. ^,^ Can you give me an example package where > build depends are different per platform, but the resultant package is > more or less the exact same (exact same feature set, exact same runtime > dependencies) ? No, because I've been referring to "different build deps and different feature set" all the time. Package examples for that [different] scenario could be Bluefish (aspell), Sylpheed (aspell, gpgme, gnupg), Apt as well as packages that depend on NPTL, openssl and packages which set a distribution-specific package release tag themselves. And let me repeat -- might be necessary ;) -- that detection of some build platform features can be performed without examining /etc/redhat-release, but can get ugly. > This hypothetical discussion is starting to loose focus > of real issues versus imaginary ones. ;-) Wonder why? Not sure what I've been dragged into. :) > You specifically said that packages are only intended to work on the > platform they are built for, and working on anything else is just dumb > luck. That's no fun. Doesn't matter. Packages are created for a known set of distributions. You cannot make sure that a package compiles with older software and that it will still compile with newer software. Such configurations are unsupported. > > > Instead of fixing the problem, you're arguing about Fedora breaking the > > > packaging habits you've been forced to develop to hack around the > > > problem. > > > > Huh? You you sure you don't confuse me with anyone else? > > I don't think so - you're arguing for having Fedora avoid a perfectly > legitimate change of the release version solely for the sake package > dependencies, yes? No. Point me to the message in the archives, please. > > _Optional_ features have _optional_ build dependencies. You can't > > depend on stuff that _is simply not available_. You can't install it > > because it's not available anywhere unless someone provides in in form > > of packages again. Now make the same unmodified src.rpm compile on > > And what is the problem with getting the packages for the build > dependency? Lack of human resources to package the latest software for old distributions? Maybe even incompatibility due to insufficient compiler versions? Maybe conflicts with other components? - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/ffOq0iMVcrivHFQRAv0OAJ40rxTKKbU8vXt1jCno5PmEi5g1dACcD9Eu rAyiBTXOuRBhN63cqYT1Q7A= =JxIM -----END PGP SIGNATURE----- From gavin.henry at magicfx.co.uk Fri Oct 3 22:40:18 2003 From: gavin.henry at magicfx.co.uk (G Henry) Date: Fri, 3 Oct 2003 23:40:18 +0100 Subject: grsecurity kernels Message-ID: <200310032340.22988.gavin.henry@magicfx.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, are there any plans to do grsecurity kernel rpms? - -- Regards Trying to be a RHCE http://www.magicfx.co.uk http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/ffrWgNqd7Kng8UoRAlsiAKCyvJGxFxIx4hOtxeOXe+T99GKmPgCeNe8h RhNvheyRSRKWWzYjId7RawY= =1lAz -----END PGP SIGNATURE----- From elanthis at awesomeplay.com Fri Oct 3 23:31:31 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 03 Oct 2003 19:31:31 -0400 Subject: Kind request: fix your packages In-Reply-To: <20031004000946.0b045708.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <20031004000946.0b045708.ms-nospam-0306@arcor.de> Message-ID: <1065223891.32213.65.camel@stargrazer.home.awesomeplay.com> On Fri, 2003-10-03 at 18:09, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 03 Oct 2003 16:39:48 -0400, Sean Middleditch wrote: > > > > Let's see. Quoting you: > > > > > > > > Users should just be able to grab any package online they want, > > > > and install it. > > > > > > Do you see rpm-dep-hell complaints from apt/yum/up2date users? > > > I don't. But rpmfind.net/rpmseek.com users complain regularly. > > > This is the context of the reply to your comment. > > > > Ah, you mean tools that don't grab dependencies on install. Those are a > > pain, aren't they? > > You do know what rpmfind.net and rpmseek.com are, don't you? Somewhat - big links of packages, yes? Good examples of sickeningly horrible site/UI design, if nothing else. ~,^ > > > I have a nifty idea. ^,^ Can you give me an example package where > > build depends are different per platform, but the resultant package is > > more or less the exact same (exact same feature set, exact same runtime > > dependencies) ? > > No, because I've been referring to "different build deps and different > feature set" all the time. I'm guessing the feature set argument is pointless, then, since neither of us agree which is more important. > > Package examples for that [different] scenario could be Bluefish > (aspell), Sylpheed (aspell, gpgme, gnupg), Apt as well as packages > that depend on NPTL, openssl and packages which set a > distribution-specific package release tag themselves. And let me > repeat -- might be necessary ;) -- that detection of some build > platform features can be performed without examining > /etc/redhat-release, but can get ugly. Right, which is the "fix the problem, not the hack" I've been mentioning a lot - if it *is* so ugly, then *that* needs to be fixed. > > > This hypothetical discussion is starting to loose focus > > of real issues versus imaginary ones. ;-) > > Wonder why? Not sure what I've been dragged into. :) :P > > > You specifically said that packages are only intended to work on the > > platform they are built for, and working on anything else is just dumb > > luck. That's no fun. > > Doesn't matter. Packages are created for a known set of distributions. > You cannot make sure that a package compiles with older software and > that it will still compile with newer software. Such configurations > are unsupported. I've never said otherwise. > > > > > Instead of fixing the problem, you're arguing about Fedora breaking the > > > > packaging habits you've been forced to develop to hack around the > > > > problem. > > > > > > Huh? You you sure you don't confuse me with anyone else? > > > > I don't think so - you're arguing for having Fedora avoid a perfectly > > legitimate change of the release version solely for the sake package > > dependencies, yes? > > No. Point me to the message in the archives, please. http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00061.html Hmm, looks like I did get you confused with someone else there. my apologies. ^^; > > > > _Optional_ features have _optional_ build dependencies. You can't > > > depend on stuff that _is simply not available_. You can't install it > > > because it's not available anywhere unless someone provides in in form > > > of packages again. Now make the same unmodified src.rpm compile on > > > > And what is the problem with getting the packages for the build > > dependency? > > Lack of human resources to package the latest software for old > distributions? Maybe even incompatibility due to insufficient compiler > versions? Maybe conflicts with other components? but the latest software shouldn't *need* repackaging for older distributions, of course. > > > - -- > Michael, who doesn't reply to top posts and complete quotes anymore. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQE/ffOq0iMVcrivHFQRAv0OAJ40rxTKKbU8vXt1jCno5PmEi5g1dACcD9Eu > rAyiBTXOuRBhN63cqYT1Q7A= > =JxIM > -----END PGP SIGNATURE----- > > > -- > 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 veillard at redhat.com Sat Oct 4 00:15:28 2003 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 3 Oct 2003 20:15:28 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065223891.32213.65.camel@stargrazer.home.awesomeplay.com>; from elanthis@awesomeplay.com on Fri, Oct 03, 2003 at 07:31:31PM -0400 References: <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <20031004000946.0b045708.ms-nospam-0306@arcor.de> <1065223891.32213.65.camel@stargrazer.home.awesomeplay.com> Message-ID: <20031003201528.S21001@redhat.com> On Fri, Oct 03, 2003 at 07:31:31PM -0400, Sean Middleditch wrote: > > You do know what rpmfind.net and rpmseek.com are, don't you? > > Somewhat - big links of packages, yes? Good examples of sickeningly > horrible site/UI design, if nothing else. ~,^ I assume I have a right to defend myself :-) Well, design is from 97, and I spend nearly no time working on it. "If it ain't broken, don't fix it" and since I very seldomly receive this kind of complaints (which might be perfectly justified :-) though I see a lot of use, so I don't change it. Another key point is that Cool URI don't change [1], and the trend of breaking all the links on a site to loose all the references, searches, and piss off the userbase every year or so, while very appreciated of a lot of the web designer apparently, it just against my own standards. It's like an old truck, it's not shiny, it's a bit rusty, smells and leak oil, but when you need it, it's there and it gets you and your stuff where you want to go, though you won't use it to attract girls by driving downtown, it's not pretty. Daniel [1] http://www.w3.org/Provider/Style/URI.html -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Nicolas.Mailhot at laPoste.net Fri Oct 3 21:43:36 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 03 Oct 2003 23:43:36 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1065217416.3337.22.camel@rousalka.dyndns.org> Le ven 03/10/2003 ? 22:39, Sean Middleditch a ?crit : > On Fri, 2003-10-03 at 16:11, Michael Schwendt wrote: > > > Perl/Python are co-installable with different versions, and thus are a > > > different issue. > > > > Oh, great, a second Perl installation. As if Python/Python2 wouldn't > > be enough already. > > If that's what it takes to make things work, then that's what it takes. > I didn't say it was perfect, just that it solves the problem that users > shouldn't ever have to rebuild to software, and users shouldn't have to > run around figuring out what their system is to find the right package > and deal with that mess. In a truly ideal world, Perl/Python/etc. > wouldn't keep breaking compatibility so often. ~,^ Since that's *not* > reality, the only solution left for sane packages (form a user's point > of view again) is to let any necessary versions be installed so the > user's apps just work and the user doesn't even have to think about OS > versions or dependencies. Don't make me laugh. The user cares about duplicate stuff too. Before we build a serious infrastructure that enabled us to modularise stuff someone would complain every other week we shipped java 1.3 jars with our tomcat rpm (and those jars were necessary to run it with a 1.3 jvm, and didn't hurt when using a 1.4 jvm. But for a 1.4 user they were redundant stuff and we got complains). Show me a repository with big fat packages that include all deps to be standalone and I'll show you a repository no one wants to use. Users may not all know the zen of packaging but it will only take a few long downloads or stuffed disks to enlighten them. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From elanthis at awesomeplay.com Sat Oct 4 03:23:50 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 03 Oct 2003 23:23:50 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065217416.3337.22.camel@rousalka.dyndns.org> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> Message-ID: <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> On Fri, 2003-10-03 at 17:43, Nicolas Mailhot wrote: > Le ven 03/10/2003 ? 22:39, Sean Middleditch a ?crit : > > On Fri, 2003-10-03 at 16:11, Michael Schwendt wrote: > > > > > Perl/Python are co-installable with different versions, and thus are a > > > > different issue. > > > > > > Oh, great, a second Perl installation. As if Python/Python2 wouldn't > > > be enough already. > > > > If that's what it takes to make things work, then that's what it takes. > > I didn't say it was perfect, just that it solves the problem that users > > shouldn't ever have to rebuild to software, and users shouldn't have to > > run around figuring out what their system is to find the right package > > and deal with that mess. In a truly ideal world, Perl/Python/etc. > > wouldn't keep breaking compatibility so often. ~,^ Since that's *not* > > reality, the only solution left for sane packages (form a user's point > > of view again) is to let any necessary versions be installed so the > > user's apps just work and the user doesn't even have to think about OS > > versions or dependencies. > > Don't make me laugh. The user cares about duplicate stuff too. > Before we build a serious infrastructure that enabled us to modularise > stuff someone would complain every other week we shipped java 1.3 jars > with our tomcat rpm (and those jars were necessary to run it with a 1.3 > jvm, and didn't hurt when using a 1.4 jvm. But for a 1.4 user they were > redundant stuff and we got complains). Are you talking about users, or sysadmins/hackers? I'd doubt a user would even know a jar file is, or their installed version of Java. Certainly, every user I've dealt with recently (including a handful friends and a number of coworkers) would have no clue; they can barely remember their OS is "Microsoft Windows" and not "Compaq Explorer." ;-) (and no, that isn't an implication users are stupid, merely that they often don't know much about computers. i can't keep the names of various parts of a car engine straight, but that's only because i'm not really familiar with it, and I don't really care in the least, so long as it moves. just like many users don't care how the computer runs, jsut that it works. and yes, that was a real example, not my usual satirical exaggeration ;-) > > Show me a repository with big fat packages that include all deps to be > standalone and I'll show you a repository no one wants to use. Users may > not all know the zen of packaging but it will only take a few long > downloads or stuffed disks to enlighten them. All dependencies embedded aren't at all needed. Just the ones people can't develop and/or package correctly. If things were developed using sane release and maintenance practices, you'd never have need to ship a dependency with an application. It's only when the dependency is released/maintained in the usual inexperienced 13-year-old style that you need to do that. ~,^ > > Cheers, -- Sean Middleditch AwesomePlay Productions, Inc. From hp at redhat.com Sat Oct 4 04:13:06 2003 From: hp at redhat.com (Havoc Pennington) Date: 04 Oct 2003 00:13:06 -0400 Subject: Mozilla icons [was: Open Office 1.1 suggestion] In-Reply-To: <1065215253.3614.14.camel@localhost.localdomain> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> <1065215253.3614.14.camel@localhost.localdomain> Message-ID: <1065240786.12691.3.camel@dhcppc3> On Fri, 2003-10-03 at 17:07, Julien Olivier wrote: > > While we are talking about applications not respecting the icon theme > spec, what about Mozilla ? > > Are there any plans to make it respect the icon theme ? Or, at the very > least, do you plan to use the MozCurveBlue theme > (http://www.users.bigpond.net.au/gavindi/) by default on Fedora Core ? > Agree in principle this is a good idea, and there's been some idea of doing it for a while, but just hasn't been time to get it done. Probably too late for Fedora Core 1. For Fedora Core 2, one possibility is that we move to Firebird or Epiphany as the default browser instead, since those should be reaching a usable state, and the current Moz frontend is being replaced by Firebird. But if that doesn't happen we should definitely be looking into the theme. Havoc From behdad at cs.toronto.edu Sat Oct 4 04:23:06 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sat, 4 Oct 2003 00:23:06 -0400 Subject: Mozilla icons [was: Open Office 1.1 suggestion] In-Reply-To: <1065240786.12691.3.camel@dhcppc3> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> <1065215253.3614.14.camel@localhost.localdomain> <1065240786.12691.3.camel@dhcppc3> Message-ID: On Sat, 4 Oct 2003, Havoc Pennington wrote: > On Fri, 2003-10-03 at 17:07, Julien Olivier wrote: > > > > While we are talking about applications not respecting the icon theme > > spec, what about Mozilla ? > > > > Are there any plans to make it respect the icon theme ? Or, at the very > > least, do you plan to use the MozCurveBlue theme > > (http://www.users.bigpond.net.au/gavindi/) by default on Fedora Core ? > > > > Agree in principle this is a good idea, and there's been some idea of > doing it for a while, but just hasn't been time to get it done. > > Probably too late for Fedora Core 1. For Fedora Core 2, one possibility > is that we move to Firebird or Epiphany as the default browser instead, > since those should be reaching a usable state, and the current Moz > frontend is being replaced by Firebird. But if that doesn't happen we > should definitely be looking into the theme. Switching the default browser to Epiphany is really appreciated. Right now GNOME applications default to Epiphany, and others to Mozilla. BTW, the worst thing I found about that is that Epiphany has an extra "Open Link" option as the first one when you right click on a link, so the second choice is "Open Link in New Windows" instead of "Open Link in New Tab". Actually that's the most important thing that matters for me. > Havoc behdad From rezso at rdsor.ro Sat Oct 4 11:36:21 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Sat, 4 Oct 2003 07:36:21 -0400 Subject: alpha architecture In-Reply-To: References: Message-ID: <200310040736.21490.rezso@rdsor.ro> On Friday 03 October 2003 15:01, Mike A. Harris wrote: > On Thu, 2 Oct 2003, Jim wrote: > >I have the HP edition of RH7.2 installed on a 21164 533Mhz pc164lx. All > >is well with the system and I have had no problems except that there are > >no software updates/upgrades to the latest versions of applications I need > >such as postgresql/php/apache/ssl etc. Then I ran across the Fedora > >project and noticed that the latest alpha rpm's for these applications > >were availible for download. The problem is that they don't work on the > >7.2 release and rpm -Uvh for the packages I need give me countless failed > >deps as I expected they would. Will there be an upcomming alpha iso > >release for the latest redhat version? If not, I would like to port > >an updated rh release for the alpha architecture. If any one is doing > >this already or if anybody needs help doing this I'd be pleased to help > >out. If someone is already doing this could you please point me in the > >right direction? > > Myself, Jeff Garzik, Richard Henderson, Phil "Bryce" Copeland and > various people from DEC/COMPAQ/HP have been slowly making evil > plans to work on an alpha port of the current distribution > sometime soon. We have no details as of yet, but once we are > ready to start building and pushing packages we'll let people > know here. The intent is to make a Fedora/Alpha distribution. Oh, cool ! kudos, power, and unlimited 32/24 time to you guys !! All the best, cristian > > That is all the detail I have for now. When there is more > information, we will announce it here. -- Life in itself has no meaning. Life is an opportunity to create meaning. \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ From hp at redhat.com Sat Oct 4 04:51:11 2003 From: hp at redhat.com (Havoc Pennington) Date: 04 Oct 2003 00:51:11 -0400 Subject: Mozilla icons [was: Open Office 1.1 suggestion] In-Reply-To: References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> <1065215253.3614.14.camel@localhost.localdomain> <1065240786.12691.3.camel@dhcppc3> Message-ID: <1065243071.12845.1.camel@dhcppc3> On Sat, 2003-10-04 at 00:23, Behdad Esfahbod wrote: > Switching the default browser to Epiphany is really appreciated. > Right now GNOME applications default to Epiphany, and others to > Mozilla. That's a bug, however. Everything should default to Mozilla right now as it's the default web browser. > BTW, the worst thing I found about that is that > Epiphany has an extra "Open Link" option as the first one when > you right click on a link, so the second choice is "Open Link in > New Windows" instead of "Open Link in New Tab". Actually that's > the most important thing that matters for me. Discussion of this should really be on the epiphany mailing list or bugzilla.gnome.org, as that's where the decision would be made. Havoc From jspaleta at princeton.edu Sat Oct 4 06:26:50 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Sat, 04 Oct 2003 02:26:50 -0400 Subject: Fedora Bugzilla Triage-Overview Message-ID: <1065248810.18486.66.camel@localhost.localdomain> Well someone called my bluff and dared me to write a useful post to a fedora mailinglist. I'd like to start a discussion on implementing a community based bugzilla triage team for the Fedora bugzilla. Okay well actually I'd be interested in a broader discussion of establishing a full guide for beta testers/bug hunters for the fedora.redhat.com..but I'd like to focus on triage first, since bugzilla triage has the potential to greatly improve the productivity of package maintainers/developers and its something interested community members with little coding skill can spend a few minutes here and there during the day making a useful contribution if there is a good set of guidelines and some mentoring. So in preparation for this little essay. I've read over the Gnome Bugsquad's project's detailed outline of how to do useful gnome bugzilla triage. http://developer.gnome.org/projects/bugsquad/ http://developer.gnome.org/projects/bugsquad/triage/ I don't want to rehash the full documentation Gnome has done, but I would like to hi-lite some of the things Gnome's Bugsquad webpages that would probably be useful for a Fedora triage team. Okay well actually taking pretty much the entire process Gnome has developed sort of makes sense to me. The only issue i see that Fedora will have to deal with is how to escalate a bug ticket for a package to an upstream project maintenance system, But here are some specific things I like about gnomes bugsquad: *) Strong documentation on the website on the steps to triage bugs. Clear example cases, http://developer.gnome.org/projects/bugsquad/triage/examples.html and even more importantly examples on how to form bugzilla queries that make sense when trying to pick bugs to triage. http://developer.gnome.org/projects/bugsquad/triage/finding-bugs.html *)A focus on having people learn from established bugsquad members. New contributors to the triage effort are encouraged to suggest how bugreports should be changed to active bugsquad members either through irc or in a mailinglist...and over time they earn more access to make bugzilla bugreport changes themselves..once they've shown they've got the hang of how to triage. It's a mentor approach to get around bugzilla's inherent steep learning curve for the average new bug reporter. *) examples of polite stock responses when bugs need more information to be useful for the developer to understand the technical specifics of what is going wrong. The 'get to the point' culture of how development is done can be a culture shock to people who are new to this sort of environment. The current Fedora test release seems to be appealing to many non-techinically savvy users...people who are excited by the project, and want to make a best effort at contributing via bugreporting...some of these people are stumbling over how bugzilla interacts with them. Not in a technical sense...but strictly on perception oh how valuable their contribution. A triage team can be used to grease the wheels a little. The polite stock responses gnome has could go a long way to overcome the perception issues bugzilla's rather terse responses are causing. http://developer.gnome.org/projects/bugsquad/triage/stock-responses.html *) Last but not least....organized Bug Day efforts...to clean the cruft out of Fedora. If a triage team is of significant interest as a tool to increase the productivity of the fedora developers...i think the first step is laying down some useful guidelines and a 12 easy steps outline of what triage in fedora involves so it can be documented on the website. I can't imagine its going to look horribly different than how gnome handles this issue. The other think i really think is different is how to handle bugs that should also be reported to an upstream project maintainer. I welcome further discussion on this issue. Other contrasting models of how this sort of bug triage is done by other projects than Gnome would be useful too. I firmly believe that the pacing item in development processes will continue to be the number of hours in a day a developer has. I'm not going to pretend that everybody in this community has the ability to contribute technical skill on the level needed to actually constructively work on major portions of he Fedora codebase. But i think there are a significant number of technically proficient people who can help the experts keep their todo lists organized...and act as an interface between end-user and developer, saving valuable developer time for code writing, instead of "please add more info" message writing in bugzilla. -jef"Ask not what the fedora developers can do for you...but what you can do to for the fedora developers"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 behdad at cs.toronto.edu Sat Oct 4 06:52:26 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sat, 4 Oct 2003 02:52:26 -0400 Subject: Mozilla icons [was: Open Office 1.1 suggestion] In-Reply-To: <1065243071.12845.1.camel@dhcppc3> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> <1065215253.3614.14.camel@localhost.localdomain> <1065240786.12691.3.camel@dhcppc3> <1065243071.12845.1.camel@dhcppc3> Message-ID: On Sat, 4 Oct 2003, Havoc Pennington wrote: > On Sat, 2003-10-04 at 00:23, Behdad Esfahbod wrote: > > Switching the default browser to Epiphany is really appreciated. > > Right now GNOME applications default to Epiphany, and others to > > Mozilla. > > That's a bug, however. Everything should default to Mozilla right now as > it's the default web browser. It would be nice if everything would rely on htmlview. I even mean the Browser icon on the panel, so that changing to epiphany in /etc/htmlview.conf would do the switch. BTW, htmlview is still looking for galeon instead of epiphany. I'm going to file a bug right now. > > BTW, the worst thing I found about that is that > > Epiphany has an extra "Open Link" option as the first one when > > you right click on a link, so the second choice is "Open Link in > > New Windows" instead of "Open Link in New Tab". Actually that's > > the most important thing that matters for me. > > Discussion of this should really be on the epiphany mailing list or > bugzilla.gnome.org, as that's where the decision would be made. Sure. > Havoc From andyhanton at comcast.net Sat Oct 4 07:25:09 2003 From: andyhanton at comcast.net (Andy Hanton) Date: Sat, 04 Oct 2003 03:25:09 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' Message-ID: <1065252308.4488.116.camel@andy> I think that the 'Kind request: fix your packages' thread is going off course by discussing how to fix what we have instead of what we need to implement to make Sean's vision possible while making it possible to support older systems easily. I think that we need development tools that work more like the tools on Mac OS classic. Macs didn't actually have libraries so they got some very cool features for free. You can actually build an application on Mac OS 9 and run it on Mac OS 1. You don't need a chroot environment or any other fancy setup. All you need to do is stick to the API that Mac OS 1.0 supported and it just works. The bad part was that if you used a function that wasn't supported the application would crash at runtime. Because Linux has library versioning it should be able to get the flexibility of compiling easily for older systems while knowing for sure that the binary will work on the old systems. On Linux the dependencies of a library or binary get inflated by the system. For example all binaries built on Redhat 9 depend on libc 2.3 but they usually don't depend on any new APIs introduced in 2.3. If each developer compiled against the minimal library versions necessary then the resulting binaries would be nearly universal when used with an rpm repository. For example it would be possible to compile abiword 2.0 with gnome support on RedHat 9 or Fedora 1.0 and have the same binary run on redhat 7.3. The package manager would automatically the gnome2 platform libraries from the Fedora 1.0 release and install them. Although it would require more disk space, end users would probably prefer to have only one Linux/i386 binary just like there is only one Windows binary. I am not a compiler guru, so I don't know how we get there. It might be a good idea to compile the core of the OS inside a LSB chroot. Another possibility might be using pkg-config to request a specific minor version of a library. It might look something like gcc -o foo foo.c `pkg-config --cflags --libs gtk+-2.0:2.0 libgnome-2.0:2.0 libc-2:2.2` The library would implement this by specifying a preprocessor macro to set with the requested library version number. Then it would add ifdefs to the headers so that only the symbols available in the particular version would be available. It would be cool to support aliases for different versions. For example gtk+-2.0:LSB_2_0 might be equivalent to gtk+-2.0:2.0. There might be some extra linker magic necessary, but since RedHat employs lots of compiler tool chain experts I don't think it would be impossible. It might be possible to reuse whatever tools the LSB project is using to generate stub libraries for each minor version of every library. To make the automatic dependency fetching work right the repository should probably provide a mapping between library names and package names. I would think that it would be easy to write a script that would extract this information from all the rpms in a yum or apt-get repository and write it to a file with a standardized name and location. In this setup a few programs that can optionally use a feature that a newer distribution has would need to be compiled more than once. Packagers wouldn't need to figure out the dependency information because the developer would have already done that work. Unfortunately, if a single binaries could be built to run on any recent Linux system, then the author of the code would probably package the binary themselves. Some Fedora developers would need to find a new way to spend their free time. ;-) -- Andy Hanton From drepper at redhat.com Sat Oct 4 07:48:45 2003 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 04 Oct 2003 00:48:45 -0700 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065252308.4488.116.camel@andy> References: <1065252308.4488.116.camel@andy> Message-ID: <3F7E7B5D.70809@redhat.com> Andy Hanton wrote: > On Linux the dependencies of a library or binary get inflated by the > system. For example all binaries built on Redhat 9 depend on libc 2.3 > but they usually don't depend on any new APIs introduced in 2.3. That's wrong. The versioning mechanism always picks the minimum required versions. There is no automatic inflation. The fact that most apps linked against glibc 2.3 will also require GLIBC_2.3 is that some fundamental interfaces changed. > It might look something like gcc -o foo foo.c > `pkg-config --cflags --libs gtk+-2.0:2.0 libgnome-2.0:2.0 libc-2:2.2` That's something I never want to see. Compiling against old headers and linking with old libraries always means a) more bugs and b) less optimal results. For instance, compile some code using conditional variables with old headers and new headers, and compare the resulting performance and memory consumption (and maybe even stability). If I have the possibility to have better binaries I am not willing to give this up just because some people clinch to their old installations and demand equal treatment when it comes to package updates. -- --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- From Nicolas.Mailhot at laPoste.net Sat Oct 4 08:55:06 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 04 Oct 2003 10:55:06 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> Message-ID: <1065257706.6399.37.camel@rousalka.dyndns.org> Le sam 04/10/2003 ? 05:23, Sean Middleditch a ?crit : > On Fri, 2003-10-03 at 17:43, Nicolas Mailhot wrote: > > Le ven 03/10/2003 ? 22:39, Sean Middleditch a ?crit : > > > On Fri, 2003-10-03 at 16:11, Michael Schwendt wrote: > > > > > > > Perl/Python are co-installable with different versions, and thus are a > > > > > different issue. > > > > > > > > Oh, great, a second Perl installation. As if Python/Python2 wouldn't > > > > be enough already. > > > > > > If that's what it takes to make things work, then that's what it takes. > > > I didn't say it was perfect, just that it solves the problem that users > > > shouldn't ever have to rebuild to software, and users shouldn't have to > > > run around figuring out what their system is to find the right package > > > and deal with that mess. In a truly ideal world, Perl/Python/etc. > > > wouldn't keep breaking compatibility so often. ~,^ Since that's *not* > > > reality, the only solution left for sane packages (form a user's point > > > of view again) is to let any necessary versions be installed so the > > > user's apps just work and the user doesn't even have to think about OS > > > versions or dependencies. > > > > Don't make me laugh. The user cares about duplicate stuff too. > > Before we build a serious infrastructure that enabled us to modularise > > stuff someone would complain every other week we shipped java 1.3 jars > > with our tomcat rpm (and those jars were necessary to run it with a 1.3 > > jvm, and didn't hurt when using a 1.4 jvm. But for a 1.4 user they were > > redundant stuff and we got complains). > > Are you talking about users, or sysadmins/hackers? I'd doubt a user > would even know a jar file is, or their installed version of Java. Well java is a bit special. Most upstream projects do not care about packaging at all (you know, big ugly system-dependent mess, not like their WORA nirvana) so people are used to struggle to install stuff. When they're fed up they find a nice packaging project like jpackage and are delighted ; however they can see if you've done something less optimal that what they did manually before and will complain (loudly) in that case. But even if the proportion of clueful users were less for a mainstream project like Fedora I strongly object to the idea bad packaging should be allowed to ease some users pain. If you drive out all enlightened users the contributor pool will dry up and Redhat will be left alone supporting Fedora - not something they're ready to I think. > Certainly, every user I've dealt with recently (including a handful > friends and a number of coworkers) would have no clue; they can barely > remember their OS is "Microsoft Windows" and not "Compaq Explorer." > ;-) (and no, that isn't an implication users are stupid, merely that > they often don't know much about computers. i can't keep the names of > various parts of a car engine straight, but that's only because i'm not > really familiar with it, and I don't really care in the least, so long > as it moves. just like many users don't care how the computer runs, > jsut that it works. and yes, that was a real example, not my usual > satirical exaggeration ;-) Sure. But do you see any of them installing Fedora by themselves ? If there is someone clueful enough somewhere to install Linux he will understand some packaging issues so your example is not relevant (and he won't have to understand everything to point out at least a few mistakes) > > Show me a repository with big fat packages that include all deps to be > > standalone and I'll show you a repository no one wants to use. Users may > > not all know the zen of packaging but it will only take a few long > > downloads or stuffed disks to enlighten them. > > All dependencies embedded aren't at all needed. Just the ones people > can't develop and/or package correctly. I like the "just" bit. That was already the case for libgal for a long time. And it is a pita for normal users - package managers like apt do not like duplicate stuff so people have to largely handle this manually. Don't open the gates if you're not prepared to handle the flood that *will* follow. > If things were developed using > sane release and maintenance practices, you'd never have need to ship a > dependency with an application. It's only when the dependency is > released/maintained in the usual inexperienced 13-year-old style that > you need to do that. ~,^ I see you've never tried to package a large pool of inter-dependant projects. In 80%+ of the cases the problem lies upstream. If the packager accepts the deps upstream wants to force on him the mess will only grow. Most of the upstream projects I work with would jump to the possibility to embed all the deps they need because that matches their vision of their app as the center of the system. Someone must say stop at one point. It might be a larger project (Gnome), a packaging project (Fedora) or the end-user (because in the end duplicating stuff is a maintenance burden and you're only exchanging upstream-level work with packager or user work by embedding stuff). You're right most users do not want to bother with package deps. You're wrong however in thinking they'll accept the mess a massive embedding policy would foster on them. I'm perfectly happy with un-packageable projects (ie projects that do not address packager needs and can not work with the same deps as the rest of the system) being kicked out of Fedora. I'm also perfectly happy with old releases not getting the same kind of care as new ones. They have to die at some point - you can not support every single release at vitam eternam. Nobody here will knowingly make upgrades harder for older releases. Sacrificing the system sanity to the golden cow of eternal upgradeability however will only produce a Windows-like mess were everything "sort-of" works for everyone. You have to do some spring cleanups, even in real life. 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 buildsys at porkchop.devel.redhat.com Sat Oct 4 09:48:38 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sat, 4 Oct 2003 05:48:38 -0400 Subject: rawhide report: 20031004 changes Message-ID: <200310040948.h949mcg18824@porkchop.devel.redhat.com> New package gnopernicus gnopernicus screen magnifier Updated Packages: balsa-2.0.15-1 -------------- * Fri Oct 03 2003 Bill Nottingham 2.0.15-1 - add a versioned libesmtp *build*requirement, not just requirement (#71319) - use libgnomeprint22 (#97744, ) - update to 2.0.15 gaim-0.59.8-1 ------------- * Wed Apr 09 2003 Matt Wilson 1:0.59.8-1 - use system libtool (#88340) * Wed Jan 29 2003 Christopher Blizzard 0.59.8-0 - Update to 0.59.8 * Wed Jan 22 2003 Tim Powers - rebuilt * Wed Dec 18 2002 Elliot Lee 0.59-11 - Add libtoolize etc. steps * Tue Dec 17 2002 Elliot Lee 0.59-10 - Rebuild * Mon Nov 18 2002 Tim Powers - build on all arches * Fri Aug 09 2002 Christopher Blizzard 0.59-7 - Include patch that uses htmlview instead of calling Netscape directly - Include patch that turns off the buddy ticker and changes the button look to the (sane) default. * Thu Aug 01 2002 Christopher Blizzard - Fix .desktop file, and put it in the right place. - More .desktop file fixes * Tue Jun 25 2002 Christopher Blizzard - Update to 0.59. - Disable perl for now. * Sun May 26 2002 Tim Powers - automated rebuild * Fri May 24 2002 Matt Wilson 0.58-1 - 0.58 - remove applet * Fri Mar 22 2002 Trond Eivind Glomsr?d 0.53-1 - Langify * Wed Mar 13 2002 Christopher Blizzard - update 0.53 * Thu Feb 21 2002 Christopher Blizzard - update to 0.52 * Tue Jan 29 2002 Christopher Blizzard - update to 0.51 * Fri Sep 14 2001 Matt Wilson - update to 0.43 * Fri Aug 03 2001 Christopher Blizzard - Add BuildRequires for gnome-libs-devel (bug #44739) * Mon Jul 02 2001 Christopher Blizzard - Add BuildRequires for gnome-core-devel (bug #44739) * Sun Jun 24 2001 Elliot Lee - Bump release + rebuild. * Thu Feb 15 2001 Trond Eivind Glomsr?d - make it compile * Sun Feb 11 2001 Tim Powers - updated to 0.11.0pre4 (bug fixes) - applied Bero's konqueror patch to fix kfm->konq * Tue Dec 05 2000 Tim Powers - updated to 0.11.0pre2 - enable gnome support - updated ispell to aspell patch - cleaned up file list * Thu Nov 16 2000 Tim Powers - updated to 0.10.3 * Fri Nov 10 2000 Tim Powers - update to 0.10.2 * Mon Sep 11 2000 Tim Powers - some ideas taken from the package available at the gaim website, mainly to install the applet stuff too. * Wed Aug 09 2000 Tim Powers - added Serial so that we can upgrade from Helix packages from 6.2 * Mon Jul 24 2000 Prospector - rebuilt * Tue Jul 18 2000 Tim Powers - changed default spell checker to aspell from ispell, patched. - requires aspell * Mon Jul 10 2000 Tim Powers - rebuilt * Thu Jun 22 2000 Tim Powers - fixed problems with ldconfig PreReq, shouls have been /sbin/ldconfig * Mon Jun 12 2000 Preston Brown - 0.9.19 - fix ldconfig stuff * Thu Jun 01 2000 Tim Powers - cleaned up spec for use with RPM 4.0 (al la _sysconfdir _datadir etc) - update to 0.9.17 - yay! a man page! * Thu May 25 2000 Tim Powers - we left a bunch of stuff out, pixmaps, plugins. Fixed - added applnk entry * Wed May 10 2000 Tim Powers - updated to 0.9.15 * Mon Apr 24 2000 Matt Wilson - updated to 0.9.14 * Mon Apr 24 2000 Matt Wilson - updated to 0.9.13 * Thu Feb 10 2000 Matt Wilson - added patch to prevent floating point errors in lag-o-meter update code * Wed Nov 10 1999 Tim Powers - updated to 0.9.10 * Tue Jul 13 1999 Tim Powers - rebuilt and put into Powertools 6.1 * Mon Jul 12 1999 Dale Lovelace - First RPM Build gaim-0.70-2 ----------- gnome-themes-2.4.0-1 -------------------- * Fri Oct 03 2003 Alexander Larsson 2.4.0-1 - 2.4.0 kernel-2.4.22-1.2086.nptl ------------------------- * Fri Oct 03 2003 Dave Jones - Disable laptop_mode kudzu-1.1.31-1 -------------- * Fri Oct 03 2003 Bill Nottingham 1.1.31-1 - tweak RadeonIGP exclude list to be less exclusive * Thu Oct 02 2003 Bill Nottingham 1.1.30-1 - resurrect PCI disabled probe for video cards (#91265, #106030) - don't probe PS/2 mice if we appear to be running on a local X display * Wed Sep 24 2003 Bill Nottingham 1.1.21-1 - fix clashing 'serial' consoles (#104851) * Wed Aug 27 2003 Bill Nottingham 1.1.20-1 - export CLASS_IDE in the python module * Mon Aug 25 2003 Bill Nottingham 1.1.19-1 - fix a bug that could misorder ethernet devices * Fri Aug 22 2003 Bill Nottingham 1.1.18-1 - set up hvc0 on pSeries (#98007) * Mon Aug 18 2003 Bill Nottingham 1.1.17-1 - fix segfault, and don't call matchNetDevices() so often (#102617) * Fri Aug 15 2003 Bill Nottingham 1.1.16-1 - more changes/fixes to guarantee uniqueness of network device names - use this for configuration/deconfiguration (#61169) - various other networking-related fixes (#101488, #99269) * Tue Aug 05 2003 Bill Nottingham 1.1.15-1 - viocd probing (#89232) - read /etc/sysconfig/network-scripts/ifcfg-* for device names (#99269) * Thu Jul 17 2003 Jeremy Katz 1.1.13-1 - fix another segfault (#99317) * Tue Jul 15 2003 Bill Nottingham 1.1.12-1 - fix segfault (#99176) * Fri Jul 11 2003 Bill Nottingham 1.1.11-1 - remove debugging code. duh. * Thu Jul 10 2003 Bill Nottingham 1.1.10-1 - fix bug that would cause us to lose track of some network devices * Thu Jul 03 2003 Bill Nottingham 1.1.9-1 - associate ethernet hardware address with PCI, PCMCIA, USB ethernet devices * Tue Jun 24 2003 Bill Nottingham 1.1.7-1 - fix updfstab to not do bizarre things when called in parallel (#89229) * Thu Jun 19 2003 Bill Nottingham 1.1.6-1 - fix some of the python bindings * Mon Jun 09 2003 Bill Nottingham 1.1.5-1 - probe IDE controllers, for those driven by separate modules (SATA) * Wed May 21 2003 Brent Fox 1.1.4-1.1 - replace call to kbdconfig with redhat-config-keyboard (bug #87919) * Thu Apr 17 2003 Bill Nottingham 1.1.3-1 - fix severe blowing of the stack * Wed Apr 16 2003 Bill Nottingham 1.1.2-1 - fix module_upgrade * Wed Mar 26 2003 Bill Nottingham 1.1.1-1 - fix asignment of class in readDevice() * Mon Mar 17 2003 Bill Nottingham 1.1.0-1 - change semantics of class enumeration; now treated bitwise, like bus - make BUS_UNSPEC and CLASS_UNSPEC ~0 instead of 0 - change field name from 'class' to 'type' for C++ happiness (#26463) * Tue Feb 25 2003 Bill Nottingham 0.99.99-1 - fix syntax error (#85127) * Thu Feb 20 2003 Bill Nottingham 0.99.98-1 - fix segfault in updfstab --skipprobe by weeding out non ide/scsi/misc/firewire devices * Wed Feb 19 2003 Bill Nottingham 0.99.97-1 - don't say PS/2 mice are removed in safe mode (#80662) - don't configure USB mice; they're always configured (#84047) - fix PCMCIA ranges () - set LANG, not LC_MESSAGES, for CJK in init script * Thu Feb 13 2003 Bill Nottingham 0.99.96-1 - add support for another USB floppy drive to updfstab (#70282) - fix removal of wrong device in updfstab on USB device removal (#77382) * Thu Feb 13 2003 Elliot Lee 0.99.95-1 - Add ppc64 to Makefile * Tue Feb 11 2003 Bill Nottingham 0.99.94-1 - MacIO, ADB, and ppc DDC probing () - tweak serial probe - fix silly initscript typo * Fri Jan 31 2003 Bill Nottingham 0.99.92-1 - fix segfault (#83255) * Wed Jan 29 2003 Bill Nottingham 0.99.91-1 - support in updfstab for linking /dev/cdwriter to /dev/sg* * Thu Jan 23 2003 Bill Nottingham 0.99.90-1 - don't show CJK on console (#82537) - fix handling of null strings in kudzumodule * Mon Jan 20 2003 Bill Nottingham 0.99.89-1 - really fix the broken ps2 probe * Thu Jan 16 2003 Bill Nottingham 0.99.88-1 - ps2 probe fixing * Fri Jan 10 2003 Bill Nottingham 0.99.87-1 - add -k to specify kernel version to look for modules for - usb class -> kudzu class mapping tweaks * Mon Jan 06 2003 Bill Nottingham 0.99.86-1 - PCMCIA probing support - PCMCIA fixes * Tue Dec 03 2002 Bill Nottingham 0.99.83-1 - switch floppy probing back * Tue Nov 26 2002 Bill Nottingham 0.99.82-1 - write "udf,iso9660" in updfstab * Fri Nov 22 2002 Bill Nottingham 0.99.81-1 - handle compressed modules * Thu Nov 14 2002 Preston Brown 0.99.80-1 - speed up floppy probe. * Wed Nov 13 2002 Bill Nottingham 0.99.79-1 - fix broken ps2 probe - remove check for X in ps2 code * Wed Nov 13 2002 Preston Brown 0.99.77-1 - boot-time optimizations and speedups * Tue Nov 12 2002 Bill Nottingham 0.99.76-1 - mouse driver tweakage * Mon Nov 04 2002 Bill Nottingham 0.99.75-1 - deal with switched network driver mappings * Tue Sep 03 2002 Bill Nottingham 0.99.69-1 - don't have mouseconfig modify X configs for USB mice (#69581) * Mon Sep 02 2002 Bill Nottingham 0.99.68-1 - fix parallel device naming - fix printer config () * Fri Aug 23 2002 Jeremy Katz 0.99.66-1 - build libkudzu_loader with diet on x86 to avoid conflicting ideas about dirent in the loader * Wed Aug 21 2002 Bill Nottingham 0.99.65-1 - fix duplicate modules.conf entries, and other weirdness (#68905, #68044) * Thu Aug 15 2002 Bill Nottingham 0.99.64-2 - rebuild against new newt * Tue Aug 13 2002 Bill Nottingham 0.99.64-1 - fix firewire probe - fix firewire mapping in python module * Mon Jul 29 2002 Bill Nottingham 0.99.63-4 - add missing header * Wed Jul 24 2002 Bill Nottingham 0.99.63-1 - USB printer config support * Tue Jul 23 2002 Bill Nottingham 0.99.62-1 - printer config support * Mon Jul 22 2002 Bill Nottingham 0.99.61-1 - kill Xconfigurator support, add redhat-config-xfree86 support * Sun Jul 21 2002 Bill Nottingham 0.99.60-1 - firewire controller support (#65386, ) - minimal firewire bus probing * Wed Jul 17 2002 Bill Nottingham 0.99.59-1 - fix fix for #66652 - fix serial console support * Thu Jul 11 2002 Bill Nottingham 0.99.57-1 - fix assorted brokenness in the DDC probing * Thu Jul 11 2002 Erik Troan 0.99.56-1 - collapsed jaz/zip entries into consistent /mnt/jaz, /mnt/zip mount points * Sun Jul 07 2002 Erik Troan - added CAMERA search string for updfstab (Minolta S304, at least) * Thu Jun 27 2002 Bill Nottingham 0.99.55-1 - don't initialize full device lists on all probes () * Wed Jun 19 2002 Bill Nottingham 0.99.54-1 - more modules.pcimap blacklisting (#66652) * Mon Jun 17 2002 Bill Nottingham - rebuild against new slang * Wed Apr 17 2002 Bill Nottingham - fix uninitialized variable (#63664) * Mon Apr 15 2002 Bill Nottingham - fix segfault in pciserial code * Sat Apr 06 2002 Bill Nottingham - set buffering for reading /proc/partitions (#61617, #56815) * Tue Apr 02 2002 Bill Nottingham - add support for USB2 (ehci-hcd) - add device entries for *all* usb interfaces, not just the first (#52758) * Thu Mar 21 2002 Bill Nottingham - fix various ethernet device removal bugs (#61169) * Fri Feb 22 2002 Bill Nottingham - rebuild * Thu Jan 31 2002 Bill Nottingham - quick hack * Wed Jan 30 2002 Bill Nottingham - require hwdata, tweak paths accordingly - require eepro100-diag on ia64 * Tue Jan 15 2002 Bill Nottingham - rename config file to updfstab.conf * Mon Jan 07 2002 Erik Troan - updated updfstab to use a config file * Mon Jan 07 2002 Bill Nottingham - don't print out VBE videocards when asked for DDC monitors, and vice versa * Fri Jan 04 2002 Bill Nottingham - fix LRMI to work with pthreads * Thu Jan 03 2002 Bill Nottingham - split vbe-probed memory into its own video device - fix a segfault in pci.c on bad pcitable data * Thu Oct 11 2001 Bill Nottingham - go to the head of the tree. mmm, python 2.2 * Tue Sep 25 2001 Bill Nottingham - dink with eepro100 eeproms * Sat Sep 08 2001 Bill Nottingham - add G550 pci id * Thu Sep 06 2001 Bill Nottingham - fix enabling of bcm5820 in boot environment * Tue Aug 28 2001 Bill Nottingham - fix po file headers (#52701) * Fri Aug 24 2001 Bill Nottingham - only refer to things in the cards DB - we configure CLASS_OTHER now too (#51707) * Fri Aug 24 2001 Mike A. Harris - Updated ATI video hardware PCI ID's and sync'd with XFree86's ID's * Wed Aug 22 2001 Mike A. Harris - Fixed Radeon QD PCI ID, and a few others. - Fixed broken pt_BR.po file so kudzu will actually build. * Wed Aug 22 2001 Bill Nottingham - move PS/2 probe to PROBE_SAFE (fixes #52040, indirectly...) * Wed Aug 15 2001 Bill Nottingham - fix checking of module aliases during device unconfiguration (#51100) * Mon Aug 13 2001 Bill Nottingham - add another megaraid variant to the pcitable - add some configuration for bcm5820 cards (#51707) * Fri Aug 10 2001 Bill Nottingham - pcitable & translation updates (including fixing #51479) * Mon Aug 06 2001 Bill Nottingham - enumerate cardbus bridges before the rest of the PCI bus scan (fixes #35136, #41972, #49842, possibly others) * Wed Aug 01 2001 Bill Nottingham - don't override generic pcitable entries with subvendor/subdevice specific entries from modules.pcimap unless it uses a different module (#46454, #50604) - don't try to configure X if they don't appear to have it installed (#50088) * Thu Jul 26 2001 Bill Nottingham - fix changes from yesterday * Wed Jul 25 2001 Bill Nottingham - shrink parts of libkudzu_loader.a * Tue Jul 24 2001 Bill Nottingham - put scsi.o in libkudzu_loader.a * Mon Jul 23 2001 Bill Nottingham - USB floppy probing, via scsi.c ugliness * Mon Jul 23 2001 Florian La Roche - some some more gdth entries * Thu Jul 19 2001 Bill Nottingham - floppy probing! * Mon Jul 09 2001 Bill Nottingham - return fb device for VESA fb devices * Tue May 08 2001 Bill Nottingham - fix updfstab erroring out on floppies, other devices (#39623) * Mon May 07 2001 Bill Nottingham - add a couple of e1000 ids (#39391) - use dynamic buffer size for /proc/scsi/scsi (#37936) * Wed May 02 2001 Bill Nottingham - handle CLASS_RAID like CLASS_SCSI - put man pages in man8, not man1 - don't map all i960 stuff to megaraid; use explicit list * Tue May 01 2001 Erik Troan - added a man page for updfstab - updfstab added devices even when the full disk device was in fstab already * Thu Apr 26 2001 Florian La Roche - add hack to not start kudzu on s390/s390x on bootup * Mon Apr 02 2001 Preston Brown - mark camera mount types w/a default partition. * Fri Mar 30 2001 Bill Nottingham - fix a couple of random only-on-occasion memory scribbles in pci.c * Thu Mar 29 2001 Bill Nottingham - if we're running for the first time, don't configure additional mice if some existing mouse is configured * Wed Mar 28 2001 Bill Nottingham - more PS/2 probe tweaks to work with yet more strange KVMs - random pcitable tweaks (G450, etc.) * Mon Mar 26 2001 Bill Nottingham - don't segfault if they don't have a PS/2 port * Thu Mar 22 2001 Bill Nottingham - cosmetic pcitable tweaks * Wed Mar 21 2001 Bill Nottingham - don't map a particular Compaq i960 thing to megaraid (#32082) * Tue Mar 20 2001 Erik Troan - set detached for usb devices that aren't plugged in - don't put detached dfevices in the fstab * Mon Mar 19 2001 Bill Nottingham - only probe once in updfstab - fix aumix lines, again (#32163) - fix it so we don't reconfigure configured USB mice (#32236) * Fri Mar 16 2001 Erik Troan - check for Y-E (Vaio) floppies * Fri Mar 16 2001 Erik Troan - updfstab ignores partition tables that look invalid * Wed Mar 14 2001 Bill Nottingham - fix ps2 probe - fix long latent bug in python module - add new it/de/fr/es .po files * Tue Mar 13 2001 Bill Nottingham - add some documentation on the hwconf file * Mon Mar 12 2001 Bill Nottingham - new and improved PS/2 probe () * Mon Mar 12 2001 Bill Nottingham - fix two segfaults, one in the isapnp code, one in the ddc code * Thu Mar 08 2001 Bill Nottingham - some pcitable updates - update to updfstab (pam_console support) - don't try and load IDE modules if we don't need to * Wed Mar 07 2001 Bill Nottingham - clean up mouse handling (#30939, #21483, #18862, others) - ignore non-native ISAPnP stuff for now (#30805) * Thu Mar 01 2001 Bill Nottingham - fix a segfault and other weirdness in the SCSI probe (#30168) * Wed Feb 28 2001 Bill Nottingham - fix a SCSI order bug * Tue Feb 27 2001 Preston Brown - identify 16meg G450 * Tue Feb 27 2001 Bill Nottingham - enable the ISAPnP stuff (part of #29450) - fix a segfault * Mon Feb 26 2001 Bill Nottingham - merge in some stuff in pcitable that got lost * Sun Feb 25 2001 Bill Nottingham - don't return CLASS_NETWORK for everything in PCI_BASE_CLASS_NETWORK (like, say, ISDN cards) (#29308) * Fri Feb 23 2001 Bill Nottingham - only probe the PCI bus in module_upgrade (#29092, sort of) - random cleanups, plug some memory leaks - don't give SCSI device names to non-SCSI devices * Fri Feb 23 2001 Preston Brown - don't make duplicate fstab entries for devices that have the same dev entry but match different patterns. * Thu Feb 22 2001 Bill Nottingham - write aliases for multiple usb controllers * Wed Feb 21 2001 Bill Nottingham - add a new i810_audio id - read modules.pcimap from the normal directory if we're running the BOOT kernel * Tue Feb 20 2001 Bill Nottingham - write lines to modules.conf to save/restore sound settings (#28504) - fix module_upgrade for eth0 aliases * Tue Feb 20 2001 Preston Brown - set up agpgart on i860s. - improvements and fixes to updfstab, including mounting IOMEGA devices in the format they prefer. * Fri Feb 16 2001 Matt Wilson - set usbDeviceList to NULL in freeUsbDevices * Thu Feb 15 2001 Bill Nottingham - fix USB multiple probe segfault * Wed Feb 14 2001 Bill Nottingham - fix updfstab up some * Wed Feb 14 2001 Preston Brown - final translation update * Tue Feb 13 2001 Preston Brown - sync pcitable w/Xconfigurator. * Tue Feb 13 2001 Bill Nottingham - fix configuration of PCI modems (#27414) * Mon Feb 12 2001 Bill Nottingham - fix python module * Sun Feb 11 2001 Bill Nottingham - expand the USB probing; return all sorts of devices, and more sane descriptions * Sun Feb 11 2001 Erik Troan - added sony devices to updfstab - look through /proc/partitions for actual partition to mount - made symlinks optional, and only create them for /dev/cdrom * Fri Feb 09 2001 Bill Nottingham - don't bother showing a dialog for hardware we aren't going to do anything with - don't configure CD-ROMs * Thu Feb 08 2001 Preston Brown - update pcitable with new XFree86 stuff * Thu Feb 08 2001 Erik Troan - added updfstab - don't report ide devices bound to ide-scsi -- they're really scsi devices * Wed Feb 07 2001 Matt Wilson - added modules.o to LOADEROBJS in Makefile - remove modules.o from LOADEROBJS and add stub functions in kudzu.c * Wed Feb 07 2001 Bill Nottingham - add in modules.conf upgrader - describe the types of hardware that's added or removed in the dialog * Mon Feb 05 2001 Bill Nottingham - map disabled PCI devices to 'disabled', not to 'ignore' * Thu Feb 01 2001 Bill Nottingham - fix calling of VESA BIOS stuff (#24176) * Wed Jan 31 2001 Bill Nottingham - fix detection of disabled video boards * Fri Jan 26 2001 Trond Eivind Glomsr?d - fix bug in USB detection * Thu Jan 25 2001 Bill Nottingham - fix some broken pcitable entries - add BUS_USB to python module * Wed Jan 24 2001 Bill Nottingham - fix it so we actually pay attention to which button they push (#24858) * Wed Jan 24 2001 Preston Brown - final i18n update before beta * Sun Jan 21 2001 Bill Nottingham - change i18n mechanism * Sat Jan 20 2001 Bill Nottingham - add hack for 'configure/unconfigure all' in interactive mode * Thu Jan 18 2001 Erik Troan - pcitable update for natsemi module * Wed Jan 17 2001 Bill Nottingham - pcitable updates * Tue Jan 09 2001 Bill Nottingham - don't write modules.conf aliases for cardbus network stuff * Thu Dec 28 2000 Bill Nottingham - fix continual redetection of SOCKET devices * Fri Dec 22 2000 Bill Nottingham - read modules.pcimap as well - pcitable updates * Tue Dec 19 2000 Bill Nottingham - map yenta_socket driver for cardbus bridges (CLASS_SOCKET) * Wed Dec 13 2000 Bill Nottingham - work around a possible glibc bug - fix up the USB device stuff * Tue Dec 12 2000 Bill Nottingham - fix segfault caused by yesterday's changes - stub load/removeModule for the loader * Mon Dec 11 2000 Bill Nottingham - libmodules gets integrated into libkudzu - load necessary modules before probing * Fri Dec 08 2000 Bill Nottingham - a WORM device is a CD-ROM (#19250) * Tue Dec 05 2000 Michael Fulbright - fix for IDE CDROM probing segfault * Mon Nov 20 2000 Erik Troan - fix for scd devices > scd9 * Sat Nov 18 2000 Bill Nottingham - don't use files in /tmp to determine whether to switch runlevels * Sat Oct 21 2000 Matt Wilson - install kudzu.py into /usr/lib/python1.5/site-packages, not /usr/lib/python1.5/ - added backwards compatibility for old python interface - fixed crashes in python C binding * Wed Oct 18 2000 Bill Nottingham - pcitable updates - don't 'configure' agpgart on alpha - don't configure usb controllers if there are no modules * Wed Oct 04 2000 Trond Eivind Glomsr?d - segfault fix * Tue Oct 03 2000 Trond Eivind Glomsr?d - some fixes to avoid segfaulting with serial devices in kudzu if no PnP-description is available - minor fix to the makefile * Fri Sep 29 2000 Trond Eivind Glomsr?d - rewritten USB support - new python module (formerly kudzu2), giving access to more information * Wed Sep 13 2000 Trond Eivind Glomsr?d - include more info in the kudzu2 python module * Fri Sep 08 2000 Trond Eivind Glomsr?d - new kudzu2 python module which gives access to all of the information available on the device in the C library. Hopefully will be the main module soonish. * Wed Aug 30 2000 Bill Nottingham - pcitable tweaks * Thu Aug 24 2000 Erik Troan - updated it/es translations * Thu Aug 24 2000 Bill Nottingham - fix segfault when passed '-f ' * Wed Aug 23 2000 Bill Nottingham - fix some ATI Mobility mappings - use ftw() to look for modules; it's the only sane way to handle 2.4 kernels * Sat Aug 19 2000 Bill Nottingham - fix network device ordering * Tue Aug 15 2000 Bill Nottingham - disabled things also have IRQ 255. Neat. * Wed Aug 09 2000 Bill Nottingham - actually include translation files. Duh. * Wed Aug 09 2000 Tim Waugh - avoid overflowing the monitor id buffer (#15795) * Tue Aug 08 2000 Erik Troan - look for PCMCIA IDE devices (they aren't in /proc) * Mon Aug 07 2000 Bill Nottingham - handle probing for excessive numbers of SCSI devices - tweak IRQ 0 ignoring slightly * Sun Aug 06 2000 Bill Nottingham - ignore devices on IRQ 0 * Fri Aug 04 2000 Bill Nottingham - fix subdevice sorting in pci device table (#14503) * Fri Aug 04 2000 Florian La Roche - make some functions in pci.c "static" * Wed Aug 02 2000 Bill Nottingham - assorted pcitable and translation fixes * Fri Jul 28 2000 Bill Nottingham - fixes so translations get activated * Wed Jul 26 2000 Bill Nottingham - pcitable fixes (Neomagic, Matrox) * Wed Jul 26 2000 Matt Wilson - new translations for de fr it es * Tue Jul 25 2000 Bill Nottingham - pci.ids updates - probe for memory in DDC probe - link vbe library in directly * Tue Jul 25 2000 Florian La Roche - update gdth ICP vortex entries * Mon Jul 24 2000 Bill Nottingham - turn off DDC probing in generic hardware probe - random pcitable updates * Tue Jul 18 2000 Michael Fulbright - enable USB bus probing for loader * Tue Jul 18 2000 Bill Nottingham - pcitable updates * Fri Jul 14 2000 Matt Wilson - added USB probing to kudzu_loader library * Fri Jul 14 2000 Bill Nottingham - move initscript back * Tue Jul 11 2000 Florian La Roche - add another ncr/sym controller to pcitable * Mon Jul 03 2000 Trond Eivind Glomsr?d - USB mouse detection * Mon Jul 03 2000 Bill Nottingham - preliminary USB probing (from Trond) * Tue Jun 27 2000 Bill Nottingham - add /etc/sysconfig/kudzu where you can force only safe probes on boot * Mon Jun 26 2000 Bill Nottingham - configure USB controllers - initscript path munging * Sun Jun 18 2000 Bill Nottingham - fix broken bus handling in library * Thu Jun 15 2000 Bill Nottingham - add r128 driver mappings * Thu Jun 15 2000 Matt Wilson - hacks to probe vesa and vga16 framebuffers * Tue Jun 13 2000 Bill Nottingham - DDC probing fixes * Wed Jun 07 2000 Bill Nottingham - add in monitor probing * Sun Jun 04 2000 Bill Nottingham - pcitable fixes * Thu Jun 01 2000 Bill Nottingham - modules.confiscation * Tue May 30 2000 Erik Troan - moved kudzumodule to main kudzu package * Wed May 10 2000 Bill Nottingham - add support for PCI subvendor, subdevice IDs * Tue Apr 04 2000 Bill Nottingham - add fix for odd keyboard controllers * Tue Mar 28 2000 Erik Troan - added kudzumodule to devel package - added libkudzu_loader to devel * Sat Mar 04 2000 Matt Wilson - added 810 SVGA mapping * Thu Mar 02 2000 Bill Nottingham - fixes in pci device list merging * Thu Feb 24 2000 Bill Nottingham - fix aliasing and configuration of network devices - only configure modules that are available * Mon Feb 21 2000 Bill Nottingham - fix handling of token ring devices * Thu Feb 17 2000 Bill Nottingham - yet more serial fixes * Wed Feb 16 2000 Bill Nottingham - more serial fixes; bring back DTR and RTS correctly * Fri Feb 04 2000 Bill Nottingham - don't run serial probe on serial console, fixed right * Tue Feb 01 2000 Bill Nottingham - fix previous fixes. * Wed Jan 26 2000 Bill Nottingham - fix add/remove logic somewhat * Wed Jan 19 2000 Bill Nottingham - don't run serial probe on serial console * Fri Jan 07 2000 Bill Nottingham - fix stupid bug in configuring scsi/net cards * Mon Oct 25 1999 Bill Nottingham - oops, don't try to configure 'unknown's. * Mon Oct 11 1999 Bill Nottingham - fix creation of /etc/sysconfig/soundcard... * Wed Oct 06 1999 Bill Nottingham - add inittab munging for sparc serial consoles... * Thu Sep 30 1999 Bill Nottingham - add sun keyboard probing (from jakub) - add some bttv support * Wed Sep 22 1999 Bill Nottingham - run 'telinit 5' if needed in the initscript * Mon Sep 20 1999 Bill Nottingham - new & improved UI - module aliasing fixes * Thu Sep 09 1999 Bill Nottingham - sanitize, homogenize, sterilize... * Wed Sep 08 1999 Bill Nottingham - get geometry for ide drives - enumerate buses (jj at ultra.linux.cz) libesmtp-1.0.1-1 ---------------- * Fri Oct 03 2003 Bill Nottingham 1.0.1-1 - update to 1.0.1, rebuild to fix some broken 64-bit libs mozilla-1.4.1-4 --------------- ncftp-3.1.6-1 ------------- * Fri Oct 03 2003 Florian La Roche - 3.1.6 - disabled patch6, seems not necessary rawhide-release-20031004-1 -------------------------- redhat-config-securitylevel-1.2.10-1 ------------------------------------ * Fri Oct 03 2003 Bill Nottingham 1.2.10-1 - minor code cleanup * Fri Oct 03 2003 Bill Nottingham 1.2.9-1 - fix interactive disabling of firewall in TUI (#106243) redhat-menus-0.40-1 ------------------- * Fri Oct 03 2003 Havoc Pennington 0.40-1 - 0.40 rusers-0.17-32 -------------- * Fri Oct 03 2003 Florian La Roche - rebuild * Mon Sep 08 2003 Dan Walsh 0.17-31.4 - turn selinux off * Fri Sep 05 2003 Dan Walsh 0.17-31.3.sel - turn selinux on * Mon Jul 28 2003 Dan Walsh 0.17-31.2 - Add SELinux library support * Mon Jul 14 2003 Tim Powers 0.17-31.1 - rebuilt for RHEL From nphilipp at redhat.com Sat Oct 4 10:21:24 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 04 Oct 2003 12:21:24 +0200 Subject: artwork project In-Reply-To: <3F7C7689.3020009@redhat.com> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <3F7C4DEE.2010705@redhat.com> <200310021729.19728.gavin.henry@magicfx.co.uk> <3F7C7689.3020009@redhat.com> Message-ID: <1065262883.7680.44.camel@wombat.tiptoe.de> On Thu, 2003-10-02 at 21:03, Garrett LeSage wrote: > Also, having a tablet can help with some procedures, although I need to > get mine working again (upgrading the kernel or XFree86 often breaks > support unfortunately, as the kernel driver does things it shouldn't do, > for no reason). Hmm, mine works from an X or kernel POV, but the way current gimp 1.3 handles input devices is a bit cumbersome for me -- I was used to change GIMP tools for the tablet tools by just clicking with the tool on the toolbox, now I have to open the device status dialog, click on the tablet tool's tool icon, another dialog opens in which I can change it. Just a wee bit cumbersome. I hope that'll change for the final version. 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 ottohaliburton at comcast.net Sat Oct 4 10:54:47 2003 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Sat, 4 Oct 2003 05:54:47 -0500 Subject: Kind request: fix your packages In-Reply-To: <1065217416.3337.22.camel@rousalka.dyndns.org> Message-ID: <003f01c38a65$edbca8c0$735eee0c@C515816A> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Nicolas Mailhot > Sent: Friday, October 03, 2003 4:44 PM > To: fedora-devel-list at redhat.com > Subject: Re: Kind request: fix your packages > > Le ven 03/10/2003 ? 22:39, Sean Middleditch a ?crit : > > On Fri, 2003-10-03 at 16:11, Michael Schwendt wrote: > > > > > Perl/Python are co-installable with different versions, and thus are > a > > > > different issue. > > > > > > Oh, great, a second Perl installation. As if Python/Python2 wouldn't > > > be enough already. > > > > If that's what it takes to make things work, then that's what it takes. > > I didn't say it was perfect, just that it solves the problem that users > > shouldn't ever have to rebuild to software, and users shouldn't have to > > run around figuring out what their system is to find the right package > > and deal with that mess. In a truly ideal world, Perl/Python/etc. > > wouldn't keep breaking compatibility so often. ~,^ Since that's *not* > > reality, the only solution left for sane packages (form a user's point > > of view again) is to let any necessary versions be installed so the > > user's apps just work and the user doesn't even have to think about OS > > versions or dependencies. > > Don't make me laugh. The user cares about duplicate stuff too. > Before we build a serious infrastructure that enabled us to modularise > stuff someone would complain every other week we shipped java 1.3 jars > with our tomcat rpm (and those jars were necessary to run it with a 1.3 > jvm, and didn't hurt when using a 1.4 jvm. But for a 1.4 user they were > redundant stuff and we got complains). > > Show me a repository with big fat packages that include all deps to be > standalone and I'll show you a repository no one wants to use. Users may > not all know the zen of packaging but it will only take a few long > downloads or stuffed disks to enlighten them. > > Cheers, > > -- > Nicolas Mailhot here's m .02 cents. The user shouldn't have to worry about how, what, or why it works or doesn't work. The object of good development is that it "all ways work". So what does that mean? It means that all packages should contain everything necessary for that instant to work now matter what happened before it arrives. When you obtain a package freely or pay for it, you don't need to dig up everything else that will require that package to work. We developers like to troubleshoot, but it a waste of time and effort to troubleshoot the needs and intentions of another developer. That's my opinion and I'm stuck with it. From behdad at cs.toronto.edu Sat Oct 4 11:21:36 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sat, 4 Oct 2003 07:21:36 -0400 Subject: Mozilla icons [was: Open Office 1.1 suggestion] In-Reply-To: <1065243071.12845.1.camel@dhcppc3> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> <1065215253.3614.14.camel@localhost.localdomain> <1065240786.12691.3.camel@dhcppc3> <1065243071.12845.1.camel@dhcppc3> Message-ID: On Sat, 4 Oct 2003, Havoc Pennington wrote: > On Sat, 2003-10-04 at 00:23, Behdad Esfahbod wrote: > > Switching the default browser to Epiphany is really appreciated. > > Right now GNOME applications default to Epiphany, and others to > > Mozilla. > > That's a bug, however. Everything should default to Mozilla right now as > it's the default web browser. I just filed a bug for that, but I guess it should be discussed here: Why not everything simply call htmlview? So the user can simply change his browser in /etc/htmlview.conf? I mean even the default browser launcher in the panel, and main Internet menu. > Havoc behdad From pmatilai at welho.com Sat Oct 4 13:13:11 2003 From: pmatilai at welho.com (Panu Matilainen) Date: 04 Oct 2003 16:13:11 +0300 Subject: rawhide report: 20031003 changes In-Reply-To: <20031003200752.557db910.matthias@rpmforge.net> References: <200310031609.h93G9v819695@porkchop.devel.redhat.com> <20031003200752.557db910.matthias@rpmforge.net> Message-ID: <1065273191.3922.0.camel@chip.ath.cx> On Fri, 2003-10-03 at 21:07, Matthias Saou wrote: > Build System wrote : > > > Updated Packages: > > > [...] > > This is really neat and incredibly useful, thanks a lot to whoever > implemented it at last. Yup, really nice. Thank you RH for implementing this! - Panu - From roozbeh at sharif.edu Sat Oct 4 13:17:12 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Sat, 04 Oct 2003 16:47:12 +0330 Subject: OpenOffice.org 1.1 Message-ID: <1065273432.17897.125.camel@guava.bamdad.org> What are the plans for OOo 1.1 in Fedora Core? I'm specially interested since OOo 1.1 has some nice BiDi (Hebrew, Arabic, ...) support, which I'd love to impress my friends with ;-) roozbeh From mandreiana at rdslink.ro Sat Oct 4 13:30:15 2003 From: mandreiana at rdslink.ro (Marius Andreiana) Date: 04 Oct 2003 16:30:15 +0300 Subject: rawhide report: 20031004 changes In-Reply-To: <200310040948.h949mcg18824@porkchop.devel.redhat.com> References: <200310040948.h949mcg18824@porkchop.devel.redhat.com> Message-ID: <1065274214.11858.32.camel@marte.biciclete.ro> Could this have only the diff between prev. and current ChangeLog for each package? -- Marius Andreiana LOAD - Linux Open Alternative Days Specialist Linux, Co-organizator http://www.load.ro From Nicolas.Mailhot at laPoste.net Sat Oct 4 13:11:11 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 04 Oct 2003 15:11:11 +0200 Subject: Kind request: fix your packages In-Reply-To: <003f01c38a65$edbca8c0$735eee0c@C515816A> References: <003f01c38a65$edbca8c0$735eee0c@C515816A> Message-ID: <1065273071.3207.67.camel@rousalka.dyndns.org> Le sam 04/10/2003 ? 12:54, Otto Haliburton a ?crit : > > here's m .02 cents. The user shouldn't have to worry about how, what, or > why it works or doesn't work. The object of good development is that it > "all ways work". So what does that mean? It means that all packages should > contain everything necessary for that instant to work now matter what > happened before it arrives. When you obtain a package freely or pay for it, > you don't need to dig up everything else that will require that package to > work. We developers like to troubleshoot, but it a waste of time and effort > to troubleshoot the needs and intentions of another developer. That's my > opinion and I'm stuck with it. Dear user, As we all know you're dumb and you can not learn to use a package manager ever. To ease your pain we've decided not to inflict you the so-called "dependency hell" and provide you an autonomous application. Just click on its auto-update menu and it will download everything you need, we swear it. Of course when you've done you'll just have to do a cpan refresh, tell xemacs to auto-update itself, your movie player to download new codecs, mozilla to download a langage pack and a few themes and by the way did you know about this wonderful openoffice macro that will help you update your spellchecker ? To help you keep up with updates we've thoughtfully provided a "time to update" popup that will remind you every few weeks you need to keep up with us. To avoid any misunderstanding we designed it to be completely different from the swarm of update popups you deal with every day. Since another application might update some libraries we depend on at an inconvenient time, we've provided you with a private copy of all the dependencies we need. You can be sure no one will mess with their configuration files or change their format, since we also use a private copy of these files. God forbid it was trampled on by one of those nasty control panel thingies ! The system has no business telling us what fonts to use. We swear we'll keep up with security fixes for all this peripheral uninteresting stuff, at least as long as it doesn't interfere with our application wellbeing but you won't mind because we know best and you trust us. To avoid migration breakage we even use different configuration files for each version. You just have to re-enter the few scores of options our app use and you're done ! No risk of automated conversion mess-up whatsoever ! The app will even refuse to start till you've filled the four screens of configuration to prevent mess-ups ! You might need to get yourself a new disk of pay for a broadband link, but that's truly trivial and you should thank us to help you keep with your times. We're pleased to inform you we're working on a bootable standalone CD that will drop you in your preferred application without having to worry about the system altogether. For the time being we've implemented a 100% user-side install so you won't have to worry about nasty unix permissions. Just click the setup icon and the whole app will install itself in Wonderful Technologies\Wonderful Technologies Application Plus Professional\6.6 SR6\ in your workspace. And it only takes 300 Mb per user! We stay committed to provide products that work now no matter what happened before they arrive, P.S. Regarding you question on why you can't print from Wonderful Technologies Application Plus Professional we're sorry to inform you update of the print library is not scheduled before the release of Wonderful Technologies Application Plus Professional Entreprise 7 first quarter of next year. That it works with the rest of the system is purely a fluke of your imagination and due to you system provider bundling an unstable untested printing backend too early. You're better of with the Obsolete Corp backend we provide now - it has been tested a full two days with my nephew's inkjet printer. Hopefully our app-on-cd system will take care of those regrettable incidents soon. In the meanwhile we advise you to buy an Expensive Systems LaserColourWriter 9000000000000 which are known to work with Wonderful Technologies Application Plus Professional (at least for the american models). They even come bundled with vouchers for other Wonderful Technologies great products ! P.P.S. If you can't afford an Expensive Systems LaserColourWriter 9000000000000 my nephew just wrote me we wants to sell its inkjet printer. JUST CALL ! -- 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 Sat Oct 4 14:15:11 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 4 Oct 2003 16:15:11 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065252308.4488.116.camel@andy> References: <1065252308.4488.116.camel@andy> Message-ID: <20031004161511.10275871.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 04 Oct 2003 03:25:09 -0400, Andy Hanton wrote: > I think that the 'Kind request: fix your packages' thread is going off > course by discussing how to fix what we have instead of what we need to > implement to make Sean's vision possible while making it possible to > support older systems easily. What exactly is Sean's vision? It might be just me, but I don't think that became clear in the controversy due to misunderstandings (e.g. with regard to optional [versioned] build requirements). Maybe someone can sum up a few major flaws in current "RPM packaging" with regard to packagers and package users and outline the changes that are supposed to improve the situation. Btw, if you're asking for major efforts to make the life easier for a tiny group of users, who stick to an old distribution and who want to install the latest and greatest software in form of prebuilt packages nevertheless, I think that's a hopeless venture due to API and ABI changes. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD4DBQE/ftXv0iMVcrivHFQRAoT1AJiZmB6ltNT9oLtKiaBnlGWj5RoAAJ0VryrW W1TGtmWBb1dTZeQXr1eZfA== =xHlQ -----END PGP SIGNATURE----- From ottohaliburton at comcast.net Sat Oct 4 14:22:46 2003 From: ottohaliburton at comcast.net (Otto Haliburton) Date: 04 Oct 2003 09:22:46 -0500 Subject: Kind request: fix your packages In-Reply-To: <1065273071.3207.67.camel@rousalka.dyndns.org> References: <003f01c38a65$edbca8c0$735eee0c@C515816A> <1065273071.3207.67.camel@rousalka.dyndns.org> Message-ID: <1065277366.6443.3.camel@c515816-a> On Sat, 2003-10-04 at 08:11, Nicolas Mailhot wrote: > Le sam 04/10/2003 ? 12:54, Otto Haliburton a ?crit : > > > > > here's m .02 cents. The user shouldn't have to worry about how, what, or > > why it works or doesn't work. The object of good development is that it > > "all ways work". So what does that mean? It means that all packages should > > contain everything necessary for that instant to work now matter what > > happened before it arrives. When you obtain a package freely or pay for it, > > you don't need to dig up everything else that will require that package to > > work. We developers like to troubleshoot, but it a waste of time and effort > > to troubleshoot the needs and intentions of another developer. That's my > > opinion and I'm stuck with it. > > Dear user, > > As we all know you're dumb and you can not learn to use a package > manager ever. To ease your pain we've decided not to inflict you the > so-called "dependency hell" and provide you an autonomous application. > Just click on its auto-update menu and it will download everything you > need, we swear it. > > Of course when you've done you'll just have to do a cpan refresh, tell > xemacs to auto-update itself, your movie player to download new codecs, > mozilla to download a langage pack and a few themes and by the way did > you know about this wonderful openoffice macro that will help you update > your spellchecker ? > > To help you keep up with updates we've thoughtfully provided a "time to > update" popup that will remind you every few weeks you need to keep up > with us. To avoid any misunderstanding we designed it to be completely > different from the swarm of update popups you deal with every day. > > Since another application might update some libraries we depend on at > an inconvenient time, we've provided you with a private copy of all the > dependencies we need. You can be sure no one will mess with their > configuration files or change their format, since we also use a private > copy of these files. God forbid it was trampled on by one of those nasty > control panel thingies ! The system has no business telling us what > fonts to use. > > We swear we'll keep up with security fixes for all this peripheral > uninteresting stuff, at least as long as it doesn't interfere with our > application wellbeing but you won't mind because we know best and you > trust us. To avoid migration breakage we even use different > configuration files for each version. You just have to re-enter the few > scores of options our app use and you're done ! No risk of automated > conversion mess-up whatsoever ! The app will even refuse to start till > you've filled the four screens of configuration to prevent mess-ups ! > > You might need to get yourself a new disk of pay for a broadband link, > but that's truly trivial and you should thank us to help you keep with > your times. We're pleased to inform you we're working on a bootable > standalone CD that will drop you in your preferred application without > having to worry about the system altogether. For the time being we've > implemented a 100% user-side install so you won't have to worry about > nasty unix permissions. Just click the setup icon and the whole app will > install itself in Wonderful Technologies\Wonderful Technologies > Application Plus Professional\6.6 SR6\ in your workspace. And it only > takes 300 Mb per user! > > We stay committed to provide products that work now no matter what > happened before they arrive, > > P.S. > > Regarding you question on why you can't print from Wonderful > Technologies Application Plus Professional we're sorry to inform you > update of the print library is not scheduled before the release of > Wonderful Technologies Application Plus Professional Entreprise 7 first > quarter of next year. That it works with the rest of the system is > purely a fluke of your imagination and due to you system provider > bundling an unstable untested printing backend too early. You're better > of with the Obsolete Corp backend we provide now - it has been tested a > full two days with my nephew's inkjet printer. Hopefully our app-on-cd > system will take care of those regrettable incidents soon. In the > meanwhile we advise you to buy an Expensive Systems LaserColourWriter > 9000000000000 which are known to work with Wonderful Technologies > Application Plus Professional (at least for the american models). They > even come bundled with vouchers for other Wonderful Technologies great > products ! > > P.P.S. > > If you can't afford an Expensive Systems LaserColourWriter 9000000000000 > my nephew just wrote me we wants to sell its inkjet printer. JUST CALL ! So what's the problem. The developer wants his product used. If you don't fix your software/hardware/programs the user will rebel and not update it at all, then where's your problem. The user instinct is not to make changes cause "it works for what I want it to do", It may not be the best or have all the functions I want but if I got to go trouble shoot all the problems then f__ it!!!!!! From heinlein at madboa.com Sat Oct 4 14:29:12 2003 From: heinlein at madboa.com (Paul Heinlein) Date: Sat, 4 Oct 2003 07:29:12 -0700 (PDT) Subject: rawhide report: 20031004 changes In-Reply-To: <1065274214.11858.32.camel@marte.biciclete.ro> References: <200310040948.h949mcg18824@porkchop.devel.redhat.com> <1065274214.11858.32.camel@marte.biciclete.ro> Message-ID: On Sat, 4 Oct 2003, Marius Andreiana wrote: > Could this have only the diff between prev. and current ChangeLog > for each package? Or, perhaps * list of new packages * short list of updated packages, one package per line * full list of updated packages, changelogs and all --Paul Heinlein From ottohaliburton at comcast.net Sat Oct 4 14:37:44 2003 From: ottohaliburton at comcast.net (Otto Haliburton) Date: 04 Oct 2003 09:37:44 -0500 Subject: Kind request: fix your packages In-Reply-To: <1065277366.6443.3.camel@c515816-a> References: <003f01c38a65$edbca8c0$735eee0c@C515816A> <1065273071.3207.67.camel@rousalka.dyndns.org> <1065277366.6443.3.camel@c515816-a> Message-ID: <1065278264.6443.8.camel@c515816-a> O > So what's the problem. The developer wants his product used. If you > don't fix your software/hardware/programs the user will rebel and not > update it at all, then where's your problem. The user instinct is not > to make changes cause "it works for what I want it to do", It may not > be the best or have all the functions I want but if I got to go trouble > shoot all the problems then f__ it!!!!!! > > Sorry about the back to back post. The above statement is exactly what Microsoft has found out on it constant updates to fix its system. The user will not make the change cause "it will break something else". So they are not keeping there system up with what MS calls critical updates. Think about it!!!!! From gavin.henry at magicfx.co.uk Sat Oct 4 14:56:15 2003 From: gavin.henry at magicfx.co.uk (G Henry) Date: Sat, 4 Oct 2003 15:56:15 +0100 Subject: artwork project In-Reply-To: <1065115882.3057.7.camel@GreenTea> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <200310021822.25961.gavin.henry@magicfx.co.uk> <1065115882.3057.7.camel@GreenTea> Message-ID: <200310041556.24578.gavin.henry@magicfx.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 02 Oct 2003 6:31 pm, Phillip Compton wrote: > On Thu, 2003-10-02 at 13:22, G Henry wrote: > > > Have you tried the development branch? 1.3.20 works great for me. It's > > > available from the fedora.us repo (unstable although w/ the upcoming > > > pre-releases it will probably move to testing). It's named gimp2, so it > > > can safely be installed along side the stable branch. > > > > Will give it a shot. Is it rpm and does it install on RH9, as I have got > > fedora installed yet. (Don't ask, I know, strange when I want to help the > > project) > > The RH9 repo has: > http://download.fedora.us/fedora/redhat/9/i386/RPMS.unstable/gimp2-1.3.18-0 >.fdr.5.rh90.i386.rpm > > Severn1 repo has: > http://download.fedora.us/fedora/redhat/9.0.93/i386/RPMS.unstable/gimp2-1.3 >.20-0.fdr.1.rh90.93.i386.rpm > > and hopefully, it will be recompiled shortly for the Severn2 repo. > > > Phil > It's very nice. Will do my new company logo on it. - -- Regards Trying to be a RHCE http://www.magicfx.co.uk http://www.suretecsystems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/ft+SgNqd7Kng8UoRAsZmAKC5376EpNdB70DnUBtK8E9HTitQ8ACgu+x4 p1ftJxpWtFW/DoGWpB7AZ8A= =oP5k -----END PGP SIGNATURE----- From hp at redhat.com Sat Oct 4 15:32:48 2003 From: hp at redhat.com (Havoc Pennington) Date: 04 Oct 2003 11:32:48 -0400 Subject: Mozilla icons [was: Open Office 1.1 suggestion] In-Reply-To: References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> <1065215253.3614.14.camel@localhost.localdomain> <1065240786.12691.3.camel@dhcppc3> <1065243071.12845.1.camel@dhcppc3> Message-ID: <1065281568.18446.11.camel@dhcppc3> On Sat, 2003-10-04 at 02:52, Behdad Esfahbod wrote: > > It would be nice if everything would rely on htmlview. I even > mean the Browser icon on the panel, so that changing to epiphany > in /etc/htmlview.conf would do the switch. htmlview is IMHO a horrible hackaround for the problem of not having a common MIME association system for all the apps. Are we going to have "officeview", "mediaplayerview", "pdfview", etc. with separate /etc/fooview.conf for each? It's just an unscalable broken hack. I believe the reason we dropped htmlview and go straight to mozilla in many places was that we couldn't get a .desktop file right for htmlview. StartupNotify=????, Name=?????, you can't fill it out properly. The light is at the end of the tunnel; I have to hope we'll have a common MIME associations system in the next 6 months, there's some motion there. Havoc From pmatilai at welho.com Sat Oct 4 15:43:11 2003 From: pmatilai at welho.com (Panu Matilainen) Date: 04 Oct 2003 18:43:11 +0300 Subject: Mozilla icons [was: Open Office 1.1 suggestion] In-Reply-To: <1065281568.18446.11.camel@dhcppc3> References: <20031003155322.99381.qmail@web14205.mail.yahoo.com> <1065204762.2080.10.camel@dhcp64-175.boston.redhat.com> <1065205891.25063.36.camel@icon.devel.redhat.com> <1065215253.3614.14.camel@localhost.localdomain> <1065240786.12691.3.camel@dhcppc3> <1065243071.12845.1.camel@dhcppc3> <1065281568.18446.11.camel@dhcppc3> Message-ID: <1065282191.3927.8.camel@chip.ath.cx> On Sat, 2003-10-04 at 18:32, Havoc Pennington wrote: > On Sat, 2003-10-04 at 02:52, Behdad Esfahbod wrote: > > > > It would be nice if everything would rely on htmlview. I even > > mean the Browser icon on the panel, so that changing to epiphany > > in /etc/htmlview.conf would do the switch. > > htmlview is IMHO a horrible hackaround for the problem of not having a > common MIME association system for all the apps. Are we going to have > "officeview", "mediaplayerview", "pdfview", etc. with separate > /etc/fooview.conf for each? It's just an unscalable broken hack. > > I believe the reason we dropped htmlview and go straight to mozilla in > many places was that we couldn't get a .desktop file right for htmlview. > StartupNotify=????, Name=?????, you can't fill it out properly. How about dropping the whole htmlview package if it's not going to be used and considered an ugly hack (which it is)? The fact that it's included but then used makes me feel like submitting a bug each time I find a place that doesn't use it :) > > The light is at the end of the tunnel; I have to hope we'll have a > common MIME associations system in the next 6 months, there's some > motion there. Finally... thank goodness. - Panu - From elanthis at awesomeplay.com Sat Oct 4 15:51:34 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 04 Oct 2003 11:51:34 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <20031004161511.10275871.ms-nospam-0306@arcor.de> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> Message-ID: <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> On Sat, 2003-10-04 at 10:15, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 04 Oct 2003 03:25:09 -0400, Andy Hanton wrote: > > > I think that the 'Kind request: fix your packages' thread is going off > > course by discussing how to fix what we have instead of what we need to > > implement to make Sean's vision possible while making it possible to > > support older systems easily. > > What exactly is Sean's vision? It might be just me, but I don't think > that became clear in the controversy due to misunderstandings (e.g. > with regard to optional [versioned] build requirements). Maybe someone > can sum up a few major flaws in current "RPM packaging" with regard to > packagers and package users and outline the changes that are supposed > to improve the situation. Most basic theme of my misunderstood ;-) ranting - only one package per application, ever. Package always works, save asking for dependencies, of which there are also only one package for each. Only in cases of true (but hopefully avoidable) platform incompatibility should this be broken. Given the autopackage project, RPMs and their (possible) problems may in the future just be relegated to low-level system stuff, which is another solution, but one not yet ready. > > Btw, if you're asking for major efforts to make the life easier for a > tiny group of users, who stick to an old distribution and who want to > install the latest and greatest software in form of prebuilt packages > nevertheless, I think that's a hopeless venture due to API and ABI > changes. > > - -- > Michael, who doesn't reply to top posts and complete quotes anymore. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD4DBQE/ftXv0iMVcrivHFQRAoT1AJiZmB6ltNT9oLtKiaBnlGWj5RoAAJ0VryrW > W1TGtmWBb1dTZeQXr1eZfA== > =xHlQ > -----END PGP SIGNATURE----- > > > -- > 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 Nicolas.Mailhot at laPoste.net Sat Oct 4 15:57:42 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 04 Oct 2003 17:57:42 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065278264.6443.8.camel@c515816-a> References: <003f01c38a65$edbca8c0$735eee0c@C515816A> <1065273071.3207.67.camel@rousalka.dyndns.org> <1065277366.6443.3.camel@c515816-a> <1065278264.6443.8.camel@c515816-a> Message-ID: <1065283062.4868.59.camel@rousalka.dyndns.org> Le sam 04/10/2003 ? 16:37, Otto Haliburton a ?crit : > O > > So what's the problem. The developer wants his product used. If you > > don't fix your software/hardware/programs the user will rebel and not > > update it at all, then where's your problem. The user instinct is not > > to make changes cause "it works for what I want it to do", It may not > > be the best or have all the functions I want but if I got to go trouble > > shoot all the problems then f__ it!!!!!! > > > > > Sorry about the back to back post. The above statement is exactly what > Microsoft has found out on it constant updates to fix its system. The > user will not make the change cause "it will break something else". So > they are not keeping there system up with what MS calls critical > updates. Think about it!!!!! Oh, but I think about it. I can assure you each time I get a new swen virus in my mailbox I think bloody hard about it. Read my post. Sleep on it. Then read it again. Somehow you seem to assume dependencies are the worst thing that can happen to a user. I've given you a mailfull of real examples of people that thought the same thing, and ended up screwing the user big time because their solution was at best 80% of the cost of using a full-featured system package manager, and they conveniently forgot that 0.8*100 >> 1. We're no longer talking about single-user single-application dedicated systems. Any single user nowadays will interact with multiple apps, and if apps integration is broken because they each use their own library set he will be immensely pissed of. And this is only when you purposefully ignore the upgrade problems. Updates are a fact of life. Live with it. You need to upgrade because there are nasty people that will attack every single hole in your apps. You need to upgrade because your hardware will change and this means the software handlers must keep up with it. And, last and least of all you need to upgrade because you want the app enhancements like everyone else. I can only ROTFL when you attack dependencies then write a few posts later about the user refusing updates because MS taught it they constantly break new things. I'll give you another hint. Once. MS happens to sell a system with no dependencies checks. It's also a system that can not get updates right. RPM and deb use dependencies. rpm and dep system have been seamlessly updated by users for years. The truth is that the user is not hopelessly dumb as people seem so fond of writing. The user is L.A.Z.Y. The user will happily use whatever tech that helps him get rid of the broken application-centric update processes the MS and proprietary world have forced upon him for the last years. It is false to think he'll reject every new approach (for him). It is false to write he needs standalone apps because he's used to them (conveniently forgetting this standalone approach is what got us in the current mess, and that computer systems managed to replace VCRs as the most hated piece of tech in our everyday life). Integrated solutions like unified print systems, directx, etc have been a huge success. Modern package managers are nothing more that an integrated upgrade system. That mainstream operating systems don't use them yet is no reason to reject them. Quite the contrary since those very same systems have failed miserably to solve the update problem. The average user will try apt/yum/up2date and find it saves him hours of update procedure time he can pass doing more interesting stuff. The average user like you wrote wouldn't care less if its package manager used dependencies, cold fusion or fuzzy logic. The average user cares that its works without sucking his precious time. This is the single success criterion. Today Linux modular package installations pass this test hands-on. When I read someone advocating doing it the windows or mac standalone way I read someone that wants to save himself some packaging work at the expense of the end-user. The fun things is it's always advocated to spare the user the dreadful rpm experience. rpm is not dreadful. With apt/yum/up2date/urpmi it's a lifesaver. -- 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 elanthis at awesomeplay.com Sat Oct 4 16:19:27 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 04 Oct 2003 12:19:27 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065273071.3207.67.camel@rousalka.dyndns.org> References: <003f01c38a65$edbca8c0$735eee0c@C515816A> <1065273071.3207.67.camel@rousalka.dyndns.org> Message-ID: <1065284367.5142.38.camel@stargrazer.home.awesomeplay.com> On Sat, 2003-10-04 at 09:11, Nicolas Mailhot wrote: > Dear user, > > As we all know you're dumb and you can not learn to use a package > manager ever. To ease your pain we've decided not to inflict you the > so-called "dependency hell" and provide you an autonomous application. > Just click on its auto-update menu and it will download everything you > need, we swear it. *bzzt* It has *nothing* to do with users being "dumb." *nothing* It has to do with the fact the user doesn't care, doesn't need to care, and shouldn't be forced to care. I don't have a fricken clue how a jet engine works, don't really care how it works, but that doesn't mean I'm not allowed to fly on a plane. Indeed, the usage of an airplane is completely independent of knowing how the engine works, including the pilots. Computers aren't any different. There is no reason a user should *have* to understand the inner workings of it. That doesn't mean they *can't* know it, only that they don't need to. Don't confuse those two ideas. > To help you keep up with updates we've thoughtfully provided a "time to > update" popup that will remind you every few weeks you need to keep up > with us. To avoid any misunderstanding we designed it to be completely > different from the swarm of update popups you deal with every day. Red Hat/Fedora offers the up2date applet, which does just this, and is a good thing. ^,^ -- Sean Middleditch AwesomePlay Productions, Inc. From elanthis at awesomeplay.com Sat Oct 4 16:23:23 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 04 Oct 2003 12:23:23 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065257706.6399.37.camel@rousalka.dyndns.org> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> <1065257706.6399.37.camel@rousalka.dyndns.org> Message-ID: <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> On Sat, 2003-10-04 at 04:55, Nicolas Mailhot wrote: > Le sam 04/10/2003 ? 05:23, Sean Middleditch a ?crit : > > Are you talking about users, or sysadmins/hackers? I'd doubt a user > > would even know a jar file is, or their installed version of Java. > > Well java is a bit special. > Most upstream projects do not care about packaging at all (you know, big > ugly system-dependent mess, not like their WORA nirvana) so people are > used to struggle to install stuff. When they're fed up they find a nice > packaging project like jpackage and are delighted ; however they can see > if you've done something less optimal that what they did manually before > and will complain (loudly) in that case. The package could have been split up nicely and with dependencies on either a 1.4 jvm or your 1.3 jar file addons, resulting in a small download for java 1.4 users and continued ease of use for java 1.3 users, no? (assuming you did something along these lines - haven'tu sed your packages) > > But even if the proportion of clueful users were less for a mainstream > project like Fedora I strongly object to the idea bad packaging should > be allowed to ease some users pain. If you drive out all enlightened > users the contributor pool will dry up and Redhat will be left alone > supporting Fedora - not something they're ready to I think. I'm not arguing for "bad packaging", i'm arguing for *correct* packaging. One package should always work; its dependencies just need to be correct to ensure this. Putting everything needed in one package is not the solution I've asked for at all, if you read this thread, with the sole exception of broken dependencies that can't be packaged any other way. > > > Certainly, every user I've dealt with recently (including a handful > > friends and a number of coworkers) would have no clue; they can barely > > remember their OS is "Microsoft Windows" and not "Compaq Explorer." > > ;-) (and no, that isn't an implication users are stupid, merely that > > they often don't know much about computers. i can't keep the names of > > various parts of a car engine straight, but that's only because i'm not > > really familiar with it, and I don't really care in the least, so long > > as it moves. just like many users don't care how the computer runs, > > jsut that it works. and yes, that was a real example, not my usual > > satirical exaggeration ;-) > > Sure. But do you see any of them installing Fedora by themselves ? If > there is someone clueful enough somewhere to install Linux he will > understand some packaging issues so your example is not relevant (and he > won't have to understand everything to point out at least a few > mistakes) This is complete nonsense. I've two friends just the last couple weeks that have RH9, one I installed for him (since I helped build his machine) and the other installed by the friend after I gave him CDs. Neither of them understand jack about the packaging, and I've already had to make tons of excusses for the insanity of it (along with other Linux stupidities, which are another topic entirely). Getting calls at 10pm because they can't figure out how to get OpenRPG installed (or whatever) is irritating. Nobody should *have* to explain it to them, it should just work the way they'd expect - which is click on the package, and watch it install (possibly grabbing dependencies, or providing a very sane/clear message if they cannot be found, which is another RPM problem...) > > > > Show me a repository with big fat packages that include all deps to be > > > standalone and I'll show you a repository no one wants to use. Users may > > > not all know the zen of packaging but it will only take a few long > > > downloads or stuffed disks to enlighten them. > > > > All dependencies embedded aren't at all needed. Just the ones people > > can't develop and/or package correctly. > > I like the "just" bit. > > That was already the case for libgal for a long time. And it is a pita > for normal users - package managers like apt do not like duplicate stuff > so people have to largely handle this manually. Libgal wasn't really a "public" library, either. Apps depending on a library like that need to realize what that means. > > Don't open the gates if you're not prepared to handle the flood that > *will* follow. > > > If things were developed using > > sane release and maintenance practices, you'd never have need to ship a > > dependency with an application. It's only when the dependency is > > released/maintained in the usual inexperienced 13-year-old style that > > you need to do that. ~,^ > > I see you've never tried to package a large pool of inter-dependant > projects. In 80%+ of the cases the problem lies upstream. If the > packager accepts the deps upstream wants to force on him the mess will > only grow. Most of the upstream projects I work with would jump to the > possibility to embed all the deps they need because that matches their > vision of their app as the center of the system. Does anyone bring up these problems with the upstream in these cases, or just work around it? I might also note that this is most important for user apps, not so much backend/server stuff; my friend Dan (very bright, but never had a computer until last week) isn't going to be installing Apache or a telephony system. ;-) A lot of backend apps half the time aren't ever *intended* to be packaged. There will *always* be upstream sources from hell, but a solid packaging policy and avoidance of the cheap route out should let packagers deal with them in a sane manner. If not, then they will at least be the *exception*, and not the *rule*. I never claimed things will be 100% perfect, just that the majority of packages should work sanely. ~,^ > > Someone must say stop at one point. It might be a larger project > (Gnome), a packaging project (Fedora) or the end-user (because in the > end duplicating stuff is a maintenance burden and you're only exchanging > upstream-level work with packager or user work by embedding stuff). > > You're right most users do not want to bother with package deps. You're > wrong however in thinking they'll accept the mess a massive embedding > policy would foster on them. Again, *only* when embedding is the *only* choice. I don't like embedding any more than you, but when it's either embed or force the user to upgrade the entire system for one app... Your other mail indicates you seem not to be following that. Embedding isn't the answer, it's the hack needed when upstream breaks things for us. The answer isn't always the extreme; there *are* shades of gray. ;-) (just hopefully mostly towards the bright side) I'd imagine in almost all cases the embedding can be gone without. If nothing else, putting libraries/packages like that in different locations would help. A policy would be needed so people could know how to do that tho, and not end up with a bunhc of random, incompatible methods. ;-) > > I'm perfectly happy with un-packageable projects (ie projects that do > not address packager needs and can not work with the same deps as the > rest of the system) being kicked out of Fedora. I'm also perfectly happy > with old releases not getting the same kind of care as new ones. They > have to die at some point - you can not support every single release at > vitam eternam. Nobody here will knowingly make upgrades harder for older Right ^,^ > releases. Sacrificing the system sanity to the golden cow of eternal > upgradeability however will only produce a Windows-like mess were > everything "sort-of" works for everyone. You have to do some spring > cleanups, even in real life. This, of course, is the purpose of deprecation. We have GNOME2 and GNOME1 libs in RH9, but as soon as all apps move off of GNOME1/GTK1, those can be removed. Apps that, 5 years later, still rely on 5 year old incompatible libraries, probably need to be removed or replaced. Or at least patched to work on new systems, if they're somehow super-mandatory. (which would be an ugly situation) You only need the legacy cruft installed if you are using a legacy app. Windows' mess is due to the fact that it can't grab legacy cruft on app install, so it always has to have it laying there. Fedora can always ship its core CD(CDs if we continue with the "stuff too much crap in the base OS" philosophy) with only the cutting-edge stuff, and put legacy support packages on the other CDs or online for fetching w/ up2date. (It would also be nice if the system could detect when a "support" package, like a library, is no longer used and can be removed - tho that would need to be easily overridable for those of us installing thigns from source ;-) > > Cheers, -- Sean Middleditch AwesomePlay Productions, Inc. From Nicolas.Mailhot at laPoste.net Sat Oct 4 17:15:40 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 04 Oct 2003 19:15:40 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> <1065257706.6399.37.camel@rousalka.dyndns.org> <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> Message-ID: <1065287740.4868.94.camel@rousalka.dyndns.org> Le sam 04/10/2003 ? 18:23, Sean Middleditch a ?crit : > On Sat, 2003-10-04 at 04:55, Nicolas Mailhot wrote: > > Le sam 04/10/2003 ? 05:23, Sean Middleditch a ?crit : > > > > Are you talking about users, or sysadmins/hackers? I'd doubt a user > > > would even know a jar file is, or their installed version of Java. > > > > Well java is a bit special. > > Most upstream projects do not care about packaging at all (you know, big > > ugly system-dependent mess, not like their WORA nirvana) so people are > > used to struggle to install stuff. When they're fed up they find a nice > > packaging project like jpackage and are delighted ; however they can see > > if you've done something less optimal that what they did manually before > > and will complain (loudly) in that case. > > The package could have been split up nicely and with dependencies on > either a 1.4 jvm or your 1.3 jar file addons, resulting in a small > download for java 1.4 users and continued ease of use for java 1.3 > users, no? (assuming you did something along these lines - haven'tu sed > your packages) All external deps spun out of the package, 1.4 jvm providing the same virtuals deps as standalone 1.3 bits, run-time shells scripts that picks whatever jars are present on the system. The tomcat rpm is now lean and mean and the jars can be reused by whatever other app (jboss...) can need them. The only problem is if one installs a partial 1.4 system and a partial 1.3, and the sum of them provides all the virtuals tomcat needs but neither the 1.3 nor the 1.4 set of rpms is complete enough to support tomcat (ie there is no real way to tell rpm that A+B is ok and C+D is ok too, you have to require X and Y, have A & C provide X and B& D Y - which breaks on a A+d system). Thanksfully only developers ever try that. > > But even if the proportion of clueful users were less for a mainstream > > project like Fedora I strongly object to the idea bad packaging should > > be allowed to ease some users pain. If you drive out all enlightened > > users the contributor pool will dry up and Redhat will be left alone > > supporting Fedora - not something they're ready to I think. > > I'm not arguing for "bad packaging", i'm arguing for *correct* > packaging. One package should always work; its dependencies just need > to be correct to ensure this. Putting everything needed in one package > is not the solution I've asked for at all, if you read this thread, with > the sole exception of broken dependencies that can't be packaged any > other way. Then no one will argue with you here. I'm sure we'll always find a way not to package stuff in a single package;) > > > Certainly, every user I've dealt with recently (including a handful > > > friends and a number of coworkers) would have no clue; they can barely > > > remember their OS is "Microsoft Windows" and not "Compaq Explorer." > > > ;-) (and no, that isn't an implication users are stupid, merely that > > > they often don't know much about computers. i can't keep the names of > > > various parts of a car engine straight, but that's only because i'm not > > > really familiar with it, and I don't really care in the least, so long > > > as it moves. just like many users don't care how the computer runs, > > > jsut that it works. and yes, that was a real example, not my usual > > > satirical exaggeration ;-) > > > > Sure. But do you see any of them installing Fedora by themselves ? If > > there is someone clueful enough somewhere to install Linux he will > > understand some packaging issues so your example is not relevant (and he > > won't have to understand everything to point out at least a few > > mistakes) > > This is complete nonsense. I've two friends just the last couple weeks > that have RH9, one I installed for him (since I helped build his > machine) and the other installed by the friend after I gave him CDs. > Neither of them understand jack about the packaging, and I've already > had to make tons of excusses for the insanity of it (along with other > Linux stupidities, which are another topic entirely). Getting calls at > 10pm because they can't figure out how to get OpenRPG installed (or > whatever) is irritating. So would have standalone apps changed anything ? No. They'd have called you because your integrated app used its own config files and didn't pick up the system settings they chose in the control panel. What could have changed something is the app be properly packaged in Fedora (for example) and your friends being taught to use apt/yum/whatever. > Nobody should *have* to explain it to them, it should just work the way > they'd expect - which is click on the package, and watch it install > (possibly grabbing dependencies, or providing a very sane/clear message > if they cannot be found, which is another RPM problem...) ROTFL. The way they expect it is you doing the install for them. I have questions about MS office every other week even though I'm the only person at work who *never* use it 'cos I has a linux desktop (I have questions about office by people who use it all the day !). The problem is not following "what the user expects". The problem is having a working framework so people won't assume they should not bother learning it because it's as broken as the other ones and asking their resident guru is easier anyway. [...] > > I see you've never tried to package a large pool of inter-dependant > > projects. In 80%+ of the cases the problem lies upstream. If the > > packager accepts the deps upstream wants to force on him the mess will > > only grow. Most of the upstream projects I work with would jump to the > > possibility to embed all the deps they need because that matches their > > vision of their app as the center of the system. > > Does anyone bring up these problems with the upstream in these cases, or > just work around it? Both. Strangely enough users understand readily enough what they win in a nicely modular system, while upstream developers more often than not strongly object to someone even suggesting they massive bundle of straight-from-cvs binaries is not proper packaging. > I might also note that this is most important for user apps, not so much > backend/server stuff; my friend Dan (very bright, but never had a > computer until last week) isn't going to be installing Apache or a > telephony system. ;-) A lot of backend apps half the time aren't ever > *intended* to be packaged. A sysadmin likes its stuff properly packaged like anyone else. [...] > I'd imagine in almost all cases the embedding can be gone without. Then why bring it up now ? When you find an app that you feel absolutely needs embedding then it will be time to argue. Doing it now over an hypothetical case is pointless. I'm sure someone on the list will always find a way to avoid embedding s > > releases. Sacrificing the system sanity to the golden cow of eternal > > upgradeability however will only produce a Windows-like mess were > > everything "sort-of" works for everyone. You have to do some spring > > cleanups, even in real life. > > This, of course, is the purpose of deprecation. We have GNOME2 and > GNOME1 libs in RH9, but as soon as all apps move off of GNOME1/GTK1, > those can be removed. Apps that, 5 years later, still rely on 5 year > old incompatible libraries, probably need to be removed or replaced. Or > at least patched to work on new systems, if they're somehow > super-mandatory. (which would be an ugly situation) Just freeze the repository at release time and have all new packages go into an unstable branch (or at least require them to go into unstable before hitting stable). If something didn't get packaged in unstable by the time it's time for another release - drop it. The announced release frequency is high enough people can wait for the next release for new stuff. 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 ms-nospam-0306 at arcor.de Sat Oct 4 17:20:21 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 4 Oct 2003 19:20:21 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> Message-ID: <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 04 Oct 2003 11:51:34 -0400, Sean Middleditch wrote: > Given the autopackage project, RPMs and their (possible) problems may in > the future just be relegated to low-level system stuff, which is another > solution, but one not yet ready. This one? http://autopackage.org/faq.html Doesn't look promising in the middle of the FAQ. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fwFV0iMVcrivHFQRApoQAJwO0z1i/1KhKCxsNQj60QvVOyPNeQCfWz4p ZwEYSD52z9HxNs7K07J04Ks= =8IFF -----END PGP SIGNATURE----- From andyhanton at comcast.net Sat Oct 4 17:58:32 2003 From: andyhanton at comcast.net (Andy Hanton) Date: Sat, 04 Oct 2003 13:58:32 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> Message-ID: <1065290312.4488.130.camel@andy> On Sat, 2003-10-04 at 13:20, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 04 Oct 2003 11:51:34 -0400, Sean Middleditch wrote: > > > Given the autopackage project, RPMs and their (possible) problems may in > > the future just be relegated to low-level system stuff, which is another > > solution, but one not yet ready. > > This one? http://autopackage.org/faq.html Doesn't look promising > in the middle of the FAQ. They aren't the only ones working on this stuff. The zero-install project (http://zero-install.sf.net/) seems to be trying for a more interesting solution. They actually link software to libraries using a caching http filesystem. For example, an application that needs gtk2 would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. So it doesn't need the funny hacks autopackage uses to detect what the user has installed. The user can double click the application and all the dependencies are downloaded automatically and doing so never breaks anything else on the system. -- Andy Hanton From Nicolas.Mailhot at laPoste.net Sat Oct 4 18:02:01 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 04 Oct 2003 20:02:01 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065290312.4488.130.camel@andy> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> Message-ID: <1065290520.4868.96.camel@rousalka.dyndns.org> Le sam 04/10/2003 ? 19:58, Andy Hanton a ?crit : > On Sat, 2003-10-04 at 13:20, Michael Schwendt wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Sat, 04 Oct 2003 11:51:34 -0400, Sean Middleditch wrote: > > > > > Given the autopackage project, RPMs and their (possible) problems may in > > > the future just be relegated to low-level system stuff, which is another > > > solution, but one not yet ready. > > > > This one? http://autopackage.org/faq.html Doesn't look promising > > in the middle of the FAQ. > > They aren't the only ones working on this stuff. The zero-install > project (http://zero-install.sf.net/) seems to be trying for a more > interesting solution. They actually link software to libraries using a > caching http filesystem. For example, an application that needs gtk2 > would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. So it > doesn't need the funny hacks autopackage uses to detect what the user > has installed. The user can double click the application and all the > dependencies are downloaded automatically and doing so never breaks > anything else on the system. And how do you trust the result ? RPMs at least are signed. -- 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 andyhanton at comcast.net Sat Oct 4 18:18:23 2003 From: andyhanton at comcast.net (Andy Hanton) Date: Sat, 04 Oct 2003 14:18:23 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065290520.4868.96.camel@rousalka.dyndns.org> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <1065290520.4868.96.camel@rousalka.dyndns.org> Message-ID: <1065291503.4488.157.camel@andy> On Sat, 2003-10-04 at 14:02, Nicolas Mailhot wrote: > Le sam 04/10/2003 ? 19:58, Andy Hanton a ?crit : > > On Sat, 2003-10-04 at 13:20, Michael Schwendt wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On Sat, 04 Oct 2003 11:51:34 -0400, Sean Middleditch wrote: > > > > > > > Given the autopackage project, RPMs and their (possible) problems may in > > > > the future just be relegated to low-level system stuff, which is another > > > > solution, but one not yet ready. > > > > > > This one? http://autopackage.org/faq.html Doesn't look promising > > > in the middle of the FAQ. > > > > They aren't the only ones working on this stuff. The zero-install > > project (http://zero-install.sf.net/) seems to be trying for a more > > interesting solution. They actually link software to libraries using a > > caching http filesystem. For example, an application that needs gtk2 > > would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. So it > > doesn't need the funny hacks autopackage uses to detect what the user > > has installed. The user can double click the application and all the > > dependencies are downloaded automatically and doing so never breaks > > anything else on the system. > > And how do you trust the result ? > RPMs at least are signed. I would assume that the daemon that runs the /uri filesystem would check signatures on downloads. I don't think it does yet but there is no reason that it couldn't. Some effort would be necessary to set up a web of trust so that the user didn't have to decide if the keys were valid. I believe that the zero-install system actually downloads the contents of directories as tarballs, so the could just sign the tarball for each release. I don't really see how that is any worse than what rpm offers. There is already a per user daemon in the system responsible for displaying download progress bars and stuff. If the signature checking failed it could present the user with a nice dialog saying that the software couldn't be run. -- Andy Hanton From ms-nospam-0306 at arcor.de Sat Oct 4 18:39:36 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 4 Oct 2003 20:39:36 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065290312.4488.130.camel@andy> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> Message-ID: <20031004203936.42e69624.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 04 Oct 2003 13:58:32 -0400, Andy Hanton wrote: > They aren't the only ones working on this stuff. The zero-install > project (http://zero-install.sf.net/) seems to be trying for a more > interesting solution. They actually link software to libraries using a > caching http filesystem. For example, an application that needs gtk2 > would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. Treat me like a dumb user, please. In which way is that better than the current dependency on libgtk-x11-2.0.so.0? What problems is it supposed to fix? > So it > doesn't need the funny hacks autopackage uses to detect what the user > has installed. $ rpm --redhatprovides libgtk-x11-2.0.so.0 gtk2-2.2.1-4 > The user can double click the application and all the > dependencies are downloaded automatically and doing so never breaks > anything else on the system. We do have that feature already, don't we? - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fxPo0iMVcrivHFQRAvM1AJ91hI0g9q5KcbacfWSQ9kvFhFpRiACeIjKC szGEAMw6GNAzEY5nx1jvZH0= =KCEZ -----END PGP SIGNATURE----- From ckloiber at redhat.com Sat Oct 4 18:44:59 2003 From: ckloiber at redhat.com (Chris Kloiber) Date: Sat, 04 Oct 2003 14:44:59 -0400 Subject: alpha architecture In-Reply-To: References: Message-ID: <1065293099.19982.315.camel@luser.ckloiber.com> On Thu, 2003-10-02 at 14:16, Jim wrote: > I have the HP edition of RH7.2 installed on a 21164 533Mhz pc164lx. All > is well with the system and I have had no problems except that there are > no software updates/upgrades to the latest versions of applications I need > such as postgresql/php/apache/ssl etc. Then I ran across the Fedora > project and noticed that the latest alpha rpm's for these applications > were availible for download. The problem is that they don't work on the > 7.2 release and rpm -Uvh for the packages I need give me countless failed > deps as I expected they would. Will there be an upcomming alpha iso > release for the latest redhat version? If not, I would like to port > an updated rh release for the alpha architecture. If any one is doing > this already or if anybody needs help doing this I'd be pleased to help > out. If someone is already doing this could you please point me in the > right direction? > > Thanks, > Jimmy Green God how I wish so, I have the hardware, but not the knowledge. I have a working Dual 667Mhz UP2000 (ev67), a Dual 533Mhz AS1200 (ev6), a Personal Workstation 500au (ev5, iirc), a Single 533 SX164 (pca56) and even a functional 233 Multia (ev4). Back when Red Hat had an Alpha distribution, I used to support it. But I am not a developer. If you ever do get an Alpha project going, I can test it on a bunch of hardware. Right now I only run the UP2000 on a day-to-day basis. I have not been able to build a working Alpha kernel in a long time. I however won't have time to look at this again until 2004. I'll be in Manila, Philippines from next Saturday until Dec.15, and won't really be home until after the holidays. -- Chris Kloiber Red Hat, Inc. From rezso at rdsor.ro Sun Oct 5 01:56:45 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Sat, 4 Oct 2003 21:56:45 -0400 Subject: alpha architecture In-Reply-To: <1065293099.19982.315.camel@luser.ckloiber.com> References: <1065293099.19982.315.camel@luser.ckloiber.com> Message-ID: <200310042156.45625.rezso@rdsor.ro> On Saturday 04 October 2003 14:44, Chris Kloiber wrote: > On Thu, 2003-10-02 at 14:16, Jim wrote: > > I have the HP edition of RH7.2 installed on a 21164 533Mhz pc164lx. All > > is well with the system and I have had no problems except that there are > > no software updates/upgrades to the latest versions of applications I > > need such as postgresql/php/apache/ssl etc. Then I ran across the Fedora > > project and noticed that the latest alpha rpm's for these applications > > were availible for download. The problem is that they don't work on the > > 7.2 release and rpm -Uvh for the packages I need give me countless failed > > deps as I expected they would. Will there be an upcomming alpha iso > > release for the latest redhat version? If not, I would like to port an > > updated rh release for the alpha architecture. If any one is doing this > > already or if anybody needs help doing this I'd be pleased to help out. > > If someone is already doing this could you please point me in the right > > direction? > > > > Thanks, > > Jimmy Green > > God how I wish so, I have the hardware, but not the knowledge. I have a > working Dual 667Mhz UP2000 (ev67), a Dual 533Mhz AS1200 (ev6), a > Personal Workstation 500au (ev5, iirc), a Single 533 SX164 (pca56) and > even a functional 233 Multia (ev4). Back when Red Hat had an Alpha > distribution, I used to support it. But I am not a developer. If you > ever do get an Alpha project going, I can test it on a bunch of > hardware. Right now I only run the UP2000 on a day-to-day basis. > > I have not been able to build a working Alpha kernel in a long time. I Hmm .18 .19 .20 .21 all worked stable, and even 2.6.0-test5 works on it !! If anyone have time to play and want latest rawhide packages for alpha machines which fit nicely with rpm -Uvh * over 7.2/7.1 i have an own tree builded in my free time which works well here on my poor Miata: ftp://ftp.rdsor.ro/pub/Linux/Distributions/AlphaLinux/rawhide/ -not all package are there because havnt time only base gcc/glibc/xfree and mplayer goodie of course :) but planning to do some automated scripts. cristian > however won't have time to look at this again until 2004. I'll be in > Manila, Philippines from next Saturday until Dec.15, and won't really be > home until after the holidays. -- Life in itself has no meaning. Life is an opportunity to create meaning. \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ From andyhanton at comcast.net Sat Oct 4 19:10:35 2003 From: andyhanton at comcast.net (Andy Hanton) Date: Sat, 04 Oct 2003 15:10:35 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <20031004203936.42e69624.ms-nospam-0306@arcor.de> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> Message-ID: <1065294635.4488.313.camel@andy> On Sat, 2003-10-04 at 14:39, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 04 Oct 2003 13:58:32 -0400, Andy Hanton wrote: > > > They aren't the only ones working on this stuff. The zero-install > > project (http://zero-install.sf.net/) seems to be trying for a more > > interesting solution. They actually link software to libraries using a > > caching http filesystem. For example, an application that needs gtk2 > > would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. > > Treat me like a dumb user, please. In which way is that better than > the current dependency on libgtk-x11-2.0.so.0? What problems is it > supposed to fix? The idea is that the same library could be used on debian or Suse or whatever. Basically it effects end users, but it doesn't really solve any problems for Fedora developers. > > > So it > > doesn't need the funny hacks autopackage uses to detect what the user > > has installed. > > $ rpm --redhatprovides libgtk-x11-2.0.so.0 > gtk2-2.2.1-4 It doesn't really help as much for common libraries. The idea is that library authors can maintain their own binaries. Application authors can be sure that the end user's system will be able to find the library because the url is embedded in the binary. Try rpm --redhatprovides libenchant.so.1.0.0 on a redhat 9 box. /uri/0install/www.abisource.com/enchant/libenchant.so.1.0.0 would clearly be better in that case. I think the idea that we can package all the dependencies that could ever exist is unrealistic. Even if we become like debian with 10,000 packages that won't solve the cross distribution problem. You can't tell your grandmother who runs Suse to go to the web page and download an rpm because suse hasn't packaged all the dependencies. > > > The user can double click the application and all the > > dependencies are downloaded automatically and doing so never breaks > > anything else on the system. > > We do have that feature already, don't we? No, we don't. With zero-install the user never actually uses a package management system. Here is how it works: 1.download an application from the author's web page 2. double click the archive to untar it 3. double-click the application and it runs Basically the user does not need to think about finding a binary for their specific distribution or understand dependencies or package management. It provides Mac OS X type simplicity on Linux. -- Andy Hanton From ms-nospam-0306 at arcor.de Sat Oct 4 20:29:27 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 4 Oct 2003 22:29:27 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065294635.4488.313.camel@andy> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> Message-ID: <20031004222927.3e69de95.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 04 Oct 2003 15:10:35 -0400, Andy Hanton wrote: > It doesn't really help as much for common libraries. The idea is that > library authors can maintain their own binaries. Application authors > can be sure that the end user's system will be able to find the library > because the url is embedded in the binary. So, in other words I would depend on arbitrary sites to supply prebuilt libraries rather than getting software from trusted community repositories? Would those prebuilt libraries be of the same poor quality than what is offered on the average upstream site? The average upstream site features contributed packages. Contributed by individuals. The same individual who would contribute their packages to a community project, provided that such a community project is available. > Try rpm --redhatprovides libenchant.so.1.0.0 on a redhat 9 box. > /uri/0install/www.abisource.com/enchant/libenchant.so.1.0.0 > would clearly be better in that case. Not clear at all. Why would I need that library? Why wouldn't it be found automatically when I install an application with e.g. Yum? Why hasn't anyone created a src.rpm for it? Aha, the software is complicated to install from source? There we have the real problem. > I think the idea that we can package all the dependencies that could > ever exist is unrealistic. Only what is popular or worthwhile gets packaged by someone. Everything else can be rebuilt from source. > Even if we become like debian with 10,000 > packages that won't solve the cross distribution problem. Ah, cross-distribution. *cough* Who makes sure that app A from site B and lib D from site E for distribution C work smoothly on distribution F where inter-library dependencies are satisfied with packages from site G? Where is the testing and quality assurance in this scenario? > You can't > tell your grandmother who runs Suse to go to the web page and download > an rpm because suse hasn't packaged all the dependencies. Isn't that what Fedora Extras tries to target? The chance for the community to package the popular stuff and maintain it as long as their is enough interest in it? > With zero-install the user never actually uses a package > management system. > > Here is how it works: > 1.download an application from the author's web page > 2. double click the archive to untar it > 3. double-click the application and it runs Scary scenario. Even more scary when the application asks for superuser privileges in order to perform some ordinary integration tasks. The scenario gets threatening when the author of the application focuses on prebuilt binaries as primary distribution channel and neglects the source code level. Oh, and don't dare to report a bug to the author when you run a different distribution. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fy2n0iMVcrivHFQRApccAJ9rcYeRJspZfkbvqEXnU+vf1Gg7eQCeOC8s VW4IsE0js3KqKQX3BdrZ0/g= =kNEA -----END PGP SIGNATURE----- From hp at redhat.com Sat Oct 4 21:49:28 2003 From: hp at redhat.com (Havoc Pennington) Date: 04 Oct 2003 17:49:28 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <20031004222927.3e69de95.ms-nospam-0306@arcor.de> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> Message-ID: <1065304168.2226.13.camel@dhcppc3> On Sat, 2003-10-04 at 16:29, Michael Schwendt wrote: > > Even if we become like debian with 10,000 > > packages that won't solve the cross distribution problem. > > Ah, cross-distribution. *cough* Who makes sure that app A from site B > and lib D from site E for distribution C work smoothly on distribution > F where inter-library dependencies are satisfied with packages from > site G? Where is the testing and quality assurance in this scenario? > The solution to end-user dependency problems is very simple, and it is the same one used on Windows. Here it is: don't have any dependencies that don't come with the OS. Bundle everything internal to your app. This is what almost all proprietary software for Linux does. It's also what an LSB-compliant package _must_ do. But of course, nobody seems to make LSB-compliant packages, instead they just complain about how packages are distribution-dependent. ;-) People, this is the whole point of the LSB... For software that comes with the OS and lives in the Fedora Project, we should be able to do better; redhat-config-packages doesn't make you see dependencies really, and it could be made even better than it is. Here is one way to think about it from a UI standpoint. The user model is that there's "the application" which can be installed, uninstalled, moved around, and launched. Unfortunately, for moving around and launching you're using a .desktop file. For install/uninstall you're using the r-c-p "comps group" concept sometimes, and "foo.rpm" files sometimes. So there are three implementation details leaking out, where the simple user model would have only 1 concept. So ways to improve this might include: - a way to bundle a set of RPMs into a single user-visible file, so you can have an "uninstalled app" visible in the file manager - have ways to install/uninstall a package by manipulating the thing implemented now as a .desktop file (the menu/filemanager entry) - try to ensure packages for "end user apps" always have names that match the primary desktop file in the package; so e.g. the Gnumeric .rpm package would show up in file manager as "Gnumeric Spreadsheet" and once installed you get same in menu Those are just some possibilities, not well-researched proposals. The general idea is to fix the "leakiness" of the current abstraction; ideally, a naive end user doesn't have to learn 3 implementation details when a single concept of "an application" should be sufficient. Havoc From alan at redhat.com Sat Oct 4 22:58:47 2003 From: alan at redhat.com (Alan Cox) Date: Sat, 4 Oct 2003 18:58:47 -0400 (EDT) Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <20031004222927.3e69de95.ms-nospam-0306@arcor.de> from "Michael Schwendt" at Hyd 04, 2003 10:29:27 Message-ID: <200310042258.h94MwlS30560@devserv.devel.redhat.com> > So, in other words I would depend on arbitrary sites to supply prebuilt > libraries rather than getting software from trusted community > repositories? Would those prebuilt libraries be of the same poor quality Actually if the binary is supplied signed by the trusted community source its origin isnt actually too important. Did it come froma mirror, did it come from your ISP web cache - was it in fact several round robin sites. The truth is you already don't know. > Isn't that what Fedora Extras tries to target? The chance for the > community to package the popular stuff and maintain it as long as > their is enough interest in it? Yes, and to provide a place to find good stuff versus the sea of junk that you get with arbitary indexes. > channel and neglects the source code level. Oh, and don't dare to > report a bug to the author when you run a different distribution. The inability to define the precise system state is a big issue for business or industrial uses. 'zero install' itself doesn't impress me, its a special case subset of a distributed caching network file system like AFS or DAV. Life really starts to get fun when you have a companywide caching fs and your boot up looks something like Set up cache dhcp network setup mount companwide fs chroot companywidefs exec init At that point its a lot more powerful From Nicolas.Mailhot at laPoste.net Sat Oct 4 23:51:55 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 05 Oct 2003 01:51:55 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065304168.2226.13.camel@dhcppc3> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> Message-ID: <1065311515.3129.11.camel@rousalka.dyndns.org> Le sam 04/10/2003 ? 23:49, Havoc Pennington a ?crit : > So ways to improve this might include: > > - a way to bundle a set of RPMs into a single user-visible file, > so you can have an "uninstalled app" visible in the file manager Actually the smart thing would be to distribute apt/yum/up2date profiles that match an usage, and let them the package manager download the parts that are not installed yet and all second, third, fourth... -level dependencies. I'll be strongly suspicious of any application-level bundling. Upstream projects just do not care enough to get all peripheral stuff right. OTOH some way to specify weak user-level dependencies (like "my doc is in pdf - get yourself a pdf reader") would help many people ("hard" dependencies ie stuff that is required by the code to work being handled the usual rpm way). 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 Sun Oct 5 00:03:59 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 05 Oct 2003 02:03:59 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <200310042258.h94MwlS30560@devserv.devel.redhat.com> References: <200310042258.h94MwlS30560@devserv.devel.redhat.com> Message-ID: <1065312239.3129.24.camel@rousalka.dyndns.org> Le dim 05/10/2003 ? 00:58, Alan Cox a ?crit : > > So, in other words I would depend on arbitrary sites to supply prebuilt > > libraries rather than getting software from trusted community > > repositories? Would those prebuilt libraries be of the same poor quality > > Actually if the binary is supplied signed by the trusted community source > its origin isnt actually too important. Did it come froma mirror, did > it come from your ISP web cache - was it in fact several round robin sites. > The truth is you already don't know. Sure. But a srpm requires someone to document the build process. Allowing projects to directly provide binaries means you'll soon not be able to rebuild their stuff because their build scripts will rot in strange and wonderful ways, depend on undocumented build environments and anyway even if you manage to build them they will check their signature at runtime and refuse to run if they're not signed by the upstream project key. Which I'm sure the gcc people will love next time they want to release a new version since instead of pulling a RedHat they'll have to convince every single project the system use it's time to upgrade their build tools. (and I case someone thinks I'm overly pessimistic - this kind of stuff already exists. I met it. Every single aspect from the broken build system to the key check is already used by people who thought about auto-upload before the autoupdate project. And it's not even closed commercial stuff but pure FOSS) -- 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 hp at redhat.com Sun Oct 5 01:04:14 2003 From: hp at redhat.com (Havoc Pennington) Date: 04 Oct 2003 21:04:14 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065311515.3129.11.camel@rousalka.dyndns.org> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065311515.3129.11.camel@rousalka.dyndns.org> Message-ID: <1065315854.2226.80.camel@dhcppc3> On Sat, 2003-10-04 at 19:51, Nicolas Mailhot wrote: > Actually the smart thing would be to distribute apt/yum/up2date profiles > that match an usage, and let them the package manager download the parts > that are not installed yet and all second, third, fourth... -level > dependencies. That's the comps file approach redhat-config-packages uses now, essentially. Just need to have an idea of a comps file as a standalone thing with a MIME handler perhaps. Havoc From xose at wanadoo.es Sun Oct 5 03:00:54 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sun, 05 Oct 2003 05:00:54 +0200 Subject: Future unsupported Red Hat Linux systems Message-ID: <3F7F8966.6020807@wanadoo.es> hi, I know three[*] projects to provided support for future unsupported Red Hat Linux systems. But I don't see too much movement. Is there any current .plan? -thanks- [*] Fedora Legacy -> http://www.fedora.us/wiki/FedoraLegacy Univ-Linux -> http://linux.duke.edu/projects/univ-linux/ RH-Consortium -> http://www.quantumlinux.com/mailman/listinfo/rh-consortium be careful, cross-posted mail! -- :x From skvidal at phy.duke.edu Sun Oct 5 04:02:09 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Oct 2003 00:02:09 -0400 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <3F7F8966.6020807@wanadoo.es> References: <3F7F8966.6020807@wanadoo.es> Message-ID: <1065326528.14230.56.camel@binkley> On Sat, 2003-10-04 at 23:00, Xose Vazquez Perez wrote: > hi, > > I know three[*] projects to provided support for future unsupported > Red Hat Linux systems. But I don't see too much movement. Where would you like things to move? I think the plans probably look much like this: make use of the infrastructure that is being worked on for fedora extras to help packages to use for fedora legacy. I think the plan is to continue working on those systems and for anyone who has the need and ability to work on errata as needed. Does that make sense? -sv From jgardner at jonathangardner.net Sun Oct 5 06:00:54 2003 From: jgardner at jonathangardner.net (Jonathan Gardner) Date: Sat, 4 Oct 2003 23:00:54 -0700 Subject: New README file for cipe Message-ID: <200310042300.55855.jgardner@jonathangardner.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After spending a couple of hours trying to figure out cipe and how to use it with Redhat, i think I have put together a fairly comprehensive README. I intend this to be just a start, and I hope others who know more about cipe than myself will add notes and correct it where it is wrong. I personally don't know how to configure the redhat routes so that I can direct traffic to networks through the newly configure cipe interface. I wil figure that out pretty soon and I may add a note about it to the README if people are interested. There is also a patch for the /etc/sysconfig/network-scripts/ifdown-cipcb script attached. It addresses the attachment of "ifcfg-" to the CONFIG variable to match the behavior of /etc/sysconfig/network-scripts/ifup-cipcb. - -- Jonathan Gardner jgardner at jonathangardner.net Live Free, Use Linux! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/f7OWWgwF3QvpWNwRAjvtAKCOCr8oWFJ0h5y8ygTRg6SociYMkwCgisHB X15SFcreaKHKHFn4lx+7gik= =77Zr -----END PGP SIGNATURE----- -------------- next part -------------- Configuring cipe with Redhat by Jonathan Gardner 1) Planning. You'll need to determine what the new IP addresses of the two computers will be after the connection. You'll also need to know what ports you will use on each host. In my case, I am setting up a tunnel between atlas and jenner. I decide to use port 6789 on atlas, and 6790 on jenner. I also decide to give the IP address of 192.168.0.1 to atlas, and 192.168.0.2 to jenner. atlas: Using port 6789, will be 192.168.0.1 jenner: Using port 6790, will be 192.168.0.2 2) Open the firewall. I edited the file /etc/sysconfig/iptables to allow incoming UDP packets on jenner and atlas, but only from and to the appropriate ports. On atlas: -A INPUT -p udp -m udp -s jenner -d atlas --sport 6790 --dport 6789 -j ACCEPT On jenner: -A INPUT -p udp -m udp -s atlas -d jenner --sport 6789 --dport 6790 -j ACCEPT After I edited the iptables file, I restarted iptables. # service iptables restart 3) Configure the tunnelling. This will require a file at /etc/sysconfig/network-scripts/ifcfg-cipcb0 on both machines. The files read as follows. On atlas: DEVICE=cipcb0 ONBOOT=yes USERCTL=yes MYPORT=6789 PEER=jenner:6790 PTPADDR=192.168.0.2 IPADDR=192.168.0.1 On jenner: DEVICE=cipcb0 ONBOOT=yes USERCTL=yes MYPORT=6790 PEER=atlas:6789 PTPADDR=192.168.0.1 IPADDR=192.168.0.2 4) Finally, I created a key in /etc/cipe/options.cipcb0 on both machines. It reads: key [md5sum] where md5sum is the result of running: $ ps -aux | md5sum (note that I only included the 128 digit hexadecimal number - not the '-' part.) The options.cipcb0 must be set to be read only by the root user: # chmod 600 /etc/cipe/options.cipcb0 This file must match on both computers. 5) I could restart the network service on both machines to get it running. But I can also try starting and stopping the individual interface. To do that, I run: # /etc/sysconfig/network-scripts/ifup-cipcb ifcfg-cipcb0 to start it and # /etc/sysconfig/network-scripts/ifdown-cipcb ifcfg-cipcb0 to stop it. 6) Test the connection by pinging the opposite host. $ ping 192.168.0.1 $ ping 192.168.0.2 Congratulations! You have succeeded. If not, check the following: - The /etc/cipe/option.cipcb0 files match on both machines. - The firewall allows connections to the ports. Check both iptables and whatever else is connecting your computers. Remember that you have to restart iptables to get the changes you made. The same may hold true for whatever routers you have between your computers. - Watch the /var/log/messages file as you start and stop the service for odd messages about cipe. Try to figure out what they mean. 7) Now you may route traffic through the interface. -------------- next part -------------- A non-text attachment was scrubbed... Name: ifdown-cipcb.patch Type: text/x-diff Size: 241 bytes Desc: not available URL: From elanthis at awesomeplay.com Sun Oct 5 06:08:46 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 05 Oct 2003 02:08:46 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065287740.4868.94.camel@rousalka.dyndns.org> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> <1065257706.6399.37.camel@rousalka.dyndns.org> <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> <1065287740.4868.94.camel@rousalka.dyndns.org> Message-ID: <1065334125.4986.13.camel@stargrazer.home.awesomeplay.com> On Sat, 2003-10-04 at 13:15, Nicolas Mailhot wrote: > Le sam 04/10/2003 ? 18:23, Sean Middleditch a ?crit : > > This is complete nonsense. I've two friends just the last couple weeks > > that have RH9, one I installed for him (since I helped build his > > machine) and the other installed by the friend after I gave him CDs. > > Neither of them understand jack about the packaging, and I've already > > had to make tons of excusses for the insanity of it (along with other > > Linux stupidities, which are another topic entirely). Getting calls at > > 10pm because they can't figure out how to get OpenRPG installed (or > > whatever) is irritating. > > So would have standalone apps changed anything ? No. They'd have called > you because your integrated app used its own config files and didn't > pick up the system settings they chose in the control panel. No offense, but... where the hell are you getting this stuff from? I haven't said *anythign* about system settings, and even if I did, "integrated" rather means it *would* use them. > > What could have changed something is the app be properly packaged in > Fedora (for example) and your friends being taught to use > apt/yum/whatever. I doubt Fedora is ever going to package all useful software, and users shouldn't need to learn to open up a command line and type cryptic names of software when they are on the software's website with a fricken link to it right there. What should happen is they click on the osftware, *that* package is installed, and apt/yum is used for dependency resolution (without the user needing to type or see cryptic things like libfoo2-common-1:4.5.i386.rpm and so on.) > > > Nobody should *have* to explain it to them, it should just work the way > > they'd expect - which is click on the package, and watch it install > > (possibly grabbing dependencies, or providing a very sane/clear message > > if they cannot be found, which is another RPM problem...) > > ROTFL. > The way they expect it is you doing the install for them. > I have questions about MS office every other week even though I'm the > only person at work who *never* use it 'cos I has a linux desktop (I > have questions about office by people who use it all the day !). The I see no correlation between either of those statements... the user expects not to need to ask anyone about it, since it should just work they way they expect, not have cryptic/unobvious behaviour. > problem is not following "what the user expects". The problem is having > a working framework so people won't assume they should not bother > learning it because it's as broken as the other ones and asking their > resident guru is easier anyway. Right. A working framework is needed, not just a mass of packages that are recompiled everytime someone sneezes so they keep working on the exact snapshot version of some various random Linux OS. Fix the system so its not broken, and users won't have learn much (why the hell should they need to care about apt/yum/rpm at all?) *and* it'll work like they expect > > [...] > > > > I see you've never tried to package a large pool of inter-dependant > > > projects. In 80%+ of the cases the problem lies upstream. If the > > > packager accepts the deps upstream wants to force on him the mess will > > > only grow. Most of the upstream projects I work with would jump to the > > > possibility to embed all the deps they need because that matches their > > > vision of their app as the center of the system. > > > > Does anyone bring up these problems with the upstream in these cases, or > > just work around it? > > Both. > Strangely enough users understand readily enough what they win in a > nicely modular system, while upstream developers more often than not > strongly object to someone even suggesting they massive bundle of > straight-from-cvs binaries is not proper packaging. Totally lost by that last sentence, sorry. > > > I might also note that this is most important for user apps, not so much > > backend/server stuff; my friend Dan (very bright, but never had a > > computer until last week) isn't going to be installing Apache or a > > telephony system. ;-) A lot of backend apps half the time aren't ever > > *intended* to be packaged. > > A sysadmin likes its stuff properly packaged like anyone else. Yes, but sysadmins are expected to understand the differences between apache, libapache-modssl, libapr, and evolution. Users, on the otherhand, would know about Evolution, and probably would care at all about Apache. > > [...] > > > I'd imagine in almost all cases the embedding can be gone without. > > Then why bring it up now ? > When you find an app that you feel absolutely needs embedding then it > will be time to argue. Doing it now over an hypothetical case is > pointless. I still have absolutely no clue what you are talking about. I haven't once at all argued any specific dependencies must be embedded. I said that *if* a dependency is so broken it can't be sanely coinstalled, at all, then it needs to be embedded, versus the current practice of only letting the user have one version installed at a time (and thus forcing them to use either package set A or B). That's it. That's all I said, ever, about the embedding topic. You're going on and on about something nobody's even arguing against you about. *applause* > > I'm sure someone on the list will always find a way to avoid embedding s > > > > releases. Sacrificing the system sanity to the golden cow of eternal > > > upgradeability however will only produce a Windows-like mess were > > > everything "sort-of" works for everyone. You have to do some spring > > > cleanups, even in real life. > > > > This, of course, is the purpose of deprecation. We have GNOME2 and > > GNOME1 libs in RH9, but as soon as all apps move off of GNOME1/GTK1, > > those can be removed. Apps that, 5 years later, still rely on 5 year > > old incompatible libraries, probably need to be removed or replaced. Or > > at least patched to work on new systems, if they're somehow > > super-mandatory. (which would be an ugly situation) > > Just freeze the repository at release time and have all new packages go > into an unstable branch (or at least require them to go into unstable > before hitting stable). If something didn't get packaged in unstable by > the time it's time for another release - drop it. > > The announced release frequency is high enough people can wait for the > next release for new stuff. This is about as dumb as it can get. I have to upgrade an entire fricken OS for maybe one piece of software I want? *bzzt* Let's try to move forward, not backward, here. > > Regards, -- Sean Middleditch AwesomePlay Productions, Inc. From Nicolas.Mailhot at laPoste.net Sun Oct 5 07:39:26 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 05 Oct 2003 09:39:26 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065315854.2226.80.camel@dhcppc3> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065311515.3129.11.camel@rousalka.dyndns.org> <1065315854.2226.80.camel@dhcppc3> Message-ID: <1065339566.25248.0.camel@rousalka.dyndns.org> Le dim 05/10/2003 ? 03:04, Havoc Pennington a ?crit : > On Sat, 2003-10-04 at 19:51, Nicolas Mailhot wrote: > > Actually the smart thing would be to distribute apt/yum/up2date profiles > > that match an usage, and let them the package manager download the parts > > that are not installed yet and all second, third, fourth... -level > > dependencies. > > That's the comps file approach redhat-config-packages uses now, > essentially. Just need to have an idea of a comps file as a standalone > thing with a MIME handler perhaps. Sure. I realised after posting that was exactly what anaconda already did at installation time;) -- 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 pp at ee.oulu.fi Sun Oct 5 07:44:36 2003 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Sun, 5 Oct 2003 10:44:36 +0300 Subject: New README file for cipe In-Reply-To: <200310042300.55855.jgardner@jonathangardner.net> References: <200310042300.55855.jgardner@jonathangardner.net> Message-ID: <20031005074435.GA28693@ee.oulu.fi> On Sat, Oct 04, 2003 at 11:00:54PM -0700, Jonathan Gardner wrote: > 4) Finally, I created a key in /etc/cipe/options.cipcb0 on both machines. It > reads: > > key [md5sum] > > where md5sum is the result of running: > > $ ps -aux | md5sum > > (note that I only included the 128 digit hexadecimal number - not the '-' > part.) Argh! I filed a bug about this way of generating keys in redhat-config-securitylevel, obviously the source was CIPE docs :-) Please recommend something like: [root at connecting root]# dd if=/dev/random bs=1 count=16 | xxd -ps 16+0 records in 16+0 records out 9a1639e5fd8674eed2b6ab31aa62fcc1 so you don't have to worry about the amount entropy of ps aux has. I would argue that it's less than 128 bits, especially if generate the key on a fresh system just after rebooting. Too risky when talking about crypto keys in any case :-) -- Pekka Pietikainen From pp at ee.oulu.fi Sun Oct 5 07:49:51 2003 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Sun, 5 Oct 2003 10:49:51 +0300 Subject: New README file for cipe In-Reply-To: <20031005074435.GA28693@ee.oulu.fi> References: <200310042300.55855.jgardner@jonathangardner.net> <20031005074435.GA28693@ee.oulu.fi> Message-ID: <20031005074951.GB28693@ee.oulu.fi> On Sun, Oct 05, 2003 at 10:44:36AM +0300, Pekka Pietikainen wrote: > Argh! I filed a bug about this way of generating keys in > redhat-config-securitylevel, obviously the source was CIPE docs :-) redhat-config-network too :-) -- Pekka Pietikainen From Nicolas.Mailhot at laPoste.net Sun Oct 5 08:23:51 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 05 Oct 2003 10:23:51 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065334125.4986.13.camel@stargrazer.home.awesomeplay.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> <1065257706.6399.37.camel@rousalka.dyndns.org> <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> <1065287740.4868.94.camel@rousalka.dyndns.org> <1065334125.4986.13.camel@stargrazer.home.awesomeplay.com> Message-ID: <1065342230.25248.44.camel@rousalka.dyndns.org> Le dim 05/10/2003 ? 08:08, Sean Middleditch a ?crit : > On Sat, 2003-10-04 at 13:15, Nicolas Mailhot wrote: > > Le sam 04/10/2003 ? 18:23, Sean Middleditch a ?crit : > > > > This is complete nonsense. I've two friends just the last couple weeks > > > that have RH9, one I installed for him (since I helped build his > > > machine) and the other installed by the friend after I gave him CDs. > > > Neither of them understand jack about the packaging, and I've already > > > had to make tons of excusses for the insanity of it (along with other > > > Linux stupidities, which are another topic entirely). Getting calls at > > > 10pm because they can't figure out how to get OpenRPG installed (or > > > whatever) is irritating. > > > > So would have standalone apps changed anything ? No. They'd have called > > you because your integrated app used its own config files and didn't > > pick up the system settings they chose in the control panel. > > No offense, but... where the hell are you getting this stuff from? I > haven't said *anythign* about system settings, and even if I did, > "integrated" rather means it *would* use them. I'm taking this from the last integrated solutions we've got : mozilla with its own xft stack, jvms we have to package and so on. The fact is when you start defending against system libraries conflicts by shipping your own "tested working" private versions you also ship your own versions of the configuration files they use because even though you might be able to read the system versions of those files at first you know there's a big risk once the system updates its own backend their format may change and your private libraries will no longer grok them. In my experience the kind of defensive packaging where all deps are bundled with the app always leads to configuration files duplication for this reason, with the direct result of the user having to do the same operation twice or more on the system because the standalone components won't talk to each other ot to the system. > > What could have changed something is the app be properly packaged in > > Fedora (for example) and your friends being taught to use > > apt/yum/whatever. > > I doubt Fedora is ever going to package all useful software, They won't have to. Unlike old RedHat this is a community project now and people can submit packages here that work with the same repository instead of the semi-working stuff projects used to propose alongside their tar downloads. It only needs to reach critical mass so enough stuff is packaged users can ignore unpackaged stuff (or shame upstream projects into packaging their own mess). At this point I doubt many useful software will be left packageless. > and users > shouldn't need to learn to open up a command line There are beautiful clickey frontends you know. > and type cryptic names > of software when they are on the software's website with a fricken link > to it right there. Co's they didn't have to type cryptic names in their navigation bar to get thier software right ? And the fricken link system you find on sites like sf (to name it) are not fricken more annoying than an apt system that does everything in the background ? The answer to your problem is something like the profile I've discussed with Havoc, not some sort of standalone monstruosity (which will inevitably be installed userside and not be shared among the system users since unix rights are something else you won't want to teach your ex-ms users) > What should happen is they click on the osftware, *that* package is > installed, and apt/yum is used for dependency resolution (without the > user needing to type or see cryptic things like > libfoo2-common-1:4.5.i386.rpm and so on.) And here we agree at last. But take it any further and you'll see there no need to have them download the core package at all either since it can be apted like the rest. [...] > > problem is not following "what the user expects". The problem is having > > a working framework so people won't assume they should not bother > > learning it because it's as broken as the other ones and asking their > > resident guru is easier anyway. > > Right. A working framework is needed, not just a mass of packages that > are recompiled everytime someone sneezes so they keep working on the > exact snapshot version of some various random Linux OS. Here you introduce your own technical bias again. The user won't care if its rebuild every hour at long at it works. > Fix the system so its not broken, and users won't have learn much (why > the hell should they need to care about apt/yum/rpm at all?) Why the hell should they need to care about your installshield-like setup ? It's not even as if it were working as well as apt/yum/rpm. [...] > > > > I see you've never tried to package a large pool of inter-dependant > > > > projects. In 80%+ of the cases the problem lies upstream. If the > > > > packager accepts the deps upstream wants to force on him the mess will > > > > only grow. Most of the upstream projects I work with would jump to the > > > > possibility to embed all the deps they need because that matches their > > > > vision of their app as the center of the system. > > > > > > Does anyone bring up these problems with the upstream in these cases, or > > > just work around it? > > > > Both. > > Strangely enough users understand readily enough what they win in a > > nicely modular system, while upstream developers more often than not > > strongly object to someone even suggesting they massive bundle of > > straight-from-cvs binaries is not proper packaging. > > Totally lost by that last sentence, sorry. Ie most of the times upstream are outraged we do not want to use the binary bundle they've assembled from their own code and binary dependencies they lovingly extracted from their own cvs. It works for them why should it not work for us ? Don't we trust the binaries they put into their cvs after applying who knows how many hastily hacked patches, changing the file names so they're sure no one will know where to download the dependencies original sources ? (short answer - we don't). Don't we know that if they use two-year old versions of those very same binaries that's because we should ? (not because they lacked the manpower to follow the projects they depend on) > > > > > I might also note that this is most important for user apps, not so much > > > backend/server stuff; my friend Dan (very bright, but never had a > > > computer until last week) isn't going to be installing Apache or a > > > telephony system. ;-) A lot of backend apps half the time aren't ever > > > *intended* to be packaged. > > > > A sysadmin likes its stuff properly packaged like anyone else. > > Yes, but sysadmins are expected to understand the differences between > apache, libapache-modssl, libapr, and evolution. Users, on the > otherhand, would know about Evolution, and probably would care at all > about Apache. Sysadmins can be asked to put systems on line in at a very short notice. They'd rather spend what little time they have to tune the system than following a ten-ages long manual procedure (which doesn't help much at crash-time anyway) > > > > [...] > > > > > I'd imagine in almost all cases the embedding can be gone without. > > > > Then why bring it up now ? > > When you find an app that you feel absolutely needs embedding then it > > will be time to argue. Doing it now over an hypothetical case is > > pointless. > > I still have absolutely no clue what you are talking about. I haven't > once at all argued any specific dependencies must be embedded. I said > that *if* a dependency is so broken it can't be sanely coinstalled, at > all, then it needs to be embedded, versus the current practice of only > letting the user have one version installed at a time (and thus forcing > them to use either package set A or B). That's it. That's all I said, > ever, about the embedding topic. You're going on and on about something > nobody's even arguing against you about. *applause* But what you argue for is already current practice (see how the xft port of mozilla was done). And it should be limited, not extended because it has real costs for the end-user. > > I'm sure someone on the list will always find a way to avoid embedding s > > > > > > releases. Sacrificing the system sanity to the golden cow of eternal > > > > upgradeability however will only produce a Windows-like mess were > > > > everything "sort-of" works for everyone. You have to do some spring > > > > cleanups, even in real life. > > > > > > This, of course, is the purpose of deprecation. We have GNOME2 and > > > GNOME1 libs in RH9, but as soon as all apps move off of GNOME1/GTK1, > > > those can be removed. Apps that, 5 years later, still rely on 5 year > > > old incompatible libraries, probably need to be removed or replaced. Or > > > at least patched to work on new systems, if they're somehow > > > super-mandatory. (which would be an ugly situation) > > > > Just freeze the repository at release time and have all new packages go > > into an unstable branch (or at least require them to go into unstable > > before hitting stable). If something didn't get packaged in unstable by > > the time it's time for another release - drop it. > > > > The announced release frequency is high enough people can wait for the > > next release for new stuff. > > This is about as dumb as it can get. I have to upgrade an entire > fricken OS for maybe one piece of software I want? *bzzt* Let's try to > move forward, not backward, here. Really, I don't see why you oppose a clean upgrade every few months when your solution would result in massive code duplication. In my scenario at least the on-disk system size wouldn't grow exponentially over time. 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 buildsys at porkchop.devel.redhat.com Sun Oct 5 09:34:35 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sun, 5 Oct 2003 05:34:35 -0400 Subject: rawhide report: 20031005 changes Message-ID: <200310050934.h959YZu06703@porkchop.devel.redhat.com> Updated Packages: kernel-2.4.22-1.2087.nptl ------------------------- rawhide-release-20031005-1 -------------------------- From jaap_haitsma at zonnet.nl Sun Oct 5 10:48:45 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Sun, 05 Oct 2003 12:48:45 +0200 Subject: Suggestion for gnome-terminal Message-ID: <3F7FF70D.40204@zonnet.nl> After installation of Fedora gnome-terminal does not recognize aliases like ll and also does not display the listings in color. You can get this by going to Edit / Current Profile / Title and Command and then selecting "Run command as a login shell" I think it would be nice for users if this was enabled by default Jaap From xose at wanadoo.es Sun Oct 5 11:31:59 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sun, 05 Oct 2003 13:31:59 +0200 Subject: alpha architecture Message-ID: <3F80012F.50505@wanadoo.es> Jim wrote: > were availible for download. The problem is that they don't work on the > 7.2 release and rpm -Uvh for the packages I need give me countless failed > deps as I expected they would. Will there be an upcomming alpha iso > release for the latest redhat version? If not, I would like to port > an updated rh release for the alpha architecture. If any one is doing > this already or if anybody needs help doing this I'd be pleased to help > out. If someone is already doing this could you please point me in the > right direction? Updates for Red Hat 7.2 Alpha are at ftp://ftp2.compaq.com/pub/linux/RedHat/7.2-alpha/ more info -> http://www.alphalinux.org -- :x From aoliva at redhat.com Sun Oct 5 12:31:32 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 05 Oct 2003 09:31:32 -0300 Subject: Suggestion for gnome-terminal In-Reply-To: <3F7FF70D.40204@zonnet.nl> References: <3F7FF70D.40204@zonnet.nl> Message-ID: On Oct 5, 2003, "Jaap A. Haitsma" wrote: > After installation of Fedora gnome-terminal does not recognize aliases > like ll and also does not display the listings in color. > You can get this by going to Edit / Current Profile / Title and Command > and then selecting "Run command as a login shell" Err... WORKSFORME. Did you change your .bash_profile or .bashrc? -- 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 jaap_haitsma at zonnet.nl Sun Oct 5 12:44:49 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Sun, 05 Oct 2003 14:44:49 +0200 Subject: Suggestion for gnome-terminal In-Reply-To: References: <3F7FF70D.40204@zonnet.nl> Message-ID: <3F801241.5030404@zonnet.nl> Alexandre Oliva wrote: > On Oct 5, 2003, "Jaap A. Haitsma" wrote: > > >>After installation of Fedora gnome-terminal does not recognize aliases >>like ll and also does not display the listings in color. > > >>You can get this by going to Edit / Current Profile / Title and Command >>and then selecting "Run command as a login shell" > > > Err... WORKSFORME. Did you change your .bash_profile or .bashrc? > Nope, didn't change them From nhruby at uga.edu Sun Oct 5 13:48:08 2003 From: nhruby at uga.edu (nathan r. hruby) Date: Sun, 5 Oct 2003 09:48:08 -0400 (EDT) Subject: Suggestion for gnome-terminal In-Reply-To: <3F7FF70D.40204@zonnet.nl> References: <3F7FF70D.40204@zonnet.nl> Message-ID: On Sun, 5 Oct 2003, Jaap A. Haitsma wrote: > After installation of Fedora gnome-terminal does not recognize aliases > like ll and also does not display the listings in color. > > You can get this by going to Edit / Current Profile / Title and Command > and then selecting "Run command as a login shell" > > I think it would be nice for users if this was enabled by default > Or, you can synlink .bash_profile to .bashrc, perf. in /etc/skel. -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From thomas at apestaart.org Sun Oct 5 14:02:42 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 05 Oct 2003 16:02:42 +0200 Subject: automated build tool for an src.rpm tree ? In-Reply-To: <200309301830.12753.rezso@rdsor.ro> References: <200309301830.12753.rezso@rdsor.ro> Message-ID: <1065362562.4157.22.camel@ana.onshuis> Yep, that's what I wrote mach for. http://thomas.apestaart.org/projects/mach/ I've added some bug fixes and support for Fedora Core 0.94 in cvs, will release as soon as Matthias Saou tested his bug fixes and gives me config info for rh70-rh72 :) Thomas On Wed, 2003-10-01 at 00:30, Balint Cristian wrote: > Hi ! > > Have someone developed a tool or have knowledge of some perl/python scripted stuff for > automated build of a src.rpm tree wich inteligently compute dependency and start compiling/installing > packages step by step in right order till whole tree is compiled and installed. > > PS: dont need to knoledge even some bug hunting skill :))) > > Thanks a lot, > > > Cristian Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> I could do so much harm I could do you no good I'll leave a stain in your heart I would <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From elanthis at awesomeplay.com Sun Oct 5 15:15:43 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 05 Oct 2003 11:15:43 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065342230.25248.44.camel@rousalka.dyndns.org> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> <1065257706.6399.37.camel@rousalka.dyndns.org> <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> <1065287740.4868.94.camel@rousalka.dyndns.org> <1065334125.4986.13.camel@stargrazer.home.awesomeplay.com> <1065342230.25248.44.camel@rousalka.dyndns.org> Message-ID: <1065366943.4953.12.camel@stargrazer.home.awesomeplay.com> On Sun, 2003-10-05 at 04:23, Nicolas Mailhot wrote: > Le dim 05/10/2003 ? 08:08, Sean Middleditch a ?crit : > > I still have absolutely no clue what you are talking about. I haven't > > once at all argued any specific dependencies must be embedded. I said > > that *if* a dependency is so broken it can't be sanely coinstalled, at > > all, then it needs to be embedded, versus the current practice of only > > letting the user have one version installed at a time (and thus forcing > > them to use either package set A or B). That's it. That's all I said, > > ever, about the embedding topic. You're going on and on about something > > nobody's even arguing against you about. *applause* > > But what you argue for is already current practice (see how the xft port > of mozilla was done). And it should be limited, not extended because it > has real costs for the end-user. I'm not even sure you know what I'm arguing for. Why are you going on and on about code duplication when that was one teensy little minor point I made just for *very* rare cases where there is *no* other solution? Seriously, *what* are you going on about that I'm disagreeing with? > > > > I'm sure someone on the list will always find a way to avoid embedding s > > > > > > > > releases. Sacrificing the system sanity to the golden cow of eternal > > > > > upgradeability however will only produce a Windows-like mess were > > > > > everything "sort-of" works for everyone. You have to do some spring > > > > > cleanups, even in real life. > > > > > > > > This, of course, is the purpose of deprecation. We have GNOME2 and > > > > GNOME1 libs in RH9, but as soon as all apps move off of GNOME1/GTK1, > > > > those can be removed. Apps that, 5 years later, still rely on 5 year > > > > old incompatible libraries, probably need to be removed or replaced. Or > > > > at least patched to work on new systems, if they're somehow > > > > super-mandatory. (which would be an ugly situation) > > > > > > Just freeze the repository at release time and have all new packages go > > > into an unstable branch (or at least require them to go into unstable > > > before hitting stable). If something didn't get packaged in unstable by > > > the time it's time for another release - drop it. > > > > > > The announced release frequency is high enough people can wait for the > > > next release for new stuff. > > > > This is about as dumb as it can get. I have to upgrade an entire > > fricken OS for maybe one piece of software I want? *bzzt* Let's try to > > move forward, not backward, here. > > Really, I don't see why you oppose a clean upgrade every few months when > your solution would result in massive code duplication. In my scenario > at least the on-disk system size wouldn't grow exponentially over time. Because when people want software, they want it *now*. If you tell them, "well, you have to wait two months to install that software, even tho the software it already out now" then they're going to (rightly) switch to an OS that doesn't suffer from a complete lack of backward or forward compatibility. And, again, the above has *ABSOLUTELY* nothing to do with with embedded dependencies. Just good packaging habits. Disk size only grows if the user *needs* multiple versions of something. Good packaging would *avoid* that as much as possible. Take a look at Debian - they quite often a have a couple versions of certain components *available*, altho they usually aren't ever *installed*. If the user needed, say, and older version of Python for a piece of software, it's usually there for them. But, most of the time, the user doesn't actually need it. So long as the dependency is available, then both older and newer software can be installed. The dependencies are *only* needed when app *actually* uses them. And even if you install version 1.2 of an app that needs dependency foo 1.0, you're still completely allowed to make a release of the app 1.2-1 that uses the more up-to-date foo 1.02. Users aren't forced to update their app, but those that do don't have to deal with the "legacy" dependency. Users of an OS release that only had foo 1.0, upon install of the new 1.2-1 version of the app, would have foo 1.02 pulled in as the dependency. > > Regards, -- Sean Middleditch AwesomePlay Productions, Inc. From Nicolas.Mailhot at laPoste.net Sun Oct 5 15:33:19 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 05 Oct 2003 17:33:19 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065366943.4953.12.camel@stargrazer.home.awesomeplay.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> <1065257706.6399.37.camel@rousalka.dyndns.org> <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> <1065287740.4868.94.camel@rousalka.dyndns.org> <1065334125.4986.13.camel@stargrazer.home.awesomeplay.com> <1065342230.25248.44.camel@rousalka.dyndns.org> <1065366943.4953.12.camel@stargrazer.home.awesomeplay.com> Message-ID: <1065367999.3608.4.camel@rousalka.dyndns.org> Le dim 05/10/2003 ? 17:15, Sean Middleditch a ?crit : > Because when people want software, they want it *now*. If you tell > them, "well, you have to wait two months to install that software, even > tho the software it already out now" then they're going to (rightly) > switch to an OS that doesn't suffer from a complete lack of backward or > forward compatibility. I can assure you the time between a release being dogfoodable and it hitting the end-users disks is much more than two months for those other OSs. Two months is quite acceptable for a beta period. In fact it's quite fast - why do you thing Oracle and friends were screaming at RedHat for a slower release cycle ? 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 xose at wanadoo.es Sun Oct 5 15:42:55 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sun, 05 Oct 2003 17:42:55 +0200 Subject: [Univ-linux] Future unsupported Red Hat Linux systems References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> Message-ID: <3F803BFF.9080700@wanadoo.es> seth vidal wrote: > Where would you like things to move? > > make use of the infrastructure that is being worked on for fedora extras > to help packages to use for fedora legacy. > > I think the plan is to continue working on those systems and for anyone > who has the need and ability to work on errata as needed. There is a lot of people out there waiting for an answer. Should I change to other distribution, buy Enterprise edition or waiting for a miracle ? People wants to take a decission now, or next month like late. And still there is not an 'official' unofficial announce about the project ;-) Three months and counting down... I would like to see a clearer .plan, dates, people involved, central mailing-list.... -thanks- -- :x From elanthis at awesomeplay.com Sun Oct 5 15:44:06 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 05 Oct 2003 11:44:06 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065367999.3608.4.camel@rousalka.dyndns.org> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <1065027607.2675.21.camel@denk.nakedape.priv> <1065028989.1002.28.camel@support02.civic.twp.ypsilanti.mi.us> <20031001211647.57bce429.ms-nospam-0306@arcor.de> <1065036872.1002.46.camel@support02.civic.twp.ypsilanti.mi.us> <20031001234612.14a8a54c.ms-nospam-0306@arcor.de> <1065061488.7065.41.camel@stargrazer.home.awesomeplay.com> <20031002231526.1b5e1af2.ms-nospam-0306@arcor.de> <1065145763.18024.18.camel@stargrazer.home.awesomeplay.com> <20031003154157.75e46420.ms-nospam-0306@arcor.de> <1065190305.13005.19.camel@support02.civic.twp.ypsilanti.mi.us> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> <1065257706.6399.37.camel@rousalka.dyndns.org> <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> <1065287740.4868.94.camel@rousalka.dyndns.org> <1065334125.4986.13.camel@stargrazer.home.awesomeplay.com> <1065342230.25248.44.camel@rousalka.dyndns.org> <1065366943.4953.12.camel@stargrazer.home.awesomeplay.com> <1065367999.3608.4.camel@rousalka.dyndns.org> Message-ID: <1065368646.4953.20.camel@stargrazer.home.awesomeplay.com> On Sun, 2003-10-05 at 11:33, Nicolas Mailhot wrote: > Le dim 05/10/2003 ? 17:15, Sean Middleditch a ?crit : > > > Because when people want software, they want it *now*. If you tell > > them, "well, you have to wait two months to install that software, even > > tho the software it already out now" then they're going to (rightly) > > switch to an OS that doesn't suffer from a complete lack of backward or > > forward compatibility. > > I can assure you the time between a release being dogfoodable and it > hitting the end-users disks is much more than two months for those other > OSs. But they never have to wait to install new software, and older software just works. Even if behind the scenes its ugly as hell, which definitely sucks for developers, the users don't really care. ;-) > > Two months is quite acceptable for a beta period. In fact it's quite > fast - why do you thing Oracle and friends were screaming at RedHat for > a slower release cycle ? Yes, that's great if we're talking an OS release. I'm not, tho - I'm talking uers who want to install some piece of software right now, and don't want to be told they have to wait 2 months for a new version of their OS to come out; not when "other" OSs can run apps from 10 years ago, and even the newest apps coming out still run on at least several releases back, which covers a decent number of years (so far as computers go). Fedora doesn't have to slow down releases, nor does it have to stop being cutting edge - it just has to make sure necessary dependencies are *available* (not necessarily installed, if the user doesn't need them) to cover at least a somewhat acceptable number of years of backwards compatibility. There's also the commercial software people try to release, which can't make use of the "crap, a month went by and a new OS is out, we need to recompile!" and offer 67 RPMs slightly-different on their install CD for users. The way things are now, that software *does* ship all of their dependencies embedded, *even when they shouldn't*, because the OSs don't provide them; plus the software almost always uses shell scripts and other hacks that no user should *ever* need to use just to install something. But, they don't have much choice, at the moment. > > Regards, -- Sean Middleditch AwesomePlay Productions, Inc. From benny+nospam at amorsen.dk Sun Oct 5 15:55:57 2003 From: benny+nospam at amorsen.dk (Benny Amorsen) Date: Sun, 05 Oct 2003 17:55:57 +0200 Subject: New README file for cipe In-Reply-To: <20031005074435.GA28693@ee.oulu.fi> References: <200310042300.55855.jgardner@jonathangardner.net> <20031005074435.GA28693@ee.oulu.fi> Message-ID: <1065369356.3531.3.camel@vega.amorsen.dk> On 2003-10-05 at 09:44, Pekka Pietikainen wrote: > Please recommend something like: > > [root at connecting root]# dd if=/dev/random bs=1 count=16 | xxd -ps > 16+0 records in > 16+0 records out > 9a1639e5fd8674eed2b6ab31aa62fcc1 > > so you don't have to worry about the amount entropy of ps aux > has. I would argue that it's less than 128 bits, especially > if generate the key on a fresh system just after rebooting. > Too risky when talking about crypto keys in any case :-) The quality of the key used for CIPE is probably unimportant. CIPE has significant other weaknesses: http://www.mit.edu:8008/bloom-picayune/crypto/14238 Personally I think CIPE should just be removed from Fedora. IPSEC is ready, it is just a matter of integrating the tools. And IPSEC has a chance of being reasonably secure. (I actually use CIPE in production since it is so hard to deal with IPSEC when the distribution lacks the necessarily tools. I only send encrypted data over CIPE though, so I feel reasonably safe. I look forward to migrating to IPSEC.) /Benny From hp at redhat.com Sun Oct 5 16:08:50 2003 From: hp at redhat.com (Havoc Pennington) Date: 05 Oct 2003 12:08:50 -0400 Subject: Suggestion for gnome-terminal In-Reply-To: <3F7FF70D.40204@zonnet.nl> References: <3F7FF70D.40204@zonnet.nl> Message-ID: <1065370129.2226.108.camel@dhcppc3> On Sun, 2003-10-05 at 06:48, Jaap A. Haitsma wrote: > After installation of Fedora gnome-terminal does not recognize aliases > like ll and also does not display the listings in color. > > You can get this by going to Edit / Current Profile / Title and Command > and then selecting "Run command as a login shell" > > I think it would be nice for users if this was enabled by default > Your entire X session should be a child of a login shell (that is, .bash_profile should be run by gdm when you first log in). It's only one login session for the whole X session, not one per terminal opened. If your whole session isn't a login session then there's some other problem, but not a gnome-terminal problem. Havoc From skvidal at phy.duke.edu Sun Oct 5 16:19:36 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Oct 2003 12:19:36 -0400 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <3F803BFF.9080700@wanadoo.es> References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> Message-ID: <1065370776.14230.61.camel@binkley> > There is a lot of people out there waiting for an answer. > Should I change to other distribution, buy Enterprise edition or > waiting for a miracle ? > > People wants to take a decission now, or next month like late. > And still there is not an 'official' unofficial announce about the project ;-) > Three months and counting down... People want a lot of things, they don't always get them. Right now I think that way you can help is not by demanding action and dates and names but by figuring out what packages you think you'll need errata for the most and maybe familiarizing yourself with how they are currently patched by red hat. If you want dates and plans then how about this: Dates: when errata is needed. Plans: use the current fedora.us infrastructure to upload packages and get them QA'd until the fedora extras infrastructure and build systems are implemented. -sv From xose at wanadoo.es Sun Oct 5 17:27:31 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sun, 05 Oct 2003 19:27:31 +0200 Subject: [Univ-linux] Future unsupported Red Hat Linux systems References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> <1065370776.14230.61.camel@binkley> Message-ID: <3F805483.5090404@wanadoo.es> seth vidal wrote: > People want a lot of things, they don't always get them. Right now I > think that way you can help is not by demanding action and dates and > names but by figuring out what packages you think you'll need errata for > the most and maybe familiarizing yourself with how they are currently > patched by red hat. You are getting me wrong, I am not *demanding*. I am trying to get information to separate real projects from smoke ;-) If I get free time I will help, sure. -- :x From jason at geshp.com Sun Oct 5 18:01:22 2003 From: jason at geshp.com (Jason Luka) Date: Sun, 05 Oct 2003 13:01:22 -0500 Subject: Bootsplash Patch Message-ID: <3F805C72.6020509@geshp.com> I've built the bootsplash patch for 2.4.22, however it won't let me send it through email because of a 40k limit on messages. Anybody know the proper channels to send this through? From ms-nospam-0306 at arcor.de Sun Oct 5 18:06:07 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 5 Oct 2003 20:06:07 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065368646.4953.20.camel@stargrazer.home.awesomeplay.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> <1065257706.6399.37.camel@rousalka.dyndns.org> <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> <1065287740.4868.94.camel@rousalka.dyndns.org> <1065334125.4986.13.camel@stargrazer.home.awesomeplay.com> <1065342230.25248.44.camel@rousalka.dyndns.org> <1065366943.4953.12.camel@stargrazer.home.awesomeplay.com> <1065367999.3608.4.camel@rousalka.dyndns.org> <1065368646.4953.20.camel@stargrazer.home.awesomeplay.com> Message-ID: <20031005200607.63b3b39e.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 05 Oct 2003 11:44:06 -0400, Sean Middleditch wrote: > I'm > talking uers who want to install some piece of software right now, and > don't want to be told they have to wait 2 months for a new version of > their OS to come out; not when "other" OSs can run apps from 10 years > ago, and even the newest apps coming out still run on at least several > releases back, which covers a decent number of years (so far as > computers go). There's one of those "other" OSs, where a friend points me to a versatile media player I should check out. The only download option is an .EXE file, several MiB big. Great. That should be easy. But wait, it unpacks files into a temporary directory, then refuses to proceed and tells me I need a newer version of DirectX. No idea where to get that. I search the web and download the latest version which is even newer than what is required. I fail to find a place where to get exactly the version that is required. Hopefully it doesn't matter. The installer seems to be happy about the new version. Then I'm told I need an update to DCOM and a couple of similar packages. Somehow I manage to find and install all this stuff. The application's installer finishes. But the application doesn't work completely. The developers tell me some of my system software is too new and not yet supported. Something would be special about my system, but they don't know what. I should get the latest version of the OS where the necessary stuff is preinstalled. Or I could also install the previous version where they've tested the application, too. I then notice that some of the updates overwrote important system files, and now other applications don't work anymore. When asked, my friend admits he has had a few problems, too. But he thought the problems would be due to his own mistakes, and everywhere else it would work flawlessly. Thanks god I have a backup of my installation. Before restoring my system, I take the chance to try a commercial application which I have been given on CD for evaluation. It says explicitly it supports my version of the OS. Its installer is smarter. Afterall, it's a commercial application. It offers to download missing components from the Internet. Unfortunately, after asking me half a dozen times on whether I would let it overwrite mysterious .DLL system files, it refuses to proceed. It wants a specific version of DirectX, an older version than what I've updated to. I get the chance to downgrade to a version on the CD, although I don't have the slightest idea whether that might affect any other applications, such as the partially working media player which is still installed. At the end of the installation, most parts of my system are still working, the application disables one feature due to insufficient system features. So far so good, but a few parts of my OS now are in English and no longer in German. I ask a person who considers himself an expert on that operating system. He shakes his head and says I should reinstall from scratch or from backup. It could take hours to fix the mess manually. I should try custom installation. Once I would have figured out how to complete a working installation, everything would be fine. He tells me about a message board where I should ask for help prior to installing from scratch. The people in that forum try to help. Half of them ask questions which seem to address a completely different OS. Some try to analyze my system with detailed questions on what options I see in the menus and what tools are installed. Then they excuse for not being helpful and write that they run the latest version of the OS where things are different. The other half blame me for not having a backup. I didn't tell them I do have backups. I just mentioned I would not want to reinstall. Seems that's the only option. One wizard steps up in private mail, accusing the other board members of not knowing their stuff. He/she suggests I should uninstall the application and let it revert its changes. Sounds good. Unfortunately, the uninstaller doesn't do the job automatically. Instead -- as if it doesn't know better -- it asks me on whether to keep or erase each of maybe 50 modified system files. Guess what I did. I reinstalled from backup. Seems to be widespread and common practise. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gF2P0iMVcrivHFQRAorXAJ9q7oBYHUpQOmzGJUvKOuj6H3+cdQCfROOt 2ksyL+xucWY+JgeYjWl4Ktc= =Vxox -----END PGP SIGNATURE----- From hosting at j2solutions.net Sun Oct 5 18:13:45 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Sun, 5 Oct 2003 11:13:45 -0700 Subject: Future unsupported Red Hat Linux systems In-Reply-To: <3F7F8966.6020807@wanadoo.es> References: <3F7F8966.6020807@wanadoo.es> Message-ID: <200310042046.47877.hosting@j2solutions.net> On Saturday 04 October 2003 20:00, Xose Vazquez Perez uttered: > I know three[*] projects to provided support for future unsupported > Red Hat Linux systems. But I don't see too much movement. > > Is there any current .plan? Univ-Linux might join forces w/ Fedora Legacy if we can get Legacy worked out. I"m somewhat of the community spokes person for Legacy, nobody else was doing anything with it so I stepped up. I'm waiting to see what all Red Hat will let me do with Legacy, since they've coined the phrase so to speak. I'm hoping to have some answers by the end of next week. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (www.mondorescue.org) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From elanthis at awesomeplay.com Sun Oct 5 18:23:56 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 05 Oct 2003 14:23:56 -0400 Subject: Kind request: fix your packages In-Reply-To: <20031005200607.63b3b39e.ms-nospam-0306@arcor.de> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031003173621.4b2d0fcd.ms-nospam-0306@arcor.de> <1065197075.13005.42.camel@support02.civic.twp.ypsilanti.mi.us> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> <1065257706.6399.37.camel@rousalka.dyndns.org> <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> <1065287740.4868.94.camel@rousalka.dyndns.org> <1065334125.4986.13.camel@stargrazer.home.awesomeplay.com> <1065342230.25248.44.camel@rousalka.dyndns.org> <1065366943.4953.12.camel@stargrazer.home.awesomeplay.com> <1065367999.3608.4.camel@rousalka.dyndns.org> <1065368646.4953.20.camel@stargrazer.home.awesomeplay.com> <20031005200607.63b3b39e.ms-nospam-0306@arcor.de> Message-ID: <1065378236.4953.37.camel@stargrazer.home.awesomeplay.com> On Sun, 2003-10-05 at 14:06, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, 05 Oct 2003 11:44:06 -0400, Sean Middleditch wrote: > > > I'm > > talking uers who want to install some piece of software right now, and > > don't want to be told they have to wait 2 months for a new version of > > their OS to come out; not when "other" OSs can run apps from 10 years > > ago, and even the newest apps coming out still run on at least several > > releases back, which covers a decent number of years (so far as > > computers go). [long story about one package for "some OS"] Yes, that's what we'd also call Bad Packaging(tm). ;-) That is the *exception*, not the *rule*, on that OS. There are always exceptions, just like I expect there to be in Linux packaging for the rest of its existence. The common case doesn't have to suffer (and actually doesn't, depending on OS) because of those rarities, however. ^,^ > - -- > Michael, who doesn't reply to top posts and complete quotes anymore. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQE/gF2P0iMVcrivHFQRAorXAJ9q7oBYHUpQOmzGJUvKOuj6H3+cdQCfROOt > 2ksyL+xucWY+JgeYjWl4Ktc= > =Vxox > -----END PGP SIGNATURE----- > > > -- > 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 laroche at redhat.com Sun Oct 5 18:23:35 2003 From: laroche at redhat.com (Florian La Roche) Date: Sun, 5 Oct 2003 20:23:35 +0200 Subject: Bootsplash Patch In-Reply-To: <3F805C72.6020509@geshp.com> References: <3F805C72.6020509@geshp.com> Message-ID: <20031005182335.GA6928@dudweiler.stuttgart.redhat.com> On Sun, Oct 05, 2003 at 01:01:22PM -0500, Jason Luka wrote: > I've built the bootsplash patch for 2.4.22, however it won't let me send > it through email because of a 40k limit on messages. Anybody know the > proper channels to send this through? Attach it into a bugzilla request? greetings, Florian La Roche From ms-nospam-0306 at arcor.de Sun Oct 5 18:53:56 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 5 Oct 2003 20:53:56 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065378236.4953.37.camel@stargrazer.home.awesomeplay.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <20031003195245.25dcd08e.ms-nospam-0306@arcor.de> <1065205722.13005.78.camel@support02.civic.twp.ypsilanti.mi.us> <20031003221116.0d590fc6.ms-nospam-0306@arcor.de> <1065213588.13005.95.camel@support02.civic.twp.ypsilanti.mi.us> <1065217416.3337.22.camel@rousalka.dyndns.org> <1065237830.32213.149.camel@stargrazer.home.awesomeplay.com> <1065257706.6399.37.camel@rousalka.dyndns.org> <1065284603.5142.44.camel@stargrazer.home.awesomeplay.com> <1065287740.4868.94.camel@rousalka.dyndns.org> <1065334125.4986.13.camel@stargrazer.home.awesomeplay.com> <1065342230.25248.44.camel@rousalka.dyndns.org> <1065366943.4953.12.camel@stargrazer.home.awesomeplay.com> <1065367999.3608.4.camel@rousalka.dyndns.org> <1065368646.4953.20.camel@stargrazer.home.awesomeplay.com> <20031005200607.63b3b39e.ms-nospam-0306@arcor.de> <1065378236.4953.37.camel@stargrazer.home.awesomeplay.com> Message-ID: <20031005205356.417dba6d.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 05 Oct 2003 14:23:56 -0400, Sean Middleditch wrote: > [long story about one package for "some OS"] Actually, it was a story about two packages and about unavailability of dependencies. > Yes, that's what we'd also call Bad Packaging(tm). ;-) That is the > *exception*, not the *rule*, on that OS. If that is your personal experience, "Consider Yourself Lucky"(tm). :-P - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gGjE0iMVcrivHFQRAslqAJ0fqGPEBLrjL9xJPLyr9x32cA2F4ACeKc08 YelT4HXAX0Sx7gP2WQQC7k8= =sPm5 -----END PGP SIGNATURE----- From jason at geshp.com Sun Oct 5 19:00:01 2003 From: jason at geshp.com (Jason Luka) Date: Sun, 05 Oct 2003 14:00:01 -0500 Subject: Bootsplash Patch In-Reply-To: <20031005182335.GA6928@dudweiler.stuttgart.redhat.com> References: <3F805C72.6020509@geshp.com> <20031005182335.GA6928@dudweiler.stuttgart.redhat.com> Message-ID: <3F806A31.6000104@geshp.com> Florian La Roche wrote: >On Sun, Oct 05, 2003 at 01:01:22PM -0500, Jason Luka wrote: > > >>I've built the bootsplash patch for 2.4.22, however it won't let me send >>it through email because of a 40k limit on messages. Anybody know the >>proper channels to send this through? >> >> > >Attach it into a bugzilla request? > >greetings, > >Florian La Roche > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > That has been done. Thanks. From ottohaliburton at comcast.net Sun Oct 5 19:06:39 2003 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Sun, 5 Oct 2003 14:06:39 -0500 Subject: Kind request: fix your packages In-Reply-To: <20031005200607.63b3b39e.ms-nospam-0306@arcor.de> Message-ID: <001701c38b73$ce84dea0$735eee0c@C515816A> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Michael Schwendt > Sent: Sunday, October 05, 2003 1:06 PM > To: fedora-devel-list at redhat.com > Subject: Re: Kind request: fix your packages > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, 05 Oct 2003 11:44:06 -0400, Sean Middleditch wrote: > > > I'm > > talking uers who want to install some piece of software right now, and > > don't want to be told they have to wait 2 months for a new version of > > their OS to come out; not when "other" OSs can run apps from 10 years > > ago, and even the newest apps coming out still run on at least several > > releases back, which covers a decent number of years (so far as > > computers go). > > There's one of those "other" OSs, where a friend points me to a > versatile media player I should check out. The only download option is > an .EXE file, several MiB big. Great. That should be easy. But wait, > it unpacks files into a temporary directory, then refuses to proceed > and tells me I need a newer version of DirectX. No idea where to get > that. I search the web and download the latest version which is even > newer than what is required. I fail to find a place where to get > exactly the version that is required. Hopefully it doesn't matter. > > The installer seems to be happy about the new version. Then I'm told I > need an update to DCOM and a couple of similar packages. Somehow I > manage to find and install all this stuff. The application's installer > finishes. But the application doesn't work completely. The developers > tell me some of my system software is too new and not yet supported. > Something would be special about my system, but they don't know what. > I should get the latest version of the OS where the necessary stuff is > preinstalled. Or I could also install the previous version where > they've tested the application, too. > > I then notice that some of the updates overwrote important system > files, and now other applications don't work anymore. When asked, my > friend admits he has had a few problems, too. But he thought the > problems would be due to his own mistakes, and everywhere else it > would work flawlessly. Thanks god I have a backup of my installation. > > Before restoring my system, I take the chance to try a commercial > application which I have been given on CD for evaluation. It says > explicitly it supports my version of the OS. Its installer is smarter. > Afterall, it's a commercial application. It offers to download missing > components from the Internet. Unfortunately, after asking me half a > dozen times on whether I would let it overwrite mysterious .DLL system > files, it refuses to proceed. It wants a specific version of DirectX, > an older version than what I've updated to. I get the chance to > downgrade to a version on the CD, although I don't have the slightest > idea whether that might affect any other applications, such as the > partially working media player which is still installed. > > At the end of the installation, most parts of my system are still > working, the application disables one feature due to insufficient > system features. So far so good, but a few parts of my OS now are in > English and no longer in German. I ask a person who considers himself > an expert on that operating system. He shakes his head and says I > should reinstall from scratch or from backup. It could take hours to > fix the mess manually. I should try custom installation. Once I would > have figured out how to complete a working installation, everything > would be fine. > > He tells me about a message board where I should ask for help prior to > installing from scratch. The people in that forum try to help. Half of > them ask questions which seem to address a completely different OS. > Some try to analyze my system with detailed questions on what options > I see in the menus and what tools are installed. Then they excuse for > not being helpful and write that they run the latest version of the OS > where things are different. The other half blame me for not having a > backup. I didn't tell them I do have backups. I just mentioned I would > not want to reinstall. Seems that's the only option. > > One wizard steps up in private mail, accusing the other board members of > not knowing their stuff. He/she suggests I should uninstall the > application and let it revert its changes. Sounds good. Unfortunately, > the uninstaller doesn't do the job automatically. Instead -- as if it > doesn't know better -- it asks me on whether to keep or erase each of > maybe 50 modified system files. Guess what I did. I reinstalled from > backup. Seems to be widespread and common practise. > > - -- > Michael, who doesn't reply to top posts and complete quotes anymore. As with all development, it sounds as though you have the same problem that should be addressed by all developers. First is as in the medical world the first thing is "Thou shall do no harm". So the developer should be aware of what his package needs and check for those things, second, if a new version of a common routine is needed, then it should broadcast that fact and proceed no further, third, if a replacement routine is added then that routine should support all previous versions or make this fact widely known. Common courtesy should always be observed no matter the OS the existing system requirements. Some of the problems with Open Source software is obvious though and the community needs to address those concerns. The main one is that the development of software comes after the product is introduced and because of that there will always be a problems. The next one is that the manufacturers will only release interface to the open source community after the proprietary period expires or there is a great demand for it. Given these facts the open source community needs to make damn sure that what it puts out software that works and will cover most situations or users will be reluctant to use it even though it is free and I think that is what has already happened. From jaap_haitsma at zonnet.nl Sun Oct 5 19:39:39 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Sun, 05 Oct 2003 21:39:39 +0200 Subject: Suggestion for gnome-terminal In-Reply-To: <1065370129.2226.108.camel@dhcppc3> References: <3F7FF70D.40204@zonnet.nl> <1065370129.2226.108.camel@dhcppc3> Message-ID: <3F80737B.2020602@zonnet.nl> > > > Your entire X session should be a child of a login shell (that is, > .bash_profile should be run by gdm when you first log in). > It's only one login session for the whole X session, not one per > terminal opened. > > If your whole session isn't a login session then there's some other > problem, but not a gnome-terminal problem. > Maybe it's due to the fact that gdm in the latest update is not working properly, and starts a failsafe session. Maybe it works with a new update. Sorry about the fuzz Jaap From davej at redhat.com Sun Oct 5 19:42:20 2003 From: davej at redhat.com (Dave Jones) Date: Sun, 5 Oct 2003 20:42:20 +0100 Subject: New README file for cipe In-Reply-To: <1065369356.3531.3.camel@vega.amorsen.dk> References: <200310042300.55855.jgardner@jonathangardner.net> <20031005074435.GA28693@ee.oulu.fi> <1065369356.3531.3.camel@vega.amorsen.dk> Message-ID: <20031005194220.GA21933@redhat.com> On Sun, Oct 05, 2003 at 05:55:57PM +0200, Benny Amorsen wrote: > Personally I think CIPE should just be removed from Fedora. IPSEC is > ready, it is just a matter of integrating the tools. And IPSEC has a > chance of being reasonably secure. AFAIK, that is the plan for FC2. FC1 will continue shipping with CIPE for the time being however. Dave -- Dave Jones http://www.codemonkey.org.uk From nhruby at uga.edu Sun Oct 5 19:53:25 2003 From: nhruby at uga.edu (nathan r. hruby) Date: Sun, 5 Oct 2003 15:53:25 -0400 (EDT) Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <1065370776.14230.61.camel@binkley> References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> <1065370776.14230.61.camel@binkley> Message-ID: On Sun, 5 Oct 2003, seth vidal wrote: > If you want dates and plans then how about this: > Dates: when errata is needed. > Plans: use the current fedora.us infrastructure to upload packages and > get them QA'd until the fedora extras infrastructure and build systems > are implemented. > This brings up a question for me as a mirror maintainer. What's the new mirror structure going to look like? Current FC1 simply lives in redhat's linux/beta/ directory and the downloads.fedora.us site has a compltely different structure, but there's a lot of duplication which I don't currently have the disk space to cover. Maybe this is still in the process of being decided upon, or maybe there's a better place to discuss this? If either, please LMK. I am (as many of you can probably attest to :) not very smart sometimes. -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From nphilipp at redhat.com Sun Oct 5 21:25:08 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Sun, 05 Oct 2003 23:25:08 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065284367.5142.38.camel@stargrazer.home.awesomeplay.com> References: <003f01c38a65$edbca8c0$735eee0c@C515816A> <1065273071.3207.67.camel@rousalka.dyndns.org> <1065284367.5142.38.camel@stargrazer.home.awesomeplay.com> Message-ID: <1065389108.11834.111.camel@wombat.tiptoe.de> On Sat, 2003-10-04 at 18:19, Sean Middleditch wrote: > On Sat, 2003-10-04 at 09:11, Nicolas Mailhot wrote: > > > Dear user, > > > > As we all know you're dumb and you can not learn to use a package > > manager ever. To ease your pain we've decided not to inflict you the > > so-called "dependency hell" and provide you an autonomous application. > > Just click on its auto-update menu and it will download everything you > > need, we swear it. > > *bzzt* It has *nothing* to do with users being "dumb." *nothing* It I think Nicolas forgot the irony tags. > has to do with the fact the user doesn't care, doesn't need to care, and > shouldn't be forced to care. I don't have a fricken clue how a jet > engine works, don't really care how it works, but that doesn't mean I'm > not allowed to fly on a plane. Indeed, the usage of an airplane is To turn around your comparison, the pilot would be the person pushing around the mouse and pushing the keys for you (and everyone would be clapping hands when the document comes out of the printer ;-). Doesn't sound right? I thought so. > completely independent of knowing how the engine works, including the > pilots. They too have their specialists ("flight mechanics") for the engines, but at least basic knowledge how they work (e.g. the kernel) and intimate knowledge about flight mechanics (e.g. how the system boots, what package dependencies are and how to deal with them). If you look at small planes, the pilots often are the flight mechanics. As I see it, the flight mechanics represent developers, the pilot represents an administrator, the passengers represent normal users. At the moment, passengers are restricted to using their seats, watching TV and going to the bathroom during flight -- with much assistance and hand-holding they could possibly emergency-land a machine if the pilots are sick or whatever, but what are the odds that they succeed? I don't say that I don't wish that users could easily do complicate tasks on a computer, aided by carefully crafted tools (auto-pilot ;-) who take care of the innards they don't want to know about. > Computers aren't any different. There is no reason a user should *have* > to understand the inner workings of it. That doesn't mean they *can't* > know it, only that they don't need to. A computer is a very complex machine and I don't see that today's tools are intelligent enough to hide all that from the user and still give them all the potential the machines have. I don't see the majority of the people having their private planes/gliders/etc. in the next years either ;-). Just some thoughts... Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- 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 elanthis at awesomeplay.com Sun Oct 5 21:55:12 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 05 Oct 2003 17:55:12 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065389108.11834.111.camel@wombat.tiptoe.de> References: <003f01c38a65$edbca8c0$735eee0c@C515816A> <1065273071.3207.67.camel@rousalka.dyndns.org> <1065284367.5142.38.camel@stargrazer.home.awesomeplay.com> <1065389108.11834.111.camel@wombat.tiptoe.de> Message-ID: <1065390912.8033.29.camel@stargrazer.home.awesomeplay.com> On Sun, 2003-10-05 at 17:25, Nils Philippsen wrote: > On Sat, 2003-10-04 at 18:19, Sean Middleditch wrote: > > has to do with the fact the user doesn't care, doesn't need to care, and > > shouldn't be forced to care. I don't have a fricken clue how a jet > > engine works, don't really care how it works, but that doesn't mean I'm > > not allowed to fly on a plane. Indeed, the usage of an airplane is > > To turn around your comparison, the pilot would be the person pushing > around the mouse and pushing the keys for you (and everyone would be > clapping hands when the document comes out of the printer ;-). Doesn't > sound right? I thought so. The absolute worst thing about analogies is that people take parts of them that don't apply to the situation, and go with them. ~,^ Use an analogy of how an angry person is like a hungry bear, and someone will think that you are saying angry people get furry and crave meat... The pilot vs. passenger distinction is irrelevant, both are airplane users. Perhaps I should've used cars as a cleaner analogy. ;-) I don't know how most of my Ford Ranger works, and I couldn't care - I just get in and drive the thing. (oh, no, wait, now someone is going to take the analogy to another extreme and start bringing in proper oil changes and driver's licenses or something - that's not what this analogy is about! misusing a computer doesn't cause deadly accidents, and lack of proper software maintenance doesn't cause the harder to rust and break. not relevant!) > > > completely independent of knowing how the engine works, including the > > pilots. > > They too have their specialists ("flight mechanics") for the engines, > but at least basic knowledge how they work (e.g. the kernel) and > intimate knowledge about flight mechanics (e.g. how the system boots, > what package dependencies are and how to deal with them). If you look at > small planes, the pilots often are the flight mechanics. Totally beyond the scope of my original analogy. My mother has a computer she uses just by herself (single pilot system), but she certainly doesn't know anything about the mechanics. Granted, she hasn't needed to know about mechanics to get her work done in the almost 20 years she's been using various definitely-not-Linux operating systems. ;-) > > As I see it, the flight mechanics represent developers, the pilot > represents an administrator, the passengers represent normal users. At > the moment, passengers are restricted to using their seats, watching TV > and going to the bathroom during flight -- with much assistance and > hand-holding they could possibly emergency-land a machine if the pilots > are sick or whatever, but what are the odds that they succeed? > > I don't say that I don't wish that users could easily do complicate > tasks on a computer, aided by carefully crafted tools (auto-pilot ;-) > who take care of the innards they don't want to know about. Eek. Double negatives, my English parser just got thrown off. :( You *do* say that you *do* wish users could do complicated tasks...? (sorry, I've always had trouble with double negatives ;-) > > > Computers aren't any different. There is no reason a user should *have* > > to understand the inner workings of it. That doesn't mean they *can't* > > know it, only that they don't need to. > > A computer is a very complex machine and I don't see that today's tools > are intelligent enough to hide all that from the user and still give > them all the potential the machines have. I don't see the majority of > the people having their private planes/gliders/etc. in the next years > either ;-). A lot of the potential a machine has, a user doesn't want. Computers can be just as flexible and complex for the users with the knowledge as our beautiful systems have today; we can still make it work efficiently (least amount of time and effort to complete a task) for users who see it as a tool for simpler tasks like writing a paper, browsing a website, playing a game, or chatting with friends/family. Not everyone is a hacker or sysadmin-wannabe. ~,^ I *definitely* don't want Fedora/Linux "dumbed down" to be easier - that's the wrong approach. It just needs to purify the stuff that's too complex for some, and needlessly cumbersome for others. I often compile software from source, have spent tons of time rebuilding RPMs and manually fixing dependencies, and develop software - that doesn't mean I enjoy having to go thru a lot of the trouble all that often requires. Simple != less flexible, and neither does complex == power. The current situation's correlation between the later doesn't imply causality in the least. ~,^ To go with a (hopefully) relevant analogy, look at GNOME2. Tons of uninformed fools whined on and on about it being "dumbed down," yet it's just as powerful as before. Whole components can be replaced if necessary (available flexibility that doesn't require other users to understand the mechanism), and its become a lot cleaner and easier for both the newbie *and* expert; it pulled the crap out of the way to let *everyone*, no matter the experience level, use it as a tool to get work done, versus being a desktop that gets in the way of getting work done. Simplified, *needless* complexity stripped out, yet fully functional for just about everyone save those with truly special needs. And of course, for those who don't like it, they can just use something besides GNOME. But a normal GNOME user doesn't need to know about that, or even what makes that possible, to be able to use GNOME. My friend Dan definitely wouldn't understand (again, not because he's stupid, just because he hasn't bothered to learn how a Linux system operates), yet he uses GNOME mostly happily (save for the questions about getting software installed I get from him, and other irrelevant-to-this-thread annoyances like media mounting.) Cleaning up and purifying the package system and development methodologies doesn't have to sacrifice anything, assuming they are cleaned up *right*. (just removing external dependencies and unconditionally embedding them is definitely not *right*) > > Just some thoughts... > > Nils -- Sean Middleditch AwesomePlay Productions, Inc. From ottohaliburton at comcast.net Sun Oct 5 21:59:22 2003 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Sun, 5 Oct 2003 16:59:22 -0500 Subject: Kind request: fix your packages In-Reply-To: <1065389108.11834.111.camel@wombat.tiptoe.de> Message-ID: <002401c38b8b$ef34b630$735eee0c@C515816A> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Nils Philippsen > Sent: Sunday, October 05, 2003 4:25 PM > To: fedora-devel-list at redhat.com > Subject: RE: Kind request: fix your packages > > On Sat, 2003-10-04 at 18:19, Sean Middleditch wrote: > > On Sat, 2003-10-04 at 09:11, Nicolas Mailhot wrote: > > > > > Dear user, > > > > > > As we all know you're dumb and you can not learn to use a package > > > manager ever. To ease your pain we've decided not to inflict you the > > > so-called "dependency hell" and provide you an autonomous application. > > > Just click on its auto-update menu and it will download everything you > > > need, we swear it. > > > > *bzzt* It has *nothing* to do with users being "dumb." *nothing* It > > I think Nicolas forgot the irony tags. > > > has to do with the fact the user doesn't care, doesn't need to care, and > > shouldn't be forced to care. I don't have a fricken clue how a jet > > engine works, don't really care how it works, but that doesn't mean I'm > > not allowed to fly on a plane. Indeed, the usage of an airplane is > > To turn around your comparison, the pilot would be the person pushing > around the mouse and pushing the keys for you (and everyone would be > clapping hands when the document comes out of the printer ;-). Doesn't > sound right? I thought so. > > > completely independent of knowing how the engine works, including the > > pilots. > > They too have their specialists ("flight mechanics") for the engines, > but at least basic knowledge how they work (e.g. the kernel) and > intimate knowledge about flight mechanics (e.g. how the system boots, > what package dependencies are and how to deal with them). If you look at > small planes, the pilots often are the flight mechanics. > > As I see it, the flight mechanics represent developers, the pilot > represents an administrator, the passengers represent normal users. At > the moment, passengers are restricted to using their seats, watching TV > and going to the bathroom during flight -- with much assistance and > hand-holding they could possibly emergency-land a machine if the pilots > are sick or whatever, but what are the odds that they succeed? > > I don't say that I don't wish that users could easily do complicate > tasks on a computer, aided by carefully crafted tools (auto-pilot ;-) > who take care of the innards they don't want to know about. > > > Computers aren't any different. There is no reason a user should *have* > > to understand the inner workings of it. That doesn't mean they *can't* > > know it, only that they don't need to. > > A computer is a very complex machine and I don't see that today's tools > are intelligent enough to hide all that from the user and still give > them all the potential the machines have. I don't see the majority of > the people having their private planes/gliders/etc. in the next years > either ;-). > > Just some thoughts... > > Nils Nils, I think you have forgotten what computers are. Computers are a tool. There are two phases to the tool. The user phase and the developer phase. The developer phase is the OS and all the things that go with making the computer work and do things. The user is the person that operates the tool and perform the task that the developer phase created. The user doesn't have a need to know anything about the developer phase, it's a waste of his time and energy. Once these relationships are understood then I think everybody will be happy. Think of it as a team, part of the team keeps the engine running and the other part does the driving. From wcooley at nakedape.cc Sun Oct 5 22:10:18 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Sun, 05 Oct 2003 15:10:18 -0700 Subject: Future unsupported Red Hat Linux systems In-Reply-To: <3F7F8966.6020807@wanadoo.es> References: <3F7F8966.6020807@wanadoo.es> Message-ID: <1065391817.18330.21.camel@denk.nakedape.priv> On Sat, 2003-10-04 at 20:00, Xose Vazquez Perez wrote: > hi, > > I know three[*] projects to provided support for future unsupported > Red Hat Linux systems. But I don't see too much movement. > > Is there any current .plan? I've asked on the fedeora-devel list that a RH 7.3 repository be opened, but my request has been met with dead silence. 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 jaap_haitsma at zonnet.nl Mon Oct 6 00:31:16 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Mon, 06 Oct 2003 02:31:16 +0200 Subject: Suggestion for gnome-terminal In-Reply-To: <3F80737B.2020602@zonnet.nl> References: <3F7FF70D.40204@zonnet.nl> <1065370129.2226.108.camel@dhcppc3> <3F80737B.2020602@zonnet.nl> Message-ID: <3F80B7D4.9070603@zonnet.nl> Jaap A. Haitsma wrote: >> >> >> Your entire X session should be a child of a login shell (that is, >> .bash_profile should be run by gdm when you first log in). >> It's only one login session for the whole X session, not one per >> terminal opened. >> >> If your whole session isn't a login session then there's some other >> problem, but not a gnome-terminal problem. >> > Maybe it's due to the fact that gdm in the latest update is not working > properly, and starts a failsafe session. Maybe it works with a new update. > > Sorry about the fuzz > > Jaap It's indeed a problem with gdm. I downgraded it to the version before the update and now everything works fine From jspaleta at princeton.edu Mon Oct 6 03:14:14 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Sun, 05 Oct 2003 23:14:14 -0400 Subject: Kind request: fix your packages Message-ID: <1065410054.12773.27.camel@localhost.localdomain> Sean Middleditch wrote: > The absolute worst thing about analogies is that people take parts of > them that don't apply to the situation Then stop using analogies.... > Perhaps I should've used cars as a cleaner analogy. ;-) I > don't know how most of my Ford Ranger works, and I couldn't care - I > just get in and drive the thing. Right, out of the pan into the fire... and if you just used a computer without trying to add functional elements to it...your repeated user of mechanical transportation analogy would be a much better fit. Do you drop in a v8 engine into your car, when you need more power? Do you upgrade your brakes to abs when you need better brakes? Do you drop in an 4 wheel drive when you need it? Your analogies still stink. When someone finds that a certain car has a "bug" do the car manufacturers expect users to install it...or do they have a recall and have an expert fix the problem? Normal mundane car users do not routinely try to add functionality or enhance functionality to their cars by themselves. Cup holders, fuzzy dice and cowhide seat covers...maybe...but those things are more akin to themes, desktop wallpapers and skins in the computer world than real functional elements. Hell most car users wouldn't even THINK about even installing their own stereo system without some expert assistance. Adding something like air conditioning is frankly well beyond a normal car user. But mundane computer users try to add functional components all the time, without a thought to how its suppose to work. That is what upgrading software and hardware in a computer is really...upgrading major functional elements of the tool. Normal users of cars and planes, do not and should not attempt to add significant functional elements without help or understanding...and using your analogy neither should computer users. It comes down to what a "user" is suppose to be doing when the "use" the software. Is downloading and adding new functionality really "using" the computer? Or is it tweaking it? Isn't my little store bought cable modem/router with a webinterface a computer? I use it all the time without actually downloading and installing any sort of software on it. I think your definition of "use" and "user" is overly broad and is itself a sort of misplaced analogy. -jef"if car manufacturers handled bug fixes like software companies..i would have gotten several lengths of electrical wire and a couple of engine mounting brackets in the mail with instructions on how to replace them...good thing car manufacturers have recalls to dealerships instead"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 elanthis at awesomeplay.com Mon Oct 6 03:53:44 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 05 Oct 2003 23:53:44 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065410054.12773.27.camel@localhost.localdomain> References: <1065410054.12773.27.camel@localhost.localdomain> Message-ID: <1065412423.8033.64.camel@stargrazer.home.awesomeplay.com> On Sun, 2003-10-05 at 23:14, Jef Spaleta wrote: > Sean Middleditch wrote: > > > The absolute worst thing about analogies is that people take parts of > > them that don't apply to the situation > > Then stop using analogies.... I tend to find them useful when explaining things, at least when talking to people who can think abstractly. If nothing else, I can get a good laugh at people whose language thought patterns haven't evolved past grade school level. ;-) > > > Perhaps I should've used cars as a cleaner analogy. ;-) I > > don't know how most of my Ford Ranger works, and I couldn't care - I > > just get in and drive the thing. > > Right, out of the pan into the fire... > and if you just used a computer without trying to add functional > elements to it...your repeated user of mechanical transportation analogy > would be a much better fit. Do you drop in a v8 engine into your car, > when you need more power? Do you upgrade your brakes to abs when you > need better brakes? Do you drop in an 4 wheel drive when you need it? Going with the anology (which is getting insane - guess I know which abstract levels I need to use from now on), replacing an engine or brake systems is like replacing a kernel or core desktop. That's a major functionality upgrade, not an add-on. > Your analogies still stink. When someone finds that a certain car has a Thanks. That's *really* useful to the discussion. You're putting *way* too much thought into this analogy stuff. ;-) > "bug" do the car manufacturers expect users to install it...or do they > have a recall and have an expert fix the problem? Normal mundane car Recall: manufacturer issues a "patch", which the user uses a "expert" update utility to apply. No more bug. Only difference is the user doesn't have to physically get up and go anywhere. > users do not routinely try to add functionality or enhance functionality > to their cars by themselves. Cup holders, fuzzy dice and cowhide seat > covers...maybe...but those things are more akin to themes, desktop > wallpapers and skins in the computer world than real functional > elements. Hell most car users wouldn't even THINK about even installing > their own stereo system without some expert assistance. Adding something And now you've wonderfully and pointlessly gone beyond the abstraction of a metaphor. Hope you had fun. ^,^ > like air conditioning is frankly well beyond a normal car user. But > mundane computer users try to add functional components all the time, > without a thought to how its suppose to work. That is what upgrading > software and hardware in a computer is really...upgrading major > functional elements of the tool. Normal users of cars and planes, do not My word processor is not a "major functional component". It's a wrench in my toolbox. (crap, I used another metaphor, now I'm going to have to listen to people drag it into some pointless comparison based on bolts and jackhammers or something. ;-) And hardware, I might note, is another thing entirely. Completely beyond the scope of the original discussion. > and should not attempt to add significant functional elements without > help or understanding...and using your analogy neither should computer > users. It comes down to what a "user" is suppose to be doing when the > "use" the software. Is downloading and adding new functionality really > "using" the computer? Or is it tweaking it? Good point. The difference is, a car comes with everything you expect a car to have. I don't buy a car without wheels and then go to add them. A computer, on the other hand, never comes with everything you want, unless you're a *very* basic user. (i.e., you browse the web, use webmail, and maybe write a paper.) In which case, they aren't probably going to even try installing software, so that is pointless (as I think your point was supposed to be.) Unfortunately, most people want utilities they don't already have. In personal experience, it's games (most of my friends are college kids and don't use their computers for many useful pursuits ;-) altho my family members tend to go for weird little utilities that do something-er-other they think is great. The "packaged for each OS release" approach fails, because (a) you will NEVER get everything people want packaged in Fedora Core/Extras, and (b) nobody wants to hear "you have to wait 3 months for the next release of your OS, which is kind of a pain to do since you have to sit and wait and watch all your software upgrade and cross your fingers nothing breaks and/or changes like it has with *every other* OS upgrade so far" when they just want to install FooWhiz, especially when they're sitting at its website with the "FooWhiz 1.0 with extra Bar available NOW!" on their screen. > Isn't my little store bought cable modem/router with a webinterface a > computer? I use it all the time without actually downloading and > installing any sort of software on it. I think your definition of "use" > and "user" is overly broad and is itself a sort of misplaced analogy. I generally refer to a desktop computer. Fedora isn't a router OS. ;-) (And yes, it *is* a small server OS, but people running servers aren't the ones that I'm worried for ;-) > > -jef"if car manufacturers handled bug fixes like software companies..i > would have gotten several lengths of electrical wire and a couple of > engine mounting brackets in the mail with instructions on how to replace > them...good thing car manufacturers have recalls to dealerships > instead"spaleta Wow, that nickname must be a pita during group introductions. ~,^ -- Sean Middleditch AwesomePlay Productions, Inc. From jspaleta at princeton.edu Mon Oct 6 05:47:40 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Mon, 06 Oct 2003 01:47:40 -0400 Subject: Kind request: fix your packages Message-ID: <1065419260.12773.104.camel@localhost.localdomain> Sean Middleditch wrote: > I tend to find them useful when explaining things, at least when talking > to people who can think abstractly Then you need to do a better job of picking the illustrative educational tool for the audience at hand. Continuing to use analogy, when several people are having trouble following you, just shows you aren't really interested in communicating with the people responding to you..you're just here to poke fun at those with diminished mental capacity. So far it seems you have not done so well getting people on this list to understand your abstract explanations...if agreement is the measure you use for understanding. I think you should consider using interpretive dance from now when trying to deal in the abstract on this list. > Good point. The difference is, a car comes with everything you expect a > car to have. I don't buy a car without wheels and then go to add them. > A computer, on the other hand, never comes with everything you want, Everything you WANT in a computer....and everything that is EXPECTED to come with a computer are very different...and I'm amazed you mixed the two concepts up. Are you honestly saying that cars and planes and boats and trains and dump trucks and dragsters..and whatever other complex transportation machine you want to try to draw an analogy with, come with everything that everyone could possibly want in such a machine. What is EXPECTED to come with a computer and what people WANT to come with a computer are different concepts. If you are going to continue to use the analogy of cars and trucks that people buy...then the analogy leads to the idea that computers that people are buying should be coming equipped with the things most people want, and not the conclusion you are trying to beat us over the head with, that adding functionality to computers after the initial purchase should be end-user easy. If everyone who wanted cd players for their cars got them when they bought their car..there would be no after market for cd players or other car electronics. But yet there is, people buy these things for their cars and want them installed, but few people actually install things like cd players and electronic alarm systems themselves..and there is no real expectation that installing car electronics is end-user easy. Where DID the expectation that installing new software is an end-user easy task? If the goal that you want is to have a computer be as easy to "use" as it is to "use" a car..well thats quite easy to accomplish. It would be quite easy to create a computer that just ran like a car...by building a computer that was not easily upgradable with new software unless it was brought in to be serviced by an expert. Installing software is not using a computer. Installing a cd player in your car is not using your car. But that's clearly not a solution to the problem you are prepared to accept. Because really, you aren't interested in just something that is easy to "use", you want something that is also easy to fix and to extend with new functionality. Your basic analogy doesn't speak to the real nature of the problem you want solved. So stop trying to be cute by talking around the problem...talk about the problem instead. -jef"describing a computer as a tool box..and new software as a new wrench you just throw in...is insulting to the subtle complexity of the awe inspiring effort it takes to get the intricate layers of software that builds up a computer system to pretend to work together. A wrench, even if poorly made doesn't stand a good chance of interfering with how the other tools in the toolbox work...no matter how cute the toolbox analogy seems"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 notting at redhat.com Mon Oct 6 05:48:18 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Oct 2003 01:48:18 -0400 Subject: OpenOffice.org 1.1 In-Reply-To: <1065273432.17897.125.camel@guava.bamdad.org>; from roozbeh@sharif.edu on Sat, Oct 04, 2003 at 04:47:12PM +0330 References: <1065273432.17897.125.camel@guava.bamdad.org> Message-ID: <20031006014818.B12313@devserv.devel.redhat.com> Roozbeh Pournader (roozbeh at sharif.edu) said: > What are the plans for OOo 1.1 in Fedora Core? I'm specially interested > since OOo 1.1 has some nice BiDi (Hebrew, Arabic, ...) support, which > I'd love to impress my friends with ;-) It's planned. Bill From notting at redhat.com Mon Oct 6 05:49:07 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Oct 2003 01:49:07 -0400 Subject: rawhide report: 20031004 changes In-Reply-To: <1065274214.11858.32.camel@marte.biciclete.ro>; from mandreiana@rdslink.ro on Sat, Oct 04, 2003 at 04:30:15PM +0300 References: <200310040948.h949mcg18824@porkchop.devel.redhat.com> <1065274214.11858.32.camel@marte.biciclete.ro> Message-ID: <20031006014907.C12313@devserv.devel.redhat.com> Marius Andreiana (mandreiana at rdslink.ro) said: > Could this have only the diff between prev. and current ChangeLog for > each package? That's the plan, there's a bug in the script, I know roughly where it is (the way it determines where the changes end is not a particularly smart algorithm.) Bill From notting at redhat.com Mon Oct 6 05:52:43 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Oct 2003 01:52:43 -0400 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: ; from nhruby@uga.edu on Sun, Oct 05, 2003 at 03:53:25PM -0400 References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> <1065370776.14230.61.camel@binkley> Message-ID: <20031006015243.D12313@devserv.devel.redhat.com> nathan r. hruby (nhruby at uga.edu) said: > What's the new mirror structure going to look like? Current FC1 simply > lives in redhat's linux/beta/ directory and the downloads.fedora.us site > has a compltely different structure, but there's a lot of duplication > which I don't currently have the disk space to cover. Not yet decided. > Maybe this is still in the process of being decided upon, or maybe there's > a better place to discuss this? If either, please LMK. I am (as many of > you can probably attest to :) not very smart sometimes. Probably on the mirror discussion lists. Bill From nphilipp at redhat.com Mon Oct 6 06:54:12 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 06 Oct 2003 08:54:12 +0200 Subject: Kind request: fix your packages In-Reply-To: <002401c38b8b$ef34b630$735eee0c@C515816A> References: <002401c38b8b$ef34b630$735eee0c@C515816A> Message-ID: <1065423251.6257.12.camel@wombat.tiptoe.de> On Sun, 2003-10-05 at 23:59, Otto Haliburton wrote: > > -----Original Message----- > > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > > admin at redhat.com] On Behalf Of Nils Philippsen > > Sent: Sunday, October 05, 2003 4:25 PM > > To: fedora-devel-list at redhat.com > > Subject: RE: Kind request: fix your packages > > > > On Sat, 2003-10-04 at 18:19, Sean Middleditch wrote: > > > On Sat, 2003-10-04 at 09:11, Nicolas Mailhot wrote: > > > > > > > Dear user, > > > > > > > > As we all know you're dumb and you can not learn to use a package > > > > manager ever. To ease your pain we've decided not to inflict you the > > > > so-called "dependency hell" and provide you an autonomous application. > > > > Just click on its auto-update menu and it will download everything you > > > > need, we swear it. > > > > > > *bzzt* It has *nothing* to do with users being "dumb." *nothing* It > > > > I think Nicolas forgot the irony tags. > > > > > has to do with the fact the user doesn't care, doesn't need to care, and > > > shouldn't be forced to care. I don't have a fricken clue how a jet > > > engine works, don't really care how it works, but that doesn't mean I'm > > > not allowed to fly on a plane. Indeed, the usage of an airplane is > > > > To turn around your comparison, the pilot would be the person pushing > > around the mouse and pushing the keys for you (and everyone would be > > clapping hands when the document comes out of the printer ;-). Doesn't > > sound right? I thought so. > > > > > completely independent of knowing how the engine works, including the > > > pilots. > > > > They too have their specialists ("flight mechanics") for the engines, > > but at least basic knowledge how they work (e.g. the kernel) and > > intimate knowledge about flight mechanics (e.g. how the system boots, > > what package dependencies are and how to deal with them). If you look at > > small planes, the pilots often are the flight mechanics. > > > > As I see it, the flight mechanics represent developers, the pilot > > represents an administrator, the passengers represent normal users. At > > the moment, passengers are restricted to using their seats, watching TV > > and going to the bathroom during flight -- with much assistance and > > hand-holding they could possibly emergency-land a machine if the pilots > > are sick or whatever, but what are the odds that they succeed? > > > > I don't say that I don't wish that users could easily do complicate > > tasks on a computer, aided by carefully crafted tools (auto-pilot ;-) > > who take care of the innards they don't want to know about. > > > > > Computers aren't any different. There is no reason a user should *have* > > > to understand the inner workings of it. That doesn't mean they *can't* > > > know it, only that they don't need to. > > > > A computer is a very complex machine and I don't see that today's tools > > are intelligent enough to hide all that from the user and still give > > them all the potential the machines have. I don't see the majority of > > the people having their private planes/gliders/etc. in the next years > > either ;-). > > > > Just some thoughts... > > > > Nils > > Nils, > I think you have forgotten what computers are. Computers are a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I don't think so, but see below. > tool. There are two phases to the tool. The user phase and the developer > phase. The developer phase is the OS and all the things that go with making > the computer work and do things. The user is the person that operates the > tool and perform the task that the developer phase created. The user > doesn't have a need to know anything about the developer phase, it's a waste > of his time and energy. Once these relationships are understood then I > think everybody will be happy. Think of it as a team, part of the team > keeps the engine running and the other part does the driving. I think we differ in how we define "driving". I think "driving" includes running installed programs, running the installer or updater but anything beyond that is clearly "off-road" for a mere driver. Fiddling with your engine or tuning the car with stuff from various sources is not "driving" for me, i.e. it requires knowledge to do properly. The "monolithic approach" I've seen in this thread (brings all needed stuff with it, allegedly works always) might work, but then this is basically like an appliance where the OS is just the kernel or in the (stretched into oblivion) car analogy: you can keep the engine, but everything else will be added to the car again. Can you imagine driving a car with more than one steering wheel? I hate unnecessary redundancy as it often brings more problems than it solves. 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 Axel.Thimm at physik.fu-berlin.de Mon Oct 6 08:42:50 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 10:42:50 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <1065026194.4814.11.camel@hagrid> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <1065026194.4814.11.camel@hagrid> Message-ID: <20031006084250.GJ8013@puariko.nirvana> On Wed, Oct 01, 2003 at 12:36:34PM -0400, Konstantin Riabitsev wrote: > On Wed, 2003-10-01 at 11:00, Axel Thimm wrote: > Well, this is a piece of legacy that you have created for yourself. You > have opted to use an unreliable way of providing "upgradeability" for > the packages you ship that was never guaranteed to be a foolproof > solution. It is not fair to demand that this system should be continued > simply because you made a choice that might have seemed a good one in > the past, but ended up creating unnecessary legacy out of which you > cannot get out (or are unwilling). You are getting me wrong here. I simply present a solution for concurrent repositories, e.g. having the same package (sourcewise) in RH7.3, RH8.0, RH9 and the next N releases. This is a problem that the Fedora Legacy will face sooner or later, and it's better faced now, where things can get fixed. If one is interested in keeping sane upgrade paths between the supported releases, one will find the only way to do so is to generate rpms with VRs following this scheme: foo-1.2.3-4 foo-1.2.3-4 foo-1.2.3-4 Making sure the ordering of the suffixN corresponds to the rpm upgrade path algorithm. The natural way to create this suffix is to use the distro versioning number, but this has now broken. Note: not only for my repo, but for others as well, including fedora.us! fedora.us is saving their day with a kludge: While previously the distro release was prepended by alphabetic characters ("rh"), they skip it for the new releases, as anything starting with "f" is rpm-older. But this is already broken for Fedora Legacy, as older rpms do not sort properly numbers and alphabetic entries (its a bug fixed only rather recently). And even if it were, it still is a kludge to remove the distro identification of the rpm. > It was never guaranteed that the versioning of releases would remain > consistent, and most packagers who have seen the jump from 8.0 to 9 have > quickly realized that making the OS version part of their release is a > very icky way of guaranteeing package upgradeability. > > You've dug this hole for yourself, and I do not think it is fair to > expect us all to jump down it. Please see it constructively. Maybe you are not interested in supporting multiple distros, but other who are ("Fedora Lagacy") need a versioning scheme they can live with. So please provide a better working scheme. -- 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 Mon Oct 6 08:42:57 2003 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 06 Oct 2003 10:42:57 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065389108.11834.111.camel@wombat.tiptoe.de> References: <003f01c38a65$edbca8c0$735eee0c@C515816A> <1065273071.3207.67.camel@rousalka.dyndns.org> <1065284367.5142.38.camel@stargrazer.home.awesomeplay.com> <1065389108.11834.111.camel@wombat.tiptoe.de> Message-ID: <1065429777.12083.9.camel@ulysse.olympe.o2t> Le dim 05/10/2003 ? 23:25, Nils Philippsen a ?crit : > On Sat, 2003-10-04 at 18:19, Sean Middleditch wrote: > > On Sat, 2003-10-04 at 09:11, Nicolas Mailhot wrote: > > > > > Dear user, > > > > > > As we all know you're dumb and you can not learn to use a package > > > manager ever. To ease your pain we've decided not to inflict you the > > > so-called "dependency hell" and provide you an autonomous application From Axel.Thimm at physik.fu-berlin.de Mon Oct 6 08:50:52 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 10:50:52 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031001191908.09b44222.ms-nospam-0306@arcor.de> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> Message-ID: <20031006085052.GK8013@puariko.nirvana> On Wed, Oct 01, 2003 at 07:19:08PM +0200, Michael Schwendt wrote: > A few observations: In your repository I don't see a consistent > platform specific release tag scheme. check the dates and the discussion on fedora.us in March/April (yes, I was once a fedora member). The fact is that there still is no versioning scheme one can rely upon. The scheme we discussed with fedora.us in March/April is now broken. The main issue is, that RH need to come up with a consistent scheme (not only for fedora but also including fedora legacy), or bless an existing one. Currently there is no schem that will work: o either the upgrade paths are broken, e.g. rh9 -> fc1/fdr1 o or rpm bugs are triggered, e.g. rhXX -> numbers o Red Hat policy is violated, e.g. rh9 -> rh10 I understand RH's marketing and company policy, I won't join the "free beer" group, but I would like the policy to not spoil technical issues. > > What about Fedora Legacy, should part of it be distro-tagged and > > some not (like your example above)? > > I haven't seen any work on guidelines for Fedora Legacy yet. This thread _is_ about Fedora Lagacy ... ;) -- 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 Mon Oct 6 08:53:46 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 10:53:46 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031001121748.A10182@devserv.devel.redhat.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> Message-ID: <20031006085346.GL8013@puariko.nirvana> On Wed, Oct 01, 2003 at 12:17:48PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > > I'll also go with your suggestion, Rex. I'd call it the "it's written > > rh10, but it is pronounced Fedora Core 1" idiom ... > > Now that's just patently misleading. It's *not* Red Hat Linux 10, > it's Fedora Core 1. It's a shift in the development model, shifts > in the goals of the release, and more. Hence, the new name, and > new version. > > > By bumping all epochs of "Fedora Core" to ensure > > upgradability, and maintaining unnecessary multiple specfiles? > > Huh? We aren't bumping all epochs of Fedora Core packages, and > we don't have to to maintain upgradeability. > > > The alternative is to drop support for upgrading from RH <= 9 to FC, > > which is even uglier. > > Uprgrades work... there were a couple hiccups in the test release, > but by the time of the final release, I do believe there will only > be epochs added to indexhtml and comps. I think you lost the context, maybe I should have but Fedora Legacy in the subject. It is not about Fedora Core, where the affected packages are only a few, but for Fedora Lagacy projects, which will host the same package in different Legacy repos and will have to ensure upgradability. -- 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 jos at xos.nl Mon Oct 6 08:58:51 2003 From: jos at xos.nl (Jos Vos) Date: Mon, 6 Oct 2003 10:58:51 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006085346.GL8013@puariko.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Mon, Oct 06, 2003 at 10:53:46AM +0200 References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <20031006085346.GL8013@puariko.nirvana> Message-ID: <20031006105851.B4089@xos037.xos.nl> On Mon, Oct 06, 2003 at 10:53:46AM +0200, Axel Thimm wrote: > It is not about Fedora Core, where the affected packages are only a > few, but for Fedora Lagacy projects, which will host the same package > in different Legacy repos and will have to ensure upgradability. But still, why should the release be numbered 10 then, as this only relates to the redhat-release (or whatever) package (and maybe a few more)? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From warren at togami.com Mon Oct 6 09:29:22 2003 From: warren at togami.com (Warren Togami) Date: Sun, 05 Oct 2003 23:29:22 -1000 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <20031006015243.D12313@devserv.devel.redhat.com> References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> <1065370776.14230.61.camel@binkley> <20031006015243.D12313@devserv.devel.redhat.com> Message-ID: <3F8135F2.6040606@togami.com> Bill Nottingham wrote: >>Maybe this is still in the process of being decided upon, or maybe there's >>a better place to discuss this? If either, please LMK. I am (as many of >>you can probably attest to :) not very smart sometimes. > > > Probably on the mirror discussion lists. > There has been discussion there, but that list isn't open to the public. It should be moved here to fedora-devel-list as this is important. Any ugly flaw in the design we will have to live with forever. =( Warren From warren at togami.com Mon Oct 6 09:31:22 2003 From: warren at togami.com (Warren Togami) Date: Sun, 05 Oct 2003 23:31:22 -1000 Subject: Future unsupported Red Hat Linux systems In-Reply-To: <200310042046.47877.hosting@j2solutions.net> References: <3F7F8966.6020807@wanadoo.es> <200310042046.47877.hosting@j2solutions.net> Message-ID: <3F81366A.5050101@togami.com> Jesse Keating wrote: > > Univ-Linux might join forces w/ Fedora Legacy if we can get Legacy worked out. > I"m somewhat of the community spokes person for Legacy, nobody else was doing > anything with it so I stepped up. I'm waiting to see what all Red Hat will > let me do with Legacy, since they've coined the phrase so to speak. I'm > hoping to have some answers by the end of next week. > RH has shown absolutely no interest in doing it, so it was *I* who coined "Fedora Legacy". Aside from that I have been rather worthless. =) Still waiting for key answers from RH regarding Legacy's status within the new world order... Warren From Axel.Thimm at physik.fu-berlin.de Mon Oct 6 09:39:16 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 11:39:16 +0200 Subject: Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths) In-Reply-To: <20030924074545.GB1919@pua.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> Message-ID: <20031006093916.GM8013@puariko.nirvana> I am changing the subject to avoid loosing the context again. I am also top posting, as the quoted part below is for reference only and not a reply. I hope this longish post clarifies the problem and stimulates more constructive discussions (no, the thread until now was not constructive ;) If you are a "Fedora Legacy" champion take your time please to get through it. I hope the problem becomes more transparent that way, and that a good solution is found before everything gets hit in stone (e.g. November). Thank you for your time! The problem: ============ The aim is to have packages for Red Hat Linux and Fedora (Core) which should be naturally (speak rpm-wise) upgradeable. For Red Hat's packages from release to release this is ensured by o Updated upstream versions o Updated release tags due to different packaging or simply due to rebuilding for the current release o Epoch bumping where the above is not possible, e.g. downgrading a buggy package. When common errata were issued, either the packages were having different upstream versions, or the errata was using an ad hoc method for ensuring upgrade paths, usually with suffixes derived from the distro version, like .7x, .80, .90, or .7, .8 and .9. There was no policy on how to deal with it, as it was not really an issue within RH. The true trouble comes up, when you want to maintain the same package for multiple different releases, e.g. RH7.3, RH8.0, RH9, FC/FDR 1 etc. This is a common task in the "Fedora Legacy" subcomponent. These packages will have the same upstream version and will (whenever possible) be based on the same sources (same SourceN/PatchN/specfile). This had been discussed on fedora.us half a year before. The viable solutions that emerged were to have suffixes at the rpm release tag that order the rpms according to the distro version, e.g. foo-1.2.3-4_rh7.3 foo-1.2.3-4_rh8.0 foo-1.2.3-4_rh9 There are variations on this scheme, like dropping "rh" or using 73, 80, 90 instead of 7.3, 8.0 and 9. The current decision to rewind the distro release is breaking such schemes, and "Fedora Legacy" like repos need a solution. Defining the problem domain for Fedora Legacy: ============================================== a) We need a versioning scheme that ensures upgradability without obfuscating too much the VR scheme. b) It should be possible to use the same sources/patches/specfiles with macro controlled differences c) It should work with older rpm versions, e.g. don't let rpm compare numbers with letters. The easiest way to achieve a) and b) is to have Release: 4_%{disttag} in the specfile and let %{disttag} expand to values in the right rpm-order for the given distributions. A proposal on the fedora.us side is to allow rpm to compare "rh9" versus "1", which under newer rpms will resolve as older, but which is not the case for RH7.x (possibly even stock RH8.0, but I may be mistaken). There are updated rpm rpms fixing this issue, but they are neither available via RHN, nor can Fedora Legacy assume that those rpms are available on the system to be upgraded. Therefore it is far better to compare numbers only with rpm. So we need a versioning scheme f that numerically sorts ... < f("7.3") < f("8.0") < f("9") < f("1") < ... Possible solutions: =================== a) Call _internally_ the next release ("Fedora [Core] 1") "RawHide 10" or "RawHide 9.1". It looks compatible with RH's policy and would allow for tags like "rh10" to complete the above scheme. b) Drop upgradability withing Fedora Legacy from RHL to FC/FDR. c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" < "number" idiom. d) Use tags with something larger than "rh", e.g. "tfp" ("The Fedora Project") X) Your suggestion here. It is important to have Red Hat's consent on any sollution, as well as a common versioning scheme across repositories of different maintainers to allow for properly formulating cross-repository dependencies and having easy identification by end users. Optional good-to-have semantics: ================================ o Use the same versioning for Fedora. It would be good to have a scheme applicable to both Fedora Legacy as well as Fedora (current release). That way Fedora releases could automatically become Fedora Legacy without rebuilding and re-versioning. o Use the same versioning for RawHide/Betas. This would help building more often for RawHide. E.g. the following scheme could be used until now: foo-1.2.3-4_rh8.0 foo-1.2.3-4_rh8.0.93 (beta) foo-1.2.3-4_rh8.0.94.20030325 (rawhide) foo-1.2.3-4_rh9 (release) On Wed, Sep 24, 2003 at 10:45:45AM +0300, Axel Thimm wrote: > On Tue, Sep 23, 2003 at 07:28:58PM -0400, Elliot Lee wrote: > > On Wed, 24 Sep 2003, Axel Thimm wrote: > > > > > What about the versioning? Will xxx-release continue to have > > > rpm-monotonic larger VRs than the previous releases? > > > > EpochVR yes, VR no. > > > > The beta will have redhat-release-0.94-1 (epoch 1). > > That is ugly in multiple ways. Leaving all other reasons for not > using epochs aside, this will break all upgrade paths from embedded > disttags like 7.3, 8.0 or 9. The logical conduction would be to have > these repos also bump up epochs to ensure rpm upgradability or invent > their own versioning. > > Any way it will be creating confusion and disorder. ;) > > Could a better mechanism be created before the 25th that enables > disttags to be carried on? Please use no epoch/release, and make the > version be (rpm-)bigger than "9". Also keep redhat-release as a proper > package carrying that version information. > > Background: > =========== > > Up to now RH was not often in the need to release multiple versions of > the same package for different RH releases. Even if the package did > not change its release tag was bumbed (rebuilt for xxx). > > Errata were either based on different upstream sources, so no upgrade > clashes could come up, while in the very rare cases, where exactly the > same package was rebuilt for different RH release the package > maintainer had to invent a scheme that worked in that timeframe > (e.g. the kernel errata releases for RH 7.3/8.0/9). > > 3rd party repos have been using the idiom of keeping the same upstream > release current in multiple RH releases more often. The only portable > way up to now to do so was to inspect the rpm-version value of > redhat-release. Tags were created like > > foo-fooversion-foorelease.rh8.0.i386.rpm > > etc., ensuring sane upgrade paths for users of the 3rd party > repo. Here are some google pointers: > > http://www.google.com/search?q=rpm+%22--qf%22+version+redhat-release > > My plea is therefore to > > o keep redhat-release as a package of its own, so that > `rpm -q --qf "%{VERSION}" redhat-release' still works. > o Make the version of this package rpm-monotonic without using epoch > (or even release tags), e.g. use a version rpm-larger than "9". > o Put redhat-release into rawhide carrying the anaconda version ... > > The alternative is to break the upgrade path mechanism of several > repos or single package sites, please don't. -- 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 buildsys at porkchop.devel.redhat.com Mon Oct 6 09:50:47 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Mon, 6 Oct 2003 05:50:47 -0400 Subject: rawhide report: 20031006 changes Message-ID: <200310060950.h969olc07964@porkchop.devel.redhat.com> Updated Packages: XFree86-4.3.0-36 ---------------- * Fri Oct 03 2003 Mike A. Harris 4.3.0-36 - Added XFree86-4.3.0-ati-generic-shared-chip-data.patch to unify changes to atichip.h into a single harmless patch to avoid patch overlap and merge conflicts - Updated XFree86-4.3.0-radeon-support-from-ATI-backport-from-CVS.patch to remove changes to atichip.h as they're merged into the above patch instead - Added XFree86-4.3.0-radeon-support-backport-from-CVS.patch backport of support for newer Radeon 9600/9800/IGP/Mobility hardware from CVS head, along with a few minor bug fixes for Mobility and IGP. Very low risk change which is heavily audited, however currently configured to only build for cambridge and psyche until runtime tested sufficiently - Renamed XFree86-4.3.0-ati-radeon-dpms-on-dvi-v2.patch for consistency, to XFree86-4.3.0-radeon-dpms-on-dvi-v2.patch - Added XFree86-4.3.0-Xserver-xf86PciInfo-updates.patch which from now on will hold all xf86PciInfo updates. Moved all Radeon, savage, and S3 updates from other patches into this file. * Fri Oct 03 2003 Mike A. Harris 4.3.0-35.EL - Rebuilt 4.3.0-35 as 4.3.0-35.EL for RHEL glibc-2.3.2-98 -------------- * Sat Oct 04 2003 Jakub Jelinek 2.3.2-98 - update from CVS - fix close, pause and fsync (#105348) - fix pthread_once on IA-32 - implement backtrace () on IA-64, handle -fomit-frame-pointer in AMD64 backtrace () (#90402) libart_lgpl-2.3.16-1 -------------------- * Mon Oct 06 2003 Alexander Larsson 2.3.16-1 - 2.3.16 rawhide-release-20031006-1 -------------------------- xemacs-sumo-20031003-1 ---------------------- * Mon Oct 06 2003 Jens Petersen - 20031003-1 - update to 2003-10-03 release From goeran at uddeborg.se Mon Oct 6 10:04:44 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Mon, 6 Oct 2003 12:04:44 +0200 Subject: Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths) In-Reply-To: <20031006093916.GM8013@puariko.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20031006093916.GM8013@puariko.nirvana> Message-ID: <16257.15932.939702.972542@uebn.uddeborg.se> Axel Thimm writes: > c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" < > "number" idiom. A little observation I haven't seen so far. (But I can have missed it in the long thread, sorry if so.): It will matter that "rhnumber" < "number" only for systems from FC1 and on. And those systems come rpm > 4.2. Systems with rpm < 4.1 should never have to see the packages without rh. So it ought to work out right in practice. It's still kludgy, though. From Axel.Thimm at physik.fu-berlin.de Mon Oct 6 10:13:54 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 12:13:54 +0200 Subject: Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths) In-Reply-To: <20031006093916.GM8013@puariko.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20031006093916.GM8013@puariko.nirvana> Message-ID: <20031006101354.GO8013@puariko.nirvana> On Mon, Oct 06, 2003 at 11:39:16AM +0200, Axel Thimm wrote: > A proposal on the fedora.us side is to allow rpm to compare "rh9" > versus "1", which under newer rpms will resolve as older, but which is > not the case for RH7.x (possibly even stock RH8.0, but I may be > mistaken). Small addendum: I just looked it up for another communication on fedora.us list. This bug was fixed 9 months ago in rpm 4.2-0.55: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=50977#c20 So that means that even RH8.0 is affected. I assume the 4.1.1 backport available from rpm.org does contain the bug-fix, but I know nothing about 4.0.5. > There are updated rpm rpms fixing this issue, but they are neither > available via RHN, nor can Fedora Legacy assume that those rpms are > available on the system to be upgraded. > [...] > c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" < > "number" idiom. This should then probably be "rpm < 4.1.1". Anyway, the presence of this bug prohibits mixing numerical and alphabetical segments in rpm comparision for any system running an rpm from before 2003, unless rpm is upgraded to a version without this bug before any other upgrading operation. Therefore IMHO mixing numerical and alphabetical segments in comparisons should be avoided for legacy considerations. -- 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 Mon Oct 6 10:48:25 2003 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 06 Oct 2003 12:48:25 +0200 Subject: Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths) In-Reply-To: <20031006101354.GO8013@puariko.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20031006093916.GM8013@puariko.nirvana> <20031006101354.GO8013@puariko.nirvana> Message-ID: <1065437305.12083.20.camel@ulysse.olympe.o2t> Le lun 06/10/2003 ? 12:13, Axel Thimm a ?crit : > On Mon, Oct 06, 2003 at 11:39:16AM +0200, Axel Thimm wrote: > Anyway, the presence of this bug prohibits mixing numerical and > alphabetical segments in rpm comparision for any system running an rpm > from before 2003, unless rpm is upgraded to a version without this bug > before any other upgrading operation. > > Therefore IMHO mixing numerical and alphabetical segments in > comparisons should be avoided for legacy considerations. At one point you should consider if providing a fixed rpm version for all affected systems and have all updates depend on this rpm version is not easier than trying to come with the perfect backwards-compatible macro. 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 warren at togami.com Mon Oct 6 11:06:30 2003 From: warren at togami.com (Warren Togami) Date: Mon, 06 Oct 2003 01:06:30 -1000 Subject: Fedora and Fedora Legacy package versioning schemes In-Reply-To: <20031006093916.GM8013@puariko.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20031006093916.GM8013@puariko.nirvana> Message-ID: <3F814CB6.2040904@togami.com> Thank you for your well written proposal. Axel Thimm wrote: > Defining the problem domain for Fedora Legacy: > ============================================== > > a) We need a versioning scheme that ensures upgradability without > obfuscating too much the VR scheme. > b) It should be possible to use the same sources/patches/specfiles with > macro controlled differences > c) It should work with older rpm versions, e.g. don't let rpm compare > numbers with letters. > a + b are perfectly valid, but I see no reason to continue to support the ugly behavior of c, and here's why: 1) jbj has long indicated that he wishes all distributions to use the same upgraded version of rpm in order to simplify maintenance. 2) Fedora Legacy is the time to FORCE everyone to upgrade RPM if they wish to continue to use the repository. This means that we will be able to avoid a lot of unpredictable behavior (#1) in older versions of rpm, making Legacy distributions easier to support in the long term. 3) RH 8.0 Psyche rpm *needs* to be upgraded anyway because the default rpm is too broken to use. (Read the bottom of this message for a summary of my %{release} naming proposal.) > The easiest way to achieve a) and b) is to have > > Release: 4_%{disttag} > > in the specfile and let %{disttag} expand to values in the right > rpm-order for the given distributions. > > A proposal on the fedora.us side is to allow rpm to compare "rh9" > versus "1", which under newer rpms will resolve as older, but which is > not the case for RH7.x (possibly even stock RH8.0, but I may be > mistaken). There are updated rpm rpms fixing this issue, but they are > neither available via RHN, nor can Fedora Legacy assume that those > rpms are available on the system to be upgraded. > > Therefore it is far better to compare numbers only with rpm. > > So we need a versioning scheme f that numerically sorts > > ... < f("7.3") < f("8.0") < f("9") < f("1") < ... > > Possible solutions: > =================== > > a) Call _internally_ the next release ("Fedora [Core] 1") "RawHide 10" > or "RawHide 9.1". It looks compatible with RH's policy and would > allow for tags like "rh10" to complete the above scheme. > -1 Too confusing to have different numbers and names in different places. > b) Drop upgradability withing Fedora Legacy from RHL to FC/FDR. > -999 We should always maintain upgradability between distributions, and Fedora will strengthen this and prevent problems by stricter packaging standards than those enforced by RH internally in the past. There is currently absolutely no reason to break upgradability. > c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" < > "number" idiom. -1 > > d) Use tags with something larger than "rh", e.g. "tfp" ("The Fedora > Project") -500 The whole reason why we had those dist tags was because fedora.us (or freshrpms, or dag, or axel, etc.) were not official repositories. Now Fedora is official, so I believe we can drop this ugliness that makes the package filename unnecessarily longer. > > X) Your suggestion here. > > It is important to have Red Hat's consent on any sollution, as well as > a common versioning scheme across repositories of different > maintainers to allow for properly formulating cross-repository > dependencies and having easy identification by end users. > > Optional good-to-have semantics: > ================================ > o Use the same versioning for Fedora. > > It would be good to have a scheme applicable to both Fedora Legacy > as well as Fedora (current release). That way Fedora releases could > automatically become Fedora Legacy without rebuilding and > re-versioning. > +1 > o Use the same versioning for RawHide/Betas. > > This would help building more often for RawHide. E.g. the following > scheme could be used until now: > > foo-1.2.3-4_rh8.0 > foo-1.2.3-4_rh8.0.93 (beta) > foo-1.2.3-4_rh8.0.94.20030325 (rawhide) > foo-1.2.3-4_rh9 (release) > +1 I dislike your specific examples that contain "rh", but the numbers I fully agree. Warren's Release Naming Proposal (draft 1) ========================================== All distributions in Fedora Legacy must upgrade to the latest version of rpm for that distribution. %{release} name structure ------------------------- X.%{non-numeric version}.%{distrel} X RPM package release number, always increments with every update, even a rebuild. %{non-numeric version} Non-numeric characters at the end of upstream's %{version}. Since %{version} must (almost) never contain non-numeric characters in order to avoid the Epoch treadmill (like mozilla package), the non-numeric portion can optionally be contained within the %{release} tag after the release number. Examples: mozilla-1.5-5.rc2 foobar-2.0-7.cvs20031005 %{distrel} Upgrade Path from fedora.us -------------------------------------- 0.fdr.X.rh80 -> 0.fdr.X.rh90 -> 0.fdr.X.0.94 -> 0.94 -> 1 fedora.us currently has an even longer "0.fdr.X" prepended before the suggested fedora.redhat.com scheme. Thus absolutely anything containing numbers in the second glob will "win" against "fdr". Examples: foobar-1.5-6.rc3_1.9.2 (Fedora Core 1.92 beta) foobar-1.5-6.rc3_1 (Fedora Core 1) foobar-1.5-6.rc3_0.9.4 (Fedora Core 0.94) foobar-1.5-6.rc3_0.8 (RHL 8.0 Psyche) foobar-1.5-6.rc3_0.7.3 (RHL 7.3) Note that I used "_" instead of "." in this particular example. Either of them would work. The former would be a clearer seperator between the %{distrel} and the rest of the tag, while the latter is slightly easier to type. I personally don't care which one is used. Opinions? Warren From warren at togami.com Mon Oct 6 11:08:26 2003 From: warren at togami.com (Warren Togami) Date: Mon, 06 Oct 2003 01:08:26 -1000 Subject: Fedora and Fedora Legacy package versioning schemes In-Reply-To: <1065437305.12083.20.camel@ulysse.olympe.o2t> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20031006093916.GM8013@puariko.nirvana> <20031006101354.GO8013@puariko.nirvana> <1065437305.12083.20.camel@ulysse.olympe.o2t> Message-ID: <3F814D2A.7040509@togami.com> Nicolas Mailhot wrote: > Le lun 06/10/2003 ? 12:13, Axel Thimm a ?crit : > >>On Mon, Oct 06, 2003 at 11:39:16AM +0200, Axel Thimm wrote: > > >>Anyway, the presence of this bug prohibits mixing numerical and >>alphabetical segments in rpm comparision for any system running an rpm >>from before 2003, unless rpm is upgraded to a version without this bug >>before any other upgrading operation. >> >>Therefore IMHO mixing numerical and alphabetical segments in >>comparisons should be avoided for legacy considerations. > > > At one point you should consider if providing a fixed rpm version for > all affected systems and have all updates depend on this rpm version is > not easier than trying to come with the perfect backwards-compatible > macro. > +1 Exactly. And given rpm-4.1 from RH8 as an example, why would anyone WANT to not upgrade it... =) Warren From Axel.Thimm at physik.fu-berlin.de Mon Oct 6 11:51:42 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 13:51:42 +0200 Subject: Fedora and Fedora Legacy package versioning schemes In-Reply-To: <3F814D2A.7040509@togami.com> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20031006093916.GM8013@puariko.nirvana> <20031006101354.GO8013@puariko.nirvana> <1065437305.12083.20.camel@ulysse.olympe.o2t> <3F814D2A.7040509@togami.com> Message-ID: <20031006115142.GV8013@puariko.nirvana> On Mon, Oct 06, 2003 at 01:08:26AM -1000, Warren Togami wrote: > Nicolas Mailhot wrote: > > >Le lun 06/10/2003 ? 12:13, Axel Thimm a ?crit : > > > >>On Mon, Oct 06, 2003 at 11:39:16AM +0200, Axel Thimm wrote: > > > > > >>Anyway, the presence of this bug prohibits mixing numerical and > >>alphabetical segments in rpm comparision for any system running an rpm > >>from before 2003, unless rpm is upgraded to a version without this bug > >>before any other upgrading operation. > >> > >>Therefore IMHO mixing numerical and alphabetical segments in > >>comparisons should be avoided for legacy considerations. > > > > > >At one point you should consider if providing a fixed rpm version for > >all affected systems and have all updates depend on this rpm version is > >not easier than trying to come with the perfect backwards-compatible > >macro. > > > +1 > Exactly. And given rpm-4.1 from RH8 as an example, why would anyone > WANT to not upgrade it... =) Then why isn't is offered on RHN? -- 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 Mon Oct 6 11:52:12 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 13:52:12 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006105851.B4089@xos037.xos.nl> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> <20031001091017.GG1876@pua.nirvana> <20031001121748.A10182@devserv.devel.redhat.com> <20031006085346.GL8013@puariko.nirvana> <20031006105851.B4089@xos037.xos.nl> Message-ID: <20031006115212.GW8013@puariko.nirvana> On Mon, Oct 06, 2003 at 10:58:51AM +0200, Jos Vos wrote: > On Mon, Oct 06, 2003 at 10:53:46AM +0200, Axel Thimm wrote: > > > It is not about Fedora Core, where the affected packages are only a > > few, but for Fedora Lagacy projects, which will host the same package > > in different Legacy repos and will have to ensure upgradability. > > But still, why should the release be numbered 10 then, as this only > relates to the redhat-release (or whatever) package (and maybe a > few more)? See the "Fedora and Fedora Legacy package versioning schemes" thread. -- 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 Mon Oct 6 11:53:14 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 13:53:14 +0200 Subject: Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths) In-Reply-To: <16257.15932.939702.972542@uebn.uddeborg.se> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20031006093916.GM8013@puariko.nirvana> <16257.15932.939702.972542@uebn.uddeborg.se> Message-ID: <20031006115314.GX8013@puariko.nirvana> On Mon, Oct 06, 2003 at 12:04:44PM +0200, G?ran Uddeborg wrote: > Axel Thimm writes: > > c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" < > > "number" idiom. > > A little observation I haven't seen so far. (But I can have missed it > in the long thread, sorry if so.): > > It will matter that "rhnumber" < "number" only for systems from FC1 > and on. And those systems come rpm > 4.2. Systems with rpm < 4.1 > should never have to see the packages without rh. Well, not for "Fedora Legacy", which is about supporting systems before FC1 (and later FC1 also etc.). > So it ought to work out right in practice. It's still kludgy, though. -- 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 Mon Oct 6 11:59:47 2003 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 06 Oct 2003 13:59:47 +0200 Subject: Kind request: fix your packages In-Reply-To: <002401c38b8b$ef34b630$735eee0c@C515816A> References: <002401c38b8b$ef34b630$735eee0c@C515816A> Message-ID: <1065441586.12083.29.camel@ulysse.olympe.o2t> Le dim 05/10/2003 ? 23:59, Otto Haliburton a ?crit : > > On Sat, 2003-10-04 at 18:19, Sean Middleditch wrote: > > > On Sat, 2003-10-04 at 09:11, Nicolas Mailhot wrote: > > > > > > > Dear user, > > > > > > > > As we all know you're dumb and you can not learn to use a package > > > > manager ever. To ease your pain we've decided not to inflict you the > > > > so-called "dependency hell" and provide you an autonomous application. > > > > Just click on its auto-update menu and it will download everything you > > > > need, we swear it. > > > > > > *bzzt* It has *nothing* to do with users being "dumb." *nothing* It > > > > I think Nicolas forgot the irony tags. How gross, mailman seems to have eaten part of my first reply. Trying again : If I remember well the irony ponctuation mark died a quick death because people (of this time) were smart enough to perceive irony without using crutches. Though in our current unicode mail society, it may need to be reintroduced. Looks it would be more useful than klingon -- Nicolas Mailhot Practising unannounced irony since the last century -------------- 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 Oct 6 12:08:07 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Oct 2003 08:08:07 -0400 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <3F8135F2.6040606@togami.com> References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> <1065370776.14230.61.camel@binkley> <20031006015243.D12313@devserv.devel.redhat.com> <3F8135F2.6040606@togami.com> Message-ID: <1065442087.26554.13.camel@binkley> On Mon, 2003-10-06 at 05:29, Warren Togami wrote: > Bill Nottingham wrote: > >>Maybe this is still in the process of being decided upon, or maybe there's > >>a better place to discuss this? If either, please LMK. I am (as many of > >>you can probably attest to :) not very smart sometimes. > > > > > > Probably on the mirror discussion lists. > > > > There has been discussion there, but that list isn't open to the public. > It should be moved here to fedora-devel-list as this is important. > Any ugly flaw in the design we will have to live with forever. =( Stephen Smoogen posted an excellent layout to the mirrors-list - one that I think should be given some consideration. -sv From Axel.Thimm at physik.fu-berlin.de Mon Oct 6 12:17:14 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 14:17:14 +0200 Subject: Fedora and Fedora Legacy package versioning schemes In-Reply-To: <3F814CB6.2040904@togami.com> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20031006093916.GM8013@puariko.nirvana> <3F814CB6.2040904@togami.com> Message-ID: <20031006121714.GY8013@puariko.nirvana> On Mon, Oct 06, 2003 at 01:06:30AM -1000, Warren Togami wrote: > Axel Thimm wrote: > >Defining the problem domain for Fedora Legacy: > >============================================== > > > >a) We need a versioning scheme that ensures upgradability without > > obfuscating too much the VR scheme. > >b) It should be possible to use the same sources/patches/specfiles with > > macro controlled differences > >c) It should work with older rpm versions, e.g. don't let rpm compare > > numbers with letters. > > > > a + b are perfectly valid, but I see no reason to continue to support > the ugly behavior of c, and here's why: > > 1) jbj has long indicated that he wishes all distributions to use the > same upgraded version of rpm in order to simplify maintenance. > 2) Fedora Legacy is the time to FORCE everyone to upgrade RPM if they > wish to continue to use the repository. This means that we will be able > to avoid a lot of unpredictable behavior (#1) in older versions of rpm, > making Legacy distributions easier to support in the long term. > 3) RH 8.0 Psyche rpm *needs* to be upgraded anyway because the default > rpm is too broken to use. I partly agree, but imagine the first time initiation of a existing RH7.3 cluster of machines. The admin would have to manually update the rpm rpms and then point his up2date/yum/apt config to a "Fedora Legacy" repo. Red Hat has been very conservative to replace the rpms in RH8.0 (and RH7.3) and even when a QA rpm release is pushed into RHN, "Fedora Legacy" should work with non-updated systems, too (just like you have to build apt/yum/up2date against a non-updated system). > >a) Call _internally_ the next release ("Fedora [Core] 1") "RawHide 10" > > or "RawHide 9.1". It looks compatible with RH's policy and would > > allow for tags like "rh10" to complete the above scheme. > > -1 > Too confusing to have different numbers and names in different places. Yes, but even Windows users could cope with different maket and technical versions, and technically it is the cleanest solution. > >b) Drop upgradability withing Fedora Legacy from RHL to FC/FDR. > -999 I agree, but this is still a possible solution ;) > >c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" < > > "number" idiom. > -1 > > > > >d) Use tags with something larger than "rh", e.g. "tfp" ("The Fedora > > Project") > -500 > The whole reason why we had those dist tags was because fedora.us (or > freshrpms, or dag, or axel, etc.) were not official repositories. Now > Fedora is official, so I believe we can drop this ugliness that makes > the package filename unnecessarily longer. You are talking about the .fdr. tag, e.g. the repo tag. Drop that by all means. I am referring to the disttag like rh9 etc. > > X) Your suggestion here. > > > >It is important to have Red Hat's consent on any sollution, as well as > >a common versioning scheme across repositories of different > >maintainers to allow for properly formulating cross-repository > >dependencies and having easy identification by end users. > > > >Optional good-to-have semantics: > >================================ > >o Use the same versioning for Fedora. > > [...] > +1 > >o Use the same versioning for RawHide/Betas. > > [...] > +1 > I dislike your specific examples that contain "rh", but the numbers I > fully agree. Note that redhat/fedora packages are also distributed on larger mirrors containing Mandrake, suse etc. rpm. A lot of people get the wrong rpm. An identification string there is nice-to-have (but nothing more, the true problem lies not here and this should not distract). > Examples: > foobar-1.5-6.rc3_1.9.2 (Fedora Core 1.92 beta) > foobar-1.5-6.rc3_1 (Fedora Core 1) > foobar-1.5-6.rc3_0.9.4 (Fedora Core 0.94) > foobar-1.5-6.rc3_0.8 (RHL 8.0 Psyche) > foobar-1.5-6.rc3_0.7.3 (RHL 7.3) > > Note that I used "_" instead of "." in this particular example. Either > of them would work. The former would be a clearer seperator between the > %{distrel} and the rest of the tag, while the latter is slightly easier > to type. I personally don't care which one is used. Opinions? I am already using _ for that purpose, and will even ask Jeff in the future to give _ a higher seperating pririty than . (but that's another issue, don't want to get off-topic). I see another suggestion in your examples (which I didn't clearly read through the description): e) Prepend "0." to previous RH releases, e.g. 0.7.3 < 0.8.0 < 0.9 < 0.9.0.93 < ... < 1.0 I personally like that. so how about conaming "RHL X" to "Fedora Core 0.X" resulting to tags like foo-1.2.3-4_fdr0.7.3 (non-numeric upstream versions, kernel modules and other special cases aside)? -- 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 nutello at sweetness.com Mon Oct 6 13:57:20 2003 From: nutello at sweetness.com (Rudi Chiarito) Date: Mon, 6 Oct 2003 15:57:20 +0200 Subject: custom DHCP vendor class identifiers Message-ID: <20031006135720.GA2049@server4.8080.it> Hi. Browsing the kickstart list I found that I am not the only one who might have a use for specifying a custom DHCP vendor class identifier, which, in RFC 2131, is a "SHOULD" requirement for clients. Both dhcpd and dhcpcd already support it; what is missing is the little bit of infrastructure necessary to have dhcpcd (and anaconda's built-in pump client) easily configured to use it. https://listman.redhat.com/archives/kickstart-list/2003-June/msg00125.html Also hoping that the feature could make it for the next beta, I quickly created some patches for ifup, libpump.a and anaconda's kickstart. To be honest, not only I haven't tested them, I haven't even had the chance to compile them yet -- no access to my main system right now. I bet there are problems with the code as it is and I must have missed something, but I thought it could be worth starting to discuss whether or not the idea has merit. Somebody with more anaconda/pump experience might be able to quickly point out any flaws. I should be able to test the patches later today; in the meantime you can give them a look at http://uberh4x0r.org/~yax/dhcp_classid/ One shortcoming that I can see so far, if I understood the anaconda code correctly, is how to pick up the class ID while in rescue mode. In that case, though, you can still restart dhcpcd manually with the appropriate -i switch. The patches add a new "ksclass" boot loader option and a "--class" switch to kickstart's "network" option. Which reminds me I need to update the documentation as well. The use of the two new keywords is orthogonal; e.g. in some cluster setups you might want to use the former, but not the latter -- or viceversa. For the time being, no changes are applied to any user interfaces, as this is a feature that is hardly going to be needed by anyone but power users. I.e., if you require it, you are likely using kickstart installs already. I did not file a Bugzilla report because I wasn't sure which component it applies mainly to. I can create one -- or three, for each of the components -- if deemed more appropriate. Rudi From jjneely at pams.ncsu.edu Mon Oct 6 14:19:17 2003 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Mon, 6 Oct 2003 10:19:17 -0400 Subject: [Univ-linux] [Fwd: Re: Future unsupported Red Hat Linux systems] In-Reply-To: <3F816036.3010604@wanadoo.es> References: <3F816036.3010604@wanadoo.es> Message-ID: <20031006141917.GW26859@anduril.pams.ncsu.edu> Folks, I hate cross posting but since all this discussion is on all the mailing lists and I'm not...here I go :-) I'm mainly interested in Fedora Legacy. I'd rather work here that beta testing the latest and greatest from my friends across the street. I've agreed to work with / maintain OpenAFS and LPRng and I'll probably pick up others. I'm the Linux guy at NC State University in Raleigh, North Carolina. Red Hat is right across the street. I maintain a linux distribution based off of what was RHL and we are quite dependant on it...which should explain my interest in Legacy. Also, I really need at good 18 months of errata for each release I support. Other resources: ftp.linux.ncsu.edu will no doubt mirror Fedora. I mean, what else am I supposed to put there? :-) I am also working to get another machine set up that can mirror other stuff and/or be a public build server. All I need is a SCA -> 68 pin SCSI adaptor. Jack Neely > > It has always been in the plans, but along with Fedora Legacy it should > not be opened unless I see a strong commitment from a dozen+ developers > that will continue to work on security errata after RH's EOL. I > personally don't have the time nor interest in working on old software, > however I will support the build system and distribution of such a > project if the developers exist. > > Jesse Keating has indicated he wishes OEM companies and Universities to > unite and commit resources and clue to this effort, so I have asked him > to become the interim organizer for Legacy. Please help him find more > people who would be committed. It is important that there be enough > people to keep this self sustaining because I feel it would be > irresponsible to publish this repository if security updates are not > maintained. > > For now have them organize here on fedora-devel at fedora.us. If traffic > becomes large enough we can ask RH and create a new list perhaps at > fedora-legacy at redhat.com or something. > > Warren -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From nhruby at uga.edu Mon Oct 6 14:33:51 2003 From: nhruby at uga.edu (nathan r. hruby) Date: Mon, 6 Oct 2003 10:33:51 -0400 (EDT) Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <20031006015243.D12313@devserv.devel.redhat.com> References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> <1065370776.14230.61.camel@binkley> <20031006015243.D12313@devserv.devel.redhat.com> Message-ID: On Mon, 6 Oct 2003, Bill Nottingham wrote: > nathan r. hruby (nhruby at uga.edu) said: > > What's the new mirror structure going to look like? Current FC1 simply > > lives in redhat's linux/beta/ directory and the downloads.fedora.us site > > has a compltely different structure, but there's a lot of duplication > > which I don't currently have the disk space to cover. > > Not yet decided. > Ok, Thanks! > > Maybe this is still in the process of being decided upon, or maybe there's > > a better place to discuss this? If either, please LMK. I am (as many of > > you can probably attest to :) not very smart sometimes. > > Probably on the mirror discussion lists. > Which I'm not on because due to silly historical reasons we are not an offical Red Hat mirror - though we may be able to change that now, not sure... :) I just dropped a subscription note to the lsit anyway, maybe they;ll let me in os they can mkae fun og my poor ytping :) -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From Axel.Thimm at physik.fu-berlin.de Mon Oct 6 14:35:27 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 16:35:27 +0200 Subject: laptop_mode (was: rawhide report: 20031004 changes) In-Reply-To: <200310040948.h949mcg18824@porkchop.devel.redhat.com> References: <200310040948.h949mcg18824@porkchop.devel.redhat.com> Message-ID: <20031006143527.GB8013@puariko.nirvana> On Sat, Oct 04, 2003 at 05:48:38AM -0400, Build System wrote: > kernel-2.4.22-1.2086.nptl > * Fri Oct 03 2003 Dave Jones > > - Disable laptop_mode Why was the laptop_mode turned off? Is it causing trouble? Will it come back before cambridge? Thanks. -- 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 elanthis at awesomeplay.com Mon Oct 6 14:36:23 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 06 Oct 2003 10:36:23 -0400 Subject: Kind request: fix your packages In-Reply-To: <1065419260.12773.104.camel@localhost.localdomain> References: <1065419260.12773.104.camel@localhost.localdomain> Message-ID: <1065450983.28485.53.camel@support02.civic.twp.ypsilanti.mi.us> On Mon, 2003-10-06 at 01:47, Jef Spaleta wrote: > Sean Middleditch wrote: > > I tend to find them useful when explaining things, at least when talking > > to people who can think abstractly > > Then you need to do a better job of picking the illustrative educational > tool for the audience at hand. Continuing to use analogy, when several > people are having trouble following you, just shows you aren't really > interested in communicating with the people responding to you..you're > just here to poke fun at those with diminished mental capacity. So far > it seems you have not done so well getting people on this list to > understand your abstract explanations...if agreement is the measure you > use for understanding. I think you should consider using interpretive > dance from now when trying to deal in the abstract on this list. In response, there's been less than 3 people to have trouble. That doesn't sound like a majority of people in the least. The topic of people's language ability is about as far as we can get from RPM packaging tho, so its probably best to drop the topic. I'll *try* to avoid metaphors when I can manage to find a different expressive method. Like, say, interpretive dance. The list won't mind mpeg attachments, will it. ;-) > > > Good point. The difference is, a car comes with everything you expect a > > car to have. I don't buy a car without wheels and then go to add them. > > A computer, on the other hand, never comes with everything you want, > > Everything you WANT in a computer....and everything that is EXPECTED to > come with a computer are very different...and I'm amazed you mixed the > two concepts up. Are you honestly saying that cars and planes and boats Point. Rather stretching the analogy a bit beyond my intent, tho. A car with its basic components does everything a car does. A computer with its basic components doesn't do anything useful at all, except let you use software - which is the purpose of the OS. A car has everything needed to transport, a computer has everything to run software. If you went to Dell and bought a computer with no OS (somewhat equivalent to car without an engine), you'd rather expect to be an expert to fix that shortcoming, or hire an expert to fix it for you. Your average user doesn't do that, tho, she buys a computer with an OS (hopefully Fedora or a derivative ;-) pre-installed - just like her car is ready to drive, her computer is ready to run software. > and trains and dump trucks and dragsters..and whatever other complex > transportation machine you want to try to draw an analogy with, come > with everything that everyone could possibly want in such a machine. > What is EXPECTED to come with a computer and what people WANT to come > with a computer are different concepts. If you are going to continue to True enough. > use the analogy of cars and trucks that people buy...then the analogy > leads to the idea that computers that people are buying should be coming > equipped with the things most people want, and not the conclusion you > are trying to beat us over the head with, that adding functionality to > computers after the initial purchase should be end-user easy. If Sort of - you're drawing too much similarity between the purpose of the two tools. The computer/OS only exists to run applications. Just like your car doesn't come pre-installed with friends to drive around with, your computer may not have everything installed you expect to do *with* the computer. You have to get those in there yourself, first. If Fedora were to try to do that, the install set would be around 3,000 CDs and the Free Software only rule would need to be chucked out the window. > everyone who wanted cd players for their cars got them when they bought > their car..there would be no after market for cd players or other car > electronics. But yet there is, people buy these things for their cars > and want them installed, but few people actually install things like cd > players and electronic alarm systems themselves..and there is no real These are usually functionality upgrades, not addons. Upgrades should also be about as effortless as they are already, tho, so its not too much of problem. Except when ugprades break compatibility (which would be fixed by the same packaging/dev methods one would need for easy installation). > expectation that installing car electronics is end-user easy. Where DID > the expectation that installing new software is an end-user easy task? Generally from the "other OS" where the same users have been doing it for years. Maybe not an expectation you like them to have, but its one they do have. And its one they should have, imo - we try to make everything else easy, why religiously avoid software management. There's also again the problem that, unlike a car, a computer generally *can't* come with everything they want. A car is fairly simple in needs - engine, wheels, necessary interior components, a couple frills like media system, etc. A car generally does one thing, driving, and just tries to make that comfortable and safe. A computer is not a single purpose tool, but a multi-tool. It not only does web browsing, but also does office work, and gaming, and media creation, and communication, and personal information management, etc. And that's just some of the non-uber-geek things a computer can do. In some cases, an "OS" can ship with those (when the OS is bloated and over-stuffed with rarely used specialty software, like most Linux distros including Fedora are), but in other cases, it can't - usually because the necessary software wasn't in existence at the time of the OS release, or the software can't legally be part of the OS. If Neverwinter Nights was Free Software and out when RH9 was released, I wouldn't have been over at my friend's apartment last evening trying to get the thing installed, since RH would probably have shipped the 3 extra CDs it needs. (*that* software is a prime example of poor installation/packaging engineering...) In cases like the above, the user doesn't EXPECT the computer to have it, since it didn't exist when they got the computer. But they do WANT it. It can't come with the OS, so they have to install it afterwards. No amount of waiting for OS upgrades will fix that, either. There are tons of other end-user oriented software that is in the same boat - high-end music composition software, for example, media-gallery software, interactive encyclopedias, etc. Fedora would be insane to put the multi-gigabyte large packages in its repository, and expect to carry 8 different versions for each minor revision of the core OS, due to poor packaging habits and policies. > > If the goal that you want is to have a computer be as easy to "use" as > it is to "use" a car..well thats quite easy to accomplish. It would be > quite easy to create a computer that just ran like a car...by building a > computer that was not easily upgradable with new software unless it was > brought in to be serviced by an expert. Installing software is not using Again, the "expert" can be the upgrading utility. You're stretching the metaphor beyond sanity at this point, tho. The user isn't manually replacing files and hand-editing config files, they're just clicking update or install; i.e., saying, "hey installation/ugprade expert thingy, could you take care of putting this software in? thanks!" That utility has to actually be able to do that, tho, or its not much of an expert. It irritates me when I take something in for repair, and they end up having to ship it out to the "real" experts, and I have to wait 2 weeks for it to get back. Likewise, the user wants the "real" expert to be there already, and not need to wait - the installer needs to be able to do its job. Which means it needs help in the form of well made packages. > a computer. Installing a cd player in your car is not using your car. > But that's clearly not a solution to the problem you are prepared to > accept. Because really, you aren't interested in just something that is > easy to "use", you want something that is also easy to fix and to extend > with new functionality. Your basic analogy doesn't speak to the real Fix usually isn't that easy - if something breaks, the user generally needs help, usually with a service department or a geek friend. But then, "fixing" broken software is an indication that you've gone *against* what I'm arguing for by making broken packages and/or broken applications. The current case of trying to install one piece of software and it invalidating half the system due to some silly little dependency issue, which could've been corrected in a far less severe fashion (i.e., properly updating a soversion in a library), is what I want to avoid, not foster. But, in the event something *does* break, which is life, then expert repair will be needed, yes - that's completely outside the scope of this discussion, tho. When they want to install, say, some family tree software, which (back to the analogy you're obsessing over) is more the equivalent of putting a beagle with a bobbing head on the dashboard, there shouldn't be any complexity involved. Get it, put it in, use it, rejoice. > nature of the problem you want solved. So stop trying to be cute by > talking around the problem...talk about the problem instead. I've rather gone over the problem itself in this thread already. Most applications, and most libraries, have absolutely no reason to be different on each release of Fedora (or any distro, perhaps once some more standardization sets in, be it thru LSB or an unofficial RPM packaging policy). Core system stuff, the "engine" in the car, is another story - that's why we *have* OS upgrades, just like we buy new cars. The fluff on top, the little system-independent apps that just work on their own, don't need the same engineer-complexity that the core OS does. Dependencies stay compatible or become co-installable, and this will generally Just Work(tm) as is, save the (hopefully rare) exceptional packages. > > -jef"describing a computer as a tool box..and new software as a new > wrench you just throw in...is insulting to the subtle complexity of the > awe inspiring effort it takes to get the intricate layers of software > that builds up a computer system to pretend to work together. A wrench, > even if poorly made doesn't stand a good chance of interfering with how > the other tools in the toolbox work...no matter how cute the toolbox > analogy seems"spaleta And if my word processor interferes with my email client, one might (going back to analogy) assume I tossed in the wrench with an attached monkey. Apps are tools, the OS the toolbox itself; or perhaps the workshop. The OS exists to let me use the tools. If either the tools or the OS get in the way of each other, there is something inherently wrong in the design of one or the other. Either the OS is over-stepping its bounds (breaking the UNIX philosophy, by trying to be more than just the OS) or the app is poorly designed (trying to stick its fingers too deeply in the OS, versus just working on its own). In either case, something needs to be fixed at the design level; /sbin/rmmod wordprocessor or whatever other insanity would cause actual unavoidable interference. ;-) -- Sean Middleditch AwesomePlay Productions, Inc. From dawson at fnal.gov Mon Oct 6 14:43:33 2003 From: dawson at fnal.gov (Troy Dawson) Date: Mon, 06 Oct 2003 09:43:33 -0500 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <3F805483.5090404@wanadoo.es> References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> <1065370776.14230.61.camel@binkley> <3F805483.5090404@wanadoo.es> Message-ID: <3F817F95.8060001@fnal.gov> Xose Vazquez Perez wrote: > seth vidal wrote: > > >>People want a lot of things, they don't always get them. Right now I >>think that way you can help is not by demanding action and dates and >>names but by figuring out what packages you think you'll need errata for >>the most and maybe familiarizing yourself with how they are currently >>patched by red hat. > > > You are getting me wrong, I am not *demanding*. I am trying to get > information to separate real projects from smoke ;-) > > If I get free time I will help, sure. Ugg ... major cross-posting, I'll keep this short. For those that have it in their power, a fedora-legacy mailling list would be appreciated. When I look at the fedora-legacy web pages, that's all I see, FEDORA legacy, no redhat legacy. To me this is saying that they have no intentions of allowing the community to put RedHat legacy in there (such as RedHat 7.3, or RedHat 9). Is this true? If it isn't, (meaning the community can support old redhat releases at the fedora-legacy area) it would be nice if we started at least getting the framework setup for the older RedHat legacy stuff. This would allow us to start testing mirrors and such. As well as give people a place to communicate in a more central place. Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From davej at redhat.com Mon Oct 6 14:50:53 2003 From: davej at redhat.com (Dave Jones) Date: Mon, 6 Oct 2003 15:50:53 +0100 Subject: laptop_mode (was: rawhide report: 20031004 changes) In-Reply-To: <20031006143527.GB8013@puariko.nirvana> References: <200310040948.h949mcg18824@porkchop.devel.redhat.com> <20031006143527.GB8013@puariko.nirvana> Message-ID: <20031006145053.GB13124@redhat.com> On Mon, Oct 06, 2003 at 04:35:27PM +0200, Axel Thimm wrote: > On Sat, Oct 04, 2003 at 05:48:38AM -0400, Build System wrote: > > kernel-2.4.22-1.2086.nptl > > * Fri Oct 03 2003 Dave Jones > > > > - Disable laptop_mode > > Why was the laptop_mode turned off? Is it causing trouble? An experiment. There's been a number of reports of data corruption, (strangely all from users of Quantum Fireballs). The plan was to get the IDE code as close to mainline as possible for a while to try and shake this out. Then Al Viro noted that he sees something similar on mainline kernels. *sigh*. Though its unclear right now if its just coincidence that Al is also running a Fireball, and might be hitting a different bug to what everyone else is seeing. So far theres not been much feedback from the folks reporting the bug on whether removing the laptopmode/AAM patches have made a difference other than "looks good so far". If things go to plan, we'll either know that laptopmode isn't safe on Fireballs, and maybe blacklist it, or if the problem reoccurs with laptopmode removed, it's safe to go back in. > Will it come back before cambridge? Maybe. As of right now, it's not looking like it'll make it back in for test3, but hopefully it'll be back for GA. See bugzilla #101357 and #91932 for highlights.. Additionally, if anyone else has been seeing anything odd on Quantum hard disks, adding "Me too's" to these bugs would be good. Folks using fireballs without any issues whatsoever, I'd like to hear from too. (Send mail, instead of cluttering bugzilla though). Dave -- Dave Jones http://www.codemonkey.org.uk From hosting at j2solutions.net Mon Oct 6 14:48:27 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Mon, 6 Oct 2003 07:48:27 -0700 Subject: Fedora and Fedora Legacy package versioning schemes In-Reply-To: <20031006121714.GY8013@puariko.nirvana> References: <20030923231759.GI3397@pua.nirvana> <3F814CB6.2040904@togami.com> <20031006121714.GY8013@puariko.nirvana> Message-ID: <200310060748.27834.hosting@j2solutions.net> On Monday 06 October 2003 05:17, Axel Thimm uttered: > I personally like that. so how about conaming "RHL X" to "Fedora Core > 0.X" resulting to tags like foo-1.2.3-4_fdr0.7.3 (non-numeric upstream > versions, kernel modules and other special cases aside)? I think the "fdr" part should be removed all together. Packages are kept in different directory trees for the relative distro. If some poor user pulls a rpm from a FedoraCore/ directory and expects it to work on Mandrake, thats his problem, not ours. I've always disliked the text tags (rhl9, fdr, fr2, etc..) and I feel that they are indicitive of 3'rd party rpms. Fedora.us and Fedora Legacy are less 3'rd party and thus shouldn't suffer the headache of text tags. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (www.mondorescue.org) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From skvidal at phy.duke.edu Mon Oct 6 14:56:05 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Oct 2003 10:56:05 -0400 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <3F817F95.8060001@fnal.gov> References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> <1065370776.14230.61.camel@binkley> <3F805483.5090404@wanadoo.es> <3F817F95.8060001@fnal.gov> Message-ID: <1065452165.18004.35.camel@opus> > For those that have it in their power, a fedora-legacy mailling list would be > appreciated. > When I look at the fedora-legacy web pages, that's all I see, FEDORA legacy, > no redhat legacy. To me this is saying that they have no intentions of > allowing the community to put RedHat legacy in there (such as RedHat 7.3, or > RedHat 9). > Is this true? > If it isn't, (meaning the community can support old redhat releases at the > fedora-legacy area) it would be nice if we started at least getting the > framework setup for the older RedHat legacy stuff. This would allow us to > start testing mirrors and such. As well as give people a place to communicate > in a more central place. Since red hat might not be interested in supporting a fedora-legacy in any way, shape or form, I could host a list here at duke. We've already got the infrastructure for the various lists. If someone wants to be the list admin just let me know. Jesse? -sv From hosting at j2solutions.net Mon Oct 6 14:50:39 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Mon, 6 Oct 2003 07:50:39 -0700 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <3F817F95.8060001@fnal.gov> References: <3F7F8966.6020807@wanadoo.es> <3F805483.5090404@wanadoo.es> <3F817F95.8060001@fnal.gov> Message-ID: <200310060750.39570.hosting@j2solutions.net> On Monday 06 October 2003 07:43, Troy Dawson uttered: > When I look at the fedora-legacy web pages, that's all I see, FEDORA > legacy, no redhat legacy. To me this is saying that they have no > intentions of allowing the community to put RedHat legacy in there (such as > RedHat 7.3, or RedHat 9). > Is this true? No. I'm the current community leader of Fedora Legacy (nobody else was doing anything). My vision is to include older RH releases, mostly 7.3 and 9 as part of the Fedora Legacy project. > If it isn't, (meaning the community can support old redhat releases at the > fedora-legacy area) it would be nice if we started at least getting the > framework setup for the older RedHat legacy stuff. This would allow us to > start testing mirrors and such. As well as give people a place to > communicate in a more central place. We are. THere are some issues we have to clear though Red Hat before we start actually doing anything. We're in contact with them and should have some answers soon. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (www.mondorescue.org) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From warren at togami.com Mon Oct 6 15:27:24 2003 From: warren at togami.com (Warren Togami) Date: Mon, 06 Oct 2003 05:27:24 -1000 Subject: Spec file macro tricks In-Reply-To: <1065451649.1487.25.camel@proton.cygnusx-1.org> References: <1065422457.1487.8.camel@proton.cygnusx-1.org> <3F8129AF.9030902@togami.com> <1065449806.1487.19.camel@proton.cygnusx-1.org> <3F817BB2.9040501@nc.rr.com> <1065451649.1487.25.camel@proton.cygnusx-1.org> Message-ID: <3F8189DC.3080006@togami.com> Nathan G. Grennan wrote: > > What is more inherently flawed is putting the distribution version in > in the release in the first place. This wasn't my decision. In that case > I am just following the fedora.us guidelines. In theory I would agree with you, but in reality we had no better solution. We simply cannot have a situation with two binary packages with the exact same filename but compiled for different distributions (without resorting to epoch. =) Even if an automated package tool is bound to a specific repository, it would have no way of comparing EVR and doing an upgrade to the new distribution's package. We *need* a sane way of doing distrel tags within the package name, or add another field to the RPM database... which would introduce even more legacy problems. Warren From ms-nospam-0306 at arcor.de Mon Oct 6 15:51:07 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 6 Oct 2003 17:51:07 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006085052.GK8013@puariko.nirvana> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> Message-ID: <20031006175107.731c27d0.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 6 Oct 2003 10:50:52 +0200, Axel Thimm wrote: > On Wed, Oct 01, 2003 at 07:19:08PM +0200, Michael Schwendt wrote: > > A few observations: In your repository I don't see a consistent > > platform specific release tag scheme. > > check the dates and the discussion on fedora.us in March/April (yes, I > was once a fedora member). Been there before I joined the fedora-devel at fedora.us list. Going through list archives is a time-consuming process. I prefer summaries of ready-to-use concepts which can be commented on as a whole. Continueing Fedora Core with Red Hat Linux specific release numbers does not sound reasonable. It is like an implicit epoch. You don't answer why some of your packages have no distribution specific release tag at all and why other packages override versions found in Red Hat Linux. > The fact is that there still is no versioning scheme one can rely > upon. The scheme we discussed with fedora.us in March/April is now > broken. What had been the plans for RHL 9 => RHL 10? I don't remember, maybe rh90 => rh100 or anything like that? And why is the "rh" in front of the version? And why is it "rh90.93" instead of "9.0.93.rh"? It's too late to change a broken system and additionally make it play nicely with future changes. But Fedora Core's start at "1" is the chance for a change. I'm not that interested in learning about old broken versions of RPM and trying to make them fit into a general concept nevertheless. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gY9r0iMVcrivHFQRAtGSAJ9QUwPQbiYL81sPaOAhkF+UUxB5NwCeMFwP 1AqDxe01Lx+s8bROepR7zS8= =11q1 -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Mon Oct 6 15:58:40 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 6 Oct 2003 17:58:40 +0200 Subject: Kind request: fix your packages In-Reply-To: <1065429777.12083.9.camel@ulysse.olympe.o2t> References: <003f01c38a65$edbca8c0$735eee0c@C515816A> <1065273071.3207.67.camel@rousalka.dyndns.org> <1065284367.5142.38.camel@stargrazer.home.awesomeplay.com> <1065389108.11834.111.camel@wombat.tiptoe.de> <1065429777.12083.9.camel@ulysse.olympe.o2t> Message-ID: <20031006175840.010a4309.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 06 Oct 2003 10:42:57 +0200, Nicolas Mailhot wrote: > > > > As we all know you're dumb and you can not learn to use a package > > > > manager ever. To ease your pain we've decided not to inflict you the > > > > so-called "dependency hell" and provide you an autonomous application-- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list This posting looks as if you've been bitten by a bug in mailman, where it terminates postings at lines which contain a single dot character. It is as if it would treat it like the SMTP end of message body delimiter. In September, I've posted about this to mailman-developers list, but there hasn't been any response. The posting included additional observations on mailman escaping "From" at the beginning of a line with a ">" character. It should not do that either before redistributing messages to subscribers. It breaks the formatting (">" is the quote prefix) as well as GPG signatures. They have a bugzilla system, but writing good bug reports takes more time, and I hate spending time on bug reports when developers are too lazy to comment briefly on a mail. Maybe someone with insight reads this and posts a followup to my message on the mailman-developers list. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gZEw0iMVcrivHFQRAipMAJ9TP3+kYRldqr5pD9sSGMiTEkNW6ACcCejW LWfy3K+jNMfhJILSZDSHNmA= =IARv -----END PGP SIGNATURE----- From chuckw at quantumlinux.com Mon Oct 6 16:43:46 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 6 Oct 2003 09:43:46 -0700 (PDT) Subject: [rh-consortium] Re: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <1065452165.18004.35.camel@opus> Message-ID: > Since red hat might not be interested in supporting a fedora-legacy in > any way, shape or form, I could host a list here at duke. Ach! This crossposting is getting crazy. We've already got a list with 33 subscribers for rh-consortium. I'm more than happy to shut it down if there's a concerted effort elsewhere. The last thing we need here is a fracturing of the pool of talent. Let's get *something* going so we can make some headway here. > We've already got the infrastructure for the various lists. If someone > wants to be the list admin just let me know. Jesse? I'll do it if no one else volunteers. -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 notting at redhat.com Mon Oct 6 16:55:09 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Oct 2003 12:55:09 -0400 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <3F8135F2.6040606@togami.com>; from warren@togami.com on Sun, Oct 05, 2003 at 11:29:22PM -1000 References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> <1065370776.14230.61.camel@binkley> <20031006015243.D12313@devserv.devel.redhat.com> <3F8135F2.6040606@togami.com> Message-ID: <20031006125509.A17268@devserv.devel.redhat.com> Warren Togami (warren at togami.com) said: > Bill Nottingham wrote: > >>Maybe this is still in the process of being decided upon, or maybe there's > >>a better place to discuss this? If either, please LMK. I am (as many of > >>you can probably attest to :) not very smart sometimes. > > > > Probably on the mirror discussion lists. > > There has been discussion there, but that list isn't open to the public. > It should be moved here to fedora-devel-list as this is important. > Any ugly flaw in the design we will have to live with forever. =( Perhaps. My thinking was that the main places where a bad design hurts *is* at the mirror level, so that's the natural people to get involved. Bill From hosting at j2solutions.net Mon Oct 6 17:00:08 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Mon, 6 Oct 2003 10:00:08 -0700 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <1065452165.18004.35.camel@opus> References: <3F7F8966.6020807@wanadoo.es> <3F817F95.8060001@fnal.gov> <1065452165.18004.35.camel@opus> Message-ID: <200310061000.08637.hosting@j2solutions.net> On Monday 06 October 2003 07:56, seth vidal wrote: > Since red hat might not be interested in supporting a fedora-legacy > in any way, shape or form, I could host a list here at duke. > > We've already got the infrastructure for the various lists. If > someone wants to be the list admin just let me know. Jesse? We're waiting to see if RH wants us to host it on their server or not. At this point I'm thinking no, Warren, any input? Seriously until we get some feedback from RH as to what all we can do and how much we can integrate into the Fedora project, there is little to discuss w/out risk of having the whole discussion rendered null and void when things are finally made clear. But... -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From esr at snark.thyrsus.com Mon Oct 6 17:16:13 2003 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Mon, 6 Oct 2003 13:16:13 -0400 Subject: Does the freeworld repository exist yet? Message-ID: <200310061716.h96HGDm8004032@snark.thyrsus.com> Does the freeworld repository exist yet? If so, where is it? -- Eric S. Raymond Our society won't be truly free until "None of the Above" is always an option. From skvidal at phy.duke.edu Mon Oct 6 17:32:53 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Oct 2003 13:32:53 -0400 Subject: Does the freeworld repository exist yet? In-Reply-To: <200310061716.h96HGDm8004032@snark.thyrsus.com> References: <200310061716.h96HGDm8004032@snark.thyrsus.com> Message-ID: <1065461573.18004.56.camel@opus> On Mon, 2003-10-06 at 13:16, Eric S. Raymond wrote: > Does the freeworld repository exist yet? If so, where is it? rpm.livna.org this is in the archives. -sv From esr at thyrsus.com Mon Oct 6 17:52:30 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 6 Oct 2003 13:52:30 -0400 Subject: Does the freeworld repository exist yet? In-Reply-To: <1065461573.18004.56.camel@opus> References: <200310061716.h96HGDm8004032@snark.thyrsus.com> <1065461573.18004.56.camel@opus> Message-ID: <20031006175230.GB4203@thyrsus.com> seth vidal : > On Mon, 2003-10-06 at 13:16, Eric S. Raymond wrote: > > Does the freeworld repository exist yet? If so, where is it? > > rpm.livna.org > > this is in the archives. Googling for "Fedora freeworld" didn't find it. Maybe the Fedora web page should include a pointer? -- Eric S. Raymond From skvidal at phy.duke.edu Mon Oct 6 17:54:17 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Oct 2003 13:54:17 -0400 Subject: Does the freeworld repository exist yet? In-Reply-To: <20031006175230.GB4203@thyrsus.com> References: <200310061716.h96HGDm8004032@snark.thyrsus.com> <1065461573.18004.56.camel@opus> <20031006175230.GB4203@thyrsus.com> Message-ID: <1065462857.18006.60.camel@opus> On Mon, 2003-10-06 at 13:52, Eric S. Raymond wrote: > seth vidal : > > On Mon, 2003-10-06 at 13:16, Eric S. Raymond wrote: > > > Does the freeworld repository exist yet? If so, where is it? > > > > rpm.livna.org > > > > this is in the archives. > > Googling for "Fedora freeworld" didn't find it. Maybe the Fedora web > page should include a pointer? They are not allowed to. Linking to places that have DMCA-violating code has been shown to violate the dmca. -sv From esr at thyrsus.com Mon Oct 6 18:01:35 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 6 Oct 2003 14:01:35 -0400 Subject: Does the freeworld repository exist yet? In-Reply-To: <1065462857.18006.60.camel@opus> References: <200310061716.h96HGDm8004032@snark.thyrsus.com> <1065461573.18004.56.camel@opus> <20031006175230.GB4203@thyrsus.com> <1065462857.18006.60.camel@opus> Message-ID: <20031006180135.GA4553@thyrsus.com> seth vidal : > > Googling for "Fedora freeworld" didn't find it. Maybe the Fedora web > > page should include a pointer? > > They are not allowed to. > > Linking to places that have DMCA-violating code has been shown to > violate the dmca. Then there should be a big, bold notice that says "Due to the DMCA, we cannot provide a link to the freeworld repository. You might be able to find it with the following Web search: xxxx xxxx xxxx." -- Eric S. Raymond From skvidal at phy.duke.edu Mon Oct 6 18:03:53 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Oct 2003 14:03:53 -0400 Subject: Does the freeworld repository exist yet? In-Reply-To: <20031006180135.GA4553@thyrsus.com> References: <200310061716.h96HGDm8004032@snark.thyrsus.com> <1065461573.18004.56.camel@opus> <20031006175230.GB4203@thyrsus.com> <1065462857.18006.60.camel@opus> <20031006180135.GA4553@thyrsus.com> Message-ID: <1065463433.18006.62.camel@opus> On Mon, 2003-10-06 at 14:01, Eric S. Raymond wrote: > seth vidal : > > > Googling for "Fedora freeworld" didn't find it. Maybe the Fedora web > > > page should include a pointer? > > > > They are not allowed to. > > > > Linking to places that have DMCA-violating code has been shown to > > violate the dmca. > > Then there should be a big, bold notice that says "Due to the DMCA, we > cannot provide a link to the freeworld repository. You might be > able to find it with the following Web search: xxxx xxxx xxxx." I do not believe red hat (where fedora.redhat.com) is hosted wants to take on this liability currently. -sv From smoogen at lanl.gov Mon Oct 6 18:08:09 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 06 Oct 2003 12:08:09 -0600 Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <1065442087.26554.13.camel@binkley> References: <3F7F8966.6020807@wanadoo.es> <1065326528.14230.56.camel@binkley> <3F803BFF.9080700@wanadoo.es> <1065370776.14230.61.camel@binkley> <20031006015243.D12313@devserv.devel.redhat.com> <3F8135F2.6040606@togami.com> <1065442087.26554.13.camel@binkley> Message-ID: <1065463688.7694.21.camel@smoogen1.lanl.gov> On Mon, 2003-10-06 at 06:08, seth vidal wrote: > On Mon, 2003-10-06 at 05:29, Warren Togami wrote: > > Bill Nottingham wrote: > > >>Maybe this is still in the process of being decided upon, or maybe there's > > >>a better place to discuss this? If either, please LMK. I am (as many of > > >>you can probably attest to :) not very smart sometimes. > > > > > > > > > Probably on the mirror discussion lists. > > > > > > > There has been discussion there, but that list isn't open to the public. > > It should be moved here to fedora-devel-list as this is important. > > Any ugly flaw in the design we will have to live with forever. =( > > Stephen Smoogen posted an excellent layout to the mirrors-list - one > that I think should be given some consideration. > Well a lot of the 'ugly flaws' from Red Hat FTP site version 3.0 were caused by me anyway. I should try to correct it. There are 2 things that I would like to get comments on... when I did the first redesign, apt-rpm,yum, autoupdate and such were either in infancy or non-existant. How would redesign help/hurt them. Putting in hooks for those should be easier now. -- 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 alan at redhat.com Mon Oct 6 18:10:35 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Oct 2003 14:10:35 -0400 (EDT) Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <200310061000.08637.hosting@j2solutions.net> from "Jesse Keating" at Hyd 06, 2003 10:00:08 Message-ID: <200310061810.h96IAZm29588@devserv.devel.redhat.com> The big disconnect here I suspect is that we thought about Fedora Legacy as "old Fedora" stuff. That meant it didn't appear on the "immediate infrastucture radar". Obviously "legacy hat" or whatever has a clear December kick off requirement From Axel.Thimm at physik.fu-berlin.de Mon Oct 6 18:47:48 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 20:47:48 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006175107.731c27d0.ms-nospam-0306@arcor.de> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006175107.731c27d0.ms-nospam-0306@arcor.de> Message-ID: <20031006184748.GB6175@puariko.nirvana> On Mon, Oct 06, 2003 at 05:51:07PM +0200, Michael Schwendt wrote: > On Mon, 6 Oct 2003 10:50:52 +0200, Axel Thimm wrote: > > On Wed, Oct 01, 2003 at 07:19:08PM +0200, Michael Schwendt wrote: > > > A few observations: In your repository I don't see a consistent > > > platform specific release tag scheme. > > > > check the dates and the discussion on fedora.us in March/April (yes, I > > was once a fedora member). > > Been there before I joined the fedora-devel at fedora.us list. Going > through list archives is a time-consuming process. I prefer > summaries of ready-to-use concepts which can be commented on as a > whole. > You don't answer why some of your packages have no distribution specific > release tag at all and why other packages override versions found in Red > Hat Linux. What I wanted to say is that the versioning scheme evolved, partly on its own, partly in discussion within (the old) fedora. So when you find inconsistency in the repo you are seeing at different layers of history. (I am hesitating to rebuild packages simply for re-versioning them to avoid bandwidth consumption at end users, especially while the versioning scheme was/is still at flux). > Continueing Fedora Core with Red Hat Linux specific release numbers > does not sound reasonable. It is like an implicit epoch. OTOH you are right, but if the packages from the Fedora Project are to be related to Red Hat Linux ones (e.g. you want them to be rpm-newer), you need to come up with a compatible scheme. Did you check Warren's proposal on doing the reverse? E.g. instead of continuing RHL versioning into Fedora, one can back-continue Fedora guidelines to the past, e.g. treat RHL8.0 as Fedora Core 0.8.0. > > The fact is that there still is no versioning scheme one can rely > > upon. The scheme we discussed with fedora.us in March/April is now > > broken. > > What had been the plans for RHL 9 => RHL 10? On fedora.us? I think the final consent was to "wait 'til it comes, it's always different than you planned". It turns out to be more than right. But that has to be fixed now, otherwise we will be having the same problems with "Fedora New Core XP2004" ... ;) > I don't remember, maybe rh90 => rh100 or anything like that? And why > is the "rh" in front of the version? And why is it "rh90.93" instead > of "9.0.93.rh"? It's too late to change a broken system and > additionally make it play nicely with future changes. But Fedora > Core's start at "1" is the chance for a change. I'm not that > interested in learning about old broken versions of RPM and trying > to make them fit into a general concept nevertheless. That's why I changed the Subject on the main thread to contain "Fedora Legacy". If one doesn't care about past releases, you don't see the problem. -- 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 Mon Oct 6 18:51:28 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 6 Oct 2003 20:51:28 +0200 Subject: Fedora and Fedora Legacy package versioning schemes In-Reply-To: <20031006121714.GY8013@puariko.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20031006093916.GM8013@puariko.nirvana> <3F814CB6.2040904@togami.com> <20031006121714.GY8013@puariko.nirvana> Message-ID: <20031006205128.15ac0e94.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 6 Oct 2003 14:17:14 +0200, Axel Thimm wrote: > > > d) Use tags with something larger than "rh", e.g. "tfp" ("The Fedora > > > Project") > > > > -500 > > The whole reason why we had those dist tags was because fedora.us (or > > freshrpms, or dag, or axel, etc.) were not official repositories. Now > > Fedora is official, so I believe we can drop this ugliness that makes > > the package filename unnecessarily longer. > > You are talking about the .fdr. tag, e.g. the repo tag. Drop that by > all means. I am referring to the disttag like rh9 etc. Fedora.us was separate from Red Hat [Linux]. And fedora.us could have offered packages for Mandrake Linux (.mdk), for instance. Hence the distribution tag to emphasize the target platform. The .fdr tag and the 0. release prefix should be adapted by 3rd party repositories. (http://fedora.redhat.com/participate/terminology.html) - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gbmw0iMVcrivHFQRAvcBAJ9syQ4dXmxt4LBRdqNBQj+6EWFIiQCfS3H7 M/oJNgFCaMEv0vXWIa2bq/E= =YHa1 -----END PGP SIGNATURE----- From jspaleta at princeton.edu Mon Oct 6 19:26:33 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 06 Oct 2003 15:26:33 -0400 Subject: [Univ-linux] Future unsupported Red Hat Linux systems Message-ID: <1065468393.27102.108.camel@spatula> Alan Coxv wrote: > The big disconnect here I suspect is that we thought about Fedora Legacy > as "old Fedora" stuff. That meant it didn't appear on the "immediate > infrastucture radar". Obviously "legacy hat" or whatever has a clear > December kick off requirement Well, if there was a clear understanding that Fedora, was meant to be a clean break with what rhl was with no expectation for an upgrade path from previous rhl releases to fedora core, then this sort of split in legacy as well would be reasonable to assume. But if Fedora is meant to be an evolutionary outgrowth of what RHL was and not a clean start, then the legacy issues surrounding pre-fedora rhl releases, falls into the same evolutionary framework i think to some extent. And if that isn't enough of a reason to reconsider the timetable...think of the rhl EOL coming up as an opportunity to work through some community process issues before Fedora Core needs them. I think its hard to get around the fact that the same people who will be interested in making Fedora Legacy a workable solution for Fedora Core releases as they expire, also want to see legacy support for rhl 7.3 and rhl 9, and if they have to build up a completely separate process for the "legacy hat" there will be far less interest in duplicating that community building effort again from scratch under Fedora Legacy. Whatever gets created for the upcoming December deadline, needs to be created with a clear understanding that its part of of an evolutionary change, or its created as part of a clean separation of church and state. -jef"however it works out...the trademark issues surrounding post EOL community support of rhl7.3/9 are not going to make anyone happy"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 Nicolas.Mailhot at laPoste.net Mon Oct 6 19:45:36 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 06 Oct 2003 21:45:36 +0200 Subject: Fedora and Fedora Legacy package versioning schemes In-Reply-To: <20031006205128.15ac0e94.ms-nospam-0306@arcor.de> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20031006093916.GM8013@puariko.nirvana> <3F814CB6.2040904@togami.com> <20031006121714.GY8013@puariko.nirvana> <20031006205128.15ac0e94.ms-nospam-0306@arcor.de> Message-ID: <1065469536.3193.9.camel@rousalka.dyndns.org> Le lun 06/10/2003 ? 20:51, Michael Schwendt a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 6 Oct 2003 14:17:14 +0200, Axel Thimm wrote: > > > > > d) Use tags with something larger than "rh", e.g. "tfp" ("The Fedora > > > > Project") > > > > > > -500 > > > The whole reason why we had those dist tags was because fedora.us (or > > > freshrpms, or dag, or axel, etc.) were not official repositories. Now > > > Fedora is official, so I believe we can drop this ugliness that makes > > > the package filename unnecessarily longer. > > > > You are talking about the .fdr. tag, e.g. the repo tag. Drop that by > > all means. I am referring to the disttag like rh9 etc. > > Fedora.us was separate from Red Hat [Linux]. And fedora.us could have > offered packages for Mandrake Linux (.mdk), for instance. Hence the > distribution tag to emphasize the target platform. Well, we've been happily providing mandrake and redhat java packages without any distributions tags for months at jpackage. People just put their distro-specific repository entries into apt and never ever see other packages. Same for ximian (of course for jpackage it helps 90% of the packages are noarch and have no overlap with whatever is already in the distributions, but anyway we've never needed any special flags to differenciate distro-specific packages). And BTW I'm deeply sceptical about Fedora getting mandrake acceptance short term. urpmi means the mdk communities had an head start, and we're only now catching up with apt/yum. RedHat is pretty late in the community game. 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 Mon Oct 6 19:50:49 2003 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 6 Oct 2003 15:50:49 -0400 (EDT) Subject: Kind request: Set release version to "10" In-Reply-To: <20031006085052.GK8013@puariko.nirvana> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> Message-ID: On Mon, 6 Oct 2003, Axel Thimm wrote: >On Wed, Oct 01, 2003 at 07:19:08PM +0200, Michael Schwendt wrote: >> A few observations: In your repository I don't see a consistent >> platform specific release tag scheme. > >check the dates and the discussion on fedora.us in March/April (yes, I >was once a fedora member). > >The fact is that there still is no versioning scheme one can rely >upon. The scheme we discussed with fedora.us in March/April is now >broken. > >The main issue is, that RH need to come up with a consistent scheme >(not only for fedora but also including fedora legacy), or bless an >existing one. > >Currently there is no schem that will work: >o either the upgrade paths are broken, e.g. rh9 -> fc1/fdr1 >o or rpm bugs are triggered, e.g. rhXX -> numbers >o Red Hat policy is violated, e.g. rh9 -> rh10 > >I understand RH's marketing and company policy, I won't join the "free >beer" group, but I would like the policy to not spoil technical >issues. This has to do with marketing. However, to stay in tune with the actual problem you're having.... Reading the thread, it is aparent to me that many people who read it and responded, did not completely listen to the problem which you are describing. Numerous people completely misunderstood what you are trying to say, or purposefully chose to not read everything and attempt to understand it. I read your emails fairly carefully however and believe I understand you correctly. Without renaming or reversioning the distribution (which is just straight plain and simple not going to happen period for any reason short of an Act of God(TM)), there is another extremely simple solution. Simply add an additional digit in front of the normal modifier you use to indicate your special packages. For example: RHL 8.0: foo-1.2.3-3.rh80 RHL 9 : foo-1.2.3-3.rh90 FC 1 : foo-1.2.3-3.1fc1 or foo-1.2.3-3.0fc1 or foo-1.2.3-3.1.fc1 Using this scheme, all of the packages with fc1 in their names are considered newer by RPM than the RHL 9 or 8.0 packages above them. No Epoch specifier is needed, no reason that the distribution naming/versioning scheme we've chosen to go with will break your packages. It may require some getting used to, but the problem is trivially solveable by you for your package repositories, and by others with their package repositories. The reason this works, is because when rpm goes to compare 2 packages to see which is newer, it compares based on name + epoch + version + release. The version and release fields are compared like this (this is fairly oversimplified): It breaks the release field into multiple parts on field boundaries. A field boundary occurs when the next character transitions from alpha to numeric or numeric to alpha, or by an optional "." or "_" delimiter character[1]. Numerals are considered higher than alphabetic characters in a given field number. So taking the 3 examples above and splitting them up into fields and comparing them, we have: Release Field1 Field2 Field3 Field4 3.rh80 3 rh 80 N/A 3.rh90 3 rh 90 N/A 3.0fc1 3 0 fc 1 3.1fc1 3 1 fc 1 3.1.fc1 3 1 fc 1 Field 1 matches for all of them so comparison proceeds to field 2, in which case 1 is newer than 0, which is newer than "rh", so the fc1 packages are all newer than both the rh80 and rh90 packages. Problem solved. Hope this helps. TTYL [1] There may be other delimiters I'm forgetting also, but I'm not trying to be 100% complete here to what the rpm source code handles, just trying to give a fairly terse example. In general, it is best to stick to using only numeric and alphabetic characters and ".". When in doubt, consult RPM documentation, and source code for the complete gory details if one requires more advanced knowledge than my terse description provides. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Mon Oct 6 19:53:40 2003 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 6 Oct 2003 15:53:40 -0400 (EDT) Subject: Kind request: Set release version to "10" In-Reply-To: References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> Message-ID: On Mon, 6 Oct 2003, Mike A. Harris wrote: >>I understand RH's marketing and company policy, I won't join the "free >>beer" group, but I would like the policy to not spoil technical >>issues. > >This has to do with marketing. ^ "nothing" Oops, I left that word out. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From ms-nospam-0306 at arcor.de Mon Oct 6 19:54:23 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 6 Oct 2003 21:54:23 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006184748.GB6175@puariko.nirvana> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006175107.731c27d0.ms-nospam-0306@arcor.de> <20031006184748.GB6175@puariko.nirvana> Message-ID: <20031006215423.60e087fd.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 6 Oct 2003 20:47:48 +0200, Axel Thimm wrote: > > > > A few observations: In your repository I don't see a consistent > > > > platform specific release tag scheme. > > > > > > check the dates and the discussion on fedora.us in March/April (yes, I > > > was once a fedora member). > > > > Been there before I joined the fedora-devel at fedora.us list. Going > > through list archives is a time-consuming process. I prefer > > summaries of ready-to-use concepts which can be commented on as a > > whole. > > You don't answer why some of your packages have no distribution specific > > release tag at all and why other packages override versions found in Red > > Hat Linux. > > What I wanted to say is that the versioning scheme evolved, partly on > its own, partly in discussion within (the old) fedora. So when you > find inconsistency in the repo you are seeing at different layers of > history. I fail to see that. Here's one of the packages for Shrike, which was touched long after the disttag discussions: mplayer-0.90-18.athlon.rpm http://atrpms.physik.fu-berlin.de/dist/rh9/mplayer/mplayer-0.90-18.athlon.rpm?info Or this one from July (0.9 = Shrike?): perl-DateManip-5.42-0.9.noarch.rpm http://atrpms.physik.fu-berlin.de/dist/rh9/perl-DateManip/perl-DateManip-5.42-0.9.noarch.rpm?info Another one for Shrike, from the same period of time, but has a disttag: libapt-pkg-devel-0.5.5cnc6-34.rh9.at.i386.rpm http://atrpms.physik.fu-berlin.de/dist/rh9/apt/libapt-pkg-devel-0.5.5cnc6-34.rh9.at.i386.rpm?info So much about consistency. There are more examples like that. Back to the topic. > > Continueing Fedora Core with Red Hat Linux specific release numbers > > does not sound reasonable. It is like an implicit epoch. > > OTOH you are right, but if the packages from the Fedora Project are to > be related to Red Hat Linux ones (e.g. you want them to be rpm-newer), > you need to come up with a compatible scheme. Packages in Fedora Core 1 will be newer than any packages in Red Hat Linux. Only a few cases (e.g. comps, maybe comps-extras, redhat-release => fedora-release) need special treatment (probably an increased epoch). I understand that Red Hat have never supported an upgrade path from installations other than Red Hat Linux. The Fedora Project is a new thing. It doubt it changes history by treating old 3rd party repositories for Red Hat Linux as if they had been official Fedora Extras/Alternatives/Legacy repositories before. In other words, they are unsupported. Starting with Fedora Core 1 you may need to implement a compatible versioning scheme, i.e. bump the release versions or vepochs (if any) of all your old packages before you put them into your Fedora add-ons repository. As I've pointed out before, some of your package versions conflict with Red Hat Linux anyway (e.g. bash, perl-DateManip, mozilla). > Did you check Warren's proposal on doing the reverse? E.g. instead of > continuing RHL versioning into Fedora, one can back-continue Fedora > guidelines to the past, e.g. treat RHL8.0 as Fedora Core 0.8.0. Yes, sounds good. It's not the first time a "0." prefix is useful. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gchv0iMVcrivHFQRAslfAJ9Ot/0Jrg+idu3H9V6aAgfDaglXmgCeOTC1 Ar1JDanpiVcP03zzeURtaVc= =TlhL -----END PGP SIGNATURE----- From Axel.Thimm at physik.fu-berlin.de Mon Oct 6 20:50:40 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 22:50:40 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> Message-ID: <20031006205040.GC6175@puariko.nirvana> On Mon, Oct 06, 2003 at 03:50:49PM -0400, Mike A. Harris wrote: > On Mon, 6 Oct 2003, Axel Thimm wrote: > > The fact is that there still is no versioning scheme one can rely > > upon. The scheme we discussed with fedora.us in March/April is now > > broken. > > > > The main issue is, that RH need to come up with a consistent > > scheme (not only for fedora but also including fedora legacy), or > > bless an existing one. > > > > Currently there is no schem that will work: > > o either the upgrade paths are broken, e.g. rh9 -> fc1/fdr1 > > o or rpm bugs are triggered, e.g. rhXX -> numbers > > o Red Hat policy is violated, e.g. rh9 -> rh10 > Reading the thread, it is aparent to me that many people who read it > and responded, did not completely listen to the problem which you > are describing. Numerous people completely misunderstood what you > are trying to say, or purposefully chose to not read everything and > attempt to understand it. I read your emails fairly carefully > however and believe I understand you correctly. > Without renaming or reversioning the distribution (which is just > straight plain and simple not going to happen period for any reason > short of an Act of God(TM)), there is another extremely simple > solution. Simply add an additional digit in front of the normal > modifier you use to indicate your special packages. > > For example: > > RHL 8.0: foo-1.2.3-3.rh80 > RHL 9 : foo-1.2.3-3.rh90 > FC 1 : foo-1.2.3-3.1fc1 or foo-1.2.3-3.0fc1 or > foo-1.2.3-3.1.fc1 This breaks with all rpm versions shipped until the beginning of this year (including RH8.0). On rpm-list we rediscussed in January the rpm non-symmetric bug (or letter-number toggling bug) that invalidated ordering of segments of different types. While there do exist backported rpm versions with this bug fixed on rpm.org, they have not been approved to enter RH errata, yet, and a Legacy project needs to take into account non-updated setups. Therefore this solution, as well as dropping the letters completely (which would have worked with the same semantics) is flawed for a Legacy project (See also the renamed "Fedora and Fedora Legacy package versioning schemes", where this is discussed in more detail.) Thanks for the suggestion, though, and for taking your time to go through it. As you noticed, only few do. Currently I think the best way would be for RH to allow to tag the old releases with tags like 0.7.3, 0.8.0, 0.9 to make the versioning ordered again. > Using this scheme, all of the packages with fc1 in their names > are considered newer by RPM than the RHL 9 or 8.0 packages above > them. No Epoch specifier is needed, no reason that the > distribution naming/versioning scheme we've chosen to go with > will break your packages. It may require some getting used to, > but the problem is trivially solveable by you for your package > repositories, and by others with their package repositories. > > The reason this works, is because when rpm goes to compare 2 > packages to see which is newer, it compares based on name + epoch > + version + release. The version and release fields are compared > like this (this is fairly oversimplified): > > It breaks the release field into multiple parts on field > boundaries. A field boundary occurs when the next character > transitions from alpha to numeric or numeric to alpha, or by an > optional "." or "_" delimiter character[1]. Numerals are > considered higher than alphabetic characters in a given field > number. > > So taking the 3 examples above and splitting them up into fields > and comparing them, we have: > > Release Field1 Field2 Field3 Field4 > 3.rh80 3 rh 80 N/A > 3.rh90 3 rh 90 N/A > 3.0fc1 3 0 fc 1 > 3.1fc1 3 1 fc 1 > 3.1.fc1 3 1 fc 1 > > Field 1 matches for all of them so comparison proceeds to field > 2, in which case 1 is newer than 0, which is newer than "rh", so > the fc1 packages are all newer than both the rh80 and rh90 > packages. > > Problem solved. > > Hope this helps. > TTYL > > > [1] There may be other delimiters I'm forgetting also, but I'm > not trying to be 100% complete here to what the rpm source code > handles, just trying to give a fairly terse example. In general, > it is best to stick to using only numeric and alphabetic > characters and ".". When in doubt, consult RPM documentation, > and source code for the complete gory details if one requires > more advanced knowledge than my terse description provides. > -- 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 Mon Oct 6 21:02:54 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 6 Oct 2003 23:02:54 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> Message-ID: <20031006230254.5b97aac6.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 6 Oct 2003 15:50:49 -0400 (EDT), Mike A. Harris wrote: > Reading the thread, it is aparent to me that many people who read > it and responded, did not completely listen to the problem which > you are describing. Numerous people completely misunderstood > what you are trying to say, or purposefully chose to not read > everything and attempt to understand it. I read your emails > fairly carefully however and believe I understand you correctly. Interesting observation. But the solution you've come up is one that has been covered before. It's used by fedora.us, and Axel calls it a "kludge". rh73 < rh80 < rh90 < 0.94 < 1 rh73 < rh80 < rh90 < 1 Whether you add something after the 0.94 (or 1), doesn't matter. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gdh90iMVcrivHFQRAvAPAJ9ljJWoDP3nfnVyWT0fmKmyVshyTACfXD5K 4s4nJsBqx0GmMfQuwGlfDrc= =+s96 -----END PGP SIGNATURE----- From mharris at redhat.com Mon Oct 6 21:06:21 2003 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 6 Oct 2003 17:06:21 -0400 (EDT) Subject: Kind request: fix your packages In-Reply-To: <1065410054.12773.27.camel@localhost.localdomain> References: <1065410054.12773.27.camel@localhost.localdomain> Message-ID: On Sun, 5 Oct 2003, Jef Spaleta wrote: >Isn't my little store bought cable modem/router with a webinterface a >computer? Yes. >I use it all the time without actually downloading and >installing any sort of software on it. I think your definition >of "use" and "user" is overly broad and is itself a sort of >misplaced analogy. Hrm.. I'd have to disagree with you there.. My router "appliance" is a Linksys WRT54g wireless 802.11g router. Under the hood (much to my unsuspecting surprise when I found out) was a MIPS compatible CPU running Linux kernel 2.4.5, and a minimalish userland running out of cramfs with flash. I've used the hacking instructions found at the following URL to "enhance" it: http://www.seattlewireless.net/index.cgi/LinksysWrt54g Using the information on that page, along with some homebrew hacks spawned from the ideas contained there, I, as a "user" of that product, have updated the DHCP server to be more useable, enhanced the firewall to be more useful, and made numerous other tweaks, such as installing an ssh server to allow me to ssh to the thing. Now all I need to do is get XFree86 compiled for MIPS, and figure out how to wire a Radeon 9000 up to the thing, and I'm all set. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From Axel.Thimm at physik.fu-berlin.de Mon Oct 6 21:11:47 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 6 Oct 2003 23:11:47 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006215423.60e087fd.ms-nospam-0306@arcor.de> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006175107.731c27d0.ms-nospam-0306@arcor.de> <20031006184748.GB6175@puariko.nirvana> <20031006215423.60e087fd.ms-nospam-0306@arcor.de> Message-ID: <20031006211147.GD6175@puariko.nirvana> On Mon, Oct 06, 2003 at 09:54:23PM +0200, Michael Schwendt wrote: > On Mon, 6 Oct 2003 20:47:48 +0200, Axel Thimm wrote: > > > > > A few observations: In your repository I don't see a > > > > > consistent platform specific release tag scheme. > > > > > > > > check the dates and the discussion on fedora.us in March/April > > > > (yes, I was once a fedora member). > > > > > > Been there before I joined the fedora-devel at fedora.us > > > list. Going through list archives is a time-consuming process. I > > > prefer summaries of ready-to-use concepts which can be commented > > > on as a whole. > > > You don't answer why some of your packages have no distribution > > > specific release tag at all and why other packages override > > > versions found in Red Hat Linux. > > > > What I wanted to say is that the versioning scheme evolved, partly > > on its own, partly in discussion within (the old) fedora. So when > > you find inconsistency in the repo you are seeing at different > > layers of history. > I fail to see that. Here's one of the packages for Shrike, which > was touched long after the disttag discussions: > [senseless examples skipped] Exactly what are you trying to prove? "My repo is more consistent than your repo"? Didn't I mention that there was evolution in the versioning scheme, _parts of which_ were discussed with fedora.us? (and the examples are crap also, i.e. you are ranting about mozilla's versioning scheme, which is a verbatim copy of rawhide ...) While the discussion with fedora.us back in March/April did create some first specifications, others and I broke with fedora.us due to the increased non-tolerance against other 3rd party repos. So the maintainers of the old repos stepped back and kept and evolved their own versioning schemes (This is a bit oversimplified, in reality there were and are coordination efforts to keep the repos compatible). Please don't repeat the same intolerance attitude. > So much about consistency. There are more examples like that. > Back to the topic. > > > > Continueing Fedora Core with Red Hat Linux specific release numbers > > > does not sound reasonable. It is like an implicit epoch. > > > > OTOH you are right, but if the packages from the Fedora Project are to > > be related to Red Hat Linux ones (e.g. you want them to be rpm-newer), > > you need to come up with a compatible scheme. > > Packages in Fedora Core 1 will be newer than any packages in Red Hat > Linux. Only a few cases (e.g. comps, maybe comps-extras, > redhat-release => fedora-release) need special treatment (probably an > increased epoch). You trimmed (and maybe didn't read) the following from my previous reply: "That's why I changed the Subject on the main thread to contain "Fedora Legacy". If one doesn't care about past releases, you don't see the problem." This applies here also, don't let the thread loose its topic. > > Did you check Warren's proposal on doing the reverse? E.g. instead of > > continuing RHL versioning into Fedora, one can back-continue Fedora > > guidelines to the past, e.g. treat RHL8.0 as Fedora Core 0.8.0. > > Yes, sounds good. It's not the first time a "0." prefix is useful. I know, I introduced it into fedora.us for consistency, shortly before I gave up ... -- 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 pp at ee.oulu.fi Mon Oct 6 21:15:21 2003 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Tue, 7 Oct 2003 00:15:21 +0300 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006205040.GC6175@puariko.nirvana> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006205040.GC6175@puariko.nirvana> Message-ID: <20031006211521.GA7744@ee.oulu.fi> On Mon, Oct 06, 2003 at 10:50:40PM +0200, Axel Thimm wrote: > While there do exist backported rpm versions with this bug fixed on > rpm.org, they have not been approved to enter RH errata, yet, and a > Legacy project needs to take into account non-updated setups. Of course, whatever the naming scheme is, one of the first Legacy updates should be a version of rpm that doesn't have random failure modes requiring manual intervention (i.e. the one on ftp.rpm.org or fedora), -- Pekka Pietikainen From warren at togami.com Mon Oct 6 22:01:15 2003 From: warren at togami.com (Warren Togami) Date: Mon, 6 Oct 2003 12:01:15 -1000 (HST) Subject: Requesting Fedora Legacy Mailing List In-Reply-To: References: <1065452165.18004.35.camel@opus> Message-ID: <19972.128.171.123.60.1065477675.squirrel@togami.com> With Jesse (Pogo Linux), Chuck (Quantum Linux), the rh-consortium group and others, I now realize there is a sufficiently large community of developers who would work on the continuance of the EOL'ed distributions. In order to consolidate this discussion in one place, I formally request a new mailing list at fedora-legacy-list at redhat.com. Warren Togami warren at togami.com From skvidal at phy.duke.edu Mon Oct 6 21:25:55 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 06 Oct 2003 17:25:55 -0400 Subject: Requesting Fedora Legacy Mailing List In-Reply-To: <19972.128.171.123.60.1065477675.squirrel@togami.com> References: <1065452165.18004.35.camel@opus> <19972.128.171.123.60.1065477675.squirrel@togami.com> Message-ID: <1065475555.19291.6.camel@opus> On Mon, 2003-10-06 at 18:01, Warren Togami wrote: > With Jesse (Pogo Linux), Chuck (Quantum Linux), the rh-consortium group > and others, I now realize there is a sufficiently large community of > developers who would work on the continuance of the EOL'ed distributions. > In order to consolidate this discussion in one place, I formally request a > new mailing list at fedora-legacy-list at redhat.com. I offered before, I'll offer again, if you want fedora-legacy-list at linux.duke.edu it can be arranged in a matter minutes. -sv From ms-nospam-0306 at arcor.de Mon Oct 6 21:32:40 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 6 Oct 2003 23:32:40 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006211147.GD6175@puariko.nirvana> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006175107.731c27d0.ms-nospam-0306@arcor.de> <20031006184748.GB6175@puariko.nirvana> <20031006215423.60e087fd.ms-nospam-0306@arcor.de> <20031006211147.GD6175@puariko.nirvana> Message-ID: <20031006233240.06d1b455.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 6 Oct 2003 23:11:47 +0200, Axel Thimm wrote: > > [senseless examples skipped] Ha! > Exactly what are you trying to prove? "My repo is more consistent than > your repo"? I don't have a repository. > Didn't I mention that there was evolution in the > versioning scheme, _parts of which_ were discussed with fedora.us? > > (and the examples are crap also, Wrong choice of words here for my taste. Aggression causes me to block off. > i.e. you are ranting about mozilla's > versioning scheme, which is a verbatim copy of rawhide ...) mplayer isn't. > While the discussion with fedora.us back in March/April did create > some first specifications, others and I broke with fedora.us due to > the increased non-tolerance against other 3rd party repos. > > So the maintainers of the old repos stepped back and kept and evolved > their own versioning schemes (This is a bit oversimplified, in reality > there were and are coordination efforts to keep the repos compatible). How is your current versioning scheme defined? > > Packages in Fedora Core 1 will be newer than any packages in Red Hat > > Linux. Only a few cases (e.g. comps, maybe comps-extras, > > redhat-release => fedora-release) need special treatment (probably an > > increased epoch). > > You trimmed (and maybe didn't read) the following from my previous > reply: "That's why I changed the Subject on the main thread to contain > "Fedora Legacy". If one doesn't care about past releases, you don't > see the problem." I refused to quote it. Does Fedora Legacy cover "old releases of Fedora Core" (quote from fedora.redhat.com) or also old release from Red Hat Linux or also pre-Fedora 3rd party repositories? - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gd940iMVcrivHFQRAksJAJ4lLetnPevG8WsC6LVFd5jEIqv/rwCdHO1k 1D+JQIBB423hIvTjUs2L75c= =BFeU -----END PGP SIGNATURE----- From smoogen at lanl.gov Mon Oct 6 21:48:51 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 06 Oct 2003 15:48:51 -0600 Subject: Requesting Fedora Legacy Mailing List In-Reply-To: <1065475555.19291.6.camel@opus> References: <1065452165.18004.35.camel@opus> <19972.128.171.123.60.1065477675.squirrel@togami.com> <1065475555.19291.6.camel@opus> Message-ID: <1065476931.7694.44.camel@smoogen1.lanl.gov> I would suggest that this is the best order of action until the Red Hat sysadmins can make it happen. The mail admins usually are usually spending all their time emptying the bit-bucket and mail-list creation takes a bit longer. On Mon, 2003-10-06 at 15:25, seth vidal wrote: > On Mon, 2003-10-06 at 18:01, Warren Togami wrote: > > With Jesse (Pogo Linux), Chuck (Quantum Linux), the rh-consortium group > > and others, I now realize there is a sufficiently large community of > > developers who would work on the continuance of the EOL'ed distributions. > > In order to consolidate this discussion in one place, I formally request a > > new mailing list at fedora-legacy-list at redhat.com. > > I offered before, I'll offer again, if you want > fedora-legacy-list at linux.duke.edu it can be arranged in a matter > minutes. > > -sv > > > > -- > 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 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 Axel.Thimm at physik.fu-berlin.de Mon Oct 6 22:02:20 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 7 Oct 2003 00:02:20 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006230254.5b97aac6.ms-nospam-0306@arcor.de> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006230254.5b97aac6.ms-nospam-0306@arcor.de> Message-ID: <20031006220220.GE6175@puariko.nirvana> On Mon, Oct 06, 2003 at 11:02:54PM +0200, Michael Schwendt wrote: > On Mon, 6 Oct 2003 15:50:49 -0400 (EDT), Mike A. Harris wrote: > > > Reading the thread, it is aparent to me that many people who read > > it and responded, did not completely listen to the problem which > > you are describing. Numerous people completely misunderstood > > what you are trying to say, or purposefully chose to not read > > everything and attempt to understand it. I read your emails > > fairly carefully however and believe I understand you correctly. > > Interesting observation. But the solution you've come up is one that > has been covered before. It's used by fedora.us, and Axel calls it a > "kludge". Please Michael, stop misquoting me, it has become a bad habit of yours. While it definitely is a kludge, you (deliberately?) skip my main concerns about this scheme being broken by all rpm versions up to this January, making this idiom unsuitable for "Fedora Legacy". You know the war 1870/71 between the German states and France was triggered because the Prussian cancler deliberately misquoted statements of the French king towards the Prussian king? > rh73 < rh80 < rh90 < 0.94 < 1 > rh73 < rh80 < rh90 < 1 > > Whether you add something after the 0.94 (or 1), doesn't matter. -- 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 hosting at j2solutions.net Mon Oct 6 22:02:28 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Mon, 6 Oct 2003 15:02:28 -0700 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006233240.06d1b455.ms-nospam-0306@arcor.de> References: <20030930075824.GD1714@pua.nirvana> <20031006211147.GD6175@puariko.nirvana> <20031006233240.06d1b455.ms-nospam-0306@arcor.de> Message-ID: <200310061502.28404.hosting@j2solutions.net> On Monday 06 October 2003 14:32, Michael Schwendt wrote: > I refused to quote it. Does Fedora Legacy cover "old releases of > Fedora Core" (quote from fedora.redhat.com) or also old release from > Red Hat Linux or also pre-Fedora 3rd party repositories? Until pried otherwise from my fingers, Fedora Legacy will provide backports for 7.3 and 9 when they respectively go EOL. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From hosting at j2solutions.net Mon Oct 6 22:04:22 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Mon, 6 Oct 2003 15:04:22 -0700 Subject: Requesting Fedora Legacy Mailing List In-Reply-To: <1065475555.19291.6.camel@opus> References: <1065452165.18004.35.camel@opus> <19972.128.171.123.60.1065477675.squirrel@togami.com> <1065475555.19291.6.camel@opus> Message-ID: <200310061504.22416.hosting@j2solutions.net> On Monday 06 October 2003 14:25, seth vidal wrote: > I offered before, I'll offer again, if you want > fedora-legacy-list at linux.duke.edu it can be arranged in a matter > minutes. Lets go ahead and do it. I fear that some relevant discussion will leave fedora-devel, but *shrug* what the hey (; -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From Axel.Thimm at physik.fu-berlin.de Mon Oct 6 22:08:24 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 7 Oct 2003 00:08:24 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006211521.GA7744@ee.oulu.fi> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006205040.GC6175@puariko.nirvana> <20031006211521.GA7744@ee.oulu.fi> Message-ID: <20031006220824.GF6175@puariko.nirvana> On Tue, Oct 07, 2003 at 12:15:21AM +0300, Pekka Pietikainen wrote: > On Mon, Oct 06, 2003 at 10:50:40PM +0200, Axel Thimm wrote: > > While there do exist backported rpm versions with this bug fixed on > > rpm.org, they have not been approved to enter RH errata, yet, and a > > Legacy project needs to take into account non-updated setups. > Of course, whatever the naming scheme is, one of the first Legacy > updates should be a version of rpm that doesn't have random failure > modes requiring manual intervention (i.e. the one on ftp.rpm.org or > fedora), Yes, most certainly, but you do see the chicken-and-egg problem? Better to not depend on the order of the packages installed. (OT: Unfortunately all current rpm versions still have the "random failure modes" you refer to, even in severn2. This is probably the reason for rpm not making it to errata. Unfortunately the bug is very difficult to reproduce, usually happens during large 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 alan at redhat.com Mon Oct 6 22:27:25 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Oct 2003 18:27:25 -0400 (EDT) Subject: [Univ-linux] Future unsupported Red Hat Linux systems In-Reply-To: <1065468393.27102.108.camel@spatula> from "Jef Spaleta" at Hyd 06, 2003 03:26:33 Message-ID: <200310062227.h96MRPw05247@devserv.devel.redhat.com> > > The big disconnect here I suspect is that we thought about Fedora Legacy > > as "old Fedora" stuff. That meant it didn't appear on the "immediate > > infrastucture radar". Obviously "legacy hat" or whatever has a clear=20 > > December kick off requirement > > be an evolutionary outgrowth of what RHL was and not a clean start, then > the legacy issues surrounding pre-fedora rhl releases, falls into the > same evolutionary framework i think to some extent. I'm not arguing about whether its a good idea or not. Jut explaining the thinking so far and where that leaves some aspects of resource provision. From ms-nospam-0306 at arcor.de Mon Oct 6 23:13:49 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 7 Oct 2003 01:13:49 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006220220.GE6175@puariko.nirvana> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006230254.5b97aac6.ms-nospam-0306@arcor.de> <20031006220220.GE6175@puariko.nirvana> Message-ID: <20031007011349.232d6e48.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 7 Oct 2003 00:02:20 +0200, Axel Thimm wrote: > Please Michael, stop misquoting me, it has become a bad habit of > yours. While it definitely is a kludge, you (deliberately?) skip my > main concerns about this scheme being broken by all rpm versions up to > this January, making this idiom unsuitable for "Fedora Legacy". Rest assured, I'm out of this thread. I'm back when there are serious attempts at developing a versioning scheme for Fedora Legacy, such as using %{release}.0.X.Y (where 0.X.Y is e.g. 0.7.3 for Valhalla and 0.9 for Shrike), instead of trying to find a compromise for current 3rd party repositories. My final comments here. You're complicating matters. I'm aware that for older versions of RPM (<= 4.1 or 4.1.1, I don't know), rh73 < 1fdr *and* 1fdr < rh73 so that would be a problem for upgrade chanells which don't update RPM to a better version. But where has been defined that Fedora Legacy will carry packages with rh* disttags? Fedora Legacy has other problems that must be considered. Obviously, packages for a Fedora Legacy supported distribution must have a higher version than all previous packages (E:V-R based version comparison) for that distribution *and* all packages of older distributions. At the same time, Fedora Legacy update packages for one distribution may not have a higher version than stock packages of newer distributions, so the upgrade path is not disturbed. You can only avoid that with backported fixes, which keep the V in E:V-R below what is shipped with later distributions, or if you break upgradability. Whether or not that may be necessary also depends on the feasibility of backporting security fixes in time. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gfct0iMVcrivHFQRAhZGAJ9uiKdPn/AHQOq8kfvlFkfC02dKuwCeJRUh JMxNXPezUHhCuAr5XZcYnW0= =Uomw -----END PGP SIGNATURE----- From aoliva at redhat.com Mon Oct 6 23:31:56 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 06 Oct 2003 20:31:56 -0300 Subject: Kind request: Set release version to "10" In-Reply-To: <20031006220824.GF6175@puariko.nirvana> References: <20030930075824.GD1714@pua.nirvana> <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006205040.GC6175@puariko.nirvana> <20031006211521.GA7744@ee.oulu.fi> <20031006220824.GF6175@puariko.nirvana> Message-ID: On Oct 6, 2003, Axel Thimm wrote: > Yes, most certainly, but you do see the chicken-and-egg problem? > Better to not depend on the order of the packages installed. Err... Isn't this what rpm dependencies are for? Sure enough, you may have to run rpm -F more than once, to get the rpm updated in the first round, and everything else later, but I can't see other problems. Do you? -- 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 hosting at j2solutions.net Tue Oct 7 03:15:19 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Mon, 6 Oct 2003 20:15:19 -0700 Subject: Fedora Legacy List launched Message-ID: <7AD15046-F874-11D7-B878-000393D35C04@j2solutions.net> Due to popular demand, we have launched a Fedora Legacy email list to go along with the IRC channel and wiki page. To subscribe, please visit: https://lists.dulug.duke.edu/mailman/listinfo/fedora-legacy-list (I'm not a member of fedora-list or fedora.us's list. Please echo this announcement there) -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (www.mondorescue.org) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From derek.moore at sbcglobal.net Tue Oct 7 03:34:53 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Mon, 6 Oct 2003 20:34:53 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065016443.6301.37.camel@locutus> Message-ID: <20031007033453.17903.qmail@web80002.mail.yahoo.com> > Does this mean we can now stop requiring kerberos in > everything that can have it required? I submit that > the vast majority of Fedora target "market" will not > ever need krb in Fedora. I need Kerberos 5 support in Fedora. Actually, I submit that Kerberos support should get /better/ in Fedora, not worse! Peace out, Derek From derek.moore at sbcglobal.net Tue Oct 7 04:31:58 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Mon, 6 Oct 2003 21:31:58 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065040320.8017.12.camel@locutus> Message-ID: <20031007043158.16540.qmail@web80001.mail.yahoo.com> > Is Fedora a business-level distribution or not? If it > is, then fine, leave it in. But if it isn't, let us > at least be honest about how few people at home and > small/medium organizations are using it and > reconsider our fascination and dedication to it. Let's try your thought experiment on something more fundamental to Fedora: "Let's be honest about how few people at home and small/medium organizations are using Linux and reconsider our fascination and dedication to it." So, using your own rationale, we should "not make everything depend on Linux" and support for Linux should be removed from Fedora. Just 'cause Bill Anderson has some weird anti-fascination with Kerberos doesn't mean it's not an important or viable technology, or that it should be removed from Fedora. Kerberos is here to stay, whether you like it or not. I, for one, /need/ Kerberos support in Fedora (no, wait, I need /better/ Kerberos support in Fedora). With Microsoft now promoting Kerberos, Kerberos support in Fedora is that much more important. Okay, I'm done now, Derek From chuckw at quantumlinux.com Tue Oct 7 04:48:00 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 6 Oct 2003 21:48:00 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <20031007043158.16540.qmail@web80001.mail.yahoo.com> Message-ID: > > Is Fedora a business-level distribution or not? If it is, then fine, > > leave it in. But if it isn't, let us at least be honest about how few > > people at home and small/medium organizations are using it and > > reconsider our fascination and dedication to it. > > Let's try your thought experiment on something more fundamental to > Fedora: > > "Let's be honest about how few people at home and small/medium > organizations are using Linux and reconsider our fascination and > dedication to it." Take that one step further. Fedora legacy is targeting RH 7.3 and RH 9. What happens in a year or two or three or four when RH 7.3 and RH9 are *FINALLY* truly dead. We're going to have to shove a stake in the ground at a Fedora release and say "This is the new fedora legacy" and flagellate 'er support it for a few years as a production OS. I'd be pretty cranky if I had to perform micro-surgery on a perfectly good distribution to add a tool like kerberos (that should have been there in the first place). /me pours a little gas on the fire... /me rubs hands together... -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 derek.moore at sbcglobal.net Tue Oct 7 04:49:42 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Mon, 6 Oct 2003 21:49:42 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065040779.8022.22.camel@locutus> Message-ID: <20031007044942.28414.qmail@web80009.mail.yahoo.com> > Why imagine it, I live it! Yet not using Kerberos to > do it. How, may I ask, do you do that without the help of Kerberos? And I hope you don't reply, "I check the 'save password' box," 'cause that's nowhere near the functionality that Kerberos provides. Derek From Dax at GuruLabs.com Tue Oct 7 05:00:45 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Mon, 06 Oct 2003 23:00:45 -0600 Subject: custom DHCP vendor class identifiers In-Reply-To: <20031006135720.GA2049@server4.8080.it> References: <20031006135720.GA2049@server4.8080.it> Message-ID: <1065502845.3091.7.camel@mentor.gurulabs.com> On Mon, 2003-10-06 at 07:57, Rudi Chiarito wrote: > Hi. > > Browsing the kickstart list I found that I am not the only one who might > have a use for specifying a custom DHCP vendor class identifier Add your comments to the RFE bug I filed in December of 2002 for exactly this feature. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=78843 Dax Kelson Guru Labs From derek.moore at sbcglobal.net Tue Oct 7 05:25:12 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Mon, 6 Oct 2003 22:25:12 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065042213.8017.47.camel@locutus> Message-ID: <20031007052512.20528.qmail@web80003.mail.yahoo.com> > I've got networks doing single-sign on using > ldap/pam/nss/friends, no K needed. Uh, I'm pretty sure (LDAP + PAM + NSS) != single sign on. However, (Kerberos + LDAP + PAM + NSS) == single sign on. LDAP in no way prevents you from needing to supply your password to the mail server or to the news server or to the LDAP server, for that matter. Kerberos does. Maybe your definition of "single sign on" is different. By "single sign on" I (and others, I'm sure) don't mean "centralized password database that all services use". We mean "type your password only once and never again". > As someone mentioned, paraphrasing "setting > up/understanding Kerberos is a nightmare". For me, setting up Kerberos was pretty easy. Just as easy as was setting up Apache my first time. I actually had /much/ more trouble with LDAP. If you managed to wrap your brain around LDAP, wrapping your brain around Kerberos is nothing. > The tools to make this a reasonable expectation are > simply not there. What tools are your talking about? Isn't a configuration file and a daemon enough for you? You're the one that keeps bringing up the point about how Fedora is a "hobbyists and enthusiasts" distro. Shouldn't "hobbyists and enthusiasts" be expected to edit a config file or two? If by "tools" you're referring to 'kadmin', I can assure you that 'kadmin' works, otherwise nobody would use Kerberos. > "Are you using it?" Yes. At home & at work. > "Do you know how?" Yes. Otherwise I wouldn't be using it. > "Do you *need* it?" Uhh, yes. Very much so. I need centralized authentication & real security, and I strongly desire single sign on. LDAP may provide centralized authentication, and, with TLS, some security; but it'll never provide single sign on, and it'll never prevent man-in-the-middle attacks, and it'll never provide mutual authentication between client & server. >> "SSH is no replacement for Kerberos" > > Agreed. But then again, you can reverse that > statement with no change in truth. Kerberos is not a > replacement for SSH either. Almost true. Kerberos certainly is a replacement for SSH (well, in a manner of speaking). Kerberized rsh, rcp, telnet, etc. are pretty much feature equivalent to SSH, transport layer encryption and all. But then again, Kerberized SSH also exists... So... Yeah. Anyways, the point is, with Kerberos, you can switch back to the tools that SSH meant to fix/replace. > Geez, didn't know Kerberos was one of the Sacred > Cows of RedHat err I mean Fedora. Geez, you didn't realize that Linux users care about security and ease-of-use. Derek From derek.moore at sbcglobal.net Tue Oct 7 06:06:28 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Mon, 6 Oct 2003 23:06:28 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065107463.14032.64.camel@locutus> Message-ID: <20031007060628.3437.qmail@web80012.mail.yahoo.com> > Kerberos does not do X11-forwarding, for example. True that. > Nor does Kerberos provide remote file copying (such > as sftp and scp). Kerberos provides those features with Kerberized ftp, rcp, etc. > The main feature of SSH is that I can establish a > secure connection from point a to point b, more than > just secure authorization but having the entire > session encrypted. Kerberos does not do that. Yes, it does. > It was not designed to. Yes, it was. > As I've said, Kerberos can be used to provide the > authentication mechanism for SSH. True. > This should be a hint that they are not replacements > for each other. Not true. > Indeed, one could have an SSH kerberized intranet > that uses SSH as the remote login facility! Not true. > I'd argue that SSH would be a massive need in that > environment. Not really true. With Kerberos: telnet, ftp, rsh, rcp, etc., etc., automagically become secure. Not only in terms of authentication, but also in terms of strong encryption of sessions. > To compare them is to compare apples to buffets. Not true. > My point was that K and SSH are *not* replacements > for each other. It still stands. They are different > things with different purposes. Actually, K is really /more/ than just a replacement for SSH. Peace out, Derek From Axel.Thimm at physik.fu-berlin.de Tue Oct 7 06:17:27 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 7 Oct 2003 08:17:27 +0200 Subject: Requesting Fedora Legacy Mailing List In-Reply-To: <19972.128.171.123.60.1065477675.squirrel@togami.com> References: <1065452165.18004.35.camel@opus> <19972.128.171.123.60.1065477675.squirrel@togami.com> Message-ID: <20031007061727.GB13685@puariko.nirvana> Hi, On Mon, Oct 06, 2003 at 12:01:15PM -1000, Warren Togami wrote: > With Jesse (Pogo Linux), Chuck (Quantum Linux), the rh-consortium group > and others, I now realize there is a sufficiently large community of > developers who would work on the continuance of the EOL'ed distributions. > In order to consolidate this discussion in one place, I formally request a > new mailing list at fedora-legacy-list at redhat.com. IMHO I think that some parts of Fedora Legacy are closely related to Fedora proper, e.g. versioning schemes and the like. Wouldn't it be better to have this discussion at fedora-devel? fedora-devel should know about the needs of fedora-legacy (after all Fedora Legacy will be collecting Fedora proper every few months). -- 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 Tue Oct 7 06:28:53 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 7 Oct 2003 08:28:53 +0200 Subject: rpm versioning scheme (was: Kind request: Set release version to "10") In-Reply-To: <20031006233240.06d1b455.ms-nospam-0306@arcor.de> References: <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006175107.731c27d0.ms-nospam-0306@arcor.de> <20031006184748.GB6175@puariko.nirvana> <20031006215423.60e087fd.ms-nospam-0306@arcor.de> <20031006211147.GD6175@puariko.nirvana> <20031006233240.06d1b455.ms-nospam-0306@arcor.de> Message-ID: <20031007062853.GC13685@puariko.nirvana> On Mon, Oct 06, 2003 at 11:32:40PM +0200, Michael Schwendt wrote: > How is your current versioning scheme defined? Extracting kernel-modules, beta/cvs and other non-trivial examples the versioning scheme I suggest to use (note not only for myself, and not only for RH/FC) is: --__ Where o _ is a seperator, that could be "_", "." or under certain circumstances even "" o disttag is a combination of a distid and a distversion, e.g. rh9, rhel3, fdr1, lsb1.3, mdk8, suse9 should be rpm-sortable within a family, e.g. rhl/fdr should be sortable, rhel also, but possible rhl/fdr and rhel should not compare, etc. o repoid is an identity marker like "at", "fr", "dag", "fdr" They are at the least significant position to not have rpm sort on them. repoid is optional and should not be used by vendors or first tier packaging repos like FC. disttag > > You trimmed (and maybe didn't read) the following from my previous > > reply: "That's why I changed the Subject on the main thread to contain > > "Fedora Legacy". If one doesn't care about past releases, you don't > > see the problem." > > I refused to quote it. No need to comment on that, I guess ... > Does Fedora Legacy cover "old releases of Fedora Core" (quote from > fedora.redhat.com) or also old release from Red Hat Linux or also > pre-Fedora 3rd party repositories? -- 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 Tue Oct 7 06:36:06 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 7 Oct 2003 08:36:06 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031007011349.232d6e48.ms-nospam-0306@arcor.de> References: <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006230254.5b97aac6.ms-nospam-0306@arcor.de> <20031006220220.GE6175@puariko.nirvana> <20031007011349.232d6e48.ms-nospam-0306@arcor.de> Message-ID: <20031007063606.GD13685@puariko.nirvana> On Tue, Oct 07, 2003 at 01:13:49AM +0200, Michael Schwendt wrote: > Rest assured, I'm out of this thread. I'm back when there are serious > attempts at developing a versioning scheme for Fedora Legacy, such as > using %{release}.0.X.Y (where 0.X.Y is e.g. 0.7.3 for Valhalla and 0.9 > for Shrike), instead of trying to find a compromise for current 3rd > party repositories. You possibly haven't read the thread ... > My final comments here. You're complicating matters. I'm aware that > for older versions of RPM (<= 4.1 or 4.1.1, I don't know), > > rh73 < 1fdr *and* 1fdr < rh73 > > so that would be a problem for upgrade chanells which don't update RPM > to a better version. But where has been defined that Fedora Legacy > will carry packages with rh* disttags? Where has anything concerning Fedora Legacy been defined? Isn't that what this list members are supposed to develop? > Fedora Legacy has other problems that must be considered. Obviously, > packages for a Fedora Legacy supported distribution must have a > higher version than all previous packages (E:V-R based version > comparison) for that distribution *and* all packages of older > distributions. At the same time, Fedora Legacy update packages for > one distribution may not have a higher version than stock packages > of newer distributions, so the upgrade path is not disturbed. You are describing the same problem. > You can only avoid that with backported fixes, which keep the V in > E:V-R below what is shipped with later distributions, or if you > break upgradability. Whether or not that may be necessary also > depends on the feasibility of backporting security fixes in time. Not true, that's exactly when an rpm-sortable disttag in the release tag would help. Check the rest of the thread. -- 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 derek.moore at sbcglobal.net Tue Oct 7 06:42:46 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Mon, 6 Oct 2003 23:42:46 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065129913.15489.27.camel@locutus> Message-ID: <20031007064246.30182.qmail@web80003.mail.yahoo.com> > Those are apps that have been compiled/built to > support Kerberos, they are not the same thing. > > No, only if you are in a kerberized environment that > uses those kerberized apps. AS I have said, and the > two of you apparently refuse to realize, is that SSH > can utilize kerberos as well. You are implicitly > saying that rcp/rsh/telnet for example are a > mandatory part of kerberos utilizing networks. That > is factually and materially incorrect. Actually... telnet, rlogin, rsh, rcp, ftp, and their respective daemons are a part of pretty much every Kerberos distribution (MIT & Heimdal). > Note, those are *apps* not kerberos supplying those. > Use a kerberized ssh and you have no need for telnet, > ssh, ftp, rlogin. rcp, et al.. Sorta true, but not really. Actually, Kerberos (or, rather, the Kerberos libraries that the Kerberized apps are linked against), not the apps themselves, provides those apps with session ecryption. So, it's not untrue to say that Kerberos provides the session encryption functionality. > And on top of it you get all the other nice things > that SSH does. Mayeb it's me but I don't consider > being able to log into a remote machine, launch a > graphical app and have it display on my screen weird. > Even if that machine is through several other "hops" > of machines. To pick a nit: Can't you do this same thing with telnet? At least as long as you set the DISPLAY environment variable correctly (or use --display [or -display]). > Kerberos and SSh are not the same, True. Just as Linux and FreeBSD are not the same. Or just as MIT Kerberos and Heimdal Kerberos are not the same. Or just as GNU 'ls' and BSD 'ls' are not the same. > and do not provide the same things, Mostly, they do provide the same things. Derek From Axel.Thimm at physik.fu-berlin.de Tue Oct 7 06:44:16 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 7 Oct 2003 08:44:16 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: References: <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006205040.GC6175@puariko.nirvana> <20031006211521.GA7744@ee.oulu.fi> <20031006220824.GF6175@puariko.nirvana> Message-ID: <20031007064416.GE13685@puariko.nirvana> On Mon, Oct 06, 2003 at 08:31:56PM -0300, Alexandre Oliva wrote: > On Oct 6, 2003, Axel Thimm wrote: > > > Yes, most certainly, but you do see the chicken-and-egg problem? > > Better to not depend on the order of the packages installed. > > Err... Isn't this what rpm dependencies are for? > > Sure enough, you may have to run rpm -F more than once, to get the rpm > updated in the first round, and everything else later, but I can't see > other problems. Do you? If rpm itself is broken and needs to be upgraded before performing any further steps, you loose. Unless of course you make all packages depend on rpm >= 4.1.1, but even then a buggy rpm would sort the dependencies according to its buggy ordering algorithm and install the wrong bits. To summarize the problem: Some suggestions for versioning concurrent packages for different RH/FC releases were to use the recent letters-are-older-than-numbers idiom from rpm, e.g. foo-1.2.3-4_rh9 < foo-1.2.3-4_1 or foo-1.2.3-4_rh9 < foo-1.2.3-4_0fdr1 which is broken for rpm up to the one shipped with RH8.0. I think the best suggestion was to set "Fedora Core 0." := "Red Hat Linux ", so that the resulting disttags compare letters to letters and numbers to numbers (so the rpm non-symmetry bug is not triggered), and the disttags sort still in chronological order, e.g. foo-1.2.3-4_fdr0.9 < foo-1.2.3-4_fdr1 Unfortunately nobody from RH commented on this. Bill? -- 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 Tue Oct 7 06:52:00 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 7 Oct 2003 09:52:00 +0300 Subject: Requesting Fedora Legacy Mailing List In-Reply-To: <20031007061727.GB13685@puariko.nirvana> References: <1065452165.18004.35.camel@opus> <19972.128.171.123.60.1065477675.squirrel@togami.com> <20031007061727.GB13685@puariko.nirvana> Message-ID: <1065509520.3f8262902d92c@webmail.welho.com> Quoting Axel Thimm : > Hi, > > On Mon, Oct 06, 2003 at 12:01:15PM -1000, Warren Togami wrote: > > With Jesse (Pogo Linux), Chuck (Quantum Linux), the rh-consortium group > > and others, I now realize there is a sufficiently large community of > > developers who would work on the continuance of the EOL'ed distributions. > > > In order to consolidate this discussion in one place, I formally request > a > > new mailing list at fedora-legacy-list at redhat.com. > > IMHO I think that some parts of Fedora Legacy are closely related to > Fedora proper, e.g. versioning schemes and the like. > > Wouldn't it be better to have this discussion at fedora-devel? > fedora-devel should know about the needs of fedora-legacy (after all > Fedora Legacy will be collecting Fedora proper every few months). For stuff relevant to fedora-devel, by all means but not all of it belongs to fedora-devel, never mind the huge amount of crossposting these discussions are creating. -- - Panu - From nos at utel.no Tue Oct 7 06:58:44 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Tue, 07 Oct 2003 08:58:44 +0200 Subject: Does the freeworld repository exist yet? In-Reply-To: <4334d4a2010b6a07d3@[192.168.170.10]> References: <200310061716.h96HGDm8004032@snark.thyrsus.com><4334d4a2010b6a07d3@[192.168.170.10]> Message-ID: <460d7f41020c1307d3@[192.168.170.10]> On Mon, 2003-10-06 at 19:32, seth vidal wrote: > On Mon, 2003-10-06 at 13:16, Eric S. Raymond wrote: > > Does the freeworld repository exist yet? If so, where is it? > > rpm.livna.org > > this is in the archives. Why is Blender there ? Does it violate anything ? -- 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 derek.moore at sbcglobal.net Tue Oct 7 07:14:42 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Tue, 7 Oct 2003 00:14:42 -0700 (PDT) Subject: Open Office 1.1 suggestion In-Reply-To: <3F7DC724.3080405@redhat.com> Message-ID: <20031007071442.45974.qmail@web80009.mail.yahoo.com> >> If we pick a hardcoded set, it should be the Bluecurve >> icon style; Garrett can fill in missing icons in the >> Fedora Core 2 timeframe probably. > > It is a bunch of icons but, when finished, OOo will look > quite nice and it will more-or-less match the entire > desktop's feel (with the exception of the widgets > looking just the same, unless someone has some magic up > their sleeves). GIMP 1.3 icons ought to be used before creating whole new ones. That way, the desktop experience is that much more consistent. Derek From derek.moore at sbcglobal.net Tue Oct 7 10:05:03 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Tue, 7 Oct 2003 03:05:03 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <20031007060628.3437.qmail@web80012.mail.yahoo.com> Message-ID: <20031007100503.47744.qmail@web80011.mail.yahoo.com> > > Indeed, one could have an SSH kerberized intranet > > that uses SSH as the remote login facility! > > Not true. Upon reviewing this email of mine, I haven't a clue why I said "Not true" here. The above statement most certainly is "true". I think this particular "Not true" snuck in there somehow during all the copy-and-pasting I was doing when writing the email. Okay, I'm done now, Derek From buildsys at porkchop.devel.redhat.com Tue Oct 7 10:16:35 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Tue, 7 Oct 2003 06:16:35 -0400 Subject: rawhide report: 20031007 changes Message-ID: <200310071016.h97AGZY26536@porkchop.devel.redhat.com> Removed package pxe Updated Packages: ORBit2-2.8.1.90-1 ----------------- * Mon Oct 06 2003 Jeremy Katz 2.8.1.90-1 - update to CVS snap off of gnome-2-4 branch apr-util-0.9.4-2 ---------------- * Mon Oct 06 2003 Joe Orton 0.9.4-2 - fix 'apu-config --apu-la-file' output * Mon Oct 06 2003 Joe Orton 0.9.4-1 - update to 0.9.4. automake-1.7.8-1 ---------------- * Tue Oct 07 2003 Jens Petersen - 1.7.8-1 - update to 1.7.8 bugfix release bind-9.2.2.P3-4 --------------- * Mon Oct 06 2003 Daniel Walsh 9.2.2.P3-4 - Fix handling of chroot -/dev/random * Thu Oct 02 2003 Daniel Walsh 9.2.2.P3-3 - Stop hammering stuff on update of chroot environment * Mon Sep 29 2003 Daniel Walsh 9.2.2.P3-2 - Fix chroot directory to grab all subdirectories epiphany-1.0.1-1 ---------------- * Mon Oct 06 2003 Jeremy Katz 1.0.1-1 - 1.0.1 gdm-2.4.4.3-3 ------------- * Mon Oct 06 2003 Havoc Pennington 1:2.4.4.3-3 - change DefaultSession=Default.desktop to DefaultSession=default.desktop - SELinux off again * Fri Oct 03 2003 Dan Walsh 1:2.4.4.3-2.sel - turn on SELinux prelink-0.3.0-7 --------------- * Mon Oct 06 2003 Jakub Jelinek 0.3.0-7 - don't rely on malloc/calloc/realloc with size 0 returning a unique pointer - fix testsuite, so that it works even if installed glibc/libstdc++ is already prelinked * Wed Sep 17 2003 Jakub Jelinek 0.3.0-6 - fix comment in /etc/sysconfig/prelink (#106217) rawhide-release-20031007-1 -------------------------- redhat-config-samba-1.1.2-1 --------------------------- * Mon Oct 06 2003 Brent Fox 1.1.2-1 - add 'client plaintext auth' to sambaDefaults.py (bug #106072) redhat-config-services-0.8.5-21 ------------------------------- * Mon Oct 06 2003 Daniel J Walsh 0.8.5-21 - Fix crash on about redhat-config-users-1.2.2-1 --------------------------- * Mon Oct 06 2003 Brent Fox 1.2.2-1 - don't allow the root's username to be changed (bug #105632) redhat-config-xfree86-0.9.9-2 ----------------------------- * Mon Oct 06 2003 Brent Fox 0.9.9-2 - finish up the dual-head code - catch case of having no layout options * Thu Oct 02 2003 Brent Fox 0.9.9-1 - first stab at multihead code - commit some additional monitor icons * Thu Aug 14 2003 Brent Fox 0.9.8-1 - tag on every build * Thu Jun 05 2003 Brent Fox 0.9.7-1 - see if we have the name for an unprobed monitor tzdata-2003d-1 -------------- * Mon Oct 06 2003 Jakub Jelinek 2003d-1 - 2003d * Thu Sep 25 2003 Jakub Jelinek 2003c-1 - 2003c - updates for Brasil (#104840) From ms-nospam-0306 at arcor.de Tue Oct 7 10:38:27 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 7 Oct 2003 12:38:27 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <20031007063606.GD13685@puariko.nirvana> References: <20031001091247.GH1876@pua.nirvana> <20031001135624.338c54e7.ms-nospam-0306@arcor.de> <20031001150051.GB1777@pua.nirvana> <20031001191908.09b44222.ms-nospam-0306@arcor.de> <20031006085052.GK8013@puariko.nirvana> <20031006230254.5b97aac6.ms-nospam-0306@arcor.de> <20031006220220.GE6175@puariko.nirvana> <20031007011349.232d6e48.ms-nospam-0306@arcor.de> <20031007063606.GD13685@puariko.nirvana> Message-ID: <20031007123827.48d027cc.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 7 Oct 2003 08:36:06 +0200, Axel Thimm wrote: > > Fedora Legacy has other problems that must be considered. Obviously, > > packages for a Fedora Legacy supported distribution must have a > > higher version than all previous packages (E:V-R based version > > comparison) for that distribution *and* all packages of older > > distributions. At the same time, Fedora Legacy update packages for > > one distribution may not have a higher version than stock packages > > of newer distributions, so the upgrade path is not disturbed. > > You can only avoid that with backported fixes, which keep the V in > > E:V-R below what is shipped with later distributions, or if you > > break upgradability. Whether or not that may be necessary also > > depends on the feasibility of backporting security fixes in time. > > Not true, that's exactly when an rpm-sortable disttag in the release > tag would help. Check the rest of the thread. Wrong. Please consider thinking about it a bit longer before you pipe out your usual quick replies. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gpej0iMVcrivHFQRAvxlAKCI6cCDodgZsa8krLiQsJd3zgeI0ACfdrbe 7KP/qDhOHREiQrm+tFww3Wk= =u+O1 -----END PGP SIGNATURE----- From anvil at livna.org Tue Oct 7 11:44:33 2003 From: anvil at livna.org (Dams) Date: Tue, 07 Oct 2003 13:44:33 +0200 Subject: Does the freeworld repository exist yet? In-Reply-To: <460d7f41020c1307d3@[192.168.170.10]> References: <200310061716.h96HGDm8004032@snark.thyrsus.com> <4334d4a2010b6a07d3@[192.168.170.10]> <460d7f41020c1307d3@[192.168.170.10]> Message-ID: <1065527072.7713.6.camel@gruyere> blender 2.28 seems to be linked against smpeg which is in freeworld (like all mpeg related packages).. D Le mar 07/10/2003 ? 08:58, =?ISO-8859-1?Q? Nils O. Sel=E5sdal?= a ?crit : > Why is Blender there ? Does it violate anything ? -- 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 nos at utel.no Tue Oct 7 12:02:17 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Tue, 07 Oct 2003 14:02:17 +0200 Subject: Does the freeworld repository exist yet? In-Reply-To: <47168e03020c5c07d3@[192.168.170.10]> References: <47168e03020c5c07d3@[192.168.170.10]> Message-ID: <47273e36020c5e07d3@[192.168.170.10]> On Tue, 2003-10-07 at 13:44, Dams wrote: > blender 2.28 seems to be linked against smpeg which is in freeworld > (like all mpeg related packages).. > > D > > Le mar 07/10/2003 ? 08:58, =?ISO-8859-1?Q? Nils O. Sel=E5sdal?= a ??crit > : > > Why is Blender there ? Does it violate anything ? Blender + openal can probably be rebuilt without smpeg. Should it be done ? -- 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 bill at noreboots.com Tue Oct 7 12:16:44 2003 From: bill at noreboots.com (Bill Anderson) Date: 07 Oct 2003 06:16:44 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <20031007043158.16540.qmail@web80001.mail.yahoo.com> References: <20031007043158.16540.qmail@web80001.mail.yahoo.com> Message-ID: <1065529004.722.16.camel@locutus> On Mon, 2003-10-06 at 22:31, Derek P. Moore wrote: > > Is Fedora a business-level distribution or not? If > it > > is, then fine, leave it in. But if it isn't, let us > > at least be honest about how few people at home and > > small/medium organizations are using it and > > reconsider our fascination and dedication to it. > > Let's try your thought experiment on something more > fundamental to Fedora: > > "Let's be honest about how few people at home and > small/medium organizations are using Linux and > reconsider our fascination and dedication to it." > > So, using your own rationale, we should "not make > everything depend on Linux" and support for Linux > should be removed from Fedora. > > Just 'cause Bill Anderson has some weird > anti-fascination with Kerberos doesn't mean it's not > an important or viable technology, or that it should > be removed from Fedora. Kerberos is here to stay, > whether you like it or not. I, for one, /need/ > Kerberos support in Fedora (no, wait, I need /better/ > Kerberos support in Fedora). > > With Microsoft now promoting Kerberos, Kerberos > support in Fedora is that much more important. > > Okay, I'm done now, Good then quit bogarting the crack pipe. And actually, it has been more than suggested on this list (or one of these fedora lists) that Fedora Core could, and is eventually expected to, run on something other than the Linux Kernel, such as BSD. And, IIRC, that came from a RH email address. Still ready to stand by that analogy. :^D -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From hadess at hadess.net Tue Oct 7 12:31:41 2003 From: hadess at hadess.net (Bastien Nocera) Date: Tue, 07 Oct 2003 13:31:41 +0100 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065529004.722.16.camel@locutus> References: <20031007043158.16540.qmail@web80001.mail.yahoo.com> <1065529004.722.16.camel@locutus> Message-ID: <1065529901.22051.115.camel@dhcp-116.surrey.redhat.com> On Tue, 2003-10-07 at 13:16, Bill Anderson wrote: > On Mon, 2003-10-06 at 22:31, Derek P. Moore wrote: > > > Is Fedora a business-level distribution or not? If > > it > > > is, then fine, leave it in. But if it isn't, let us > > > at least be honest about how few people at home and > > > small/medium organizations are using it and > > > reconsider our fascination and dedication to it. > > > > Let's try your thought experiment on something more > > fundamental to Fedora: > > > > "Let's be honest about how few people at home and > > small/medium organizations are using Linux and > > reconsider our fascination and dedication to it." > > > > So, using your own rationale, we should "not make > > everything depend on Linux" and support for Linux > > should be removed from Fedora. > > > > Just 'cause Bill Anderson has some weird > > anti-fascination with Kerberos doesn't mean it's not > > an important or viable technology, or that it should > > be removed from Fedora. Kerberos is here to stay, > > whether you like it or not. I, for one, /need/ > > Kerberos support in Fedora (no, wait, I need /better/ > > Kerberos support in Fedora). > > > > With Microsoft now promoting Kerberos, Kerberos > > support in Fedora is that much more important. > > > > Okay, I'm done now, > > Good then quit bogarting the crack pipe. > > And actually, it has been more than suggested on this list (or one of > these fedora lists) that Fedora Core could, and is eventually expected > to, run on something other than the Linux Kernel, such as BSD. And, > IIRC, that came from a RH email address. Still ready to stand by that > analogy. :^D Then I'll send a message to this list with my Red Hat e-mail address saying that "eventually, I want Totem with WMA, Sorenson, DVD, and MP3 playback in Fedora", and you're going to believe me :) Who's on the crackpipe then? ;) --- Bastien Nocera She had a deep, throaty, genuine laugh, like that sound a dog makes just before it throws up. From bill at noreboots.com Tue Oct 7 12:38:27 2003 From: bill at noreboots.com (Bill Anderson) Date: 07 Oct 2003 06:38:27 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <20031007060628.3437.qmail@web80012.mail.yahoo.com> References: <20031007060628.3437.qmail@web80012.mail.yahoo.com> Message-ID: <1065530307.737.34.camel@locutus> On Tue, 2003-10-07 at 00:06, Derek P. Moore wrote: > > Kerberos does not do X11-forwarding, for example. > > True that. > > > Nor does Kerberos provide remote file copying (such > > as sftp and scp). > > Kerberos provides those features with Kerberized ftp, > rcp, etc. *sigh* another person who can't seem to distinguish between an a authentication mechanism and apps compiled with support for it. Why even your words above should tell you that: "kerberized ftp,rcp" the ftp or rcp, telnet apps are providing those services, kerberos is providing the authentication. > > > I'd argue that SSH would be a massive need in that > > environment. > > Not really true. With Kerberos: telnet, ftp, rsh, > rcp, etc., etc., automagically become secure. Not > only in terms of authentication, but also in terms of > strong encryption of sessions. Read the post again, with open eyes this time and see that the environment described uses a kerberized ssh to do all of those functions, and that therefore qualifies as a "kerberized environment" that relies heavily on SSH. You are blindly associating apps compiled with kerberos *support* with the Kerberos itself. "Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography." MIT One is a protocol, the other is not. Think of SSL and you may start to get the picture. SSL doesn't server web pages, or serve email. It provides an encryption layer. I can use SSL on Apache, Zope, or dozens of other servers. Yet you don't claim SSL provides http service. Kerberos, like SSL is a supporting library/protocol for something else; it does *nothing* on it's own. SSH is it's own app/server. Apples and Oranges. > > My point was that K and SSH are *not* replacements > > for each other. It still stands. They are different > > things with different purposes. > > Actually, K is really /more/ than just a replacement > for SSH. No, K requires additional apps to achieve some of the functionality of SSH. Period. That's not saying one is better than the other, merely that they are fundamentally different and as such are not replacements for each other. If you can't tell the difference between an app w/support for the Foo Protocol and the Foo Protocol, then we have nothing further to discuss. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From bill at noreboots.com Tue Oct 7 12:46:43 2003 From: bill at noreboots.com (Bill Anderson) Date: 07 Oct 2003 06:46:43 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <20031007064246.30182.qmail@web80003.mail.yahoo.com> References: <20031007064246.30182.qmail@web80003.mail.yahoo.com> Message-ID: <1065530803.738.41.camel@locutus> Last one. On Tue, 2003-10-07 at 00:42, Derek P. Moore wrote: > > Note, those are *apps* not kerberos supplying those. > > Use a kerberized ssh and you have no need for > telnet, > > ssh, ftp, rlogin. rcp, et al.. > > Sorta true, but not really. No, it is true. A kerberized ssh will perform your beloved Kerberos authentication, as well as provide login services, file transfer capabilities, and more. Period. As such, using that setup there is no need for those other apps in such an environment as described. > > And on top of it you get all the other nice things > > that SSH does. Mayeb it's me but I don't consider > > being able to log into a remote machine, launch a > > graphical app and have it display on my screen > weird. > > Even if that machine is through several other "hops" > > of machines. > > To pick a nit: Can't you do this same thing with > telnet? At least as long as you set the DISPLAY > environment variable correctly (or use --display [or > -display]). No you can't. To make it simple: You sit behind a corporate firewall. There is no connectivity from the outside world in to your environment, as they do not allow inbound traffic. As such, no amount of DISPLAY exporting will cause the display form a machine outside the firewall to your machine inside. With SSH, the X connection is tunnelled through the ssh connection itself. By exporting DISPLAY=foo.com:0 you must have a route from the remote machine to yours. Another example is if the local Xserver doesn't allow remote connections, such as when firewalled off by the local machine. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From bill at noreboots.com Tue Oct 7 13:14:10 2003 From: bill at noreboots.com (Bill Anderson) Date: 07 Oct 2003 07:14:10 -0600 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065529901.22051.115.camel@dhcp-116.surrey.redhat.com> References: <20031007043158.16540.qmail@web80001.mail.yahoo.com> <1065529004.722.16.camel@locutus> <1065529901.22051.115.camel@dhcp-116.surrey.redhat.com> Message-ID: <1065532449.722.69.camel@locutus> On Tue, 2003-10-07 at 06:31, Bastien Nocera wrote: > > > > And actually, it has been more than suggested on this list (or one of > > these fedora lists) that Fedora Core could, and is eventually expected > > to, run on something other than the Linux Kernel, such as BSD. And, > > IIRC, that came from a RH email address. Still ready to stand by that > > analogy. :^D > > Then I'll send a message to this list with my Red Hat e-mail address > saying that "eventually, I want Totem with WMA, Sorenson, DVD, and MP3 > playback in Fedora", and you're going to believe me :) Why should I not believe you want those things? Are you saying you'd just up and lie about what you want, and somehow that makes a difference in whether or not the idea of having a Fedora Core that is capable of running on platforms other than intel/linux is not desirable, reasonable or forseeable? If so, I'd say you're taking a turn at the pipe. ;) Ok, as I've said before, I'll leave your precious sacred cow alone. Now drop it. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From hosting at j2solutions.net Tue Oct 7 14:44:17 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Tue, 7 Oct 2003 07:44:17 -0700 Subject: Kind request: Set release version to "10" In-Reply-To: <20031007063606.GD13685@puariko.nirvana> References: <20031007011349.232d6e48.ms-nospam-0306@arcor.de> <20031007063606.GD13685@puariko.nirvana> Message-ID: <200310070744.17031.hosting@j2solutions.net> On Monday 06 October 2003 23:36, Axel Thimm uttered: > Where has anything concerning Fedora Legacy been defined? Isn't that > what this list members are supposed to develop? Dude, I've replied to you a couple times about this... http://www.fedora.us/wiki/FedoraLegacy Legacy will have 7.3 and 9 support initially, possibly more. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (www.mondorescue.org) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From hosting at j2solutions.net Tue Oct 7 14:47:29 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Tue, 7 Oct 2003 07:47:29 -0700 Subject: Requesting Fedora Legacy Mailing List In-Reply-To: <20031007061727.GB13685@puariko.nirvana> References: <1065452165.18004.35.camel@opus> <19972.128.171.123.60.1065477675.squirrel@togami.com> <20031007061727.GB13685@puariko.nirvana> Message-ID: <200310070747.29745.hosting@j2solutions.net> On Monday 06 October 2003 23:17, Axel Thimm uttered: > IMHO I think that some parts of Fedora Legacy are closely related to > Fedora proper, e.g. versioning schemes and the like. > > Wouldn't it be better to have this discussion at fedora-devel? > fedora-devel should know about the needs of fedora-legacy (after all > Fedora Legacy will be collecting Fedora proper every few months). Versioning and such should continue to be discussed here. Fedora-Legacy list is for legacy only issues that a lot of -devel people might not want to hear about. We'll kindly remind you if you start talking about something in -legacy that needs to be discussed in -devel (; -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (www.mondorescue.org) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From garrett at redhat.com Tue Oct 7 15:16:05 2003 From: garrett at redhat.com (Garrett LeSage) Date: Tue, 07 Oct 2003 11:16:05 -0400 Subject: Open Office 1.1 suggestion In-Reply-To: <20031007071442.45974.qmail@web80009.mail.yahoo.com> References: <20031007071442.45974.qmail@web80009.mail.yahoo.com> Message-ID: <3F82D8B5.6000909@redhat.com> Derek P. Moore wrote: >GIMP 1.3 icons ought to be used before creating whole >new ones. That way, the desktop experience is that >much more consistent. > > Derek, Thanks for the suggestion. The GIMP 1.3.x icons do not overlap with the OpenOffice ones enough to use across the board. Also, the current GIMP 1.3.x icons are not Bluecurve in style; in fact, they probably share the same style as the Ximianized OOo icons. Now, however, it might make sense to use as many Bluecurve OOo icons in the GIMP 1.3.x (or 2.x, depending on timeframes), as, as you pointed out, many of them should overlap. Of course, there are many that do not as well. Still, re-use is a good thing. (: Thanks, Garrett From edwardam at interlix.com Tue Oct 7 16:01:29 2003 From: edwardam at interlix.com (Edward Muller) Date: Tue, 07 Oct 2003 11:01:29 -0500 Subject: Does the freeworld repository exist yet? In-Reply-To: <1065461573.18004.56.camel@opus> References: <200310061716.h96HGDm8004032@snark.thyrsus.com> <1065461573.18004.56.camel@opus> Message-ID: <1065542489.8112.20.camel@palin> Is there a mailing list for this repository? On Mon, 2003-10-06 at 12:32, seth vidal wrote: > On Mon, 2003-10-06 at 13:16, Eric S. Raymond wrote: > > Does the freeworld repository exist yet? If so, where is it? > > rpm.livna.org > > this is in the archives. > > -sv > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Edward Muller - http://www.interlix.com - "Open Source Specialists" Dedicated Zope Hosting - Web Hosting - Open Source Consulting Network & PC Service & Support - Custom Programming Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572 Jabber: edwardam at jabber.interlix.com - AIM: edwardam453 - ICQ: 287033 From bfox at redhat.com Tue Oct 7 17:22:18 2003 From: bfox at redhat.com (Brent Fox) Date: Tue, 07 Oct 2003 13:22:18 -0400 Subject: redhat-config-xfree86 with dual head support Message-ID: <1065547338.25887.9.camel@bfox.devel.redhat.com> redhat-config-xfree86-0.9.9-2.noarch.rpm is available in Rawhide now and now supports configuring dual-head monitor setups. You'll need to upgrade to the latest rhpl and kudzu as well. I'm sure there's bugs in it, so please try it out and see if you can break it. If you don't have a dual-head setup, it would still be helpful if you would test to make sure I didn't break the single-head setup accidentally. The UI is a pretty big change from what shipped in Fedora Test 2. Cheers, Brent From steven at silverorange.com Tue Oct 7 18:47:30 2003 From: steven at silverorange.com (Steven Garrity) Date: Tue, 07 Oct 2003 15:47:30 -0300 Subject: Default Folder icon no longer scalable? Message-ID: <3F830A42.3040809@silverorange.com> After installing test2, I noticed that the default folder icon (which is beautiful by the way) is no longer scalable (bitmap only, not svg anymore?). The previous installation I had was RedHat 9, and it did include a scalable version of the default folder icon. Is this intentional? A mistake? Apologies if this isn't the appropriate list. Thanks, Steven Garrity steven at actsofvolition.com From ms-nospam-0306 at arcor.de Tue Oct 7 18:51:06 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 7 Oct 2003 20:51:06 +0200 Subject: Kind request: Set release version to "10" In-Reply-To: <200310070744.17031.hosting@j2solutions.net> References: <20031007011349.232d6e48.ms-nospam-0306@arcor.de> <20031007063606.GD13685@puariko.nirvana> <200310070744.17031.hosting@j2solutions.net> Message-ID: <20031007205106.166a2046.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 7 Oct 2003 07:44:17 -0700, Jesse Keating wrote: > On Monday 06 October 2003 23:36, Axel Thimm uttered: > > Where has anything concerning Fedora Legacy been defined? Isn't that > > what this list members are supposed to develop? > > Dude, I've replied to you a couple times about this... > > http://www.fedora.us/wiki/FedoraLegacy > > Legacy will have 7.3 and 9 support initially, possibly more. No secret. The list announcements and things like that are everywhere. It may sound like splitting hairs, but do you have official confirmation from Red Hat or the Fedora Project committee that "Fedora (!) Legacy" will carry updates for old release of _Red Hat_ (!) Linux? You try to fit RHL Legacy under the Fedora Legacy umbrella. Fedora Legacy -- as defined at fedora.redhat.com -- and a project that extends the Legacy concept to Red Hat Linux, are two different things, albeit with a similar goal. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gwsa0iMVcrivHFQRAurpAJ9/P6IfObO4g3igTi3XnWrVl63vLgCfYkcm XCEm3zsEineCO9IDeNLsEuU= =GsgO -----END PGP SIGNATURE----- From xose at wanadoo.es Tue Oct 7 18:55:37 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Tue, 07 Oct 2003 20:55:37 +0200 Subject: Kind request: Set release version to "10" References: <20031007011349.232d6e48.ms-nospam-0306@arcor.de> <20031007063606.GD13685@puariko.nirvana> <200310070744.17031.hosting@j2solutions.net> <20031007205106.166a2046.ms-nospam-0306@arcor.de> Message-ID: <3F830C29.7000003@wanadoo.es> Michael Schwendt wrote: > It may sound like splitting hairs, but do you have official > confirmation from Red Hat or the Fedora Project committee that > "Fedora (!) Legacy" will carry updates for old release of > _Red Hat_ (!) Linux? There is a new Fedora-legacy-list: Fedora Legacy list list is for the discussion of the Fedora Legacy project. This project exists to maintain security/bug backports for EOLd Red Hat Linux and Fedora Core releases. https://lists.dulug.duke.edu/mailman/listinfo/fedora-legacy-list From hosting at j2solutions.net Tue Oct 7 19:09:24 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Tue, 7 Oct 2003 12:09:24 -0700 Subject: Kind request: Set release version to "10" In-Reply-To: <20031007205106.166a2046.ms-nospam-0306@arcor.de> References: <200310070744.17031.hosting@j2solutions.net> <20031007205106.166a2046.ms-nospam-0306@arcor.de> Message-ID: <200310071209.24578.hosting@j2solutions.net> On Tuesday 07 October 2003 11:51, Michael Schwendt wrote: > On Tue, 7 Oct 2003 07:44:17 -0700, Jesse Keating wrote: > > On Monday 06 October 2003 23:36, Axel Thimm uttered: > > > Where has anything concerning Fedora Legacy been defined? Isn't > > > that what this list members are supposed to develop? > > > > Dude, I've replied to you a couple times about this... > > > > http://www.fedora.us/wiki/FedoraLegacy > > > > Legacy will have 7.3 and 9 support initially, possibly more. > > No secret. The list announcements and things like that are > everywhere. > > It may sound like splitting hairs, but do you have official > confirmation from Red Hat or the Fedora Project committee that > "Fedora (!) Legacy" will carry updates for old release of > _Red Hat_ (!) Linux? Fedora Legacy was coined by Warren of Fedora.US. Warren was doing nothing with Legacy, mostly because it was there for the community to pick up. I've picked it up, and with Warren's blessings, I'm running with it. There isn't much to "confirm" with Red Hat, legacy is what the community wants Legacy to be. > You try to fit RHL Legacy under the Fedora Legacy umbrella. > > Fedora Legacy -- as defined at fedora.redhat.com -- and a project > that extends the Legacy concept to Red Hat Linux, are two different > things, albeit with a similar goal. The definition of Fedora Legacy at fedora.redhat.com needs to be updated. It was made long ago, prior to my involvement with the project. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From garrett at redhat.com Tue Oct 7 19:41:50 2003 From: garrett at redhat.com (Garrett LeSage) Date: Tue, 07 Oct 2003 15:41:50 -0400 Subject: Default Folder icon no longer scalable? In-Reply-To: <3F830A42.3040809@silverorange.com> References: <3F830A42.3040809@silverorange.com> Message-ID: <3F8316FE.60701@redhat.com> Steven Garrity wrote: > After installing test2, I noticed that the default folder icon (which > is beautiful by the way) is no longer scalable (bitmap only, not svg > anymore?). The previous installation I had was RedHat 9, and it did > include a scalable version of the default folder icon. Thanks. It was never SVG. I have included multiple versions of the folder at different sizes, but it seems that it wants to currently scale only from the 48x48 version. Perhaps it is because I only have a 96x96 version as the largest size. It could be quite possible that I need to include a 128x128 variety as well. I will see if this is, in fact the issue. Regardless, it should scale from a larger version if you are up-scaling. We totally redid the way the icons are maintained. It is much better now; it is easier for me to make updates and keep track of versions. Unfortunately, there are a couple of bugs here and there. This issue is one of those. > Is this intentional? A mistake? Apologies if this isn't the > appropriate list. It's a bug. Please file it in Bugzilla. http://bugzilla.redhat.com/ Thanks, Garrett From edwardam at interlix.com Tue Oct 7 20:10:07 2003 From: edwardam at interlix.com (Edward Muller) Date: Tue, 07 Oct 2003 15:10:07 -0500 Subject: VNC Message-ID: <1065557407.4889.45.camel@palin> Any reason why RealVNC 4.0b4 is included in Fedora instead of the current tightvnc, of which an older version was included in RHL 9? -- Edward Muller - http://www.interlix.com - "Open Source Specialists" Dedicated Zope Hosting - Web Hosting - Open Source Consulting Network & PC Service & Support - Custom Programming Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572 Jabber: edwardam at jabber.interlix.com - AIM: edwardam453 - ICQ: 287033 From derek.moore at sbcglobal.net Tue Oct 7 22:06:55 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Tue, 7 Oct 2003 15:06:55 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065529004.722.16.camel@locutus> Message-ID: <20031007220655.72860.qmail@web80002.mail.yahoo.com> > Good then quit bogarting the crack pipe. I much prefer marijuana pipes. And it's the nature of marijuana, and free software, that you share. (Coincidence? I think not!) So here: *pass* Okay, I'm done now, Derek From derek.moore at sbcglobal.net Tue Oct 7 22:54:44 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Tue, 7 Oct 2003 15:54:44 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065530307.737.34.camel@locutus> Message-ID: <20031007225444.72837.qmail@web80001.mail.yahoo.com> > > Kerberos provides those features with Kerberized > > ftp, rcp, etc. > > *sigh* another person who can't seem to distinguish > between an a authentication mechanism and apps > compiled with support for it. Why even your words > above should tell you that: "kerberized ftp,rcp" the > ftp or rcp, telnet apps are providing those services, > kerberos is providing the authentication. Kerberos is providing the authentication. Kerberos is also providing the session-level encryption. And, as I pointed out in that very email, Kerberos /also/ provides telnet, rlogin, rcp, rsh, and ftp clients and daemons (i.e., they are a part of MIT's and Heimdal's Kerberos distributions). (Just as SSH provides scp and sftp client and daemons.) > > > I'd argue that SSH would be a massive need in > > > that environment. > > > > Not really true. With Kerberos: telnet, ftp, rsh, > > rcp, etc., etc., automagically become secure. Not > > only in terms of authentication, but also in terms > > of strong encryption of sessions. > > Read the post again, with open eyes this time and > see that the environment described uses a kerberized > ssh to do all of those functions, and that therefore > qualifies as a "kerberized environment" that relies > heavily on SSH. You are blindly associating apps > compiled with kerberos *support* with the Kerberos > itself. I read the post again, here's what I got: You were saying, "I would even suggest that SSH would be a massive need in a Kerberized environment." I was saying, "No, SSH is a massive need in a non-Kerberized environment. It's not a massive need in Kerberized environments, because, in Kerberized environments, ftp, rcp, rlogin, and the other services that SSH attempts to replace are no longer insecure. Therefore, the massiveness of the need for SSH is lessened in comparison to non-Kerberized networks." That doesn't, however, mean that SSH isn't useful in a Kerberized environment. It certainly is /very/ useful on Kerberized networks (and I use it more than rlogin, rcp, etc.). (Actually, I never use the r* commands.) > One is a protocol, the other is not. Think of SSL > and you may start to get the picture. SSL doesn't > server web pages, or serve email. It provides an > encryption layer. I can use SSL on Apache, Zope, or > dozens of other servers. Yet you don't claim SSL > provides http service. Kerberos, like SSL is a > supporting library/protocol for something else; > it does *nothing* on it's own. SSH is it's own > app/server. Apples and Oranges. Last I checked SSH was a protocol defined the IETF SECSH working group. You're saying SSH is not a protocol? As I see it: SSH is a protocol; Kerberos is a protocol. There are software distributions of SSH which provide clients and servers for remote & secure login and file transfer; there are software distributions of Kerberos which provide clients and servers for remote & secure login, file transfer, and much more. In other words, Kerberos software distributions provide clients & servers just as SSH software distributions provide clients & servers. KTH-KRB provides rsh, rlogin, rcp, telnet, ftp, pop, kx, kauth. Heimdal provides telnet, rsh, pop, ftp. MIT provides telnet, rlogin, ftp, rsh, rcp, ksu. Seems more like Apples vs. Apple Pie, Apple Juice, Apple Sauce, Apple Cider, etc. *grin* Or something. > No, K requires additional apps to achieve some of > the functionality of SSH. Period. Just as SSH needs apps to achieve the functionality of SSH? Or just as Kerberos needs apps to achieve the functionality of Kerberos? Or just as anything needs an app to achieve the functionality that that app attempts to achieve? *smile* ... Actually, in the end, I get your point (and I hope you get mine [if I even have one, that is]). We're gettin' nowhere fast with this thread (other than I'm havin' a lot o' fun with all the word games). Long live Kerberized SSH! Derek From derek.moore at sbcglobal.net Tue Oct 7 23:25:10 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Tue, 7 Oct 2003 16:25:10 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065530307.737.34.camel@locutus> Message-ID: <20031007232510.68477.qmail@web80007.mail.yahoo.com> > *sigh* another person who can't seem to distinguish > between an a authentication mechanism and apps > compiled with support for it. Why even your words > above should tell you that: "kerberized ftp,rcp" the > ftp or rcp, telnet apps are providing those services, > kerberos is providing the authentication. Oh, I almost forgot... SSH is really three things: 1) a Transport Layer Protocol (SSH-TRANS); 2) a User Authentication Protocol (SSH-USERAUTH); 3) a Connection Protocol (SSH-CONNECT). So, ssh (the binary, not the protocol), sftp, and scp are seperate *apps* which build functionality on top of an underlying protocol. Just as Kerberized ftp, rcp, rsh, rlogin, etc. are *apps* which build functionality on top of an underlying protocol. Now who can't distinguish between protocols and the apps that are compiled to support them?? Huh? Kerberos & SSH are beginning to sound more and more like apples. "I was right, you were wrong, I'm gonna sing the 'I Was Right Song'!" Derek From otaylor at redhat.com Tue Oct 7 23:47:29 2003 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 07 Oct 2003 19:47:29 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <3F8004E1.7020808@zonnet.nl> References: <3F8004E1.7020808@zonnet.nl> Message-ID: <1065570448.32391.20.camel@poincare.devel.redhat.com> [ CC'ing and setting Reply-To to fedora-devel ] On Sun, 2003-10-05 at 07:47, Jaap A. Haitsma wrote: > I've installed Severn including all the updates (except Mozilla because > mozilla mail seems to freeze according to all the posts on this list > after updating) on my laptop (A Dell Latitude C600). > > First thing I noticed that booting was a lot slower (I even thought the > init script was frozen). Then I changed the GRAPHICAL_BOOT variable in > /etc/syconfig/init to no. Booting time reduced from 2 minutes till 1 minute. > > The problem seems to be the kudzu service, which probes for new devices. > If I disable the kudzu service a graphical boot takes also 1 minute. > > Anybody experiencing the same thing? The problem is likely that kudzu thinks your hardware has changed and is patiently waiting on the other screen waiting you to press a key. This will add 30 seconds to the boot time. Then by disabling kudzu you gain another 8-10 seconds. Jonathan and Bill are working on a fix for this; if kudzu wants to interact with the user, a vte terminal will appear on the graphical boot screen. I did some timing of booting with and without rhgb this evening and the conclusion is that rhgb slows the entire boot (on a PIII-700 with a similar-era hard drive) by about 20 seconds, from ~1:00 to ~1:20. This slow down is virtually all in starting up rhgb ... from the point where X takes control to the point where rhgb appears on the screen is just about 20 seconds; likely this time is mostly spent simply reading in libraries from disk, though there are some puzzling factors: - When booting up without rhgb, starting gdm (X => appears on screen) takes around 10 seconds. But gdm uses all the libraries that rhgb uses and more. - gdm is no faster to start when rhgb has started before, even though many of the libraries that gdm needs should already be in ram. - Running rhgb from runlevel 3 "hot" takes about 4 seconds from X => appears on screen. - Running gdm from runlevel 3 "hot" takes about 5 seconds from X => appears on screen. Possible explanations of these facts that really don't convince me: A) Many of the libraries used by rhgb and gdm are used by various bits of the init process and are loaded parallelized with other tasks between the point that rhgb starts and the point that gdm starts. (This only makes sense if most of the load time for rhgb was non-GUI libraries. Which I don't believe.) B) One of the init steps that runs *after* we start rhgb speeds up the system by a large factor. (What? /etc/sysconfig/harddisks is run later but does nothing on this test system) Next thing I want to do is to boot into runlevel 3 and see how long rhgb takes to run cold there. (Both A) and B) predict that it should take around 9-10 seconds, so it can't distinguish between them. But if it takes much longer that would tend to disprove both of them.) Regards, Owen From otaylor at redhat.com Wed Oct 8 00:22:11 2003 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 07 Oct 2003 20:22:11 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <1065570448.32391.20.camel@poincare.devel.redhat.com> References: <3F8004E1.7020808@zonnet.nl> <1065570448.32391.20.camel@poincare.devel.redhat.com> Message-ID: <1065572531.32391.25.camel@poincare.devel.redhat.com> On Tue, 2003-10-07 at 19:47, Owen Taylor wrote: > Possible explanations of these facts that really don't convince me: > > A) Many of the libraries used by rhgb and gdm are used by various > bits of the init process and are loaded parallelized with > other tasks between the point that rhgb starts and the point > that gdm starts. (This only makes sense if most of the load time for > rhgb was non-GUI libraries. Which I don't believe.) > > B) One of the init steps that runs *after* we start rhgb speeds up > the system by a large factor. (What? /etc/sysconfig/harddisks > is run later but does nothing on this test system) > > Next thing I want to do is to boot into runlevel 3 and see how long > rhgb takes to run cold there. > > (Both A) and B) predict that it should take around 9-10 seconds, so it > can't distinguish between them. But if it takes much longer that would > tend to disprove both of them.) Takes 8 seconds. Which is consistent with these theories and many others. So, I tried: - Boot into runlevel 1. Run rhgb. Run rhgb. 22 seconds from X => on screen - Remove all network services and xfs from runlevel 3. Run rhgb. 8 seconds from X => on screen - Remove *all* services from runlevel 3 (syslog and all) Run rhgb. 8 seconds from X => on screen So, the evidence at this point is that with *more* services in runlevel 1 then in runlevel 3, starting in runlevel 1 takes 10+ seconds extra. In fact, I can use 'telinit' to switch between the two levels and observe this. So, now I need to figure out what is different between runlevel 1 and runlevel 3 other than the services running. Regards, Owen From otaylor at redhat.com Wed Oct 8 02:19:30 2003 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 07 Oct 2003 22:19:30 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <1065572531.32391.25.camel@poincare.devel.redhat.com> References: <3F8004E1.7020808@zonnet.nl> <1065570448.32391.20.camel@poincare.devel.redhat.com> <1065572531.32391.25.camel@poincare.devel.redhat.com> Message-ID: <1065579570.32391.30.camel@poincare.devel.redhat.com> On Tue, 2003-10-07 at 20:22, Owen Taylor wrote: > So, I tried: > > - Boot into runlevel 1. Run rhgb. > Run rhgb. 22 seconds from X => on screen > - Remove all network services and xfs from runlevel 3. > Run rhgb. 8 seconds from X => on screen > - Remove *all* services from runlevel 3 (syslog and all) > Run rhgb. 8 seconds from X => on screen > > So, the evidence at this point is that with *more* services in > runlevel 1 then in runlevel 3, starting in runlevel 1 takes 10+ > seconds extra. > > In fact, I can use 'telinit' to switch between the two levels > and observe this. > > So, now I need to figure out what is different between runlevel 1 > and runlevel 3 other than the services running. OK, tracked things down. Basically the xfs init script and fc-cache are both making each other think that the font information in fonts.dir and fonts.cache-1 files are out of date, so all the users have to create their own fonts cache in $HOME/.fonts-cache-1. rhgb is getting run without $HOME set, so it can't even look in /root/.fonts.cache-1. I think we can fix up the xfs init script and address the problem; should also make user logins work better, especially in NFS homedir situations. Regards, Owen From alexl at redhat.com Wed Oct 8 08:37:34 2003 From: alexl at redhat.com (Alexander Larsson) Date: 08 Oct 2003 10:37:34 +0200 Subject: Default Folder icon no longer scalable? In-Reply-To: <3F8316FE.60701@redhat.com> References: <3F830A42.3040809@silverorange.com> <3F8316FE.60701@redhat.com> Message-ID: <1065602254.22938.150.camel@localhost.localdomain> On Tue, 2003-10-07 at 21:41, Garrett LeSage wrote: > Steven Garrity wrote: > > > After installing test2, I noticed that the default folder icon (which > > is beautiful by the way) is no longer scalable (bitmap only, not svg > > anymore?). The previous installation I had was RedHat 9, and it did > > include a scalable version of the default folder icon. > > > Thanks. > > It was never SVG. I have included multiple versions of the folder at > different sizes, but it seems that it wants to currently scale only from > the 48x48 version. Perhaps it is because I only have a 96x96 version as > the largest size. It could be quite possible that I need to include a > 128x128 variety as well. I will see if this is, in fact the issue. > > Regardless, it should scale from a larger version if you are up-scaling. > > We totally redid the way the icons are maintained. It is much better > now; it is easier for me to make updates and keep track of versions. > Unfortunately, there are a couple of bugs here and there. This issue is > one of those. I wonder whats causing it though. It should use the 96x96 version of the icon when scaling up larger than 48x48, but it doesn't see to do that. I'm not sure why. > It's a bug. Please file it in Bugzilla. http://bugzilla.redhat.com/ Its already reported as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106277 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a witless native American paramedic She's a vivacious blonde lawyer with only herself to blame. They fight crime! From alexl at redhat.com Wed Oct 8 08:40:30 2003 From: alexl at redhat.com (Alexander Larsson) Date: 08 Oct 2003 10:40:30 +0200 Subject: Default Folder icon no longer scalable? In-Reply-To: <1065602254.22938.150.camel@localhost.localdomain> References: <3F830A42.3040809@silverorange.com> <3F8316FE.60701@redhat.com> <1065602254.22938.150.camel@localhost.localdomain> Message-ID: <1065602429.22938.156.camel@localhost.localdomain> On Wed, 2003-10-08 at 10:37, Alexander Larsson wrote: > On Tue, 2003-10-07 at 21:41, Garrett LeSage wrote: > > Steven Garrity wrote: > > > > > After installing test2, I noticed that the default folder icon (which > > > is beautiful by the way) is no longer scalable (bitmap only, not svg > > > anymore?). The previous installation I had was RedHat 9, and it did > > > include a scalable version of the default folder icon. > > > > > > Thanks. > > > > It was never SVG. I have included multiple versions of the folder at > > different sizes, but it seems that it wants to currently scale only from > > the 48x48 version. Perhaps it is because I only have a 96x96 version as > > the largest size. It could be quite possible that I need to include a > > 128x128 variety as well. I will see if this is, in fact the issue. > > > > Regardless, it should scale from a larger version if you are up-scaling. > > > > We totally redid the way the icons are maintained. It is much better > > now; it is easier for me to make updates and keep track of versions. > > Unfortunately, there are a couple of bugs here and there. This issue is > > one of those. > > I wonder whats causing it though. It should use the 96x96 version of the > icon when scaling up larger than 48x48, but it doesn't see to do that. > I'm not sure why. > > > It's a bug. Please file it in Bugzilla. http://bugzilla.redhat.com/ > > Its already reported as: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106277 Ah, i know what it is. The 96x96/filesystems dir is not listed in the Bluecurve index.theme file. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a fast talking moralistic cat burglar on a mission from God. She's a scantily clad antique-collecting vampire with only herself to blame. They fight crime! From buildsys at porkchop.devel.redhat.com Wed Oct 8 09:58:34 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Wed, 8 Oct 2003 05:58:34 -0400 Subject: rawhide report: 20031008 changes Message-ID: <200310080958.h989wYZ13042@porkchop.devel.redhat.com> New package fedora-logos Red Hat-related icons and pictures. New package openoffice.org OpenOffice.org comprehensive office suite. New package redhat-config-netboot redhat-config-netboot is an network booting/install configuration utility Updated Packages: XFree86-4.3.0-37 ---------------- * Mon Oct 06 2003 Mike A. Harris 4.3.0-37 - Added XFree86-4.3.0-radeon-autodetect-pci-or-agp-cards.patch which is a backport from CVS of new code to autodetect wether a given card is AGP or PCI by reading PCI config space. This simplifies future updates to the radeon driver for future Radeon hardware. Older driver update patches can further be simplified later on to remove some unnecessary cruft from them. - Updated XFree86-4.3.0-radeon-support-backport-from-CVS-v2.patch to fix a few missing chip IDs in a section of radeon_driver.c - Enabled DRI support for ppc for build_cambridge target * Mon Oct 06 2003 Mike A. Harris 4.3.0-36.2 - This build contains conditionalized build changes for RHL 8.0, intended to allow pain free compilation and installation of 4.3.0 in RHL 8.0. All changes are conditionalized to build_psyche to limit their effects strictly to RHL 8.0 builds unless the change is an obvious no-risk fix that wont harm current development or erratum. - Renamed fontconfig-2.1-slighthint.patch due to a problem which was reported by a user recompiling XFree86 on Red Hat Linux 8.0, getting a fontconfig dependancy, recompiling and installing fontconfig, and then trying to recompile XFree86 from their previously installed XFree86 source rpm. Both XFree86 and fontconfig contain a patch of the same name, and the fontconfig one overwrote the one from the XFree86 packaging. The two patches are identical but the directory paths modified to match XFree86's fontconfig path. The new patch name is XFree86-4.3.0-redhat-fontconfig-2.1-slighthint.patch - Added "Provides: Xft-devel = %{xftver}" to XFree86-devel and "Provides: Xft = %{xftver}" to XFree86-libs, both wrapped with build_psyche for Red Hat Linux 8.0 compatibilty as many packages brokenly hardcode Xft dependancies - Disabled the Conflicts: Xft-devel and Conflicts: Xft lines from the -libs and -devel packages as they seem to prevent upgrades from working from XFree86 4.2.x to 4.3.0 on RHL 8.0 systems as the package both provides, and obsoletes, Xft and Xft-devel, and the 'conflicts' line seems to make it conflict with itself. - Fixed some broken with_fontconfig conditionalization for cases where XFree86 supplied fontconfig is used for building, just so the option actually works if someone sets it. anaconda-9.0.95-0.20031007180519 -------------------------------- * Tue Oct 07 2003 Anaconda team - built new version from CVS * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 * Mon Sep 09 2002 Jeremy Katz - can't buildrequire dietlibc and kernel-pcmcia-cs since they don't always exist * Wed Aug 21 2002 Jeremy Katz - added URL * Thu May 23 2002 Jeremy Katz - add require and buildrequire on rhpl * Tue Apr 02 2002 Michael Fulbright - added some more docs * Fri Feb 22 2002 Jeremy Katz - buildrequire kernel-pcmcia-cs as we've sucked the libs the loader needs to there now * Thu Feb 07 2002 Michael Fulbright - goodbye reconfig * Thu Jan 31 2002 Jeremy Katz - update the BuildRequires a bit * Fri Jan 04 2002 Jeremy Katz - ddcprobe is now done from kudzu * Wed Jul 18 2001 Jeremy Katz - own /usr/lib/anaconda and /usr/share/anaconda * Fri Jan 12 2001 Matt Wilson - sync text with specspo * Thu Aug 10 2000 Matt Wilson - build on alpha again now that I've fixed the stubs * Wed Aug 09 2000 Michael Fulbright - new build * Fri Aug 04 2000 Florian La Roche - allow also subvendorid and subdeviceid in trimpcitable * Fri Jul 14 2000 Matt Wilson - moved init script for reconfig mode to /etc/init.d/reconfig - move the initscript back to /etc/rc.d/init.d - Prereq: /etc/init.d * Thu Feb 03 2000 Michael Fulbright - strip files - add lang-table to file list * Wed Jan 05 2000 Michael Fulbright - added requirement for rpm-python * Mon Dec 06 1999 Michael Fulbright - rename to 'anaconda' instead of 'anaconda-reconfig' * Fri Dec 03 1999 Michael Fulbright - remove ddcprobe since we don't do X configuration in reconfig now * Tue Nov 30 1999 Michael Fulbright - first try at packaging reconfiguration tool aspell-0.50.3-16 ---------------- * 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 aspell-da-0.50-6 ---------------- * Tue Oct 07 2003 Adrian Havill 6:0.50-6 - add epoch to comp for the version fork (#106447) aspell-sv-0.50-4 ---------------- * Tue Oct 07 2003 Adrian Havill 4:0.50-4 - added epoch bind-9.2.2.P3-5 --------------- * Tue Oct 07 2003 Daniel Walsh 9.2.2.P3-5 - Try again curl-7.10.6-5 ------------- * Tue Oct 07 2003 Adrian Havill 7.10.6-5 - match serverAltName certs with SSL (#106168) * Tue Sep 16 2003 Adrian Havill 7.10.6-4.1 - bump n-v-r for RHEL ddd-3.3.7-3 ----------- * Wed Oct 08 2003 Than Ngo 3.3.7-3 - fixed utf-8 issue, bug #84816 filesystem-2.2.1-5 ------------------ * Tue Oct 07 2003 Than Ngo 2.2.1-5 - add /usr/share/xsessions gdm-2.4.4.3-5 ------------- * Tue Oct 07 2003 Alexander Larsson 1:2.4.4.3-5 - Fix greeter line-breaking crash (rest of #106189) * Tue Oct 07 2003 Alexander Larsson 1:2.4.4.3-4 - Set the BaseXSession properly in the config. - This fixes parts of bug #106189 gedit-2.4.0-2 ------------- * Tue Oct 07 2003 Owen Taylor 1:2.4.0-2 - Fix bug with multibyte chars in shell-output plugin (#104027, Jens Petersen) - Add missing BuildRequires on eel2, aspell-devel (#87746, Alan Cox) - Add versioned Requires on eel2, libgnomeui (#103363, Jens Petersen) gnome-media-2.4.0-1 ------------------- * Tue Oct 07 2003 Havoc Pennington 2.4.0-1 - 2.4.0 kdebase-3.1.4-2 --------------- * Tue Oct 07 2003 Than Ngo 6:3.1.4-2 - install kde.desktop in /usr/share/xsession - add more translations for kde.desktop (stolen from kde 3.2 cvs) modutils-2.4.25-13 ------------------ * Tue Oct 07 2003 Bill Nottingham 2.4.25-13 - fix handling of updates path (#106482) rawhide-release-20031008-1 -------------------------- redhat-config-bind-2.0.0-16 --------------------------- * Tue Oct 07 2003 Dan Walsh 2.0.0-16 - Allow wildcard hostnames. redhat-config-packages-1.2.5-2 ------------------------------ * Tue Oct 07 2003 Jeremy Katz 1.2.5-2 - rebuild * Wed Sep 24 2003 Jeremy Katz 1.2.5-1 - Throw out packages which aren't for our arch earlier (#105005) * Fri Sep 19 2003 Jeremy Katz 1.2.4-1 - fix requirement formatting (#104715) * Thu Sep 04 2003 Jeremy Katz 1.2.3-1 - fix help message * Fri Aug 29 2003 Jeremy Katz 1.2.2-1 - fix for ppc64 (#103375) * Wed Aug 20 2003 Jeremy Katz 1.2.1-1 - fix for case without order in comps file (#102278) * Tue Aug 12 2003 Jeremy Katz 1.2.0-1 - update for multilib fun * Fri Apr 18 2003 Jeremy Katz 1.1.9-1 - we can't check sigs with the db closed (#88343) * Mon Feb 24 2003 Jeremy Katz 1.1.8-1 - fix for backwards of what I expected flags stuff in single package mode (reported on phoebe list) * Sun Feb 23 2003 Jeremy Katz 1.1.7-1 - add startup notification - update translations * Tue Feb 11 2003 Jeremy Katz - update requires on rpm (#84039) * Sun Feb 09 2003 Jeremy Katz 1.1.6-1 - various minor bugfixes * Mon Jan 13 2003 Jeremy Katz 1.1.5-1 - name change in desktop file * Fri Jan 03 2003 Than Ngo 1.1.4-1 - fix bug #80468 * Thu Jan 02 2003 Jeremy Katz 1.1.3-1 - add url support (--tree={ftp,http}://) (#79000) * Wed Jan 01 2003 Jeremy Katz 1.1.2-1 - few minor fixes (#80800) * Sat Dec 28 2002 Jeremy Katz 1.1.1-1 - fs for cds can now be udf,iso9660 as well - fix up state reading to be faster (bug in rpm 4.2 porting) * Wed Oct 30 2002 Jeremy Katz - update to work with rpm 4.2 * Fri Oct 11 2002 Jeremy Katz - add scrollkeeper to removal blacklist so that we can't mistakenly most of GNOME (#74958) - RPMTAG_PROVIDES can be None in some cases; don't try to iterate over None (#74877) - don't allow src.rpms to be installed into the database (#75388) - fix size string translation (#75584) - fix spanish translation which caused a segfault due to missing (#74973) - make instProvs and providesDict use lists as their values so we don't remove packages erroneously if multiple packages provide something (#75661) - more translation updates * Tue Sep 03 2002 Jeremy Katz - update translations * Fri Aug 30 2002 Jeremy Katz - set hint so that nautilus won't pop up windows while installing - fix pixmap path for CDs - add a way for centering for firstboot - miscellaneous other minor bug fixes * Thu Aug 29 2002 Jeremy Katz - oops, another typo fix build * Thu Aug 29 2002 Jeremy Katz - obsolete gnorpm - other minor fixes - fix bad interactions with magicdev * Wed Aug 28 2002 Jeremy Katz - add README * Wed Aug 28 2002 Jeremy Katz - handle extra CDs having dependencies on packages within the main distribution * Tue Aug 27 2002 Jeremy Katz - handle multiple CD-ROM drives more sanely - start handling packages from multiple sources better - fix textdomain of specspo * Sat Aug 24 2002 Jeremy Katz - fix a typo * Sat Aug 24 2002 Jeremy Katz - Make the single-package tool faster if dependencies are already installed. - Various other minor bugfixes * Thu Aug 15 2002 Preston Brown - handle package installation in KDE as well. * Wed Aug 14 2002 Jonathan Blandford - new version. Added the single-package tool * Mon Aug 12 2002 Jeremy Katz - another new version with lots more changes - add sample autorun to included docs * Tue Aug 06 2002 Jonathan Blandford - New version * Sun Aug 04 2002 Jeremy Katz - huge numbers of changes. starting to work a lot better * Fri Jul 26 2002 Jeremy Katz - fix desktop file so that we show up in the main apps menu - fix requires * Tue Jul 23 2002 Jonathan Blandford - Create spec file redhat-config-printer-0.6.77-1 ------------------------------ * Tue Oct 07 2003 Tim Waugh 0.6.77-1 - 0.6.77: - Fixed traceback involving IPP transport (bug #106284). - Avoid smbclient's -N option unless absolutely necessary (bug #106395). rhgb-0.10.2-1 ------------- * Tue Oct 07 2003 Jonathan Blandford 0.10.2-1 - new splash code xmlto-0.0.15-1 -------------- * Tue Oct 07 2003 Tim Waugh 0.0.15-1 - 0.0.15. xscreensaver-4.13-1 ------------------- * Tue Oct 07 2003 Bill Nottingham 1:4.13-1 - take out flag-with-logo, don't require redhat-logos (#106046) - update to 4.13 From twaugh at redhat.com Wed Oct 8 10:01:20 2003 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 8 Oct 2003 11:01:20 +0100 Subject: VNC In-Reply-To: <1065557407.4889.45.camel@palin> References: <1065557407.4889.45.camel@palin> Message-ID: <20031008100120.GX2229@redhat.com> On Tue, Oct 07, 2003 at 03:10:07PM -0500, Edward Muller wrote: > Any reason why RealVNC 4.0b4 is included in Fedora instead of the > current tightvnc, of which an older version was included in RHL 9? RealVNC is better in a number of important respects: 1. It works on more architectures 2. It is built against a current XFree86 source tree and so is more maintainable 3. It provides vnc.so, for exporting a running display efficiently While RealVNC lacks some of the encodings that TightVNC has, it also provides ZRLE and colour peeling, which IMHO make up for that. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From warren at togami.com Wed Oct 8 10:22:22 2003 From: warren at togami.com (Warren Togami) Date: Wed, 08 Oct 2003 00:22:22 -1000 Subject: Does the freeworld repository exist yet? In-Reply-To: <47273e36020c5e07d3@[192.168.170.10]> References: <47168e03020c5c07d3@[192.168.170.10]> <47273e36020c5e07d3@[192.168.170.10]> Message-ID: <3F83E55E.6060100@togami.com> Nils O. Sel?sdal wrote: > > Blender + openal can probably be rebuilt without smpeg. > Should it be done ? I would prefer that it wouldn't. Rather than distribute crippled binaries, why not instead make binary compatible dummy packages for the US-centric distribution. Here's an example of libdvdcss. https://bugzilla.fedora.us/show_bug.cgi?id=453 Ideally a binary compatible dummy package would contain everything necessary to link against it, but infringing functionality is cut out and replaced by annoying pop-up windows that say the function is removed and why, but not how to fix it because that would be a violation of the DMCA in many cases. And yes I am completely serious about annoying pop-up windows. TRY the libdvdcss contained in the linked Bugzilla report above. The the American user would then be legally powerless to do anything, but those living in other countries where it is not illegal could possibly replace the real library if the package exists. Being a patriotic and law abiding American, it would be treasonous to my country's corporate interests to point to such a theoretical repository. God bless America and everything it stands for. I love this country. Don't you? Warren From matthias at rpmforge.net Wed Oct 8 11:43:22 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Wed, 8 Oct 2003 13:43:22 +0200 Subject: Does the freeworld repository exist yet? In-Reply-To: <3F83E55E.6060100@togami.com> References: <47168e03020c5c07d3@[192.168.170.10]> <47273e36020c5e07d3@[192.168.170.10]> <3F83E55E.6060100@togami.com> Message-ID: <20031008134322.1939da38.matthias@rpmforge.net> Warren Togami wrote : > And yes I am completely serious about annoying pop-up windows. TRY the > libdvdcss contained in the linked Bugzilla report above. I've not tried it, but how does it react if used from the console with no X? Say for instance when used through transcode? I'm not convinced "dummy" libraries are a good answer to legal problems anyway. > The the American user would then be legally powerless to do anything, > but those living in other countries where it is not illegal could > possibly replace the real library if the package exists. > > Being a patriotic and law abiding American, it would be treasonous to my > country's corporate interests to point to such a theoretical repository. If you start thinking that way, then free software in general is something bad for the US's corporate (financial) interests. Microsoft has the quasi-monopoly worldwide in the Operating System field, and market shares "lost" towards free software often means less money leaving foreign countries to go back to the US, because of local developers, distributors, support... > God bless America and everything it stands for. I love this country. > Don't you? I don't know about Nils (who seems to be Norwegian), to whom you asked this, but I know I sure don't love America. And I also don't believe in God, so I guess I wouldn't make a good patriot anyhow. Getting too much off-topic I guess. Still, if I were American but with the European mentality I have, I'd be doing all that is possible to fight against the DMCA, software patents, and all their abuses. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20031007 - Linux kernel 2.4.22-20.1.2024.2.36.nptl Load : 0.17 0.17 0.14 From nos at utel.no Wed Oct 8 12:28:23 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Wed, 08 Oct 2003 14:28:23 +0200 Subject: Does the freeworld repository exist yet? In-Reply-To: <4bf3e578030d2907d3@[192.168.170.10]> References: <47168e03020c5c07d3@[192.168.170.10]><47273e36020c5e07d3@[192.168.170.10]> <4bf3e578030d2907d3@[192.168.170.10]> Message-ID: <4c61b845030d5507d3@[192.168.170.10]> On Wed, 2003-10-08 at 12:22, Warren Togami wrote: > Nils O. Selsdal wrote: > > > > Blender + openal can probably be rebuilt without smpeg. > > Should it be done ? > > I would prefer that it wouldn't. Rather than distribute crippled > binaries, why not instead make binary compatible dummy packages for the > US-centric distribution. Here's an example of libdvdcss. > > https://bugzilla.fedora.us/show_bug.cgi?id=453 > Ideally a binary compatible dummy package would contain everything > necessary to link against it, but infringing functionality is cut out > and replaced by annoying pop-up windows that say the function is removed > and why, but not how to fix it because that would be a violation of the > DMCA in many cases. > > And yes I am completely serious about annoying pop-up windows. TRY the > libdvdcss contained in the linked Bugzilla report above. It's a nice concept, but seems like a pain to keep the real library and the dummy one in sync as the library gets updated. > The the American user would then be legally powerless to do anything, > but those living in other countries where it is not illegal could > possibly replace the real library if the package exists. It will probably also be a pain for users tracking/deciding wether it is illegal in their country or not.(for the 1% of users that actually care..) > Being a patriotic and law abiding American, it would be treasonous to my > country's corporate interests to point to such a theoretical repository. > > God bless America and everything it stands for. I love this country. > Don't you? I'll probably not comment on that.. -- 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 rdieter at math.unl.edu Wed Oct 8 12:56:22 2003 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 8 Oct 2003 07:56:22 -0500 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <20031008122600.5487.47042.Mailman@listman.back-rdu.redhat.com> References: <20031008122600.5487.47042.Mailman@listman.back-rdu.redhat.com> Message-ID: <200310080756.22990.rdieter@math.unl.edu> Owen Taylor wrote: > OK, tracked things down. Basically the xfs init script and > fc-cache are both making each other think that the font information > in fonts.dir and fonts.cache-1 files are out of date, so > all the users have to create their own fonts cache in > $HOME/.fonts-cache-1. Yep, http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97240 -- Rex From Axel.Thimm at physik.fu-berlin.de Wed Oct 8 13:05:55 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 8 Oct 2003 15:05:55 +0200 Subject: Fedora Legacy definition (was: Kind request: Set release version to "10") In-Reply-To: <200310070744.17031.hosting@j2solutions.net> References: <20031007011349.232d6e48.ms-nospam-0306@arcor.de> <20031007063606.GD13685@puariko.nirvana> <200310070744.17031.hosting@j2solutions.net> Message-ID: <20031008130555.GB15147@puariko.nirvana> On Tue, Oct 07, 2003 at 07:44:17AM -0700, Jesse Keating wrote: > On Monday 06 October 2003 23:36, Axel Thimm uttered: > > Where has anything concerning Fedora Legacy been defined? Isn't that > > what this list members are supposed to develop? > > Dude, I've replied to you a couple times about this... > > http://www.fedora.us/wiki/FedoraLegacy Thanks for the pointer (are you sure you are not mistaken me with someone else? We didn't have that much communication until now). > Legacy will have 7.3 and 9 support initially, possibly more. That's what I also thought. Since RHL is the precursor of Fedora Core/Project, one could define RHL <= 9 as "Fedora prenatal release" and say that Fedora Legacy will be supporting (part of) the EOL'd Fedora releases (including the prenatal ones ;). -- 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 jrb at redhat.com Wed Oct 8 13:34:18 2003 From: jrb at redhat.com (Jonathan Blandford) Date: 08 Oct 2003 09:34:18 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <1065570448.32391.20.camel@poincare.devel.redhat.com> References: <3F8004E1.7020808@zonnet.nl> <1065570448.32391.20.camel@poincare.devel.redhat.com> Message-ID: Owen Taylor writes: > Jonathan and Bill are working on a fix for this; if kudzu wants to > interact with the user, a vte terminal will appear on the graphical > boot screen. This feature is now in version 0.10.2 in rawhide. Thanks, -Jonathan From warren at togami.com Wed Oct 8 16:09:47 2003 From: warren at togami.com (Warren Togami) Date: Wed, 08 Oct 2003 06:09:47 -1000 Subject: Does the freeworld repository exist yet? In-Reply-To: <20031008134322.1939da38.matthias@rpmforge.net> References: <47168e03020c5c07d3@[192.168.170.10]> <47273e36020c5e07d3@[192.168.170.10]> <3F83E55E.6060100@togami.com> <20031008134322.1939da38.matthias@rpmforge.net> Message-ID: <3F8436CB.3010107@togami.com> Matthias Saou wrote: >>Being a patriotic and law abiding American, it would be treasonous to my >>country's corporate interests to point to such a theoretical repository. > > > If you start thinking that way, then free software in general is something > bad for the US's corporate (financial) interests. Microsoft has the > quasi-monopoly worldwide in the Operating System field, and market shares > "lost" towards free software often means less money leaving foreign > countries to go back to the US, because of local developers, distributors, > support... I have to stop posting at extreme late night.... that was a complete utter failed attempt of sarcasm. I apologize if it seems that I was serious about this part. > > >>God bless America and everything it stands for. I love this country. >>Don't you? > > > I don't know about Nils (who seems to be Norwegian), to whom you asked > this, but I know I sure don't love America. And I also don't believe in > God, so I guess I wouldn't make a good patriot anyhow. > This part too... Warren From dag at wieers.com Wed Oct 8 16:28:57 2003 From: dag at wieers.com (Dag Wieers) Date: Wed, 8 Oct 2003 18:28:57 +0200 (CEST) Subject: Does the freeworld repository exist yet? In-Reply-To: <3F8436CB.3010107@togami.com> Message-ID: On Wed, 8 Oct 2003, Warren Togami wrote: > Matthias Saou wrote: > >>Being a patriotic and law abiding American, it would be treasonous to my > >>country's corporate interests to point to such a theoretical repository. > > > > > > If you start thinking that way, then free software in general is something > > bad for the US's corporate (financial) interests. Microsoft has the > > quasi-monopoly worldwide in the Operating System field, and market shares > > "lost" towards free software often means less money leaving foreign > > countries to go back to the US, because of local developers, distributors, > > support... > > I have to stop posting at extreme late night.... that was a complete > utter failed attempt of sarcasm. I apologize if it seems that I was > serious about this part. I guess you meant it to be ironic, but it turned out to be pretty sarcastic. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From derek.moore at sbcglobal.net Wed Oct 8 20:23:20 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Wed, 8 Oct 2003 13:23:20 -0700 (PDT) Subject: Does the freeworld repository exist yet? In-Reply-To: <20031008134322.1939da38.matthias@rpmforge.net> Message-ID: <20031008202320.66218.qmail@web80009.mail.yahoo.com> > > Being a patriotic and law abiding American, it would be treasonous to my > > country's corporate interests to point to such a theoretical repository. > > If you start thinking that way, then free software in general is something > bad for the US's corporate (financial) interests. Microsoft has the > quasi-monopoly worldwide in the Operating System field, and market shares > "lost" towards free software often means less money leaving foreign > countries to go back to the US, because of local developers, distributors, > support... I found this very entertaining: Naomi Klein made silicon.com's Agenda Setters 2003 list. http://www.silicon.com/as2003/list43.html I'm very proud to be yet another anti-corporate, anti-capitalist, global-justice techie. > > God bless America and everything it stands for. I love this country. > > Don't you? > > I don't know about Nils (who seems to be Norwegian), to whom you asked > this, but I know I sure don't love America. And I also don't believe in > God, so I guess I wouldn't make a good patriot anyhow. > > Getting too much off-topic I guess. Still, if I were American but with the > European mentality I have, I'd be doing all that is possible to fight > against the DMCA, software patents, and all their abuses. Don't forget, the U.S. inherited its corporate fascism from Europe. Europeans have just as much of a fight ahead of them as do we Americans. Viva la revolucion! Derek From derek.moore at sbcglobal.net Wed Oct 8 20:31:55 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Wed, 8 Oct 2003 13:31:55 -0700 (PDT) Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: Message-ID: <20031008203155.36406.qmail@web80012.mail.yahoo.com> > > Jonathan and Bill are working on a fix for this; if kudzu wants to > > interact with the user, a vte terminal will appear on the graphical > > boot screen. > > This feature is now in version 0.10.2 in rawhide. What's the point of having a graphical boot process if kudzu is going to interact with the user via VTE? Shouldn't some GTK+ frontend be written? Or is the VTE thing just a temporary solution, and the long-term idea is to have a proper frontend? Peace out, Derek From Nicolas.Mailhot at laPoste.net Wed Oct 8 20:39:19 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 08 Oct 2003 22:39:19 +0200 Subject: Does the freeworld repository exist yet? In-Reply-To: <20031008202320.66218.qmail@web80009.mail.yahoo.com> References: <20031008202320.66218.qmail@web80009.mail.yahoo.com> Message-ID: <1065645559.8409.10.camel@rousalka.dyndns.org> Le mer 08/10/2003 ? 22:23, Derek P. Moore a ?crit : > > Getting too much off-topic I guess. Still, if I were American but with the > > European mentality I have, I'd be doing all that is possible to fight > > against the DMCA, software patents, and all their abuses. > > Don't forget, the U.S. inherited its corporate fascism from Europe. Europeans > have just as much of a fight ahead of them as do we Americans. You mean, like converting to the metric system ? I just love how american computer engineering brought inches back to the whole world. Don't assume Europe didn't evolve since spinning out the US of A. -- 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 Wed Oct 8 20:43:42 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 8 Oct 2003 16:43:42 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <20031008203155.36406.qmail@web80012.mail.yahoo.com>; from derek.moore@sbcglobal.net on Wed, Oct 08, 2003 at 01:31:55PM -0700 References: <20031008203155.36406.qmail@web80012.mail.yahoo.com> Message-ID: <20031008164342.D32153@devserv.devel.redhat.com> Derek P. Moore (derek.moore at sbcglobal.net) said: > > This feature is now in version 0.10.2 in rawhide. > > What's the point of having a graphical boot process if kudzu is going to > interact with the user via VTE? Shouldn't some GTK+ frontend be written? Or > is the VTE thing just a temporary solution, and the long-term idea is to have a > proper frontend? Correct. Bill From hadess at hadess.net Wed Oct 8 21:27:30 2003 From: hadess at hadess.net (Bastien Nocera) Date: Wed, 08 Oct 2003 22:27:30 +0100 Subject: Does the freeworld repository exist yet? In-Reply-To: <20031008134322.1939da38.matthias@rpmforge.net> References: <47168e03020c5c07d3@[192.168.170.10]> <47273e36020c5e07d3@[192.168.170.10]> <3F83E55E.6060100@togami.com> <20031008134322.1939da38.matthias@rpmforge.net> Message-ID: <1065648450.5345.2.camel@wyatt.hadess.net> On Wed, 2003-10-08 at 12:43, Matthias Saou wrote: > Warren Togami wrote : > > > And yes I am completely serious about annoying pop-up windows. TRY the > > libdvdcss contained in the linked Bugzilla report above. > > I've not tried it, but how does it react if used from the console with no > X? Say for instance when used through transcode? I'm not convinced "dummy" > libraries are a good answer to legal problems anyway. > > > The the American user would then be legally powerless to do anything, > > but those living in other countries where it is not illegal could > > possibly replace the real library if the package exists. > > > > Being a patriotic and law abiding American, it would be treasonous to my > > country's corporate interests to point to such a theoretical repository. > > If you start thinking that way, then free software in general is something > bad for the US's corporate (financial) interests. Microsoft has the > quasi-monopoly worldwide in the Operating System field, and market shares > "lost" towards free software often means less money leaving foreign > countries to go back to the US, because of local developers, distributors, > support... > > > God bless America and everything it stands for. I love this country. > > Don't you? > > I don't know about Nils (who seems to be Norwegian), to whom you asked > this, but I know I sure don't love America. And I also don't believe in > God, so I guess I wouldn't make a good patriot anyhow. > > Getting too much off-topic I guess. Still, if I were American but with the > European mentality I have, I'd be doing all that is possible to fight > against the DMCA, software patents, and all their abuses. Warren, it seems like sarcasm doesn't travel well via e-mail ;) --- Bastien Nocera The politician was gone but unnoticed, like the full stop after the Dr. on a Dr Pepper can. From jaap_haitsma at zonnet.nl Wed Oct 8 21:57:38 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Wed, 08 Oct 2003 23:57:38 +0200 Subject: up2date failing dependencies window too big!!! Message-ID: <3F848852.4000400@zonnet.nl> The failing dependencies list today was so large that the dialog box that was created did not fit on my screen and I had to kill up2date. Would be nice that a dialog with list box would appear with the failing dependencies so that the window can be closed normally From dan at tucny.com Wed Oct 8 22:22:49 2003 From: dan at tucny.com (Dan Tucny) Date: 08 Oct 2003 23:22:49 +0100 Subject: up2date failing dependencies window too big!!! In-Reply-To: <3F848852.4000400@zonnet.nl> References: <3F848852.4000400@zonnet.nl> Message-ID: <1065651769.12940.5.camel@beech.tlns.net> On Wed, 2003-10-08 at 22:57, Jaap A. Haitsma wrote: > The failing dependencies list today was so large that the dialog box > that was created did not fit on my screen and I had to kill up2date. > > Would be nice that a dialog with list box would appear with the failing > dependencies so that the window can be closed normally Have you fed bugzilla this info? Dan From paul at gear.dyndns.org Wed Oct 8 22:27:59 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Thu, 09 Oct 2003 08:27:59 +1000 Subject: Does the freeworld repository exist yet? In-Reply-To: <3F8436CB.3010107@togami.com> References: <47168e03020c5c07d3@[192.168.170.10]> <47273e36020c5e07d3@[192.168.170.10]> <3F83E55E.6060100@togami.com> <20031008134322.1939da38.matthias@rpmforge.net> <3F8436CB.3010107@togami.com> Message-ID: <3F848F6F.8050209@gear.dyndns.org> Warren Togami wrote: > ... > I have to stop posting at extreme late night.... that was a complete > utter failed attempt of sarcasm. I apologize if it seems that I was > serious about this part. > Some of us got it (and had a good chuckle). :-) -- Paul http://paulgear.webhop.net A: Because we read from top to bottom, left to right. Q: Why should i start my 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 jaap_haitsma at zonnet.nl Wed Oct 8 23:05:02 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Thu, 09 Oct 2003 01:05:02 +0200 Subject: up2date failing dependencies window too big!!! In-Reply-To: <1065651769.12940.5.camel@beech.tlns.net> References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> Message-ID: <3F84981E.7050609@zonnet.nl> Dan Tucny wrote: > On Wed, 2003-10-08 at 22:57, Jaap A. Haitsma wrote: > >>The failing dependencies list today was so large that the dialog box >>that was created did not fit on my screen and I had to kill up2date. >> >>Would be nice that a dialog with list box would appear with the failing >>dependencies so that the window can be closed normally > > > Have you fed bugzilla this info? > > Dan > Noop, not yet. I can do this, if people feel this should be done From aoliva at redhat.com Thu Oct 9 00:44:14 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 08 Oct 2003 21:44:14 -0300 Subject: Does the freeworld repository exist yet? In-Reply-To: <1065648450.5345.2.camel@wyatt.hadess.net> References: <47168e03020c5c07d3@[192.168.170.10]> <47273e36020c5e07d3@[192.168.170.10]> <3F83E55E.6060100@togami.com> <20031008134322.1939da38.matthias@rpmforge.net> <1065648450.5345.2.camel@wyatt.hadess.net> Message-ID: On Oct 8, 2003, Bastien Nocera wrote: > Warren, it seems like sarcasm doesn't travel well via e-mail ;) It's just a MIME encoding that most e-mail readers don't get right :-) No, I don't mean MUAs, I mean the readers themselves :-) -- 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 mattharrison at sbcglobal.net Thu Oct 9 01:21:18 2003 From: mattharrison at sbcglobal.net (Matt Jones) Date: Wed, 08 Oct 2003 18:21:18 -0700 Subject: Redhat-Config-XFree86 Message-ID: <1065662476.3226.19.camel@localhost.localdomain> Hi - The dual head support doesn't seem to work for me (i'm on a toshiba satellite 1405-s151 laptop) via redhat-config-xfree86. Whenever I restart my X server, it merely clones my X screen onto my external monitor. Looking at my logs, it shows TRIDENT(0) as picking up both monitors. Should this be happening? I'm assuming that TRIDENT(0) should only be detecting the lcd, and that TRIDENT(1) should pick up the monitor. Thanks, Matt Jones -------------- 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 Thu Oct 9 02:26:53 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Wed, 8 Oct 2003 22:26:53 -0400 Subject: up2date failing dependencies window too big!!! In-Reply-To: <3F84981E.7050609@zonnet.nl> References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> Message-ID: On Wed, 8 Oct 2003, Jaap A. Haitsma wrote: > Dan Tucny wrote: > > On Wed, 2003-10-08 at 22:57, Jaap A. Haitsma wrote: > > > >>The failing dependencies list today was so large that the dialog box > >>that was created did not fit on my screen and I had to kill up2date. > >> > >>Would be nice that a dialog with list box would appear with the failing > >>dependencies so that the window can be closed normally > > > > > > Have you fed bugzilla this info? > > > > Dan > > > Noop, not yet. I can do this, if people feel this should be done Well, why not? It's a bug (or at least an feature request). Better sit there in bugzilla than to be forgotten. behdad, who is going to study after finishing this mail. From mharris at redhat.com Thu Oct 9 03:17:49 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 8 Oct 2003 23:17:49 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs initscript Message-ID: The attached diff attempts to do the following improvements to the xfs initscript for performance and correctness: The individual fixes are: - Consider all .ttf, .ttc, .otf, .otc file extensions of any combination of upper and/or lowercase in a font directory to be a truetype or opentype font which ttmkfdir should handle. Previously, only .ttf and .ttc fonts were handled. This is a correctness fix. - When determining wether or not mkfontdir and ttmkfdir need to be called, ignore any fonts.cache files that might be present, as they're metadata files, not fonts. This is both a correctness and performance fix, as any non-font metadata files found that aren't explicitly ignored, but are newer than fonts.dir will unnecessarily trigger regeneration of fonts.dir - When determining wether a directory contains non-truetype fonts, ignore all ttf/ttc/otf/otc font types, not just ttf. - If any fonts.dir files were recreated, it now calls fc-cache afterward if fc-cache exists, in order to update all fontconfig fonts.cache-* files I've studied the regular expressions carefully and think that they cleanly implement the above, however there could be a glitch in there, so I'd like to get other people to review this change before officially committing it to the next build of XFree86, as a bad regex could result in rather serious font subsystem breakage, so the more eyes who review this the better. If you review the change and think it to be correct, please respond with an "ACK" email to fedora-devel-list, along with any comments and/or suggestions for futher improvements. On a separate note from the above, there is one possible flaw that was in the original initscript as well as my above proposal, however I want this issue treated/considered separately from the above, so please comment on each issue separately. The following line: if [ "$(ls |grep -iv '\(fonts\.\(scale\|alias\|cache.*\)$\|.+\(\.[ot]t[cf]\|dir\)$\)')" != "" ]; then In both the original initscript, and this updated one, the test doesn't take into account wether or not the directory may contain subdirectories for whatever reason. If the dir does contain subdirs, the subdir name will pass the grep test, and cause mkfontdir to be executed even if no font files are updated. I'm thinking of changing this ls|grep test to be something similar to the following, which explicitly tests for files only and ignores dirs: if [ "$(find . -type f -maxdepth=0 -not -regex '.*fonts\.\(scale\|alias\|cache.*\)$' -and -not -iregex '.+\(\.[ot]t[cf]\|dir\)$' != "" ]; then It's ugly, but I believe it may do what we're looking for nicely. Comments appreciated. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat -------------- next part -------------- --- xfs.init.old 2003-09-18 19:15:34.000000000 -0400 +++ xfs.init 2003-10-08 23:08:35.000000000 -0400 @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash # # xfs: Starts the X Font Server # @@ -29,28 +29,32 @@ if [ -d "$d" ]; then cd $d # Check if we need to rerun mkfontdir - NEEDED=no + REGEN_FONTS_DIR=no if ! [ -e fonts.dir ]; then - NEEDED=yes - elif [ "$(find . -type f -cnewer fonts.dir 2>/dev/null)" != "" ];then - NEEDED=yes + REGEN_FONTS_DIR=yes + elif [ "$(find . -type f -cnewer fonts.dir -not -name "fonts.cache*" 2>/dev/null)" != "" ];then + REGEN_FONTS_DIR=yes fi - if [ "$NEEDED" = "yes" ]; then + if [ "$REGEN_FONTS_DIR" = "yes" ]; then rm -f fonts.dir &>/dev/null - if ls | grep -i "\.tt[cf]$" &>/dev/null; then - # TrueType fonts found... + if ls | grep -i "\.[ot]t[cf]$" &>/dev/null; then + # TrueType or Opentype fonts found... ttmkfdir -d . -o fonts.scale mkfontdir . &>/dev/null [ -e fonts.dir ] && chmod 644 fonts.scale fonts.dir fi - if [ "$(ls |egrep -iv '\.tt[cf]$|^fonts\.|^encodings\.')" != "" ]; then - # This directory contains fonts that are not TrueType... + if [ "$(ls |grep -iv '\(fonts\.\(scale\|alias\|cache.*\)$\|.+\(\.[ot]t[cf]\|dir\)$\)')" != "" ]; then + # This directory contains fonts that are not TrueType or Opentype... mkfontdir . &>/dev/null [ -e fonts.dir ] && chmod 644 fonts.dir fi fi fi done + # Recreating fonts.dir files above may result in stale fonts.cache-1 + # files since the directory mtimes change, so we run fc-cache to + # update any necessary fonts.cache files. + [ "$REGEN_FONTS_DIR" = "yes" -a -x /usr/bin/fc-cache ] && /usr/bin/fc-cache popd &> /dev/null } From derek.moore at sbcglobal.net Thu Oct 9 04:11:29 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Wed, 8 Oct 2003 21:11:29 -0700 (PDT) Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: Message-ID: <20031009041129.69736.qmail@web80004.mail.yahoo.com> > ttmkfdir -d . -o fonts.scale Doesn't 'mkfontscale' replace 'ttmkfdir'? While you're updatin' this initscript, might you want to update it to use 'mkfontscale'? (In which case, 'mkfontscale &>/dev/null' would suffice; though, to follow the style of the 'mkfontdir' statements, 'mkfontscale . &>/dev/null' will also do [even though the '.' is redundant with both 'mkfontdir' and 'mkfontscale' commands]). Okay, I'm done now, Derek P.S.: I'm glad to see work in this area. I have all the Adobe Font Folio fonts on my Linux box, and a specific subset of the Postscript fonts (installed [or, rather, symlinked] under /usr/X11R6/lib/X11/fonts/Type1) consistently disappear when, I think, I 'rpm -Fvh XFree86*'. I haven't really bothered too hard to trace down what exactly is causing it, because 'mkfontdir /usr/X11R6/lib/X11/fonts/Type1 && mkfontscale /usr/X11R6/lib/X11/fonts/Type1' fixes it (and then I instantly become unmotivated to bug-hunt). From mharris at redhat.com Thu Oct 9 04:58:09 2003 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 9 Oct 2003 00:58:09 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: <20031009041129.69736.qmail@web80004.mail.yahoo.com> References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> Message-ID: On Wed, 8 Oct 2003, Derek P. Moore wrote: >> ttmkfdir -d . -o fonts.scale > >Doesn't 'mkfontscale' replace 'ttmkfdir'? "Theoretically" speaking, yes. Technically speaking however, mkfontscale and ttmkfdir output different results for fonts.scale because mkfontscale does not support Asian fonts well, in particular it doesn't handle .ttc fonts if I recall correctly. There were a few reasons such as this, which is why we kept ttmkfdir instead of migrating to mkfontscale, however we provide both. Up until now, I don't think any of our scripts use mkfontscale though, however I'm planning on using it for opentype fonts now as ttmkfdir doesn't handle opentype. >While you're updatin' this initscript, might you want to update >it to use 'mkfontscale'? (In which case, 'mkfontscale >&>/dev/null' would suffice; though, to follow the style of the >'mkfontdir' statements, 'mkfontscale . &>/dev/null' will also do >[even though the '.' is redundant with both 'mkfontdir' and >'mkfontscale' commands]). Just did that for opentype fonts. I'm going to post my latest patch here for review, with a few more enhancements. >P.S.: I'm glad to see work in this area. I have all the Adobe >Font Folio fonts on my Linux box, and a specific subset of the >Postscript fonts (installed [or, rather, symlinked] under >/usr/X11R6/lib/X11/fonts/Type1) consistently disappear when, I >think, I 'rpm -Fvh XFree86*'. I haven't really bothered too >hard to trace down what exactly is causing it, because >'mkfontdir /usr/X11R6/lib/X11/fonts/Type1 && mkfontscale >/usr/X11R6/lib/X11/fonts/Type1' fixes it (and then I instantly >become unmotivated to bug-hunt). Yes, this is unfortunate, because we ship hard coded fonts.dir files IIRC for Type1 fonts rather than installation time and boot time regenerating them like we do via xfs initscript and rpm postinstall scripts. This historically is because there was no application for generating the files shipped with XFree86. There was type1inst however that was never shipped with the distro or XFree86 for some reason I'm unaware of, and I never had time to really investigate it. mkfontscale should handle Type1 fonts now however, and I may want to add support to the xfs initscript and various font packages for using mkfontscale with all Type1 fonts. Owen: Have you played with mkfontscale and Type1 fonts at all by any chance? It's too late in the Fedora development cycle to consider making changes like this for this release, however it would be an improvment for users for Fedora Core 2 IMHO if we were to use mkfontscale on all Type1 font directories and packages in the future. Any feedback appreciated. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Thu Oct 9 05:22:35 2003 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 9 Oct 2003 01:22:35 -0400 (EDT) Subject: xfs initscript enhancements, take 5 Message-ID: Ok, I have made some more improvements to the xfs initscript, and have also incorporated improvments suggested by Owen Taylor, Havoc Pennington, Alexandre Oliva, and others. I have added our xfree86-list at redhat.com to the CC list to widen distribution a bit. Hope that doesn't annoy anyone. ;o) The latest patch is attached, and here is the current list of changes for review: - The shebang was changed to "#!/bin/bash" as I very much use bash specific features in my shell scripts, and the current initscript definitely contains non-Bourne shell script code. Futher rationale for Bourne purists: bash allows constructs using bash builtins, which allow much more to be accomplished in scripting, with much less code and complexity. Red Hat Linux, and now Fedora, requires bash be installed in /bin/bash on all systems in so many places already, that it is basically considered a hard coded requirement for running the OS in the first place. As such, using bash specifics in shell scripts is perfectly acceptable in my eyes. Don't try to convince me otherwise, as I can convert it to processor specific assembly language instead. - Cosmetic change: The "NEEDED" variable was renamed to "REGEN_FONTS_DIR" as I felt that was more descriptive and readable. - Ignore "fonts.cache*" metadata files in the font directory when determining wether or not fonts.dir needs to be regenerated. - Use grep options "-q" and "-s" on all grep invocations to prevent stdout and stderr output instead of shell redirection. This IMHO looks nicer, and it might even be faster. - Add a section to detect Opentype fonts separately from Truetype fonts because ttmkfdir doesn't handle opentype fonts. In the new section we handle opentype fonts the same way as truetype ones, only we call mkfontscale on them instead of ttmkfdir. - When attempting to detect non-truetype non-opentype fonts in the last section, we want to ignore all possible non-font files including all known font metadata files, so as to not needlessly trigger recreation of fonts.dir. Some of the files we are wanting to avoid are: fonts.scale, fonts.alias, fonts.cache*, fonts.dir, encodings.dir, *.otc, *.otf, *.ttc, *.ttf. The current regular expresion I believe handles all of these cases cleanly: '(^fonts\.(scale|alias|cache.*)$|.+(\.[ot]t[cf]|dir)$)' Comments appreciated for improvments here, or to poke holes in my regex. - Use "grep -E" instead of "egrep" now, as egrep is a shell script which calls grep -E for some ungodly reason in some OS releases. This eliminates a fork()/exec() at least and might be slightly faster, without harming readability. Also, both "grep -E and egrep" have more readable regular expression syntax for the ugly regular expression. - If any fonts.dir files were created during this invocation, then call fc-cache to update the fontconfig cache files also. While testing this enhancement in Red Hat Linux 8.0 (since I keep XFree86 4.3.0 buildable on RHL 8.0, and do much of my testing there), I determined that the fc-cache version shipped in RHL 8.0 will SEGV when invoked from the xfs initscript in this manner. We're unlikely to release an updated fontconfig for RHL 8.0 unless there is a security hole in it, however even if we did find and fix the bug and release erratum, I can't guarantee the user would have it installed anyway. As such, we test the fc-cache version and if it is version 1.0.2, we skip running fc-cache. Comments: If anyone is interested in debugging and/or fixing fontconfig in Red Hat Linux 8.0, that would be nice, however I'll likely still need the initscript hack anyway. The final "ls|grep -E" which detects non-ttf/non-otf fonts will come up true if the directory contains subdirectories. The only way I can think of to easily avoid this, is to use "find" instead of "ls|grep -E" and disable directory recursion, and only return files, not dirs. That change is a bit more experimental however, so I'm leaving that for the future. Any feedback or comments are appreciated. I'd like to commit these enhancements to 4.3.0-38 soon unless problems arise. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat -------------- next part -------------- --- xfs.init.old 2003-09-18 19:15:34.000000000 -0400 +++ xfs.init 2003-10-09 00:47:00.000000000 -0400 @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash # # xfs: Starts the X Font Server # @@ -29,28 +29,46 @@ if [ -d "$d" ]; then cd $d # Check if we need to rerun mkfontdir - NEEDED=no + REGEN_FONTS_DIR=no if ! [ -e fonts.dir ]; then - NEEDED=yes - elif [ "$(find . -type f -cnewer fonts.dir 2>/dev/null)" != "" ];then - NEEDED=yes + REGEN_FONTS_DIR=yes + elif [ "$(find . -type f -cnewer fonts.dir -not -name "fonts.cache*" 2>/dev/null)" != "" ];then + REGEN_FONTS_DIR=yes fi - if [ "$NEEDED" = "yes" ]; then + if [ "$REGEN_FONTS_DIR" = "yes" ]; then rm -f fonts.dir &>/dev/null - if ls | grep -i "\.tt[cf]$" &>/dev/null; then - # TrueType fonts found... + if ls | grep -iqs "\.tt[cf]$" ; then + # TrueType fonts found, generate fonts.scale and fonts.dir ttmkfdir -d . -o fonts.scale mkfontdir . &>/dev/null [ -e fonts.dir ] && chmod 644 fonts.scale fonts.dir fi - if [ "$(ls |egrep -iv '\.tt[cf]$|^fonts\.|^encodings\.')" != "" ]; then - # This directory contains fonts that are not TrueType... + if ls | grep -iqs "\.ot[cf]$" ; then + # Opentype fonts found, generate fonts.scale and fonts.dir + mkfontscale . + mkfontdir . &>/dev/null + [ -e fonts.dir ] && chmod 644 fonts.scale fonts.dir + fi + if ls |grep -Eiqsv '(^fonts\.(scale|alias|cache.*)$|.+(\.[ot]t[cf]|dir)$)' ; then + # This directory contains non-TrueType/non-Opentype fonts mkfontdir . &>/dev/null [ -e fonts.dir ] && chmod 644 fonts.dir fi fi fi done + # Recreating fonts.dir files above may result in stale fonts.cache-1 + # files since the directory mtimes change, so we run fc-cache to + # update any necessary fonts.cache files. + FC_CACHE=/usr/bin/fc-cache + if [ "$REGEN_FONTS_DIR" = "yes" -a -x $FC_CACHE ] + # fc-cache 1.0.2 as included in Red Hat Linux 8.0 will SEGV when executed + # by this initscript, so we don't run fc-cache for version 1.0.2 since + # even if fc-cache were fixed, we can't guarantee the user would have the + # fixed version installed. Yes, this is an ugly, but necessary hack for + # the time being. + [ $FC_CACHE --version 2>&1 | grep -q '1\.0\.2' ] || $FC_CACHE + fi popd &> /dev/null } From aoliva at redhat.com Thu Oct 9 06:31:07 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 09 Oct 2003 03:31:07 -0300 Subject: xfs initscript enhancements, take 5 In-Reply-To: References: Message-ID: On Oct 9, 2003, "Mike A. Harris" wrote: > The final "ls|grep -E" which detects non-ttf/non-otf fonts will > come up true if the directory contains subdirectories. The only > way I can think of to easily avoid this, is to use "find" instead > of "ls|grep -E" and disable directory recursion, and only return > files, not dirs. That change is a bit more experimental however, > so I'm leaving that for the future. Consider ls -F | grep -v /$ -- 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 Oct 9 06:41:11 2003 From: warren at togami.com (Warren Togami) Date: Wed, 08 Oct 2003 20:41:11 -1000 Subject: Japanese OpenOffice 1.1.0 Message-ID: <1065681671.5365.10.camel@laptop> http://togami.com/~warren/archive/2003/nihongo-ooo-1.1.0.png I am happy to report that Japanese input in OpenOffice 1.1.0 works fine after you enable Japanese mode within the Language settings of the Configuration menu. I am extremely happy that it now automatically chooses the Japanese font "Kochi Mincho" rather than the user needing to choose it manually. In order to run it from English mode, run the following from a script: #!/bin/bash kinput2 -canna & LANG=ja_JP XMODIFIERS="@im=kinput2" oowriter There is a slight problem where the little kinput2 has a blank rectangle within it rather than the usual Japanese characters. I suspect it isn't set to use the correct font internally. I will file this in Bugzilla. (I am not sure if my grammar in the above screenshot is correct. Please correct me if it is wrong. =) Warren Togami warren at togami.com From Nicolas.Mailhot at laPoste.net Thu Oct 9 07:44:57 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 09 Oct 2003 09:44:57 +0200 Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> Message-ID: <1065685496.1665.7.camel@ulysse.olympe.o2t> Le jeu 09/10/2003 ? 06:58, Mike A. Harris a ?crit : > On Wed, 8 Oct 2003, Derek P. Moore wrote: > > >> ttmkfdir -d . -o fonts.scale > > > >Doesn't 'mkfontscale' replace 'ttmkfdir'? [...] > Any feedback appreciated. What I's like is some kind of infrastructure (font macro ?) so one doesn't have to write two screenfulls of instructions in each font spec file to get fonts registered in all available fontsystems (see the fedora.us bitstream-vera rpm). Last time I asked the answer was (I think) "do only fontconfig stuff, the rest will go away soon" - but clearly you are still working on the xfs backend, so... 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 derek.moore at sbcglobal.net Thu Oct 9 08:07:13 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Thu, 9 Oct 2003 01:07:13 -0700 (PDT) Subject: xfs initscript enhancements, take 5 In-Reply-To: Message-ID: <20031009080713.57674.qmail@web80007.mail.yahoo.com> > + if ls | grep -iqs "\.tt[cf]$" ; then > + # TrueType fonts found, generate fonts.scale and fonts.dir > ttmkfdir -d . -o fonts.scale > mkfontdir . &>/dev/null > [ -e fonts.dir ] && chmod 644 fonts.scale fonts.dir > fi > + if ls | grep -iqs "\.ot[cf]$" ; then > + # Opentype fonts found, generate fonts.scale and fonts.dir > + mkfontscale . > + mkfontdir . &>/dev/null > + [ -e fonts.dir ] && chmod 644 fonts.scale fonts.dir > + fi This script is fine and dandy assuming TTF and OTF fonts are in seperate directories. However, if even one OTF file occurs in the same directory as TTF files, the 'fonts.scale' of 'ttmkfdir' will be overwritten by 'mkfontscale'. ... Which is fine, I suppose. If there /really/ is an important difference between 'ttmkfdir' and 'mkfontscale', it might be useful to be conscious of this particular "gotcha". Also... I think I must not be clued in to something here, but why doesn't this script have support for PostScript Type 1 fonts? Don't they need fonts.dir and fonts.scale files? Peace out, Derek From derek.moore at sbcglobal.net Thu Oct 9 08:43:47 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Thu, 9 Oct 2003 01:43:47 -0700 (PDT) Subject: xfs initscript enhancements, take 5 In-Reply-To: <20031009080713.57674.qmail@web80007.mail.yahoo.com> Message-ID: <20031009084347.62257.qmail@web80007.mail.yahoo.com> > Also... I think I must not be clued in to something here, but why doesn't > this script have support for PostScript Type 1 fonts? Don't they need > fonts.dir and fonts.scale files? Er... Nevermind. I didn't read your email fully and missed all the parts about "non-opentype/non-truetype fonts". *grin* However, the script still doesn't generate fonts.scale for those "other" fonts. And if I'm not incorrect, PostScript Type 1 fonts require fonts.scale, too. In any case, I know 'mkfontscale' will put shit about Type 1 fonts into fonts.scale. That's sayin' something, at least. Okay, I'm done now, Derek PS: Aren't the other font extensions '.bdf', '.pcf', '.pcf.gz', '.pfa', '.pfb', '.t1a', '.afm' (other Type 1 extensions include '.mmm' and a few others I can't remember, but if those are lyin' around, they should have corresponding '.pfa', '.pfb', or '.t1a' files, I think)? Why don't you test for those extensions instead of just test whether or not the directory is empty. Then again, I suppose that's a lot o' test-cases, so maybe "directory not empty" is good enough. *grin* PPS: In the end, I have a feeling that "mkfontdir $d && mkfontscale $d" would be much better than a bunch of test conditions for TTF vs. OTF vs. Other (at least, "theoretically". *smile* PPPS: What's so experimental about 'find' instead of 'ls | grep'? From warren at togami.com Thu Oct 9 09:04:53 2003 From: warren at togami.com (Warren Togami) Date: Wed, 08 Oct 2003 23:04:53 -1000 Subject: Regarding the Mirror structure and Fedora Legacy Message-ID: <3F8524B5.3080706@togami.com> [This was posted to Red Hat's mirror discussion list during a thread about the new Fedora mirror structure. Please do not cross-post replies as the ramifications of the mirror structure will effect all parties, so fedora-devel-list is appropriate for this discussion.] The current discussion between RH people and the interim Fedora Legacy planning team [1] seems to be that Legacy will not publish packages within the regular Fedora mirror structure. Instead both RH and Legacy want users to consciously change their configurations to point to the new location when a distribution hits the point of EOL, in order to make it clear that the packages are coming from a different source than those officially published and supported by RH the company. I personally really dislike this as I had hoped that Legacy would simply publish packages within the same directory, making it easy for the users and system administrators. Despite some protests from irrational people like me, it seems that the distribution system will need to be separate. There is already discussion about Pogo Linux supplying the server infrastructure for Legacy to be hosted somewhere in the Seattle area. Given the separateness of the repositories, the setup and transition as well as choosing of mirrors for both regular Fedora and Legacy would be eased by a theoretical GUI/TUI program that downloads a GPG signed list of official mirrors, and allows the administrator to choose. I hope that we can work on such a program for the future of Fedora. [1] https://lists.dulug.duke.edu/mailman/listinfo/fedora-legacy-list Fedora Legacy discussion list Warren Togami warren at togami.com From milan.kerslager at pslib.cz Thu Oct 9 09:33:56 2003 From: milan.kerslager at pslib.cz (Milan Kerslager) Date: Thu, 9 Oct 2003 11:33:56 +0200 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) Message-ID: <20031009093356.GA9789@pluto.pslib.cz> Hi, I just read http://www.gentoo.org/main/en/performance.xml I'm clear that this test is not fair as there is no same free RAM initial condition (and no same apps and components loaded), but still feeling that we need to make more for usable desktop (ie. loading time is important here). What I would like to make sure is that Fedora developers take an eye on this to not shoot down this new project 1 day after release. I really dislike this sort of unfair PR that avoid importatnt objectivity but what we can do more than check our reserves... -- Milan Kerslager E-mail: milan.kerslager at pslib.cz WWW: http://www.pslib.cz/~kerslage/ From mharris at redhat.com Thu Oct 9 10:32:26 2003 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 9 Oct 2003 06:32:26 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: <1065685496.1665.7.camel@ulysse.olympe.o2t> References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> Message-ID: On Thu, 9 Oct 2003, Nicolas Mailhot wrote: >> Any feedback appreciated. > >What I's like is some kind of infrastructure (font macro ?) so one >doesn't have to write two screenfulls of instructions in each font spec >file to get fonts registered in all available fontsystems (see the >fedora.us bitstream-vera rpm). > >Last time I asked the answer was (I think) "do only fontconfig stuff, >the rest will go away soon" - but clearly you are still working on the >xfs backend, so... xfs is "deprecated" in the sense that all new applications will be using the new Xft/fontconfig infrastructure, and I had this added to the release notes in order that at some undetermined time in the future (could be 2 releases, or 30 releases from now) I have the option of killing xfs and telling people "we informed people that xfs was deprecated n releases ago, and it is now no longer supported". This is however just a theoretical thing to give me the option of doing that when the time comes, so that users affected by the change (and there are likely to be people who are affected, even if it is 20 years from now...) can be pointed to the documentation that indicates the change was mentioned in advance so that people would have plenty of time to prepare. In other words, it is a "cover my ass for the future" thing being done wayyy in advance. That said... There are way too many applications out there currently which require core font support, including many apps that come with XFree86 itself, and with other major parts of the distribution. So realistically, core font support isn't going to disappear overnight, and xfs wont vanish either overnight. As long as xfs exists, and there is a need for core fonts, we have some responsibility IMHO to provide some core font support even if it's limited in some way. So I see no reason to remove support until there is a real burden on myself or other developers WRT core fonts. I will keep my font packages in a state that handle both font subsystems as long as I can without pulling out hair or making quality compromises. I do not however maintain all of the font packages, so I can't speak for the developers that maintain the other font packages in the distribution. Hopefully others will try to keep their packages cleanly handling both font systems also. As for a special macro to handle font installation, that is IMHO a double edged sword. If it was part of a particular package, then it wouldn't be centralized and thus would have to be duplicated in all packages, which isn't much different from what we have now. If it was centralized, it would have to be part of rpm's default macro set, thus imposing a dependancy on a particular version of rpm in order for those font packages to be useable. In a case like that for example, my XFree86 4.3.0 packages couldn't easily be recompiled for Red Hat Linux 8.0 and expected to work. Another option is a font installation script, but that suffers from the last problem I described also. The bigger problem, at least as I see it, is that traditionally, every font package maintainer has more or less done things "their own way", so there isn't complete consistency between font packages. I've offered to maintain all font packages in order to maintain one set of rules/etc. and have all of the packages consistent, but others believe it is more advantageous for people to maintain the font packages of the region of the world in which they are from or speak the language of. There is some merit to that decision as well. I admit that fonts and font related problems in general are a huge mess, however it isn't limited to our distribution, but is a result more of XFree86 having archaic font technology for so many years. It'll take a few more years to shake the uglies out of the font infrastructure. I definitely would like to hear other people's opinions on all of these matters though... I will probably agree with most suggestions. ;o) I wont necessarily be able to implement or control all font related suggestions though, but I can try to help influence decisions for any good ideas people come up with. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Thu Oct 9 10:41:17 2003 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 9 Oct 2003 06:41:17 -0400 (EDT) Subject: xfs initscript enhancements, take 5 In-Reply-To: <20031009080713.57674.qmail@web80007.mail.yahoo.com> References: <20031009080713.57674.qmail@web80007.mail.yahoo.com> Message-ID: On Thu, 9 Oct 2003, Derek P. Moore wrote: >> + if ls | grep -iqs "\.tt[cf]$" ; then >> + # TrueType fonts found, generate fonts.scale and fonts.dir >> ttmkfdir -d . -o fonts.scale >> mkfontdir . &>/dev/null >> [ -e fonts.dir ] && chmod 644 fonts.scale fonts.dir >> fi >> + if ls | grep -iqs "\.ot[cf]$" ; then >> + # Opentype fonts found, generate fonts.scale and fonts.dir >> + mkfontscale . >> + mkfontdir . &>/dev/null >> + [ -e fonts.dir ] && chmod 644 fonts.scale fonts.dir >> + fi > >This script is fine and dandy assuming TTF and OTF fonts are in seperate >directories. Correct, but that isn't a problem because you would be incredibly hard pressed to get both ttf and otf fonts working on your system if you installed them into the same directory. XFree86.org originally installed both TTF and OTF fonts into the same dir, until it was learned that this broke horribly, then they separated them out. So, for XFree86 4.3.0 at least, each font type MUST be in a directory which contains only fonts of that same type. There may be some exceptions to that perhaps if one was to exhaustively test all possible combinations, but the exceptions don't make the rule. If people put one font type in each directory only, there are no problems, so that is the only configuration officially supported. That is ugly of course, and so I hope to see future improvements that permit all fonts to live in one huge directory if desired. That's a ways off though IMHO, at least for core fonts. >However, if even one OTF file occurs in the same directory as TTF >files, the 'fonts.scale' of 'ttmkfdir' will be overwritten by 'mkfontscale'. >... Which is fine, I suppose. If there /really/ is an important difference >between 'ttmkfdir' and 'mkfontscale', it might be useful to be conscious of >this particular "gotcha". Yep, I'm conscious of that. ;o) XFree86.org has clearly stated "that isn't supported" so it isn't something Red Hat installation will ever do, and a user that does it kills their own installation. ;o) >Also... I think I must not be clued in to something here, but >why doesn't this script have support for PostScript Type 1 >fonts? Don't they need fonts.dir and fonts.scale files? XFree86 has never shipped with a tool to generate fonts.scale for Type1 fonts. The files are hand edited presumeably and provided in the sources. There was a tool called type1inst which was not part of XFree86, however I don't recall the story on that tool. I presume it sucked because it's never been shipped and nobody seems to use it out there. mkfontscale supports Type1 fonts however, and unless Owen objects, I would like to add support to the xfs initscript to handle Type1 fonts also for the future. It's kind of late in our development cycle for this kind of change though, so it will have to wait until the next distribution development cycle opens up. I think this could potentially solve a number of problems people occasionally encounter. One way to avoid most of the problems that currently exist, is to never ever put any of your own fonts into font directories which are provided with the distribution and populated with fonts that come with the distribution. The exceptions are the XFree86 "local" directory, and /usr/share/fonts and ~/.fonts It's best to make your own new dirs and add them to the relevant config files IMHO. This will of course improve each release until we have font sanity in OSSland. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From Nicolas.Mailhot at laPoste.net Thu Oct 9 10:47:56 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 09 Oct 2003 12:47:56 +0200 Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> Message-ID: <1065696476.3713.3.camel@ulysse.olympe.o2t> Le jeu 09/10/2003 ? 12:32, Mike A. Harris a ?crit : > I definitely would like to hear other people's opinions on all of > these matters though... I will probably agree with most > suggestions. ;o) I wont necessarily be able to implement or > control all font related suggestions though, but I can try to > help influence decisions for any good ideas people come up with. > ;o) My opinion is simple. We need more font setup coordination. I don't care if it's done via macros, an official document, or a reference spec file everyone is supposed to copy (like bitstream-vera was going to be in fedora.us before the merge), but I'm dead tired of not having two font package behaving the same way because they all use their own secret recipes. 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 Thu Oct 9 10:53:38 2003 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 9 Oct 2003 06:53:38 -0400 (EDT) Subject: xfs initscript enhancements, take 5 In-Reply-To: <20031009084347.62257.qmail@web80007.mail.yahoo.com> References: <20031009084347.62257.qmail@web80007.mail.yahoo.com> Message-ID: On Thu, 9 Oct 2003, Derek P. Moore wrote: >> Also... I think I must not be clued in to something here, but why doesn't >> this script have support for PostScript Type 1 fonts? Don't they need >> fonts.dir and fonts.scale files? > >Er... Nevermind. I didn't read your email fully and missed all the parts >about "non-opentype/non-truetype fonts". *grin* > >However, the script still doesn't generate fonts.scale for those "other" fonts. > And if I'm not incorrect, PostScript Type 1 fonts require fonts.scale, too. >In any case, I know 'mkfontscale' will put shit about Type 1 fonts into >fonts.scale. That's sayin' something, at least. > >Okay, I'm done now, Yes, but as I've said, it would be experimental. >PS: Aren't the other font extensions '.bdf', '.pcf', '.pcf.gz', '.pfa', >'.pfb', '.t1a', '.afm' (other Type 1 extensions include '.mmm' and a few others >I can't remember, but if those are lyin' around, they should have corresponding >'.pfa', '.pfb', or '.t1a' files, I think)? Why don't you test for those >extensions instead of just test whether or not the directory is empty. Because we have had 2 beta releases already, and another one coming shortly, and it is too late in the development cycle to fix any massive breakages that might result from such a change this late which have totally unknown quality. >Then again, I suppose that's a lot o' test-cases, so maybe >"directory not empty" is good enough. *grin* It's definitely not good enough, or that is all the current script would do in the first place. ;o) >PPS: In the end, I have a feeling that "mkfontdir $d && mkfontscale $d" would >be much better than a bunch of test conditions for TTF vs. OTF vs. Other (at >least, "theoretically". *smile* mkfontscale might generate totally bogus crap fonts.scale files for all we know. It's never been used in our distribution. I do know 100% though, that for truetype fonts at least, mkfontscale and ttmkfdir do NOT generate the same fonts.scale files for all fonts, and this would result in user visible font changes of unknown consequence, perhaps only in Japanese or Korean, or Chinese, or Arabic, or, etc... I can't possibly test that. It's the type of change that if we're going to consider it, it is something that needs to be put into rawhide 10 minutes after Fedora Core 1 ships, so that it's being done with up to 6 months left to fix any problems that arise or revert the change. >PPPS: What's so experimental about 'find' instead of 'ls | grep'? What's experimental about it is that making such a change requires high confidence that the code will result in identical behaviour plus the desired enhancement with no risk of regression, since this is the end of the development cycle. I can stare at a regular expression all day and run things through my mind, but until it is tested on 100000 end users systems out there, I can't possibly guess all of the possible random problems that it could cause that were unforseen. Maybe font files with spaces in the filenames cause the script to crash and burn all of a sudden, or maybe find's regex implementation is slightly different in syntax, etc... The idea here is that you don't make major changes at the last minute that you are not 110% sure are not going to break anything. Even the existing changes I'm proposing come with them some risk, which is why I was hesitant to include them without having 1000 eyes review them in addition to mine. ;o) That review process has resulted in some bug fixes and improvements which have measureable benefits. The "find" suggestion has less measureable benefit and so the risk isn't worth it for me quite yet. I want to test the existing changes out, and if they work, they'll go in. The find change I'd like to leave for the future instead. Feel free to RFE the Type1 thing using mkfontscale in bugzilla if you wish so I remember to do it soon into the next development cycle (assuming no objections from Owen or others with rational counter arguments against the idea). As for testing every type by filename extension, I think that is more or less impossible, as there are more font filename extensions than there are IPv6 IP addresses. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From Nicolas.Mailhot at laPoste.net Thu Oct 9 10:56:36 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 09 Oct 2003 12:56:36 +0200 Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: <1065696476.3713.3.camel@ulysse.olympe.o2t> References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <1065696476.3713.3.camel@ulysse.olympe.o2t> Message-ID: <1065696996.3883.2.camel@ulysse.olympe.o2t> Le jeu 09/10/2003 ? 12:47, Nicolas Mailhot a ?crit : > Le jeu 09/10/2003 ? 12:32, Mike A. Harris a ?crit : > > > I definitely would like to hear other people's opinions on all of > > these matters though... I will probably agree with most > > suggestions. ;o) I wont necessarily be able to implement or > > control all font related suggestions though, but I can try to > > help influence decisions for any good ideas people come up with. > > ;o) > > My opinion is simple. We need more font setup coordination. I don't care > if it's done via macros, an official document, or a reference spec file > everyone is supposed to copy (like bitstream-vera was going to be in > fedora.us before the merge), but I'm dead tired of not having two font > package behaving the same way because they all use their own secret > recipes. (Another solution of course being "install all fonts un /usr/share/fonts", the system will take care of fonts.* generation and directory registration at next xfs restart) However this will break rpm -e unless the xfs service also cleans ups dangling indexes/registered directories after font removal. 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 Thu Oct 9 11:08:05 2003 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 9 Oct 2003 07:08:05 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: <1065696476.3713.3.camel@ulysse.olympe.o2t> References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <1065696476.3713.3.camel@ulysse.olympe.o2t> Message-ID: On Thu, 9 Oct 2003, Nicolas Mailhot wrote: >> I definitely would like to hear other people's opinions on all of >> these matters though... I will probably agree with most >> suggestions. ;o) I wont necessarily be able to implement or >> control all font related suggestions though, but I can try to >> help influence decisions for any good ideas people come up with. >> ;o) > >My opinion is simple. We need more font setup coordination. I don't care >if it's done via macros, an official document, or a reference spec file >everyone is supposed to copy (like bitstream-vera was going to be in >fedora.us before the merge), but I'm dead tired of not having two font >package behaving the same way because they all use their own secret >recipes. So am I, but any time something changes, I can't contact n random developers and tell them what chagnes to incorporate into their packages very easily, and if I make a document and put it somewhere, I have no guarantee anyone will read it. I've direct emailed people about changes in the past and was ignored. I don't recall if I bugzilla'd my requests or not however so that may be my fault perhaps. I'd still prefer to just maintain all the font packages in the distribution myself and make them all follow one style and one common set of installation mechanics. There is also a problem where all fonts could theoretically be used by both xfs and also fontconfig/Xft, however we only want the given fonts to be in one or the other of those 2 systems for whatever preferential reasons we have. One example is the Luxi TTF font. Last I checked, we only enable this in core fonts and not in fontconfig, because the Luxi Type1 font is nicer looking in fontconfig than Luxi TTF. Having a single definitive "install-font" script which could be used in all packages would be nice, however it would have to also have commandline options to allow "core fonts only" and "fontconfig only" options, and perhaps others. I haven't had the time to investigate doing such though. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Thu Oct 9 11:13:41 2003 From: mharris at redhat.com (Mike A. Harris) Date: Thu, 9 Oct 2003 07:13:41 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: <1065696996.3883.2.camel@ulysse.olympe.o2t> References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <1065696476.3713.3.camel@ulysse.olympe.o2t> <1065696996.3883.2.camel@ulysse.olympe.o2t> Message-ID: On Thu, 9 Oct 2003, Nicolas Mailhot wrote: >> if it's done via macros, an official document, or a reference spec file >> everyone is supposed to copy (like bitstream-vera was going to be in >> fedora.us before the merge), but I'm dead tired of not having two font >> package behaving the same way because they all use their own secret >> recipes. > >(Another solution of course being "install all fonts un >/usr/share/fonts", the system will take care of fonts.* generation and >directory registration at next xfs restart) As it stands right now, when a Red Hat font package is installed, chkfontpath is called to add it to the xfs font path. The last thing chkfontpath does, is check and see if xfs is currently running, and if it is, it sends a SIGUSR1 to the xfs process, which causes xfs to reread it's config file. This will add fonts to be useable right away, however there are some cases in which it will not work if I understand correctly, however it is a convenience nonetheless. For fontconfig, the fonts are useable immediately in some applications I believe, while other apps require a restart. >However this will break rpm -e unless the xfs service also cleans ups >dangling indexes/registered directories after font removal. xfs is not signalled to reread it's config file upon font uninstallation, however IIRC, that causes problems anyway although I don't remember what they are. I believe it has something to do with glyph caching or somesuch. Maybe Owen remembers more than I do... it's even possible the problems I seem to recall don't exist anymore... -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From buildsys at porkchop.devel.redhat.com Thu Oct 9 11:32:54 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Thu, 9 Oct 2003 07:32:54 -0400 Subject: rawhide report: 20031009 changes Message-ID: <200310091132.h99BWsX05005@porkchop.devel.redhat.com> Removed package redhat-logos Updated Packages: anaconda-9.0.95-1 ----------------- * Wed Oct 08 2003 Anaconda team - built new version from CVS * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 * Mon Sep 09 2002 Jeremy Katz - can't buildrequire dietlibc and kernel-pcmcia-cs since they don't always exist * Wed Aug 21 2002 Jeremy Katz - added URL * Thu May 23 2002 Jeremy Katz - add require and buildrequire on rhpl * Tue Apr 02 2002 Michael Fulbright - added some more docs * Fri Feb 22 2002 Jeremy Katz - buildrequire kernel-pcmcia-cs as we've sucked the libs the loader needs to there now * Thu Feb 07 2002 Michael Fulbright - goodbye reconfig * Thu Jan 31 2002 Jeremy Katz - update the BuildRequires a bit * Fri Jan 04 2002 Jeremy Katz - ddcprobe is now done from kudzu * Wed Jul 18 2001 Jeremy Katz - own /usr/lib/anaconda and /usr/share/anaconda * Fri Jan 12 2001 Matt Wilson - sync text with specspo * Thu Aug 10 2000 Matt Wilson - build on alpha again now that I've fixed the stubs * Wed Aug 09 2000 Michael Fulbright - new build * Fri Aug 04 2000 Florian La Roche - allow also subvendorid and subdeviceid in trimpcitable * Fri Jul 14 2000 Matt Wilson - moved init script for reconfig mode to /etc/init.d/reconfig - move the initscript back to /etc/rc.d/init.d - Prereq: /etc/init.d * Thu Feb 03 2000 Michael Fulbright - strip files - add lang-table to file list * Wed Jan 05 2000 Michael Fulbright - added requirement for rpm-python * Mon Dec 06 1999 Michael Fulbright - rename to 'anaconda' instead of 'anaconda-reconfig' * Fri Dec 03 1999 Michael Fulbright - remove ddcprobe since we don't do X configuration in reconfig now * Tue Nov 30 1999 Michael Fulbright - first try at packaging reconfiguration tool bind-9.2.2.P3-6 --------------- * Wed Oct 08 2003 Daniel Walsh 9.2.2.P3-6 - Fix local time in log file caching-nameserver-7.2-8 ------------------------ * Wed Oct 08 2003 Dan Walsh - Change to handle chroot environments. cdlabelgen-2.6.1-1 ------------------ * Wed Oct 08 2003 Harald Hoyer 2.6.1-1 - Updated to new version 2.6.1 cdrtools-2.01-0.a19.1 --------------------- dhcp-3.0pl2-6.16 ---------------- * Wed Oct 08 2003 Dan Walsh 1:3.0pl2-6.16 - Fix location of ntp driftfile dialog-0.9b-20031002.1 ---------------------- * Wed Oct 08 2003 Harald Hoyer 0.9b-20031002.1 - version 20031002 dvd+rw-tools-5.13.4.7.4-1 ------------------------- * Wed Oct 08 2003 Harald Hoyer 5.13.4.7.4-1 - version 5.13.4.7.4 dvdrtools-0.1.5-1 ----------------- * Wed Oct 08 2003 Harald Hoyer 0.1.5-1 - version 0.1.5 fedora-release-0.95-1 --------------------- firstboot-1.2.2-1 ----------------- * Wed Oct 08 2003 Brent Fox 1.2.2-1 - remove up2date module from Fedora gkrellm-2.1.20-1 ---------------- * Wed Oct 08 2003 Karsten Hopp 2.1.20-1 - update to make it work with kernel 2.6 httpd-2.0.47-8 -------------- * Wed Oct 08 2003 Joe Orton 2.0.47-8 - use -fPIE not -fpie to fix s390x (Florian La Roche) - include VERSIONING in docdir * Mon Oct 06 2003 Joe Orton 2.0.47-7 - enable PIE support - include bug fix for #78019 initscripts-7.36-1 ------------------ * Wed Oct 08 2003 Bill Nottingham 2:3.48-1 - version 3.48 openoffice.org-1.1.0-2 ---------------------- * Tue Oct 07 2003 Jeremy Katz 1.1.0-2 - add obsoletes to subpackages rawhide-release-20031009-1 -------------------------- redhat-artwork-0.82-1 --------------------- * Wed Oct 08 2003 Alexander Larsson 0.82-1 - Icon fixes redhat-config-boot-0.1.3-1 -------------------------- * Wed Oct 08 2003 Harald Hoyer 0.1.3-1 - added po files * Thu Oct 02 2003 Harald Hoyer 0.1.2-1 - fixed desktop file redhat-config-network-1.3.7-1 ----------------------------- * Wed Oct 08 2003 Harald Hoyer 1.3.7 - merged in changes from Taroon zlib-1.2.0.7-2 -------------- * Wed Oct 08 2003 Jeff Johnson 1.2.0.7-2 - fix: gzeof not set when reading compressed file (#106424). - fix: revert zlib.h include constants for now (#106291). From pp at ee.oulu.fi Thu Oct 9 12:40:50 2003 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Thu, 9 Oct 2003 15:40:50 +0300 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <20031009093356.GA9789@pluto.pslib.cz> References: <20031009093356.GA9789@pluto.pslib.cz> Message-ID: <20031009124050.GA24469@ee.oulu.fi> On Thu, Oct 09, 2003 at 11:33:56AM +0200, Milan Kerslager wrote: > I'm clear that this test is not fair as there is no same free RAM > initial condition (and no same apps and components loaded), but still > feeling that we need to make more for usable desktop (ie. loading time > is important here). Interesting experiment would be to have a gentoo system running under Fedora inside a chroot with just the apps to be benchmarked (so libc, XFree86 and the app). That would balance the initial conditions at least, oprofile should explain the reasons for any differences. That said, I was really surprised how fast OO 1.1 from rawhide started up (even before it got prelinked) :-) -- Pekka Pietikainen From jspaleta at princeton.edu Thu Oct 9 13:36:03 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 09 Oct 2003 09:36:03 -0400 Subject: Regarding the Mirror structure and Fedora Legacy Message-ID: <1065706563.5599.9.camel@spatula> Warren Togami wrote: > The current discussion between RH people and the interim Fedora Legacy > planning team [1] seems to be that Legacy will not publish packages > within the regular Fedora mirror structure. Instead both RH and Legacy > want users to consciously change their configurations to point to the > new location when a distribution hits the point of EOL, in order to > make it clear that the packages are coming from a different source > than those officially published and supported by RH the company. Are there lurking trademark issues here as well...with regard to using "Fedora" to describe what "legacy" is. I'm not sure if this plan for Fedora Legacy, falls within the current Trademark Guidelines for the mark "Fedora." Simply put...can it even be called "Fedora Legacy" under the currently stated trademark guidelines, if it has a separate distribution structure? -jef"nothing beats a new pair of shoes...especially when they are steel toed, and water-proof, and the government pays for them"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 otaylor at redhat.com Thu Oct 9 14:08:30 2003 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 09 Oct 2003 10:08:30 -0400 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <20031009093356.GA9789@pluto.pslib.cz> References: <20031009093356.GA9789@pluto.pslib.cz> Message-ID: <1065708509.25628.4.camel@poincare.devel.redhat.com> On Thu, 2003-10-09 at 05:33, Milan Kerslager wrote: > Hi, > > I just read http://www.gentoo.org/main/en/performance.xml > > I'm clear that this test is not fair as there is no same free RAM > initial condition (and no same apps and components loaded), but still > feeling that we need to make more for usable desktop (ie. loading time > is important here). > > What I would like to make sure is that Fedora developers take an eye on > this to not shoot down this new project 1 day after release. > > I really dislike this sort of unfair PR that avoid importatnt > objectivity but what we can do more than check our reserves... What is somewhat amusing about the test is that the one major advantage of the Gentoo approach is that you *could* create two otherwise identical systems except for compiler flags quite easily, something that would be fairly hard with more conventional systems. But the tester hasn't (as far as I can see) done this, and just jumps to the conclusion that compiler flags are responsible for the major speed differences. Regards, Owen From mark at mark.mielke.cc Thu Oct 9 14:41:25 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Thu, 9 Oct 2003 10:41:25 -0400 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <1065708509.25628.4.camel@poincare.devel.redhat.com> References: <20031009093356.GA9789@pluto.pslib.cz> <1065708509.25628.4.camel@poincare.devel.redhat.com> Message-ID: <20031009144125.GA24724@mark.mielke.cc> On Thu, Oct 09, 2003 at 10:08:30AM -0400, Owen Taylor wrote: > What is somewhat amusing about the test is that the one major > advantage of the Gentoo approach is that you *could* create two > otherwise identical systems except for compiler flags quite easily, > something that would be fairly hard with more conventional > systems. > But the tester hasn't (as far as I can see) done this, and just > jumps to the conclusion that compiler flags are responsible for the > major speed differences. This perspective is a little cynical. The tester was quite clear that the results *can* be disputed. It goes further to point out that Mandrake may be running more services (i.e. the free RAM is not equivalent), and it also points to the kernel patch set (i.e. not just the compiler flags). There are a number of things about many Linux distributions, including RedHat, that are not fully optimal. These sorts of reports shouldn't be accepted as proof that RedHat/Fedora needs to revolutionize how it works, but these sorts of reports should not be ignored, or written off, either. I will echo the sentiments of the original poster: Please take these sorts of reports into account. Read between the lines, or whatever is useful, but don't write them off. Cheers, mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From otaylor at redhat.com Thu Oct 9 14:55:39 2003 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 09 Oct 2003 10:55:39 -0400 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <20031009144125.GA24724@mark.mielke.cc> References: <20031009093356.GA9789@pluto.pslib.cz> <1065708509.25628.4.camel@poincare.devel.redhat.com> <20031009144125.GA24724@mark.mielke.cc> Message-ID: <1065711339.25628.41.camel@poincare.devel.redhat.com> On Thu, 2003-10-09 at 10:41, Mark Mielke wrote: > On Thu, Oct 09, 2003 at 10:08:30AM -0400, Owen Taylor wrote: > > What is somewhat amusing about the test is that the one major > > advantage of the Gentoo approach is that you *could* create two > > otherwise identical systems except for compiler flags quite easily, > > something that would be fairly hard with more conventional > > systems. > > > But the tester hasn't (as far as I can see) done this, and just > > jumps to the conclusion that compiler flags are responsible for the > > major speed differences. > > This perspective is a little cynical. The tester was quite clear that > the results *can* be disputed. It goes further to point out that Mandrake > may be running more services (i.e. the free RAM is not equivalent), and > it also points to the kernel patch set (i.e. not just the compiler flags). > > There are a number of things about many Linux distributions, including > RedHat, that are not fully optimal. These sorts of reports shouldn't be > accepted as proof that RedHat/Fedora needs to revolutionize how it works, > but these sorts of reports should not be ignored, or written off, either. > > I will echo the sentiments of the original poster: Please take these sorts > of reports into account. Read between the lines, or whatever is useful, but > don't write them off. I think you completely missed the point of my email; what my mail was saying was: - It's interesting that such large speed differences exist in the testing. - I'm a little skeptical that the compiler had much to do with it. - Gentoo would be a great platform for verifying that one way or the other, so it would be great if those tests were extended to do an apples-versus-apples comparison with only compiler flags changed. Regards, Owen From jspaleta at princeton.edu Thu Oct 9 15:25:23 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 09 Oct 2003 11:25:23 -0400 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) Message-ID: <1065713123.5599.52.camel@spatula> Mark Mielke wrote: > This perspective is a little cynical. The tester was quite clear that > the results *can* be disputed. It goes further to point out that Mandrake > may be running more services (i.e. the free RAM is not equivalent), and > it also points to the kernel patch set (i.e. not just the compiler flags) From mark at mark.mielke.cc Thu Oct 9 15:41:37 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Thu, 9 Oct 2003 11:41:37 -0400 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <1065711339.25628.41.camel@poincare.devel.redhat.com> References: <20031009093356.GA9789@pluto.pslib.cz> <1065708509.25628.4.camel@poincare.devel.redhat.com> <20031009144125.GA24724@mark.mielke.cc> <1065711339.25628.41.camel@poincare.devel.redhat.com> Message-ID: <20031009154137.GA25807@mark.mielke.cc> On Thu, Oct 09, 2003 at 10:55:39AM -0400, Owen Taylor wrote: > On Thu, 2003-10-09 at 10:41, Mark Mielke wrote: > > On Thu, Oct 09, 2003 at 10:08:30AM -0400, Owen Taylor wrote: > > > What is somewhat amusing about the test is that the one major > > > advantage of the Gentoo approach is that you *could* create two > > > otherwise identical systems except for compiler flags quite easily, > > > something that would be fairly hard with more conventional > > > systems. > > > But the tester hasn't (as far as I can see) done this, and just > > > jumps to the conclusion that compiler flags are responsible for the > > > major speed differences. > > This perspective is a little cynical. The tester was quite clear that > > the results *can* be disputed. It goes further to point out that Mandrake > > may be running more services (i.e. the free RAM is not equivalent), and > > it also points to the kernel patch set (i.e. not just the compiler flags). > ... > I think you completely missed the point of my email; what my mail > was saying was: I apologize if I read you wrong. I will point out, though, that your concluding paragraph made an incorrect conclusion. You seem to believe that the tester believes that compiler flags made all the difference. I do not read the article referred to the same way that you do. > - Gentoo would be a great platform for verifying that one way or > the other, so it would be great if those tests were extended > to do an apples-versus-apples comparison with only compiler > flags changed. The purpose of the test wasn't to compare GCC optimizer settings. It was to compare Gentoo to Mandrake. Unless I am wrong, the reason Mandrake was chosen, is because Mandrake purports to be GCC optimized for the Pentium instruction set as well... I'm not sure what you would gain from the test that you couldn't gain from recompiling a few RedHat packages with GCC optimizer settings finely tuned. Cheers, mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From jakub at redhat.com Thu Oct 9 15:55:56 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 9 Oct 2003 11:55:56 -0400 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <20031009154137.GA25807@mark.mielke.cc>; from mark@mark.mielke.cc on Thu, Oct 09, 2003 at 11:41:37AM -0400 References: <20031009093356.GA9789@pluto.pslib.cz> <1065708509.25628.4.camel@poincare.devel.redhat.com> <20031009144125.GA24724@mark.mielke.cc> <1065711339.25628.41.camel@poincare.devel.redhat.com> <20031009154137.GA25807@mark.mielke.cc> Message-ID: <20031009115556.B26086@devserv.devel.redhat.com> On Thu, Oct 09, 2003 at 11:41:37AM -0400, Mark Mielke wrote: > The purpose of the test wasn't to compare GCC optimizer settings. It was > to compare Gentoo to Mandrake. Unless I am wrong, the reason Mandrake was > chosen, is because Mandrake purports to be GCC optimized for the > Pentium instruction set as well... Which is not true. Optimizing for Pentium is very stupid thing to do if your CPU is anything but the aging Pentium. Mandrake as well as Red Hat and Fedora are all optimized for Pentium Pro and later CPUs. Difference between Mdk and RHEL/RHL/FC is that Mdk has most packages shipped as .i586.rpm (ie. can run just on i586+, optimized for i686) while most RHEL/RHL/FC packages are .i386.rpm (ie. can run on i386+, optimized for i686). In reality there is no real difference between -march=i386 and -march=i586 if -mcpu=i686 is used. Jakub From mark at mark.mielke.cc Thu Oct 9 16:03:25 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Thu, 9 Oct 2003 12:03:25 -0400 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <20031009115556.B26086@devserv.devel.redhat.com> References: <20031009093356.GA9789@pluto.pslib.cz> <1065708509.25628.4.camel@poincare.devel.redhat.com> <20031009144125.GA24724@mark.mielke.cc> <1065711339.25628.41.camel@poincare.devel.redhat.com> <20031009154137.GA25807@mark.mielke.cc> <20031009115556.B26086@devserv.devel.redhat.com> Message-ID: <20031009160325.GA25911@mark.mielke.cc> On Thu, Oct 09, 2003 at 11:55:56AM -0400, Jakub Jelinek wrote: > On Thu, Oct 09, 2003 at 11:41:37AM -0400, Mark Mielke wrote: > > The purpose of the test wasn't to compare GCC optimizer settings. It was > > to compare Gentoo to Mandrake. Unless I am wrong, the reason Mandrake was > > chosen, is because Mandrake purports to be GCC optimized for the > > Pentium instruction set as well... > Which is not true. Optimizing for Pentium is very stupid thing to do if your > CPU is anything but the aging Pentium. > Mandrake as well as Red Hat and Fedora are all optimized for Pentium Pro and > later CPUs. The only not true part is the Pentium qualification. If you read the disagreement between Owen and I, you should easily note that my problem with Owen's statement was that he assumed that the Gentoo person assumed it was all about compiler flags. Meaning, thanks for qualifying my comment, but you haven't discredited it, but rather, you've enforced it. RedHat could not be chosen to compare against Gentoo, because RedHat doesn't pretend to be optimized for Pentium-class (which includes i686) machines. Mandrake does. > Difference between Mdk and RHEL/RHL/FC is that Mdk has most packages > shipped as .i586.rpm (ie. can run just on i586+, optimized for i686) > while most RHEL/RHL/FC packages are .i386.rpm (ie. can run on i386+, > optimized for i686). In reality there is no real difference between > -march=i386 and -march=i586 if -mcpu=i686 is used. Again, thank you for the information, but you too are only talking about compiler flags. The Gentoo test isn't about compiler flags. Compiler flags are perhaps a factor, but likely not the most significant one... Owen and I agree on this, as I suspect, so do you. The Gentoo tester never claimed that compiler flags were the most significant factor. Performance concerns seem to be almost as religious as the editors wars, or the operating system wars... *sigh* mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From hosting at j2solutions.net Thu Oct 9 16:10:58 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Thu, 9 Oct 2003 09:10:58 -0700 Subject: Regarding the Mirror structure and Fedora Legacy In-Reply-To: <1065706563.5599.9.camel@spatula> References: <1065706563.5599.9.camel@spatula> Message-ID: <200310090910.58576.hosting@j2solutions.net> On Thursday 09 October 2003 06:36, Jef Spaleta wrote: > > The current discussion between RH people and the interim Fedora > > Legacy planning team [1] seems to be that Legacy will not publish > > packages within the regular Fedora mirror structure. Instead both > > RH and Legacy want users to consciously change their configurations > > to point to the new location when a distribution hits the point of > > EOL, in order to make it clear that the packages are coming from a > > different source than those officially published and supported by > > RH the company. Thats almost misleading. My personal request was that while our updates wouldn't go in the same _directory_ as those provided by Red Hat, we would have another folder in the tree just for us, so that once the folder RH controls is no longer populated, our folder would begin to be populated. Not sure if this is feasible or agreeable by Red Hat, I'm still waiting to get on the mirror list. > Are there lurking trademark issues here as well...with regard to > using "Fedora" to describe what "legacy" is. I'm not sure if this > plan for Fedora Legacy, falls within the current Trademark Guidelines > for the mark "Fedora." Simply put...can it even be called "Fedora > Legacy" under the currently stated trademark guidelines, if it has a > separate distribution structure? I'll bring up the trademark issues today and see if I can't get some answers. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From otaylor at redhat.com Thu Oct 9 16:14:40 2003 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 09 Oct 2003 12:14:40 -0400 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <20031009154137.GA25807@mark.mielke.cc> References: <20031009093356.GA9789@pluto.pslib.cz> <1065708509.25628.4.camel@poincare.devel.redhat.com> <20031009144125.GA24724@mark.mielke.cc> <1065711339.25628.41.camel@poincare.devel.redhat.com> <20031009154137.GA25807@mark.mielke.cc> Message-ID: <1065716080.25628.56.camel@poincare.devel.redhat.com> On Thu, 2003-10-09 at 11:41, Mark Mielke wrote: > On Thu, Oct 09, 2003 at 10:55:39AM -0400, Owen Taylor wrote: > > On Thu, 2003-10-09 at 10:41, Mark Mielke wrote: > > > On Thu, Oct 09, 2003 at 10:08:30AM -0400, Owen Taylor wrote: > > > > What is somewhat amusing about the test is that the one major > > > > advantage of the Gentoo approach is that you *could* create two > > > > otherwise identical systems except for compiler flags quite easily, > > > > something that would be fairly hard with more conventional > > > > systems. > > > > But the tester hasn't (as far as I can see) done this, and just > > > > jumps to the conclusion that compiler flags are responsible for the > > > > major speed differences. > > > This perspective is a little cynical. The tester was quite clear that > > > the results *can* be disputed. It goes further to point out that Mandrake > > > may be running more services (i.e. the free RAM is not equivalent), and > > > it also points to the kernel patch set (i.e. not just the compiler flags). > > ... > > I think you completely missed the point of my email; what my mail > > was saying was: > > I apologize if I read you wrong. I will point out, though, that your > concluding paragraph made an incorrect conclusion. You seem to believe > that the tester believes that compiler flags made all the difference. > I do not read the article referred to the same way that you do. The initial sentence of the "What can be gleaned from these results" is "For one, the default optimizations of Gentoo Linux 1.4 for Pentium III appear to make a significant difference in "real world" application load-time performance with Mozilla." A claim that I don't see any substantiation of in the rest of the article. What is documented is that in the test, Mozilla loaded a lot faster, but no tests were done to separate out different possibilities for what accounted for the speed difference. (It also should be noted that this page has undergone at least some changes since I read it a few days ago... unlike an article, you can't really debate what a web page says.) I don't really want to get into a big debate here. I think it's great that people are doing desktop performance testing. I'd just like to encourage the attitude that as soon as you do a test that shows A is faster than B, the next step should be to do a test to figure out *why* A is faster than B. > > - Gentoo would be a great platform for verifying that one way or > > the other, so it would be great if those tests were extended > > to do an apples-versus-apples comparison with only compiler > > flags changed. > > The purpose of the test wasn't to compare GCC optimizer settings. It was > to compare Gentoo to Mandrake. Unless I am wrong, the reason Mandrake was > chosen, is because Mandrake purports to be GCC optimized for the > Pentium instruction set as well... I'm not sure what you would gain from > the test that you couldn't gain from recompiling a few RedHat packages with > GCC optimizer settings finely tuned. Well, doing the tests on Gentoo would be more likely to convince Gentoo users one way or the other :-). Also, the commonly heard Gentoo claim is that you get significant advantages by compiling the *entire system* with architecture-specific optimization flags. Regards, Owen From jaap_haitsma at zonnet.nl Thu Oct 9 16:34:23 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Thu, 09 Oct 2003 18:34:23 +0200 Subject: up2date failing dependencies window too big!!! In-Reply-To: References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> Message-ID: <3F858E0F.9000707@zonnet.nl> Behdad Esfahbod wrote: > On Wed, 8 Oct 2003, Jaap A. Haitsma wrote: > > >>Dan Tucny wrote: >> >>>On Wed, 2003-10-08 at 22:57, Jaap A. Haitsma wrote: >>> >>> >>>>The failing dependencies list today was so large that the dialog box >>>>that was created did not fit on my screen and I had to kill up2date. >>>> >>>>Would be nice that a dialog with list box would appear with the failing >>>>dependencies so that the window can be closed normally >>> >>> >>>Have you fed bugzilla this info? >>> >>>Dan >>> >> >>Noop, not yet. I can do this, if people feel this should be done > > > Well, why not? It's a bug (or at least an feature request). > Better sit there in bugzilla than to be forgotten. > I found it's already in Bugzilla since July 2001 See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=47800 Too bad this has never been solved up till now. Priority has been assigned as low, but it's fairly easy to fix I would say Jaap From jaap_haitsma at zonnet.nl Thu Oct 9 16:53:45 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Thu, 09 Oct 2003 18:53:45 +0200 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: References: <3F8004E1.7020808@zonnet.nl> <1065570448.32391.20.camel@poincare.devel.redhat.com> Message-ID: <3F859299.60709@zonnet.nl> The updates of today solved the initial problem I had that graphical booting was much slower then text booting :-) Furthermore it looks much nicer and there is a possibility to show details. (Great work) I still have to minor issues: 1. If I show details then after a while when the service keytable gets loaded "[ OK ]" changes to "A OK U" (actually it are an A and an U with two dots on top, don't know how you call those letters in English) 2. Furthermore interactive startup now works :-). However I have to push show details after I pushed the "I" otherwise it boots right trough. Would be nice that it would flip automatically to detailed mode if you pressed "I". Jaap From mark at mark.mielke.cc Thu Oct 9 17:09:45 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Thu, 9 Oct 2003 13:09:45 -0400 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <1065716080.25628.56.camel@poincare.devel.redhat.com> References: <20031009093356.GA9789@pluto.pslib.cz> <1065708509.25628.4.camel@poincare.devel.redhat.com> <20031009144125.GA24724@mark.mielke.cc> <1065711339.25628.41.camel@poincare.devel.redhat.com> <20031009154137.GA25807@mark.mielke.cc> <1065716080.25628.56.camel@poincare.devel.redhat.com> Message-ID: <20031009170945.GA26142@mark.mielke.cc> On Thu, Oct 09, 2003 at 12:14:40PM -0400, Owen Taylor wrote: > The initial sentence of the "What can be gleaned from these results" is > "For one, the default optimizations of Gentoo Linux 1.4 for Pentium III > appear to make a significant difference in "real world" application > load-time performance with Mozilla." The "Gentoo Linux 1.4 for Pentium III" is optimized using the compiler flags, sure, but it also has the kernel with Pentium III support compiled into it, as well as hundreds of patches. I haven't looked at each patch, but many of them are patches that have not made it into the RedHat tree (NOTE: they used their 'gaming desktop' patch set for the speed test), and definately not the Linus tree. The Pentium III focus is more of a category as in "You can build the system any way you want, but our LiveCD set comes with x86, Pentium, and Pentium III (or whatever the current set is) pre-compiled, and pre-tuned for you." > A claim that I don't see any substantiation of in the rest of the > article. What is documented is that in the test, Mozilla loaded a lot > faster, but no tests were done to separate out different possibilities > for what accounted for the speed difference. *nod* > (It also should be noted that this page has undergone at least some > changes since I read it a few days ago... unlike an article, you > can't really debate what a web page says.) Perhaps I read the later revision, in which case, I shouldn't be criticising you until I read the initial revision... :-) > Well, doing the tests on Gentoo would be more likely to convince Gentoo > users one way or the other :-). Also, the commonly heard Gentoo claim > is that you get significant advantages by compiling the *entire system* > with architecture-specific optimization flags. I've always interpretted this to mean that the entire system is compiled using "i686" or later as a target, which for some packages (especially including the kernel), includes more than just compiler flags. You are right, though, that most people likely interpret this to mean compiler flags. As for which was intended? I guess I can't speak for their motivations. :-) I believe that RedHat has ventured into this area with the inclusion of the FUTEX kernel feature, and the -nptl kernel/glibc builds. Components of these features work more efficiently with a later instruction set. I guess this issue is important to me because I find it a little embarassing that my wonderful 'linux desktop' at work takes 3X as long to start my web browser, and 10X as long to start my word processor. Much of this isn't RedHat's fault at all -- The Mozilla people and OpenOffice people are learning how to make their systems more efficient (or at least appear more efficient), and once they are done, hopefully the results will be competitive. Cheers, mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From rahul at genebrew.com Thu Oct 9 17:25:54 2003 From: rahul at genebrew.com (Rahul Karnik) Date: Thu, 09 Oct 2003 13:25:54 -0400 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <20031009170945.GA26142@mark.mielke.cc> References: <20031009093356.GA9789@pluto.pslib.cz> <1065708509.25628.4.camel@poincare.devel.redhat.com> <20031009144125.GA24724@mark.mielke.cc> <1065711339.25628.41.camel@poincare.devel.redhat.com> <20031009154137.GA25807@mark.mielke.cc> <1065716080.25628.56.camel@poincare.devel.redhat.com> <20031009170945.GA26142@mark.mielke.cc> Message-ID: <3F859A22.7050403@genebrew.com> Mark Mielke wrote: > I guess this issue is important to me because I find it a little > embarassing that my wonderful 'linux desktop' at work takes 3X as long > to start my web browser, and 10X as long to start my word > processor. Actually, look at the Gentoo forums. There are plenty of cases where the binaries provided by upstream prohects are faster than the "optimized" ones compiles by Gentoo users (mozilla and openoffice.org, IIRC). For large programs, app load times are *probably* best when compiled with -Os, something that is rarely done by Gentoo users. Typical Gentoo CFLAGS are "-O2 blah" or "-O3 blah". In my experience, -O2 yields the best results, but I would go with upstream guidance every time. As for processor optimizations, I am willing to bet that they do not affect app load times -- places where they might matter are computationally intense applications like MPlayer or scientific computation. Pardon the ramblings, Rahul -- Rahul Karnik rahul at genebrew.com http://www.genebrew.com/ From otaylor at redhat.com Thu Oct 9 18:30:56 2003 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 09 Oct 2003 14:30:56 -0400 Subject: Ugly main menu icon Message-ID: <1065724255.25628.150.camel@poincare.devel.redhat.com> OK, figured out what is going on with the blurry main menu icon: - Panel thinks that the main menu icon is going to be themed by the stock icon mechanism - We don't want the main menu icon themed, so we don't put it in Bluecurve. - The way that the default icon is set for the stock icon is that the panel looks up the icon at size 24 in the current *icon* theme. - That used to find only the 48 pixel variant, but Garrett just added 16,24,36 variants of the icon, so => extreme ugliness. I think if we just hack the panel to look up the icon at a very large size, it should fix this pretty well - - filename = gnome_desktop_item_find_icon ( - panel_icon_theme, stock_icons [i].icon, icon_height, 0); + filename = gnome_desktop_item_find_icon ( + panel_icon_theme, stock_icons [i].icon, 1000, 0); it may, in a few cases, mean that we scale down rather than using the right size icons, but for anything actually in Bluecurve it won't matter, since it will go through the normal GTK+ stock icon size look up mechanisms. And we'll never scale up that way. Of course, what the panel is doing is fundamentally broken .. it needs to decide whether these icons are being themed through: - The GTK+ stock icon system - The named icon theme system Not mix the two together in some fashion. But fixing that would take more work, and probably is best done upstream for GNOME-2.6. (For GNOME-2.6 we have named icons in GTK+ and sane stock-icon/ named-icon integration.) Regards, Owen From wen at us.ibm.com Thu Oct 9 18:41:21 2003 From: wen at us.ibm.com (Wen-Jiunn Chin) Date: Thu, 9 Oct 2003 14:41:21 -0400 Subject: Wen-Jiunn Chin/Endicott/IBM is out of the office. Message-ID: I will be out of the office starting October 9, 2003 and will not return until October 14, 2003. I am out of the office from 10/09/03, returning 10/14/03. You will receive only this notification of my absence prior to my return, at which time I will respond. Please contact Syed Abuthagir for GWA. Please contact my manager David Albright, for emergencies. On Deamand Project - Larry Sackette GWA Linux Servers - Vikas Paul Treve Project - Anand Banerjee Team Lead - Steve Bernstein From occy at occy.net Thu Oct 9 18:55:28 2003 From: occy at occy.net (Trae McCombs) Date: Thu, 09 Oct 2003 14:55:28 -0400 Subject: Ugly main menu icon In-Reply-To: <1065724255.25628.150.camel@poincare.devel.redhat.com> References: <1065724255.25628.150.camel@poincare.devel.redhat.com> Message-ID: <1065725728.29255.10.camel@redsky> Why on earth can't we be allowed to: a.) change the icon on the menu bar. and b.) be allowed to change the text for the menu bar. I do realize this is a question more or less for the gnome developers, but... example: I wanted to use a specific icon (to match my theme), and I wanted to use the words: apps and tools in lieu of Applications and Actions. This would allow for people to customize their gnome start menus, and why is that such a bad thing? -occy PS. Furthermore, there seems to be a class of some sorts setup with icons. I know when you switch to a different Icon theme, the trash and home directory icons change. Couldn't this concept be applied to the menu bar too, allowing for themers to change this to match their icon pack? On Thu, 2003-10-09 at 14:30, Owen Taylor wrote: > OK, figured out what is going on with the blurry main menu icon: > > - Panel thinks that the main menu icon is going to be themed > by the stock icon mechanism > > - We don't want the main menu icon themed, so we don't put > it in Bluecurve. > > - The way that the default icon is set for the stock icon > is that the panel looks up the icon at size 24 in the > current *icon* theme. > > - That used to find only the 48 pixel variant, but Garrett just > added 16,24,36 variants of the icon, so => extreme ugliness. > > I think if we just hack the panel to look up the icon at > a very large size, it should fix this pretty well - > > - filename = gnome_desktop_item_find_icon ( > - panel_icon_theme, stock_icons [i].icon, icon_height, 0); > + filename = gnome_desktop_item_find_icon ( > + panel_icon_theme, stock_icons [i].icon, 1000, 0); > > it may, in a few cases, mean that we scale down rather than > using the right size icons, but for anything actually in Bluecurve > it won't matter, since it will go through the normal GTK+ stock > icon size look up mechanisms. > > And we'll never scale up that way. > > Of course, what the panel is doing is fundamentally broken .. it > needs to decide whether these icons are being themed through: > > - The GTK+ stock icon system > - The named icon theme system > > Not mix the two together in some fashion. But fixing that would take > more work, and probably is best done upstream for GNOME-2.6. > (For GNOME-2.6 we have named icons in GTK+ and sane stock-icon/ > named-icon integration.) > > Regards, > Owen > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From notting at redhat.com Thu Oct 9 19:41:31 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 9 Oct 2003 15:41:31 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <3F859299.60709@zonnet.nl>; from jaap_haitsma@zonnet.nl on Thu, Oct 09, 2003 at 06:53:45PM +0200 References: <3F8004E1.7020808@zonnet.nl> <1065570448.32391.20.camel@poincare.devel.redhat.com> <3F859299.60709@zonnet.nl> Message-ID: <20031009154130.A29659@devserv.devel.redhat.com> Jaap A. Haitsma (jaap_haitsma at zonnet.nl) said: > I still have to minor issues: > > 1. If I show details then after a while when the service keytable gets > loaded "[ OK ]" changes to "A OK U" (actually it are an A and an U with > two dots on top, don't know how you call those letters in English) Yup, just disable the keytable script. It probably needs to be removed anyway (it's superfluous). Bill From warren at togami.com Thu Oct 9 19:48:52 2003 From: warren at togami.com (Warren Togami) Date: Thu, 09 Oct 2003 09:48:52 -1000 Subject: Regarding the Mirror structure and Fedora Legacy In-Reply-To: <200310090910.58576.hosting@j2solutions.net> References: <1065706563.5599.9.camel@spatula> <200310090910.58576.hosting@j2solutions.net> Message-ID: <3F85BBA4.9030305@togami.com> Jesse Keating wrote: > On Thursday 09 October 2003 06:36, Jef Spaleta wrote: > >>>The current discussion between RH people and the interim Fedora >>>Legacy planning team [1] seems to be that Legacy will not publish >>>packages within the regular Fedora mirror structure. Instead both >>>RH and Legacy want users to consciously change their configurations >>>to point to the new location when a distribution hits the point of >>>EOL, in order to make it clear that the packages are coming from a >>>different source than those officially published and supported by >>>RH the company. > > > Thats almost misleading. My personal request was that while our updates > wouldn't go in the same _directory_ as those provided by Red Hat, we > would have another folder in the tree just for us, so that once the > folder RH controls is no longer populated, our folder would begin to be > populated. Not sure if this is feasible or agreeable by Red Hat, I'm > still waiting to get on the mirror list. > > Oh, sorry, I misunderstood. I guess we're both waiting for solid answers though. Warren From behdad at cs.toronto.edu Thu Oct 9 20:04:35 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Thu, 9 Oct 2003 16:04:35 -0400 Subject: up2date failing dependencies window too big!!! In-Reply-To: <3F858E0F.9000707@zonnet.nl> References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> <3F858E0F.9000707@zonnet.nl> Message-ID: On Thu, 9 Oct 2003, Jaap A. Haitsma wrote: > Behdad Esfahbod wrote: > > On Wed, 8 Oct 2003, Jaap A. Haitsma wrote: > > > > > >>Dan Tucny wrote: > >> > >>>On Wed, 2003-10-08 at 22:57, Jaap A. Haitsma wrote: > >>> > >>> > >>>>The failing dependencies list today was so large that the dialog box > >>>>that was created did not fit on my screen and I had to kill up2date. > >>>> > >>>>Would be nice that a dialog with list box would appear with the failing > >>>>dependencies so that the window can be closed normally > >>> > >>> > >>>Have you fed bugzilla this info? > >>> > >>>Dan > >>> > >> > >>Noop, not yet. I can do this, if people feel this should be done > > > > > > Well, why not? It's a bug (or at least an feature request). > > Better sit there in bugzilla than to be forgotten. > > > > I found it's already in Bugzilla since July 2001 See: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=47800 > > Too bad this has never been solved up till now. Priority has been > assigned as low, but it's fairly easy to fix I would say Unfortunately there are too many bugs in bugzilla that never get fixed. Any way to open things a bit more so that we dumb users can fix trivial things? Submitting patches is one step toward that. Maybe bugzilla should send list of inactive open bugs to the list every night :D > Jaap behdad, who is going to study after finishing this mail. From ted at cypress.com Thu Oct 9 20:09:58 2003 From: ted at cypress.com (Thomas Dodd) Date: Thu, 09 Oct 2003 15:09:58 -0500 Subject: artwork project In-Reply-To: <3F7C7689.3020009@redhat.com> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <3F7C4DEE.2010705@redhat.com> <200310021729.19728.gavin.henry@magicfx.co.uk> <3F7C7689.3020009@redhat.com> Message-ID: <3F85C096.9070204@cypress.com> Garrett LeSage wrote: > G Henry wrote: >> Gimp is tough going sometimes, as it's all over the place (My >> opinion), I was >> just wondering if there were some I haven't heard of. > > For Linux, basically, there's GIMP and only GIMP. You might find a copy of Corel's PhotoPAINT! somewhere. Not too bad. > It's actually a great program, once you get used to the quirks. I've > been using it for a number of years now (since around 1995 really). > > The way I cope with the GIMP's UI is by opening it on its own virtual Whay UI are you comparing it too? Have you used Photoshop on the Mac? Mayny *nix /X applications? You should try Cadence tools, or SmarTest for HP-UX for some real interesting UI's. > workspace and using sloppy focus. I also have a few custom keybindings > to often used things to help speed up the process (and to avoid the > multi-nested right-mouse menus a little bit). Do you have a solution for the nested menus? One long menu doesn't work. -Thomas From paul at gear.dyndns.org Thu Oct 9 20:54:28 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Fri, 10 Oct 2003 06:54:28 +1000 Subject: up2date --show-orphans after upgrade from RHL9 Message-ID: <3F85CB04.4070300@gear.dyndns.org> Hi folks, I don't know if anyone cares about this, but after an upgrade from RHL9 to Fedora Core 0.94, i get the following output from up2date --show-orphans: libgal21-0.23-1.i386 libunicode-0.4-12.i386 lilo-21.4.4-22.i386 qtcups-2.0-15.i386 soup-0.7.10-4.i386 I don't know about all of them, but lilo particularly concerns me. Does this mean that lilo will no longer be supported? If so, please consider this bug: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484 This has been a "must fix" bug (i don't know why it's normal priority) for nearly 2 years! Without grub support for RAID 1 devices, it is an unusable boot loader on 95% of my systems (and i think a lot of other people's as well). -- Paul http://paulgear.webhop.net A: Because we read from top to bottom, left to right. Q: Why should i start my 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 garrett at redhat.com Thu Oct 9 20:57:37 2003 From: garrett at redhat.com (Garrett LeSage) Date: Thu, 09 Oct 2003 16:57:37 -0400 Subject: artwork project In-Reply-To: <3F85C096.9070204@cypress.com> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <3F7C4DEE.2010705@redhat.com> <200310021729.19728.gavin.henry@magicfx.co.uk> <3F7C7689.3020009@redhat.com> <3F85C096.9070204@cypress.com> Message-ID: <3F85CBC1.9020909@redhat.com> Thomas Dodd wrote: > Garrett LeSage wrote: > >> For Linux, basically, there's GIMP and only GIMP. > > > You might find a copy of Corel's PhotoPAINT! somewhere. > Not too bad. I have a copy of it. I don't use it. I suggest that no one else does. It's a dead ex-product. It came with my copy of CorelDraw! for Linux -- I happened to be on the beta team a number of years back, so I have a few beta copies as well as the final released product. CorelDraw! and PhotoPaint! are both programs which are: * discontinued * unsupported * buggy * clunky * proprietary * made to run under a hacked version of Wine (they don't use winelib, as promised way-back-when) The first reason itself is more than enough to consider not using it, imho. Same can be said of any one other issue, depending on any one individual you may talk to. >> It's actually a great program, once you get used to the quirks. I've >> been using it for a number of years now (since around 1995 really). >> >> The way I cope with the GIMP's UI is by opening it on its own virtual > > > Whay UI are you comparing it too? Any other UI. (: (Sodipodi being a notable exception, as it copied the GIMP's general interface somewhat.) > Have you used Photoshop on the Mac? Yes. I am also familiar with most other DTP apps on the Mac as well, including Illustrator, FreeHand, and Quark. > Mayny *nix /X applications? Yes, I've been using Linux since 1995 and also the GIMP since before the 1.0 series. I first toyed around with the GIMP back in the Motif days, but Lesstif wasn't up to snuff, so most people (myself included) had to use the binary build as building from source wasn't an option. (Motif was EXPENSIVE, especially for a poor college student.) When the first version of the GIMP came out with GTK+ (which, at the time, was only distributed with the app), I started using it extensively. > You should try Cadence tools, or SmarTest for HP-UX for some real > interesting UI's. Check out GeoPak (screenshots and documentation @ http://198.145.188.3/geopak/idiot2001/idiot2001.htm) or GProFTPD (screenshots: http://mange.dynup.net/linux.html#Screenshots) for other apps with "interesting" UIs. (: > Do you have a solution for the nested menus? One long menu doesn't work. Place the menu bar at the top instead of contextual (which adds one extra level of menus), only go down one sublevel (two at the very most, but rarely, if ever), weed out useless menu items, arrange everything in a more sensible fashion. One long menu is on crack. Menus should be short, have nice, simple, suggestive item names, and should only go down one sublevel (two at the very most). Of course, these concepts should be applied to every menu -- including the hat menu, although it is much better than it once was (such as the 7.3 time frame and before). The GIMP's interface is a result of copying Photoshop's general look. On the Mac, Photoshop works great. On Windows, Photoshop is in MDI, which is hideous. On Linux, since no tool bar exists on the top of the screen and MDI is a bad thing (and isn't really supported well), the GIMP has windows all over the place. The best way to cope with this is to either have application windows (which some apps are starting to do) or to manage different applications on separate virtual workspaces (which is what most people who use the GIMP actually do). Garrett From jspaleta at princeton.edu Thu Oct 9 21:04:58 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 09 Oct 2003 17:04:58 -0400 Subject: Too many bugs [was Re: up2date failing dependencies window too big!!!] Message-ID: <1065733497.5599.79.camel@spatula> Behdad Esfahbod wrote: > Unfortunately there are too many bugs in bugzilla that never get > fixed. Any way to open things a bit more so that we dumb users > can fix trivial things? Submitting patches is one step toward > that. Maybe bugzilla should send list of inactive open bugs to > the list every night :D Or another way to look at it...there are too many open bugs for developers to keep up with without some help. Things like duplicate bugs, and bugs that are open where developers are waiting for basic technical feedback like tracebacks or lspci output. Everytime a developer has to go into bugzilla and read a duplicate bug and mark it, or has to write a simple "please provide an lspci outout" that's less time for developers have close bugs that are fixable. This left over up2date bug is just another symptom of the problem...developer time is a premium. What we as a community can ask is how we can help the developers use their time more effectively. And i think that starts with an active, fruitful discussion on how we can use something like Gnome's bug triage idea....to have technically proficient users in this community, work to keep bugzilla in shape. http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00180.html http://developer.gnome.org/projects/bugsquad/ http://developer.gnome.org/projects/bugsquad/triage/ -jef"but first we need to create a Fedora logo...to put on the t-shirts...that we use as prizes...for Fedora Bug Day"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 jeremyp at pobox.com Thu Oct 9 21:15:57 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: Thu, 09 Oct 2003 17:15:57 -0400 Subject: bugzilla & triage : Re: up2date failing dependencies window too big!!! In-Reply-To: References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> <3F858E0F.9000707@zonnet.nl> Message-ID: <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> On Thu, 2003-10-09 at 16:04, Behdad Esfahbod wrote: > > Unfortunately there are too many bugs in bugzilla that never get > fixed. Any way to open things a bit more so that we dumb users > can fix trivial things? Submitting patches is one step toward > that. Maybe bugzilla should send list of inactive open bugs to > the list every night :D Well, there is talk of setting up more external CVS repositories so outside developers can get better access. But still, "dumb users" who aren't developers should use Bugzilla to report the problems. It's the only way things can be tracked and remembered. Regarding large numbers of open bugs, I liked Jef Spaleta's proposal of a triage system. Unfortunately, no one commented on his message: http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00180.html --Jeremy -------------- 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 jsmith at drgutah.com Thu Oct 9 21:24:28 2003 From: jsmith at drgutah.com (Jared Smith) Date: Thu, 09 Oct 2003 15:24:28 -0600 Subject: bugzilla & triage : Re: up2date failing dependencies window too big!!! In-Reply-To: <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> <3F858E0F.9000707@zonnet.nl> <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> Message-ID: <1065734668.17250.13.camel@banff.drgutah.com> On Thu, 2003-10-09 at 15:15, Jeremy Portzer wrote: > Regarding large numbers of open bugs, I liked Jef Spaleta's proposal of > a triage system. Unfortunately, no one commented on his message: > http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00180.html Just because lurkers like myself haven't responded doesn't mean we didn't think it was a good idea. Personally, I'd love to help triage bugs when I have time. Jared Smith From hp at redhat.com Thu Oct 9 21:42:44 2003 From: hp at redhat.com (Havoc Pennington) Date: Thu, 09 Oct 2003 17:42:44 -0400 Subject: Ugly main menu icon In-Reply-To: <1065725728.29255.10.camel@redsky> References: <1065724255.25628.150.camel@poincare.devel.redhat.com> <1065725728.29255.10.camel@redsky> Message-ID: <1065735764.6560.12.camel@dhcp59-203.rdu.redhat.com> On Thu, 2003-10-09 at 14:55, Trae McCombs wrote: > Why on earth can't we be allowed to: > > a.) change the icon on the menu bar. > > and > > b.) be allowed to change the text for the menu bar. > > I do realize this is a question more or less for the gnome developers, > but... > Yes, there's no point posting this to fedora-devel; we would never apply a Fedora-specific patch to add this option. It's got to go through bugzilla.gnome.org/desktop-devel-list at gnome.org, we'll inherit the result. Havoc From jfm512 at free.fr Thu Oct 9 21:50:30 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 09 Oct 2003 23:50:30 +0200 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <3F859A22.7050403@genebrew.com> References: <20031009093356.GA9789@pluto.pslib.cz> <1065708509.25628.4.camel@poincare.devel.redhat.com> <20031009144125.GA24724@mark.mielke.cc> <1065711339.25628.41.camel@poincare.devel.redhat.com> <20031009154137.GA25807@mark.mielke.cc> <1065716080.25628.56.camel@poincare.devel.redhat.com> <20031009170945.GA26142@mark.mielke.cc> <3F859A22.7050403@genebrew.com> Message-ID: <1065736230.3323.32.camel@agnes.fremen.dune> About Gentoo and the processor optimizations. I used the nbench-byte benchamrk on a PIII. Compiling with -march=i686 instead of -mcpu=I686 (the parm used by RedHat) gave me a 35% speedup... on one of the integer tests, the other six integer tests remained the same so overall improvement was 5%, in the floating point tests I got a 3% overall improvement. Restrictions: 1) I could have gone farther with exotic alignment options and sse (in fact I tried, got a little additional improvement but less than above) 2) On an athlon I get more boost from the additional instructions allowed by -march=i686. I get still an additiional (slight) increase if I compile with -march=i686 3) The increase is somewhat flattenned because the test spends time on glibc and this didn't change. On a PIII the glibc of gentoo would provide no benefit since the glibc of Redhat is fully optimized for the PIII (with -march=i686). On a PIV or Athlon RedHat will run slower than Gentoo due to its glibc who is not optimized for them. About loading times: Too many people mix loading speed with "cruise speed". It is very easy to have a program load very fast: the configure script will look if some libraries needed for additional functionality are installed, if they aren't it will continue but will build a crippled binary: a samba who cannot use certain authentification methods, a gimp who will be unable to read anything but Jpegs and so on. You can do additional curtailing with parms to configure. Since there is less to load, and less initiliazation to do the crippled binary will load blindingly fast and that way an unscrupulous/demagogic distrib vendor can give the impression its distro is ultra fast. Of course one day you will miss that functionality who was left out. Linus loading times versus Window 98 loading times. I have found that Word/Excel/Explorer load much faster on a PIII/667 than OpenOffice and Galeon on machines who are two or three times more powerful (a PIII/1000, an Athlon 2000). In part this is due to the loading of dynamic libraries being much simpler on W98. I have tried some tricks to impprove loading times on Linux like reordering members of the libraries so the ones who are more frequently used are grouped together. It didn't provide an appreciable improvement. But something has to be done about these loading times. On Thu, 2003-10-09 at 19:25, Rahul Karnik wrote: > Mark Mielke wrote: > > I guess this issue is important to me because I find it a little > > embarassing that my wonderful 'linux desktop' at work takes 3X as long > > to start my web browser, and 10X as long to start my word > > processor. > > Actually, look at the Gentoo forums. There are plenty of cases where the > binaries provided by upstream prohects are faster than the "optimized" > ones compiles by Gentoo users (mozilla and openoffice.org, IIRC). For > large programs, app load times are *probably* best when compiled with > -Os, something that is rarely done by Gentoo users. Typical Gentoo > CFLAGS are "-O2 blah" or "-O3 blah". In my experience, -O2 yields the > best results, but I would go with upstream guidance every time. > > As for processor optimizations, I am willing to bet that they do not > affect app load times -- places where they might matter are > computationally intense applications like MPlayer or scientific computation. > > Pardon the ramblings, > Rahul > -- > Rahul Karnik > rahul at genebrew.com > http://www.genebrew.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 ville.skytta at iki.fi Thu Oct 9 21:59:15 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 10 Oct 2003 00:59:15 +0300 Subject: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <20031009093356.GA9789@pluto.pslib.cz> References: <20031009093356.GA9789@pluto.pslib.cz> Message-ID: <1065736754.11132.194.camel@bobcat.mine.nu> On Thu, 2003-10-09 at 12:33, Milan Kerslager wrote: > I just read http://www.gentoo.org/main/en/performance.xml Another one here: http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227 From wen at us.ibm.com Thu Oct 9 22:10:29 2003 From: wen at us.ibm.com (Wen-Jiunn Chin) Date: Thu, 9 Oct 2003 18:10:29 -0400 Subject: Wen-Jiunn Chin/Endicott/IBM is out of the office. Message-ID: I will be out of the office starting October 9, 2003 and will not return until October 14, 2003. I am out of the office from 10/09/03, returning 10/14/03. You will receive only this notification of my absence prior to my return, at which time I will respond. Please contact Syed Abuthagir for GWA. Please contact my manager David Albright, for emergencies. From jaap_haitsma at zonnet.nl Thu Oct 9 22:48:20 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Fri, 10 Oct 2003 00:48:20 +0200 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <20031009154130.A29659@devserv.devel.redhat.com> References: <3F8004E1.7020808@zonnet.nl> <1065570448.32391.20.camel@poincare.devel.redhat.com> <3F859299.60709@zonnet.nl> <20031009154130.A29659@devserv.devel.redhat.com> Message-ID: <3F85E5B4.8060504@zonnet.nl> Thanks Bill, That did the trick Jaap > > Yup, just disable the keytable script. It probably needs to be > removed anyway (it's superfluous). > > Bill > From behdad at cs.toronto.edu Fri Oct 10 06:22:25 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Fri, 10 Oct 2003 02:22:25 -0400 Subject: bugzilla & triage : Re: up2date failing dependencies window too big!!! In-Reply-To: <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> <3F858E0F.9000707@zonnet.nl> <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> Message-ID: On Thu, 9 Oct 2003, Jeremy Portzer wrote: > On Thu, 2003-10-09 at 16:04, Behdad Esfahbod wrote: > > > > > Unfortunately there are too many bugs in bugzilla that never get > > fixed. Any way to open things a bit more so that we dumb users > > can fix trivial things? Submitting patches is one step toward > > that. Maybe bugzilla should send list of inactive open bugs to > > the list every night :D > > Well, there is talk of setting up more external CVS repositories so > outside developers can get better access. But still, "dumb users" who > aren't developers should use Bugzilla to report the problems. It's the > only way things can be tracked and remembered. What is the procedure for becoming a developer then? > Regarding large numbers of open bugs, I liked Jef Spaleta's proposal of > a triage system. Unfortunately, no one commented on his message: > http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00180.html Important/heavy posts usually get no response. > --Jeremy behdad, who is going to study after finishing this mail. From jfm512 at free.fr Fri Oct 10 06:38:02 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 10 Oct 2003 08:38:02 +0200 Subject: Art of demagogics Re: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <1065736754.11132.194.camel@bobcat.mine.nu> References: <20031009093356.GA9789@pluto.pslib.cz> <1065736754.11132.194.camel@bobcat.mine.nu> Message-ID: <1065767881.1477.30.camel@agnes.fremen.dune> As I said it is easy to make an application load fast: build with __every__ optional feature disabled: this means less initialization and less libraries to load. That will make you shine in benchmarks. You will shine less in real use when user has to recompile due to missing feature. Another point is that in my experience people who write articles in Linux magazines are completely incompetent at benchamrking. For instance comparisons between distros are only valid if you install both distros from scratch in the SAME partitions: disks are much slower when reading from internal partitions than from external ones. On Thu, 2003-10-09 at 23:59, Ville Skytt? wrote: > On Thu, 2003-10-09 at 12:33, Milan Kerslager wrote: > > > I just read http://www.gentoo.org/main/en/performance.xml > > Another one here: > http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227 > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jean Francois Martinez From paul at gear.dyndns.org Fri Oct 10 07:00:56 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Fri, 10 Oct 2003 17:00:56 +1000 Subject: up2date failing dependencies window too big!!! In-Reply-To: References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> <3F858E0F.9000707@zonnet.nl> Message-ID: <3F865928.9050207@gear.dyndns.org> Behdad Esfahbod wrote: > ... >>Too bad this has never been solved up till now. Priority has been >>assigned as low, but it's fairly easy to fix I would say > > > Unfortunately there are too many bugs in bugzilla that never get > fixed. Any way to open things a bit more so that we dumb users > can fix trivial things? Submitting patches is one step toward > that. Maybe bugzilla should send list of inactive open bugs to > the list every night :D Only if you want to use up everyone's download quotas in one night. :-) -- Paul http://paulgear.webhop.net A: Because we read from top to bottom, left to right. Q: Why should i start my 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 paul at gear.dyndns.org Fri Oct 10 07:02:49 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Fri, 10 Oct 2003 17:02:49 +1000 Subject: bugzilla & triage : Re: up2date failing dependencies window too big!!! In-Reply-To: References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> <3F858E0F.9000707@zonnet.nl> <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> Message-ID: <3F865999.9080901@gear.dyndns.org> Behdad Esfahbod wrote: > ... >>Well, there is talk of setting up more external CVS repositories so >>outside developers can get better access. But still, "dumb users" who >>aren't developers should use Bugzilla to report the problems. It's the >>only way things can be tracked and remembered. > > What is the procedure for becoming a developer then? Last post i saw from .*@redhat.com (might have been Mike Harris), they suggested that there wasn't one yet. When there is, please let me know: i have some pet applications for which i want to volunteer to maintain packages. :-) -- Paul http://paulgear.webhop.net A: Because we read from top to bottom, left to right. Q: Why should i start my 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 alexl at redhat.com Fri Oct 10 07:14:43 2003 From: alexl at redhat.com (Alexander Larsson) Date: 10 Oct 2003 09:14:43 +0200 Subject: bugzilla & triage : Re: up2date failing dependencies window too big!!! In-Reply-To: References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> <3F858E0F.9000707@zonnet.nl> <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> Message-ID: <1065770083.22938.384.camel@localhost.localdomain> On Fri, 2003-10-10 at 08:22, Behdad Esfahbod wrote: > On Thu, 9 Oct 2003, Jeremy Portzer wrote: > > > On Thu, 2003-10-09 at 16:04, Behdad Esfahbod wrote: > > > > > > > > Unfortunately there are too many bugs in bugzilla that never get > > > fixed. Any way to open things a bit more so that we dumb users > > > can fix trivial things? Submitting patches is one step toward > > > that. Maybe bugzilla should send list of inactive open bugs to > > > the list every night :D > > > > Well, there is talk of setting up more external CVS repositories so > > outside developers can get better access. But still, "dumb users" who > > aren't developers should use Bugzilla to report the problems. It's the > > only way things can be tracked and remembered. > > What is the procedure for becoming a developer then? Since the whole external setup isn't done yet its not possible for external contributors to be owners of a package at the moment. However, you don't have to do anything at all to be a developer. If you find a bug and want to fix it, just download the code, build it, hack on it, when you're done generate a patch and stick that in bugzilla. If the bug owner doesn't respond after a while sending an email to ping him about it could be nice, some people do get an awful lot of bugzilla email and can easily miss something. (Don't flood developers with emails though.) This isn't much different from any other free software project. I do the same thing as the Nautilus maintainer. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a world-famous zombie sorceror searching for his wife's true killer. She's a chain-smoking foul-mouthed opera singer who believes she is the reincarnation of an ancient Egyptian queen. They fight crime! From paul at gear.dyndns.org Fri Oct 10 07:21:46 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Fri, 10 Oct 2003 17:21:46 +1000 Subject: bugzilla & triage : Re: up2date failing dependencies window too big!!! In-Reply-To: <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> <3F858E0F.9000707@zonnet.nl> <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> Message-ID: <3F865E0A.3000804@gear.dyndns.org> Jeremy Portzer wrote: > ... > Well, there is talk of setting up more external CVS repositories so > outside developers can get better access. But still, "dumb users" who > aren't developers should use Bugzilla to report the problems. It's the > only way things can be tracked and remembered. > > Regarding large numbers of open bugs, I liked Jef Spaleta's proposal of > a triage system. Unfortunately, no one commented on his message: > http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00180.html I overlooked the post at the time because of the reading required. (Sorry, Jef! :-) I've rectified that now. The overall concept seems to be quite a good one and one that should be applied to Fedora. The important thing to learn from the gnome folks, i think, is to be organised about getting responsibility taken for bugs that have been entered, or to put it another way, to take bugs about our distribution personally. :-) One possibility that they don't seem to have mentioned is to have the bug squad members be the default bug owners for different components. That way the bugs could be checked and passed on before they reach the stage of bogging the developers down. I for one would be ready to be the default recipient for selected components that are close to my heart, like jpilot, or shorewall when it gets in ;-). I see that one of the advantages of Fedora will be that some of us can act as go-betweens for the developers and the distribution, working to facilitate the best possible distribution support for the projects. -- Paul http://paulgear.webhop.net A: Because we read from top to bottom, left to right. Q: Why should i start my 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 alexl at redhat.com Fri Oct 10 07:23:57 2003 From: alexl at redhat.com (Alexander Larsson) Date: 10 Oct 2003 09:23:57 +0200 Subject: Ugly main menu icon In-Reply-To: <1065724255.25628.150.camel@poincare.devel.redhat.com> References: <1065724255.25628.150.camel@poincare.devel.redhat.com> Message-ID: <1065770636.22938.387.camel@localhost.localdomain> On Thu, 2003-10-09 at 20:30, Owen Taylor wrote: > OK, figured out what is going on with the blurry main menu icon: > > - Panel thinks that the main menu icon is going to be themed > by the stock icon mechanism > > - We don't want the main menu icon themed, so we don't put > it in Bluecurve. > > - The way that the default icon is set for the stock icon > is that the panel looks up the icon at size 24 in the > current *icon* theme. > > - That used to find only the 48 pixel variant, but Garrett just > added 16,24,36 variants of the icon, so => extreme ugliness. > > I think if we just hack the panel to look up the icon at > a very large size, it should fix this pretty well - > > - filename = gnome_desktop_item_find_icon ( > - panel_icon_theme, stock_icons [i].icon, icon_height, 0); > + filename = gnome_desktop_item_find_icon ( > + panel_icon_theme, stock_icons [i].icon, 1000, 0); > > it may, in a few cases, mean that we scale down rather than > using the right size icons, but for anything actually in Bluecurve > it won't matter, since it will go through the normal GTK+ stock > icon size look up mechanisms. Yeah, this means all the menu items will use the largest icon scaled down instead of the 24x24 ones. I dunno if we have any 24x24 icons that aren't just downscaled 48x48 ones though. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scrappy zombie grifter who knows the secret of the alien invasion. She's a mistrustful winged socialite on the trail of a serial killer. They fight crime! From hobbit at aloss.ukuu.org.uk Fri Oct 10 08:17:46 2003 From: hobbit at aloss.ukuu.org.uk (Telsa Gwynne) Date: Fri, 10 Oct 2003 09:17:46 +0100 Subject: bugzilla & triage : Re: up2date failing dependencies window too big!!! In-Reply-To: <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> References: <3F848852.4000400@zonnet.nl> <1065651769.12940.5.camel@beech.tlns.net> <3F84981E.7050609@zonnet.nl> <3F858E0F.9000707@zonnet.nl> <1065734157.18861.11.camel@jeremy.dtcc.cc.nc.us> Message-ID: <20031010081746.GB30902@aloss.ukuu.org.uk> On Thu, Oct 09, 2003 at 05:15:57PM -0400 or thereabouts, Jeremy Portzer wrote: > On Thu, 2003-10-09 at 16:04, Behdad Esfahbod wrote: > > Unfortunately there are too many bugs in bugzilla that never get > > fixed. Any way to open things a bit more so that we dumb users > > can fix trivial things? > > Regarding large numbers of open bugs, I liked Jef Spaleta's proposal of > a triage system. Unfortunately, no one commented on his message: > http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00180.html I did, but off-list. I do that a lot. I said, roughly, that I didn't know how much time I had, but that I would like to help; that the permissions system on the bugzillas I have used is not very fine-grained; that stock _polite_ and helpful responses help a lot; and that one advantage Fedora has over Gnome is that because it's one OS, we would be able to have stock responses which include things like "run this sequence of commands and paste in the results". We can't always do that in Gnome bugzilla. A somewhat contrived example is that we can't say "you should be able to kill this runaway process with "killall programname" unless we are very very sure they are not running Solaris. Similarly, man takes different arguments on RH and Debian; "partition" seems to mean different things on Linux and BSD; some Gnome programs live in /opt on SuSE and so on. But if it's all fedora-based, then we can say things like "run script; run lspci -vv; hit control-D; add the resulting file to your bug" without worrying about whether script and lspci do something unexpected or live somewhere which is not on the typical path. And I think that should make it a lot easier to get people to do them and add the results. Telsa From buildsys at porkchop.devel.redhat.com Fri Oct 10 09:49:48 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Fri, 10 Oct 2003 05:49:48 -0400 Subject: rawhide report: 20031010 changes Message-ID: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> Updated Packages: anaconda-help-9.0.95-1 ---------------------- autorun-3.11-1 -------------- * Thu Oct 09 2003 Harald Hoyer 3.11-1 - include all languages in po * Thu Feb 27 2003 Owen Taylor 3.9-1 - In checkMedia, check for mounted, before doing ioctls(), since we won't be able to open mounted devices with O_EXCL. (#85233) * Wed Feb 26 2003 Harald Hoyer 3.8-1 - better test for EBUSY, than reopen without O_EXCL * Tue Feb 25 2003 Harald Hoyer 3.6-1 - open cdrom with O_EXCL * Thu Jan 30 2003 Harald Hoyer 3.5-1 - fixed manpage * Thu Nov 21 2002 Harald Hoyer - fixed help string for i18n #73646 * Thu Aug 29 2002 Trond Eivind Glomsr??d - Update translations - s/Copyright/License/ - use %{_tmppath} * Wed Aug 07 2002 Harald Hoyer - changed to docbook format for the manpage * Tue Aug 06 2002 Harald Hoyer - updated i18n * Thu Jun 27 2002 Harald Hoyer - removed desktop file from menu structure * Mon Jun 10 2002 Harald Hoyer - better gettext messages * Tue May 21 2002 Harald Hoyer 3.0-1 - added i18n * Wed Apr 10 2002 Harald Hoyer 2.73-1 - fixed #62965 * Mon Mar 04 2002 Harald Hoyer 2.72-1 - fixed #60629 * Tue Feb 26 2002 Elliot Lee 2.71-2 - Add BuildRequires: linuxdoc-tools * Fri Jan 25 2002 Harald Hoyer - using namespace std for g++-3 * Wed Jan 09 2002 Tim Powers - automated rebuild * Wed Sep 12 2001 Tim Powers - rebuild with new gcc and binutils * Thu Jul 26 2001 Harald Hoyer 2.66-1 - autorun now creates a lockfile * Wed Jul 25 2001 Harald Hoyer 2.65-5 - fixed autorun-condstart.sh * Wed Jul 25 2001 Harald Hoyer 2.65-4 - added autorun-condstart.sh, which fixes KDE bad Exec behaviour in .desktop * Sun Jun 24 2001 Elliot Lee - Bump release + rebuild. * Fri Apr 27 2001 Bill Nottingham - rebuild for C++ exception handling on ia64 * Fri Mar 30 2001 Harald Hoyer 2.65 - fixed .desktop (escaped the double-quotes) * Fri Mar 30 2001 Harald Hoyer 2.65 - fixed .desktop (escaped the double-quotes) * Wed Mar 28 2001 Preston Brown 2.63-5 - better check for console ownership (works in runlevel 3 also) * Wed Mar 21 2001 Preston Brown 2.63-4 - one more message marked only for verbose output * Wed Mar 21 2001 Harald Hoyer 2.63-3 - fixed Autorun.desktop * Wed Mar 14 2001 Harald Hoyer - removed requirements for kdemultimedia and kdebase * Tue Mar 06 2001 Harald Hoyer - added additional check to ensure we have a CDROM - additional check if CDROM is in defined status * Thu Feb 15 2001 Preston Brown - accept "auto" type of filesystem as valid * Wed Feb 07 2001 Bernhard Rosenkraenzer - KDE 2.x keeps its autostart files in ~/.kde/Autostart, not ~/Desktop/Autostart * Tue Feb 06 2001 Harald Hoyer - fixed Autorun.kdelnk to lock the door - renamed Autorun.kdelnk to .desktop * Wed Jul 12 2000 Prospector - automatic rebuild * Tue Jul 04 2000 Jakub Jelinek - Rebuild with new C++ * Thu Jun 01 2000 Bernhard Rosenkraenzer - rebuild with current gcc - move man pages where they belong - use makeinstall macro * Wed May 03 2000 Harald Hoyer - fixed Autostart .kdelnk * Mon Feb 14 2000 Harald Hoyer - updated man page * Thu Feb 10 2000 Harald Hoyer - released 2.6 - fixed insert-notify bug * Thu Feb 10 2000 Bernhard Rosenkraenzer - fix up Autorun.kdelnk * Wed Feb 02 2000 Cristian Gafton - fix descriptions and summary * Tue Nov 16 1999 Bernhard Rosenkraenzer - version 2.5 - some .spec cleanups * Fri Sep 24 1999 Cristian Gafton - correct patch for the "owner" option * Wed Sep 22 1999 Preston Brown - require kdemultimedia (kscd) and kdebase (kfmexec) * Tue Sep 21 1999 Preston Brown - fixed path to autorun script - don't install .kdelnks; we now check for autorun in startkde and act accordingly * Mon Sep 13 1999 Preston Brown - patched to allow "owner" mount option * Tue Sep 07 1999 Cristian Gafton - enabled back KDE-only mode * Mon Sep 06 1999 Cristian Gafton - version 2.3 * Mon Aug 23 1999 Cristian Gafton - imported for Red Hat Linux 6.1 - patch it up to make it more desktop-independant (and require cdp because of that) fedora-logos-1.1.19-1 --------------------- * Thu Oct 09 2003 Bill Nottingham 1.1.19-1 - add a symlink for up2date firstboot-1.2.3-1 ----------------- * Wed Oct 08 2003 Brent Fox 1.2.3-1 - override rhgb's background gkrellm-2.1.20-3 ---------------- * Thu Oct 09 2003 Karsten Hopp 2.1.20-3 - make it compatible with 3d party packages * Thu Oct 09 2003 Karsten Hopp 2.1.20-2 - added patches from Ville Skytt? : - Add icon for desktop entry - Install daemon in %{_sbindir} - Include themes and plugins dirs in main package - Make -daemon obsolete -server - devel subpackage (disabled because of string freeze) gnome-icon-theme-1.0.9-2 ------------------------ * Thu Oct 09 2003 Alexander Larsson 1.0.9-2 - Fix symlinks for redhat menu icons initscripts-7.36-2 ------------------ kudzu-1.1.32-1 -------------- * Wed Oct 08 2003 Bill Nottingham 1.1.32-1 - ignoremulti option and corresponding iPod support (#98881, ) - add a NEC USB floppy (#97681, ) - add another flash entry (#101990, - don't probe PS/2 mice if rhgb appears to be running libtiff-3.5.7-14 ---------------- * Thu Oct 09 2003 Florian La Roche - link shared lib against -lm (Jakub Jelinek) * Thu Sep 25 2003 Jeremy Katz 3.5.7-13 - rebuild to fix gzipped file md5sum (#91281) mozilla-1.4.1-7 --------------- * Thu Oct 09 2003 Christopher Blizzard 37:1.4.1-7 - move spellchecker from mail package into main package so composer picks it up neon-0.24.3-1 ------------- * Thu Oct 09 2003 Joe Orton 0.24.3-1 - update to 0.24.3 postgresql-odbc-7.3-4 --------------------- rawhide-release-20031010-1 -------------------------- redhat-artwork-0.84-1 --------------------- * Thu Oct 09 2003 Jonathan Blandford 0.84-1 - new greeter theme * Thu Oct 09 2003 Alexander Larsson 0.83-1 - added missing translations redhat-config-printer-0.6.78-1 ------------------------------ * Thu Oct 09 2003 Tim Waugh 0.6.78-1 - 0.6.78: - Run updateconf.py on exit from printconf_tui (bug #106478). - Build Croatian translation (bug #106610). rhpl-0.117-1 ------------ * Wed Oct 08 2003 Michael Fulbright 0.117-1 - xhwstate.py - dont write out video ram option to XF86Config rhythmbox-0.5.3-4 ----------------- * Wed Oct 08 2003 Matthias Saou 0.5.3-3 - Fix category from Development/Libraries to Applications/Multimedia. - Use bz2 instead of gz as ftp.gnome.org has both, 300k saved in the src.rpm. - Fix SCHEMES vs. SCHEMAS in the post scriplet. - Added gstreamer-plugins-devel, libvorbis-devel, scrollkeeper and gettext deps. - Removed unnecessary date expansion define. - Updated description, including mp3 reference removal. - Added libid3tag and flac optional support for convenient rebuild. - Removed obsolete omf.make and xmldocs.make (included ones are the same now). subversion-0.31.0-1 ------------------- * Thu Oct 09 2003 Joe Orton 0.31.0-1 - update to 0.31.0 up2date-4.1.5-1 --------------- * Thu Oct 09 2003 Adrian Likins - new default repo for fedora * Wed Oct 08 2003 Adrian Likins - add $ARCH subsituting in yum repo configs - make dowbloading from a yum repo slightly less cpu intensive * Tue Oct 07 2003 Adrian Likins - changed the way log and config initlization worked in a lot of places - oh, up2date doesnt need RHN now. - check for the rawhide/fedora key for fedora and prompt user - fix package download resumes - install a default sources file pointing at fedora From ms-nospam-0306 at arcor.de Fri Oct 10 12:45:14 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 10 Oct 2003 14:45:14 +0200 Subject: rawhide report: 20031010 changes In-Reply-To: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> References: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> Message-ID: <20031010144514.1d0bfa82.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 10 Oct 2003 05:49:48 -0400, Build System wrote: > * Mon Aug 23 1999 Cristian Gafton > > - imported for Red Hat Linux 6.1 > - patch it up to make it more desktop-independant (and require cdp because > of that) Unless inclusion of such old changelog entries is intended, they could be stripped off quite easily with something like: sed -e '/\* [a-zA-Z]\{3\} [a-zA-Z]\{3\} [0-9]\{2\} \(200[0-2]\|199?\).*/,99999 d' Of course, they are more ways to do it (including more complex ways). - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/hqna0iMVcrivHFQRAucEAJ0c3KpWYU7/NTTFFpIYY7VSIrkQCgCeMGGn fGMRU1RCS/jMCOOg2f3xsCk= =g2iu -----END PGP SIGNATURE----- From ted at cypress.com Fri Oct 10 13:35:07 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 08:35:07 -0500 Subject: GCC-3.3 and OO.org Message-ID: <3F86B58B.7080807@cypress.com> Two quickies (I hope). 1) What problems would ugrading from gcc-3.2.2-5 to gcc-3.3.1-6 pose? 2) Why does OpenOffice.org-1.1 have a buld requirement of gcc-3.3.1? http://tools.openoffice.org/dev_docs/build_linux.html states: gcc: OpenOffice.org has been successfully build under Linux using the gcc versions 3.0.x, 3.1.1, and 3.2.x. Older versions were built with gcc 2.95.2. Version 2.96 does not work! gcc 3.3.0 works on the 1.1, 3.3.1 does not work yet. So what "fixes" to get 3.3.1 working broke 3.2.2? -Thomas From notting at redhat.com Fri Oct 10 14:19:41 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Oct 2003 10:19:41 -0400 Subject: rawhide report: 20031010 changes In-Reply-To: <20031010144514.1d0bfa82.ms-nospam-0306@arcor.de>; from ms-nospam-0306@arcor.de on Fri, Oct 10, 2003 at 02:45:14PM +0200 References: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> <20031010144514.1d0bfa82.ms-nospam-0306@arcor.de> Message-ID: <20031010101941.E4171@devserv.devel.redhat.com> Michael Schwendt (ms-nospam-0306 at arcor.de) said: > > * Mon Aug 23 1999 Cristian Gafton > > > > - imported for Red Hat Linux 6.1 > > - patch it up to make it more desktop-independant (and require cdp because > > of that) > > Unless inclusion of such old changelog entries is intended, they > could be stripped off quite easily with something like: > > sed -e '/\* [a-zA-Z]\{3\} [a-zA-Z]\{3\} [0-9]\{2\} \(200[0-2]\|199?\).*/,99999 d' > > Of course, they are more ways to do it (including more complex ways). How the algorithm currently works is that it looks for the first line in the old changelog, and takes everything before that in the new changelog for the report. So, if the first line for the old changelog isn't in the new changelog at all, you get the whole thing. Bill From mark at mark.mielke.cc Fri Oct 10 14:45:43 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Fri, 10 Oct 2003 10:45:43 -0400 Subject: Art of demagogics Re: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <1065767881.1477.30.camel@agnes.fremen.dune> References: <20031009093356.GA9789@pluto.pslib.cz> <1065736754.11132.194.camel@bobcat.mine.nu> <1065767881.1477.30.camel@agnes.fremen.dune> Message-ID: <20031010144543.GA12134@mark.mielke.cc> On Fri, Oct 10, 2003 at 08:38:02AM +0200, Jean Francois Martinez wrote: > Another point is that in my experience people who write articles > in Linux magazines are completely incompetent at benchamrking. > For instance comparisons between distros are only valid if you install > both distros from scratch in the SAME partitions: disks are much slower > when reading from internal partitions than from external ones. What is an internal partition, and what is an external partition? Do you mean primary vs extended in DOS-speak? Is there really a difference? Should there be one? mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From ms-nospam-0306 at arcor.de Fri Oct 10 14:48:38 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 10 Oct 2003 16:48:38 +0200 Subject: rawhide report: 20031010 changes In-Reply-To: <20031010101941.E4171@devserv.devel.redhat.com> References: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> <20031010144514.1d0bfa82.ms-nospam-0306@arcor.de> <20031010101941.E4171@devserv.devel.redhat.com> Message-ID: <20031010164838.705f1b10.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 10 Oct 2003 10:19:41 -0400, Bill Nottingham wrote: > > > * Mon Aug 23 1999 Cristian Gafton > > > > > > - imported for Red Hat Linux 6.1 > > > - patch it up to make it more desktop-independant (and require cdp because > > > of that) > > > > Unless inclusion of such old changelog entries is intended, they > > could be stripped off quite easily with something like: > > > > sed -e '/\* [a-zA-Z]\{3\} [a-zA-Z]\{3\} [0-9]\{2\} \(200[0-2]\|199?\).*/,99999 d' > > > > Of course, they are more ways to do it (including more complex ways). > > How the algorithm currently works is that it looks for the first line > in the old changelog, and takes everything before that in the new > changelog for the report. So, if the first line for the old changelog > isn't in the new changelog at all, you get the whole thing. ...in which case you could still strip off the very old entries (in my example, entries from 2002 and earlier). :o) - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/hsbG0iMVcrivHFQRAghMAJ9QYyUXMt2yqg+uvGUDIdw3E6uzvACfTNru w5sl1AjTy1p60pFhE+EBInI= =3yML -----END PGP SIGNATURE----- From ted at cypress.com Fri Oct 10 14:48:54 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 09:48:54 -0500 Subject: artwork project In-Reply-To: <3F85CBC1.9020909@redhat.com> References: <20031002121240.0c9c693a.gavin.henry@magicfx.co.uk> <3F7C4DEE.2010705@redhat.com> <200310021729.19728.gavin.henry@magicfx.co.uk> <3F7C7689.3020009@redhat.com> <3F85C096.9070204@cypress.com> <3F85CBC1.9020909@redhat.com> Message-ID: <3F86C6D6.8030700@cypress.com> Garrett LeSage wrote: > Thomas Dodd wrote: >> You might find a copy of Corel's PhotoPAINT! somewhere. >> Not too bad. > > I have a copy of it. I don't use it. I suggest that no one else does. > It's a dead ex-product. Only the linux version is dead. I've used newer versions in wine. TYhe latest don't work yet though. When linux starts making inroads, I expect it'll come back. Look at the high end animation stuff starting to show up. > It came with my copy of CorelDraw! for Linux -- I happened to be on the > beta team a number of years back, so I have a few beta copies as well as > the final released product. I still have the 1st beta. Didn't find enough new bugs for the later ones:( > CorelDraw! and PhotoPaint! are both programs which are: > * proprietary So is every other commercial app. How many non-proprietary apps are out there for Windows or MacOS? > * made to run under a hacked version of Wine (they don't use > winelib, as promised way-back-when) I beleive it was a timing thing. First get it working with wine, then switch to winelib later. Problem was lack of sales. So the whole project was killed. >> Whay UI are you comparing it too? > Any other UI. (: >> Have you used Photoshop on the Mac? > Yes. I am also familiar with most other DTP apps on the Mac as well, > including Illustrator, FreeHand, and Quark. So the multiple windows that the GIMP uses are not new to you. It's better than one big window like Windows typically uses. >> Many *nix /X applications? > Yes, I've been using Linux since 1995 and also the GIMP since before the Not linux. Solaris, HP-UX, AIX, and Irix. The high end commercial stuff. > 1.0 series. I first toyed around with the GIMP back in the Motif days, > but Lesstif wasn't up to snuff, so most people (myself included) had to > use the binary build as building from source wasn't an option. (Motif > was EXPENSIVE, especially for a poor college student.) When the first I bought the Red Hat branded CDE, circa 98. Also tried a later, version after RH dropped it >> You should try Cadence tools, or SmarTest for HP-UX for some real >> interesting UI's. I ment interestin, as in poor. I have to work with them. They use multiple windows with no or partial app windows. SmarTest is the worst. It's motif, but doesn't follow any standard UI. Text defaults to overwrite mode, no cut or paste, and the app window doesn't access everything and still takes 2 pages. > Check out GeoPak (screenshots and documentation @ What is it about high-end apps that makes them have hard to use, non-intuitive interfaces? >> Do you have a solution for the nested menus? One long menu doesn't work. > > Place the menu bar at the top instead of contextual (which adds one > extra level of menus), only go down one sublevel (two at the very most, > but rarely, if ever), weed out useless menu items, arrange everything in > a more sensible fashion. Do you want each image window to have a seperat menu, or a single app window, like MacOS has? What are the "useless menu items"? They were added for some reason. Maybe you don't use them, but somebody does. How about a mockup of what you want? Have you talked with the developers about it? Did they give reasons form not changing? > The GIMP's interface is a result of copying Photoshop's general look. > On the Mac, Photoshop works great. On Windows, Photoshop is in MDI, Exactly. MDI is not the way to go. > which is hideous. On Linux, since no tool bar exists on the top of the > screen and MDI is a bad thing (and isn't really supported well), the > GIMP has windows all over the place. The best way to cope with this is Push for a standardized app/tool bar then. Only if it's standardized will other multi window apps use it. Even then it will take time for it to become accepted. How many people use the top bar in GNOME? I don't yet. Reminds me too much of KDE. :) FIrst thing I did when it first showed up is turn it off and relocate the item they moved to it. Perhaps it could be used as you tool bar? An app starts it if it's missing, and when no more apps are using it it goes away:) > to either have application windows (which some apps are starting to do) > or to manage different applications on separate virtual workspaces > (which is what most people who use the GIMP actually do). Thay's what I do with SmarTest and the Cadence tools :) Works better with GNOME than CDE though. Wish I could get GNOME to work on HP-UX. :( -Thomas From ted at cypress.com Fri Oct 10 15:10:08 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 10:10:08 -0500 Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <1065696476.3713.3.camel@ulysse.olympe.o2t> Message-ID: <3F86CBD0.5090209@cypress.com> Mike A. Harris wrote: > So am I, but any time something changes, I can't contact n random > developers and tell them what chagnes to incorporate into their > packages very easily, and if I make a document and put it > somewhere, I have no guarantee anyone will read it. I've direct You did what you could. It's up to the otheres to do their part. Post the doc, add it to the XF86 rpms with a link to the current version. After that it's up to others to follow. Just like when any other developer changes a system used by others. I cna tell you it's changed, but cannot force you to change. (I still miss the XF86 setup tools. I usually build them myself though. If someone wrote secondary config tool that required the XF86 versions, it's not your job to fix it. They were told to change, it's up to them to do so.) > There is also a problem where all fonts could theoretically be > used by both xfs and also fontconfig/Xft, however we only want > the given fonts to be in one or the other of those 2 systems for > whatever preferential reasons we have. One example is the Luxi > TTF font. Last I checked, we only enable this in core fonts and > not in fontconfig, because the Luxi Type1 font is nicer looking > in fontconfig than Luxi TTF. Sounds like the fonts need fixed. The Type1 and TTF version should look the same (within the limits of the format). In the above, the Luxi TTF should be fixed, possibly removed untill it is fixed. -Thomas From ted at cypress.com Fri Oct 10 15:21:16 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 10:21:16 -0500 Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> Message-ID: <3F86CE6C.9030601@cypress.com> Mike A. Harris wrote: > xfs is "deprecated" in the sense that all new applications will > be using the new Xft/fontconfig infrastructure, and I had this I'm curious about that. With out xfs, how do I share fonts between machines? I currently have fon't from 3 systems (Linux, Solaris, and HP-UX) shared using xfs so I don't have to keep multiple copies. There are also potential legal issues in coping the files form one OS to another. > As for a special macro to handle font installation, that is IMHO > a double edged sword. If it was part of a particular package, > then it wouldn't be centralized and thus would have to be > duplicated in all packages, which isn't much different from what > we have now. If it was centralized, it would have to be part of > rpm's default macro set, thus imposing a dependancy on a > particular version of rpm in order for those font packages to be > useable. In a case like that for example, my XFree86 4.3.0 > packages couldn't easily be recompiled for Red Hat Linux 8.0 and > expected to work. Another option is a font installation script, > but that suffers from the last problem I described also. External package is needed. Be it a script or a C program. When you make the decision to create it, make version fro the systems you plan to continue supporting. So there's the RHL8, RHL9, and FC-x versions, that understand the differences in each setup. Using nonstandard X,GNOME, and such on those systems are unsupportable any way, so If I update my RHL8 system to act like FC1, it's up to me to fix the font installation program. Since the support of older systems is based on your kindness, you set the rules of such support. > I admit that fonts and font related problems in general are a > huge mess, however it isn't limited to our distribution, but is a > result more of XFree86 having archaic font technology for so many > years. It'll take a few more years to shake the uglies out of > the font infrastructure. How exactly did X get such a screwed up system? Why was it never corrected? How do other systems, especially OS-X handle it? -Thomas From ted at cypress.com Fri Oct 10 15:39:11 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 10:39:11 -0500 Subject: xfs initscript enhancements, take 5 In-Reply-To: References: <20031009080713.57674.qmail@web80007.mail.yahoo.com> Message-ID: <3F86D29F.4040105@cypress.com> Mike A. Harris wrote: > On Thu, 9 Oct 2003, Derek P. Moore wrote: >>This script is fine and dandy assuming TTF and OTF fonts are in seperate >>directories. > > That is ugly of course, and so I hope to see future improvements > that permit all fonts to live in one huge directory if desired. > That's a ways off though IMHO, at least for core fonts. I don't see it as ugly. I see it as a good thing. Dumping all fonts into a single directory (ala M$) is a maintance nightmare. Enforcing the splits, help in the long run. Sure the learning curve is a bit steeper, but that's better than the alternative. Imagine dumping english and metric screws in one box and trying to find the corect screw to fit a given nut. If the english and metric are seperated, it helps a lot. Your eyes/hands get you close, but distinguishing english and metric is nearly impossible. Same with finding a given font in a directory full of them. Seperating them in to smaller subsets is needed as long as there is a difference in how/where TTF, OTF, Type1, and others are used. -Thomas From Nicolas.Mailhot at laPoste.net Fri Oct 10 15:56:14 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 10 Oct 2003 17:56:14 +0200 Subject: xfs initscript enhancements, take 5 In-Reply-To: <3F86D29F.4040105@cypress.com> References: <20031009080713.57674.qmail@web80007.mail.yahoo.com> <3F86D29F.4040105@cypress.com> Message-ID: <1065801373.9494.2.camel@ulysse.olympe.o2t> Le ven 10/10/2003 ? 17:39, Thomas Dodd a ?crit : > Mike A. Harris wrote: > > On Thu, 9 Oct 2003, Derek P. Moore wrote: > >>This script is fine and dandy assuming TTF and OTF fonts are in seperate > >>directories. > > > > That is ugly of course, and so I hope to see future improvements > > that permit all fonts to live in one huge directory if desired. > > That's a ways off though IMHO, at least for core fonts. > > I don't see it as ugly. I see it as a good thing. Dumping all fonts into > a single directory (ala M$) is a maintance nightmare. I agree that multiple subdirs are better *however* multiple versions of the same font in different formats are not and should be cleaned up. I don't want to have slight behaviour differences because one app will use Type1 and the other TTF (or between reading and printing). Multiformat is calling for glyph drift and (more generally) trouble. 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 Fri Oct 10 16:46:08 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 10 Oct 2003 18:46:08 +0200 Subject: XFree86 spec file for develoment snapshots ? Message-ID: <1065804368.11058.16.camel@rousalka.dyndns.org> Hi, Over time I've hit a few bugs in Rawhide XFree86 that must be fixed upstream (at least that's what the RH bugzilla entries said). And now that XFree86 maintainers have been gently convinced to provide regular source code snapshots they'd like me to test if they fix my problems. I'm a bit reluctant however to build an unpackaged XFree86 (blame previous encounters) so I'd really like to know if someone has a srpm or a spec file that works with the new XFree86 code drops (you know, like the experimental rpms mozilla.org used to provide). I've taken a peek at the rawhide spec file but I freely admit after seing patches numbered in the thousands my head began to whirl ;). Anyhow I feel this kind of packages has a place in future Fedora layout (in a bloody-unstable repository perhaps) - it could host things like 2.5 kernel rpms, latest gnomehide, rhug, latest experimental moz and so on. There's a lot of packaged stuff out there not dogfoodable enough for rawhide. 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 edwardam at interlix.com Fri Oct 10 17:09:56 2003 From: edwardam at interlix.com (Edward Muller) Date: Fri, 10 Oct 2003 12:09:56 -0500 Subject: Additional Mozilla Request [was Re: rawhide report: 20031010 changes] In-Reply-To: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> References: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> Message-ID: <1065805796.9792.126.camel@palin> Would it be possible to add mozex to the Mozilla RPM or a separate RPM? Using mozex it is possible to define external programs that can handle various tasks like: mailto:, news:, telnet:, and ftp: urls; view source; edit content areas & download files. If people think it should be in a separate RPM I will take a go at packaging it Mozex can be found at: http://mozex.mozdev.org/ On Fri, 2003-10-10 at 04:49, Build System wrote: > mozilla-1.4.1-7 > --------------- > * Thu Oct 09 2003 Christopher Blizzard 37:1.4.1-7 > > - move spellchecker from mail package into main package so composer > picks it up -- Edward Muller - http://www.interlix.com - "Open Source Specialists" Dedicated Zope Hosting - Web Hosting - Open Source Consulting Network & PC Service & Support - Custom Programming Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572 Jabber: edwardam at jabber.interlix.com - AIM: edwardam453 - ICQ: 287033 From elanthis at awesomeplay.com Fri Oct 10 17:12:03 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 10 Oct 2003 13:12:03 -0400 Subject: Additional Mozilla Request [was Re: rawhide report: 20031010 changes] In-Reply-To: <1065805796.9792.126.camel@palin> References: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> <1065805796.9792.126.camel@palin> Message-ID: <1065805923.16651.43.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2003-10-10 at 13:09, Edward Muller wrote: > Would it be possible to add mozex to the Mozilla RPM or a separate RPM? > > Using mozex it is possible to define external programs that can handle > various tasks like: mailto:, news:, telnet:, and ftp: urls; view source; > edit content areas & download files. > > If people think it should be in a separate RPM I will take a go at > packaging it This would actually be a good idea, given the "integration" goal of the Desktop sub-project. I.e., if Evolution is the system-wide default mail handler, Mozilla should be using it by default as well. (Not sure if it does already, I haven't used stock Red Hat Mozilla RPMs in a long time.) > > Mozex can be found at: > http://mozex.mozdev.org/ > > On Fri, 2003-10-10 at 04:49, Build System wrote: > > mozilla-1.4.1-7 > > --------------- > > * Thu Oct 09 2003 Christopher Blizzard 37:1.4.1-7 > > > > - move spellchecker from mail package into main package so composer > > picks it up -- Sean Middleditch AwesomePlay Productions, Inc. From mharris at redhat.com Fri Oct 10 17:15:28 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 10 Oct 2003 13:15:28 -0400 (EDT) Subject: XFree86 spec file for develoment snapshots ? In-Reply-To: <1065804368.11058.16.camel@rousalka.dyndns.org> References: <1065804368.11058.16.camel@rousalka.dyndns.org> Message-ID: On Fri, 10 Oct 2003, Nicolas Mailhot wrote: >Over time I've hit a few bugs in Rawhide XFree86 that must be fixed >upstream (at least that's what the RH bugzilla entries said). And now >that XFree86 maintainers have been gently convinced to provide regular >source code snapshots they'd like me to test if they fix my problems. > >I'm a bit reluctant however to build an unpackaged XFree86 (blame >previous encounters) so I'd really like to know if someone has a srpm or >a spec file that works with the new XFree86 code drops (you know, like >the experimental rpms mozilla.org used to provide). I currently do not have a 4.3.99.x src.rpm, however I have been fairly slowly working on one for about a week. I don't have a lot of time to devote to it for about 2-3 weeks, so while waiting for a build to compile and whatnot, I've been test building 4.3.99.x on another machine and getting rid of patches one at a time that are no longer needed. The bigger part of the work will be forward porting patches that are still needed, and isolating small pieces of patches that are mostly unneeded, but which a few bits are still needed. >I've taken a peek at the rawhide spec file but I freely admit after >seing patches numbered in the thousands my head began to whirl ;). >Anyhow I feel this kind of packages has a place in future Fedora layout >(in a bloody-unstable repository perhaps) - it could host things like >2.5 kernel rpms, latest gnomehide, rhug, latest experimental moz and so >on. I'm not really sure that experimental XFree86 belongs in fedora.us myself. XFree86 packaging and maintenance consumes a very large amount of time, and I'm not convinced that someone out there would be able to volunteer the necessary time to it that it would require. I'd also be leary of gratuitous feature/fix patches getting applied without appropriate review, etc., however that may just be a bit of paranoia on my part. ;o) Seriously though, for all the effort that it would require, I don't think it is worth anyone wasting their time to attempt to turn the 4.3.0 packages into 4.3.99.x CVS. They'd either be seriously cutting corners and producing shoddy packages, or they'd be doing a _lot_ of work - work that I've either already done privately, or work that I'm planning on doing over the next month or so. Also, I don't really want people switching from 4.3.0 to 4.3.99.x yet, as I want people using and testing the hell out of 4.3.0 as much as possible, so that Fedora Core 1 has as rock solid an XFree86 release as possible. The first week or so's worth of 4.3.99.x packages will likely have a lot of nasty flaws and gotchas, so they wont go into rawhide. Instead, I will distribute them probably from an unannounced dir on p.r.c somewhere and get a handful of 10 or so people willing to guinea pig test the package, so I have time to fix the most nasty/obvious problems that arise before widening distribution of it. Once it shapes up a bit, I'll distribute it in my normal testing/unstable directory there, which by the way now has yum support. ;o) >There's a lot of packaged stuff out there not dogfoodable enough for >rawhide. In this case, rawhide is the head of development for Fedora Core 1, so nothing new will be in rawhide that isn't going into FC1. Once rawhide opens up again after FC1 is released however I might not put XFree86 CVS into rawhide for a while anyway, until I feel very certain that 4.4.0 will be released in time for the next OS release. I want to make absolutely certain that 4.4.0 gets released in a sane schedule before committing to it for FC2. David has posted the 4.4.0 schedule, but the only thing that I consider guaranteed about his schedule is the Feature Freeze and Code Freeze dates. The actual release could be anywhere from a month to 6 months later than his estimate, so I have to be cautious. 4.3.0 came out 4 months or more later than his estimate last time, and actually went officially gold late enough in our cycle that I think I lost hair. I wont take risks on upstream release dates in the future. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From blizzard at redhat.com Fri Oct 10 18:01:05 2003 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 10 Oct 2003 14:01:05 -0400 Subject: Additional Mozilla Request [was Re: rawhide report: 20031010 changes] In-Reply-To: <1065805796.9792.126.camel@palin> References: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> <1065805796.9792.126.camel@palin> Message-ID: <3F86F3E1.9070909@redhat.com> Edward Muller wrote: >Would it be possible to add mozex to the Mozilla RPM or a separate RPM? > >Using mozex it is possible to define external programs that can handle >various tasks like: mailto:, news:, telnet:, and ftp: urls; view source; >edit content areas & download files. > >If people think it should be in a separate RPM I will take a go at >packaging it > >Mozex can be found at: >http://mozex.mozdev.org/ > >On Fri, 2003-10-10 at 04:49, Build System wrote: > > >>mozilla-1.4.1-7 >>--------------- >>* Thu Oct 09 2003 Christopher Blizzard 37:1.4.1-7 >> >>- move spellchecker from mail package into main package so composer >> picks it up >> >> There's already some kind of crazy universal plugin that does something for content. Haven't played with it much. mozex sounds to me like it should be external, fwiw. --Chris -- ------------ Christopher Blizzard http://people.redhat.com/blizzard/ ------------ From kworthington at linuxmail.org Fri Oct 10 18:16:55 2003 From: kworthington at linuxmail.org (Kevin Worthington) Date: Fri, 10 Oct 2003 13:16:55 -0500 Subject: rhgb rhgb-0.10.2-1 Message-ID: <20031010181655.2019.qmail@linuxmail.org> --- 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 ted at cypress.com Fri Oct 10 18:17:46 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 13:17:46 -0500 Subject: XFree86 spec file for develoment snapshots ? In-Reply-To: References: <1065804368.11058.16.camel@rousalka.dyndns.org> Message-ID: <3F86F7CA.5010505@cypress.com> Mike A. Harris wrote: > On Fri, 10 Oct 2003, Nicolas Mailhot wrote: > > >>Over time I've hit a few bugs in Rawhide XFree86 that must be fixed >>upstream (at least that's what the RH bugzilla entries said). And now >>that XFree86 maintainers have been gently convinced to provide regular >>source code snapshots they'd like me to test if they fix my problems. >> >>I'm a bit reluctant however to build an unpackaged XFree86 (blame >>previous encounters) so I'd really like to know if someone has a srpm or >>a spec file that works with the new XFree86 code drops (you know, like >>the experimental rpms mozilla.org used to provide). > > > I currently do not have a 4.3.99.x src.rpm, however I have been > fairly slowly working on one for about a week. I don't have a > lot of time to devote to it for about 2-3 weeks, so while waiting > for a build to compile and whatnot, I've been test building > 4.3.99.x on another machine and getting rid of patches one at a > time that are no longer needed. The bigger part of the work will > be forward porting patches that are still needed, and isolating > small pieces of patches that are mostly unneeded, but which a few > bits are still needed. I think he was asking for more of a easy to remove build of the CVS tree. No RedHat patches. Just what you get if you downloaded and did make world, but that was then used as an RPM payload. That allows easier installation, and removal (when it breaks). Perhaps with a minimal set of patches to fit the Red Hat/Fedora layout. Not sure ny more, but there used to be some differeces in the XF86 and Red Hat directory structure. XF86 didn't use /etc/X11/ for everything Red Hat did. I think font locations too. This is kind of what the current 2.6 kernels from Arjan do. Alan added a rpm target to the kerenl somtime back as well, but I think it was more generic than what Arjan is doing. Several packages include their own spec file already, but XF86 isn't one of them. -Thomas From kworthington at linuxmail.org Fri Oct 10 18:25:38 2003 From: kworthington at linuxmail.org (Kevin Worthington) Date: Fri, 10 Oct 2003 13:25:38 -0500 Subject: rhgb-0.10.2-1 Message-ID: <20031010182538.26975.qmail@linuxmail.org> I've been reading about how nice the new graphical boot up looks, so I just installed the latest (to my knowledge) rhgb (rhgb-0.10.2-1) via yum, and changed my runlevel in /etc/inittab to 5. (I usually just ssh in to the box on runlevel 3) The boot process looks very clean and professional. I really like the way it is shaping up. Many newbies will feel comfortable with the look and feel of the graphical boot, rather that the "cold white on black" console mode. I have a few suggestions and questions, in order of the boot process (excuse me if some or all of these have been addressed before): 1. Is it possible to suppress the initial "console-ish" dmesg, before the graphical interface kicks in? 2. Why is there a pause between the bootup, and the graphical login screen? It seems like X kicks out, and then restarts. It seems a little "un-refined", for lack of better words. 3. Now that there is a nice looking boot up process, what about a nice shutdown process? Are there any plans to make the shutdown/reboot look as nice as the graphical boot up? Would anybody else be interested in something like this? Thanks in advance... -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 brugolsky at telemetry-investments.com Fri Oct 10 18:29:02 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Fri, 10 Oct 2003 14:29:02 -0400 Subject: early userspace and volume management Message-ID: <20031010182902.GF31195@ti19> Back in January I started packaging up Device-Mapper, and LVM2, and made some changes to initscripts, mkinitrd, etc., to get root-on-lvm2. Now that device-mapper is stabilizing, I'd like to take up this task again and contribute the changes to Fedora core. Before doing so, I'd like to solicit some feedback on how to proceed with changes to early userspace. 1. nash is inadequate to the task. Replacing it with a real shell and other tools will take us over the size limit for a floppy. Does it matter any more? A kernel with ACPI won't fit on a floppy either, and we are going to want to include a lot of userland discovery code in initramfs as we move into 2.7. Once we exceed the size of a floppy, is there another "natural" size constraint that would prevent just using the usual tools, such as mdadm, perhaps in a multi-call binary or rebuilt against klibc? 2. People are going to use various combinations of MD, Device-Mapper, LVM2, and EVMS2. Do we want to support the simultaneous, stacked use of all of these? Is that too complicated, and should, e.g., (LVM2+dmsetup) and EVMS2 be mutually exclusive? One of the nicest features of EVMS2 is the support for legacy partitions. This can also be done with dmsetup and some scripting, or by generalizing LVM2. 3. We currently lack any infrastructure for reconfiguration in early userspace. There are numerous maintenance tasks that require that a resource be taken offline, e.g., repartitioning, or shrinking a filesystem. I am currently working on scripts to do a system upgrade (repartition, etc.) on a RAID1 system with minimal downtime by (a) breaking the mirror, (b) upgrading the detached half, (c) reboot using the upgraded system image, and (d) resyncing the mirror. One could as well imagine support for pulling a new system image from a server. Ideally, there would be infrastructure to just drop in early userspace scripts. Initramfs makes this easy, because one can just append a cpio archive with the required files. 4. Volume management is just one of many tasks that need attention in early userspace. Is there a roadmap anywhere? Any thoughts or pointers to works-in-progress would be appreciated. Regards, Bill Rugolsky From Nicolas.Mailhot at laPoste.net Fri Oct 10 18:35:19 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 10 Oct 2003 20:35:19 +0200 Subject: XFree86 spec file for develoment snapshots ? In-Reply-To: <3F86F7CA.5010505@cypress.com> References: <1065804368.11058.16.camel@rousalka.dyndns.org> <3F86F7CA.5010505@cypress.com> Message-ID: <1065810918.11680.15.camel@rousalka.dyndns.org> Le ven 10/10/2003 ? 20:17, Thomas Dodd a ?crit : > Mike A. Harris wrote: > > On Fri, 10 Oct 2003, Nicolas Mailhot wrote: > > > > > >>Over time I've hit a few bugs in Rawhide XFree86 that must be fixed > >>upstream (at least that's what the RH bugzilla entries said). And now > >>that XFree86 maintainers have been gently convinced to provide regular > >>source code snapshots they'd like me to test if they fix my problems. > >> > >>I'm a bit reluctant however to build an unpackaged XFree86 (blame > >>previous encounters) so I'd really like to know if someone has a srpm or > >>a spec file that works with the new XFree86 code drops (you know, like > >>the experimental rpms mozilla.org used to provide). > > > > > > I currently do not have a 4.3.99.x src.rpm, however I have been > > fairly slowly working on one for about a week. I don't have a > > lot of time to devote to it for about 2-3 weeks, so while waiting > > for a build to compile and whatnot, I've been test building > > 4.3.99.x on another machine and getting rid of patches one at a > > time that are no longer needed. The bigger part of the work will > > be forward porting patches that are still needed, and isolating > > small pieces of patches that are mostly unneeded, but which a few > > bits are still needed. > > I think he was asking for more of a easy to remove build of the CVS > tree. No RedHat patches. Just what you get if you downloaded and did > make world, but that was then used as an RPM payload. That allows easier > installation, and removal (when it breaks). Sure - what I need is just a way to test quickly the latest XFree86 devel snapshots, see if I can reproduce my bugs, report back in XFree bugzilla and reinstall the rawhide version. When I wrote about another repository than rawhide I meant exactly that : some central locations where people can dump highly experimental stuff and people like me can test it. Right now you need to read the package changelogs to see who at RH might be working on them, then hunt down the packages in the relevant people.redhat.com directories or even private pages (or be on a top-secret list where the maintainer annouces experimental packages) Which is a lot of fun except you don't always time to do it. It's not as if the packages were not created and people can not find them - why not put them in some sort of central place ? 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 dcbw at redhat.com Fri Oct 10 18:38:39 2003 From: dcbw at redhat.com (Dan Williams) Date: Fri, 10 Oct 2003 14:38:39 -0400 Subject: GCC-3.3 and OO.org In-Reply-To: <3F86B58B.7080807@cypress.com> References: <3F86B58B.7080807@cypress.com> Message-ID: <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> Thomas, I will change this. AFAIK only 3.2.3 has an issue with symbol generation, this was corrected for most cases but not all. I will be setting the build requirement for OOo to gcc 3.2.2-5. Dan On Fri, 2003-10-10 at 09:35, Thomas Dodd wrote: > Two quickies (I hope). > > 1) What problems would ugrading from gcc-3.2.2-5 to gcc-3.3.1-6 pose? > > 2) Why does OpenOffice.org-1.1 have a buld requirement of gcc-3.3.1? > > http://tools.openoffice.org/dev_docs/build_linux.html states: > > gcc: OpenOffice.org has been successfully build under Linux using the > gcc versions 3.0.x, 3.1.1, and 3.2.x. Older versions were built with gcc > 2.95.2. Version 2.96 does not work! gcc 3.3.0 works on the 1.1, 3.3.1 > does not work yet. > > So what "fixes" to get 3.3.1 working broke 3.2.2? > > -Thomas > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From fs111 at web.de Fri Oct 10 18:42:25 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Fri, 10 Oct 2003 20:42:25 +0200 Subject: Additional Mozilla Request [was Re: rawhide report: 20031010 changes] In-Reply-To: <1065805796.9792.126.camel@palin> References: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> <1065805796.9792.126.camel@palin> Message-ID: <1065811344.3564.4.camel@localhost> Am Fre, 2003-10-10 um 19.09 schrieb Edward Muller: > Would it be possible to add mozex to the Mozilla RPM or a separate RPM? > > Using mozex it is possible to define external programs that can handle > various tasks like: mailto:, news:, telnet:, and ftp: urls; view source; > edit content areas & download files. IMHO it is definetly a "must have" if you don't want to use mozilla-mail and you don't wnat to copy&paste the mail adresses every time. Please provide it in the main distribution (as a seperate package) until the mozilla guys can handle the "no-other-email-program-on-linux-problem" by themselves. Andr? BTW.: Are there any plans to move to python-2.3.x in the near future (in rawhide)? -------------- 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 jfm512 at free.fr Fri Oct 10 18:58:15 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 10 Oct 2003 20:58:15 +0200 Subject: Art of demagogics Re: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <20031010144543.GA12134@mark.mielke.cc> References: <20031009093356.GA9789@pluto.pslib.cz> <1065736754.11132.194.camel@bobcat.mine.nu> <1065767881.1477.30.camel@agnes.fremen.dune> <20031010144543.GA12134@mark.mielke.cc> Message-ID: <1065810134.1142.15.camel@agnes.fremen.dune> On Fri, 2003-10-10 at 16:45, Mark Mielke wrote: > On Fri, Oct 10, 2003 at 08:38:02AM +0200, Jean Francois Martinez wrote: > > Another point is that in my experience people who write articles > > in Linux magazines are completely incompetent at benchamrking. > > For instance comparisons between distros are only valid if you install > > both distros from scratch in the SAME partitions: disks are much slower > > when reading from internal partitions than from external ones. > > What is an internal partition, and what is an external partition? > Internal: the ones who are on tracks close to the center of the disk. The lowest the number of track, the closer to the edge. These tracks contain more sectors than the internal ones. Since the disk rotates at constant speed, transfer rates are higher for the larger external tracks than for the smaller ones. Another benefit of the larger external tracks is that the disk head doesn't need to be moved as frequently than on the small internal ones. > Do you mean primary vs extended in DOS-speak? Is there really a difference? > Should there be one? > No. I don't think extended versus primary makes a difference. When the system boots it will check for the beginning of partitions, this is a bit longer and more complex for extended partitions but it only affects boot time. After that there is no difference: system calculates the sector accessed respective to the beginning of partition > mark -- Jean Francois Martinez From hadess at hadess.net Fri Oct 10 18:58:23 2003 From: hadess at hadess.net (Bastien Nocera) Date: Fri, 10 Oct 2003 19:58:23 +0100 Subject: rhgb-0.10.2-1 In-Reply-To: <20031010182538.26975.qmail@linuxmail.org> References: <20031010182538.26975.qmail@linuxmail.org> Message-ID: <1065812303.6413.4.camel@wyatt.hadess.net> On Fri, 2003-10-10 at 19:25, Kevin Worthington wrote: > I've been reading about how nice the new graphical boot up looks, so I > just installed the latest (to my knowledge) rhgb (rhgb-0.10.2-1) via > yum, and changed my runlevel in /etc/inittab to 5. (I usually just ssh > in to the box on runlevel 3) The boot process looks very clean and > professional. I really like the way it is shaping up. Many newbies > will feel comfortable with the look and feel of the graphical boot, > rather that the "cold white on black" console mode. > I have a few suggestions and questions, in order of the boot process > (excuse me if some or all of these have been addressed before): > 1. Is it possible to suppress the initial "console-ish" dmesg, before > the graphical interface kicks in? MacOS X seems to have a fixed size logo in there, and a plain backdrop. If somebody were to write the code to have something like this in the kernel, would it be accepted? (at least on the RH/Fedora side) > 2. Why is there a pause between the bootup, and the graphical login > screen? It seems like X kicks out, and then restarts. It seems a > little "un-refined", for lack of better words. gdm/kdm handle starting the X server themselves, maybe they shouldn't in that particular case? > 3. Now that there is a nice looking boot up process, what about a nice > shutdown process? Are there any plans to make the shutdown/reboot look > as nice as the graphical boot up? Would anybody else be interested in > something like this? I don't want a pretty shutdown, I want a (very) fast one :) (something like "umount -a" followed by poweroff -f, under 2 seconds flat from when I click "shutdown" in GNOME) --- Bastien Nocera The red brick wall was the colour of a brick-red crayon. From mharris at redhat.com Fri Oct 10 19:03:09 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 10 Oct 2003 15:03:09 -0400 (EDT) Subject: XFree86 spec file for develoment snapshots ? In-Reply-To: <1065810918.11680.15.camel@rousalka.dyndns.org> References: <1065804368.11058.16.camel@rousalka.dyndns.org> <3F86F7CA.5010505@cypress.com> <1065810918.11680.15.camel@rousalka.dyndns.org> Message-ID: On Fri, 10 Oct 2003, Nicolas Mailhot wrote: >> I think he was asking for more of a easy to remove build of the CVS >> tree. No RedHat patches. Just what you get if you downloaded and did >> make world, but that was then used as an RPM payload. That allows easier >> installation, and removal (when it breaks). > >Sure - what I need is just a way to test quickly the latest XFree86 >devel snapshots, see if I can reproduce my bugs, report back in XFree >bugzilla and reinstall the rawhide version. There isn't any super user-friendly way of doing that though, until it is in RPM format. The simplest way, is to download Alan Hourihane's driver/module binaries, and install them in a directory on your hard disk such as /usr/local/lib/XFree86/modules-extra Then put ModulePath in your X config file as such: ModulePath /usr/local/lib/XFree86/modules-extra' ModulePath /usr/X11R6/lib/modules Put the test modules in the /usr/local/lib/XFree86/modules-extra directory to test them. When done testing, comment out the first ModulePath line and restart your X server to get back to the default modules. >When I wrote about another repository than rawhide I meant >exactly that : some central locations where people can dump >highly experimental stuff and people like me can test it. People are of course free to create their own special highly experimental repositories of such software. Of course, if they encounter/experience bugs in that software, or in the distribution of any kind while using it, they should report those bugs to the upstream projects/authors, so they can be fixed. >Right now you need to read the package changelogs to see who at >RH might be working on them, then hunt down the packages in the >relevant people.redhat.com directories or even private pages (or >be on a top-secret list where the maintainer annouces >experimental packages) > >Which is a lot of fun except you don't always time to do it. > >It's not as if the packages were not created and people can not find >them - why not put them in some sort of central place ? Because individual people have different audiences for their experimental rpms. If there is a central place, then it quickly becomes used by many people, and some fraction of those people then start to cry because their systems break, then they want special hacks added to the spec files so that upgrades to official packages work properly, etc... I would much rather limit my initial highly experimental packages to a limited number of people whom I trust can responsibly test the packages and provide me with high quality good/bad feedback and bug reports with as little "useless" reports as possible. Then continue this way until something is more stable for wider distribution to people for testing. Once my packages are of a state that I consider "good enough for centralized testing by the masses", then they will be in rawhide, which is just that - a central place for testing by the masses. Until I feel the stuff is rawhide ready however, I very much want limited testing by a select group of people, because I don't want to break hundreds of systems if I can avoid it, and I don't want 10000 bug reports, or flaming emails from people who shouldn't have been testing nitroglycerin software. Other people may feel differently, and other developers may feel differently with their packages also. That is natural and to be expected, as different packages have different consequences if they break something. XFree86 packaging is going to change very dramatically for Fedora Core 2, and while the initial packages will be similar to what we have now, the changes are going to be highly experimental and will probably screw up all kinds of stuff for a while. And that is *after* I screen the builds for the most problematic issues. ;o) Be forewarned of what is yet to come... ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From notting at redhat.com Fri Oct 10 19:04:21 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Oct 2003 15:04:21 -0400 Subject: rhgb-0.10.2-1 In-Reply-To: <20031010182538.26975.qmail@linuxmail.org>; from kworthington@linuxmail.org on Fri, Oct 10, 2003 at 01:25:38PM -0500 References: <20031010182538.26975.qmail@linuxmail.org> Message-ID: <20031010150421.C16771@devserv.devel.redhat.com> Kevin Worthington (kworthington at linuxmail.org) said: > 1. Is it possible to suppress the initial "console-ish" dmesg, before the graphical interface kicks in? Boot with 'quiet'. > 2. Why is there a pause between the bootup, and the graphical login screen? It seems like X kicks out, and then restarts. It seems a little "un-refined", for lack of better words. gdm/xdm/kdm use a different X server instance. > 3. Now that there is a nice looking boot up process, what about a nice shutdown process? Are there any plans to make the shutdown/reboot look as nice as the graphical boot up? Would anybody else be interested in something like this? It's probably better to just speed up shutdown; there's some obvious things to do here that we'll probably do for the next cycle. (Top of the list is just not shutting down most services; let init sort them out.) Bill From Nicolas.Mailhot at laPoste.net Fri Oct 10 19:11:50 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 10 Oct 2003 21:11:50 +0200 Subject: XFree86 spec file for develoment snapshots ? In-Reply-To: References: <1065804368.11058.16.camel@rousalka.dyndns.org> <3F86F7CA.5010505@cypress.com> <1065810918.11680.15.camel@rousalka.dyndns.org> Message-ID: <1065813110.11680.26.camel@rousalka.dyndns.org> Le ven 10/10/2003 ? 21:03, Mike A. Harris a ?crit : > On Fri, 10 Oct 2003, Nicolas Mailhot wrote: > > >> I think he was asking for more of a easy to remove build of the CVS > >> tree. No RedHat patches. Just what you get if you downloaded and did > >> make world, but that was then used as an RPM payload. That allows easier > >> installation, and removal (when it breaks). > > > >Sure - what I need is just a way to test quickly the latest XFree86 > >devel snapshots, see if I can reproduce my bugs, report back in XFree > >bugzilla and reinstall the rawhide version. > > There isn't any super user-friendly way of doing that though, > until it is in RPM format. The simplest way, is to download Alan > Hourihane's driver/module binaries, and install them in a > directory on your hard disk such as /usr/local/lib/XFree86/modules-extra Will explore this then. > I would much rather limit my initial highly experimental packages > to a limited number of people whom I trust can responsibly test > the packages and provide me with high quality good/bad feedback > and bug reports with as little "useless" reports as possible. Can I apply to this list ? At least until my radeon-white & input problems are solved;) 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 pri.rhl1 at iadonisi.to Fri Oct 10 19:14:21 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 10 Oct 2003 15:14:21 -0400 Subject: rhgb-0.10.2-1 In-Reply-To: <20031010182538.26975.qmail@linuxmail.org> References: <20031010182538.26975.qmail@linuxmail.org> Message-ID: <1065813260.2417.19.camel@va.local.linuxlobbyist.org> On Fri, 2003-10-10 at 14:25, Kevin Worthington wrote: > 2. Why is there a pause between the bootup, and the graphical login screen? > It seems like X kicks out, and then restarts. It seems a little "un-refined", > for lack of better words. See an earlier discussion about SystemServices on this list. One proposal is to have a '--hide-login-screen' (or whatever) option to gdm so that gdm can start X, but not start the greeter. Then, rhgb could use that instance of X and when completed, a signal (via the gdm socket?) could be sent to gdm to tell it to go ahead and start the greeter. One possibility, anyhow. The short of it is that there is no easy answer to this with the current initscripts model (as well as other factors, I'm sure). PS: Friendly etiquette request: please make sure you're mailer wraps long lines. It makes messages hard to pare down in order to reply to them (going back and forth in addition to highlighting and deleting). -- -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 ted at cypress.com Fri Oct 10 19:19:22 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 14:19:22 -0500 Subject: GCC-3.3 and OO.org In-Reply-To: <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> Message-ID: <3F87063A.9000408@cypress.com> Dan Williams wrote: > Thomas, > > I will change this. AFAIK only 3.2.3 has an issue with symbol > generation, this was corrected for most cases but not all. I will be > setting the build requirement for OOo to gcc 3.2.2-5. Cool. I tried to rebuild it on my mostly RHL9 box. No go so far. I grabbed the build from rawhide and it seams to run OK so far. I'm having some trouble with ODBC/MySQL though I see the same problem in Solaris with the OO.org build. Interesting I don't have problems using JDBC in Solaris (other than speed :( ) or ODBC in Win98 and Excel (97 I think). Time to get back on the OO.org lists... -Thomas From ted at cypress.com Fri Oct 10 19:33:37 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 14:33:37 -0500 Subject: rhgb-0.10.2-1 In-Reply-To: <1065813260.2417.19.camel@va.local.linuxlobbyist.org> References: <20031010182538.26975.qmail@linuxmail.org> <1065813260.2417.19.camel@va.local.linuxlobbyist.org> Message-ID: <3F870991.2030605@cypress.com> Paul Iadonisi wrote: > On Fri, 2003-10-10 at 14:25, Kevin Worthington wrote: >>2. Why is there a pause between the bootup, and the graphical login screen? >>It seems like X kicks out, and then restarts. It seems a little "un-refined", >>for lack of better words. > proposal is to have a '--hide-login-screen' (or whatever) option to gdm > so that gdm can start X, but not start the greeter. Then, rhgb could <...> > easy answer to this with the current initscripts model (as well as other > factors, I'm sure). What about starting X for rhgb on a different vt, say vt8, as server :1? Then *DM start X on vt7, server :) as normal. Once rhgb sees gdm up it shuts down. How many people use multiple servers? How many of them would use rhgb? My guess is most people who use multiple Xservers wouldn't care to use rhgb, not that there are many that use multiple servers anyway. Perhaps a config setting for rhgb in that case, to use a different vt/server? Parsing the correct *DM config files seams overkill. If you're ready to configure multiople servers in *DM, you should know enought to configure rhgb too. -Thomas (who doesn't expect to ever use rhgb anyway) From notting at redhat.com Fri Oct 10 19:41:42 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Oct 2003 15:41:42 -0400 Subject: rhgb-0.10.2-1 In-Reply-To: <3F870991.2030605@cypress.com>; from ted@cypress.com on Fri, Oct 10, 2003 at 02:33:37PM -0500 References: <20031010182538.26975.qmail@linuxmail.org> <1065813260.2417.19.camel@va.local.linuxlobbyist.org> <3F870991.2030605@cypress.com> Message-ID: <20031010154142.F16771@devserv.devel.redhat.com> Thomas Dodd (ted at cypress.com) said: > What about starting X for rhgb on a different vt, say vt8, as server :1? > Then *DM start X on vt7, server :) as normal. Once rhgb sees gdm up it > shuts down. > > How many people use multiple servers? How many of them would use rhgb? > > My guess is most people who use multiple Xservers wouldn't care to use > rhgb, not that there are many that use multiple servers anyway. > > Perhaps a config setting for rhgb in that case, to use a different > vt/server? Parsing the correct *DM config files seams overkill. If > you're ready to configure multiople servers in *DM, you should know > enought to configure rhgb too. Running two X servers simultaneously on the same hardware is a great way to turn up obscure X driver bugs. :) Bill From mharris at redhat.com Fri Oct 10 20:04:04 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 10 Oct 2003 16:04:04 -0400 (EDT) Subject: XFree86 spec file for develoment snapshots ? In-Reply-To: <1065813110.11680.26.camel@rousalka.dyndns.org> References: <1065804368.11058.16.camel@rousalka.dyndns.org> <3F86F7CA.5010505@cypress.com> <1065810918.11680.15.camel@rousalka.dyndns.org> <1065813110.11680.26.camel@rousalka.dyndns.org> Message-ID: On Fri, 10 Oct 2003, Nicolas Mailhot wrote: >> I would much rather limit my initial highly experimental packages >> to a limited number of people whom I trust can responsibly test >> the packages and provide me with high quality good/bad feedback >> and bug reports with as little "useless" reports as possible. > >Can I apply to this list ? At least until my radeon-white & input >problems are solved;) There is no list, and you don't apply to it. The intent of it isn't to provide people having problems with new rpms that might fix their problems. The intent will be to drop new highly experimental rpms into an otherwise stock+updates sysetm and see what breaks, so it can be (hopefully) fixed, and try again on autorepeat until the *packaging* is safe and sane, and any major issues that arise are fixed. Your request IMHO is something that would fall into the rawhide rpms category IMHO, however you of course will be the judge of what you'll install on your system. ;o) Again however, I am not making any people lists. When the time comes, I will get some internal Red Hat people to test it, and a few others that have tested things in the past, etc. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From ted at cypress.com Fri Oct 10 20:07:05 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 15:07:05 -0500 Subject: rhgb-0.10.2-1 In-Reply-To: <20031010154142.F16771@devserv.devel.redhat.com> References: <20031010182538.26975.qmail@linuxmail.org> <1065813260.2417.19.camel@va.local.linuxlobbyist.org> <3F870991.2030605@cypress.com> <20031010154142.F16771@devserv.devel.redhat.com> Message-ID: <3F871169.5040205@cypress.com> Bill Nottingham wrote: > Running two X servers simultaneously on the same hardware is a > great way to turn up obscure X driver bugs. :) And this would get them too:) Don't you think Mike would love to find out about them early in testing, due to rhgb, instead of 3 month form now when someone decideds to use multiple servers for real? -Thomas From aoliva at redhat.com Fri Oct 10 20:19:47 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Oct 2003 17:19:47 -0300 Subject: rhgb-0.10.2-1 In-Reply-To: <3F870991.2030605@cypress.com> References: <20031010182538.26975.qmail@linuxmail.org> <1065813260.2417.19.camel@va.local.linuxlobbyist.org> <3F870991.2030605@cypress.com> Message-ID: On Oct 10, 2003, Thomas Dodd wrote: > What about starting X for rhgb on a different vt, say vt8, as server :1? That's what it does. -- 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 ted at cypress.com Fri Oct 10 20:30:37 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 15:30:37 -0500 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065134595.3164.79.camel@mentor.gurulabs.com> References: <1065042213.8017.47.camel@locutus> <1065045091.2847.53.camel@mentor.gurulabs.com> <1065107463.14032.64.camel@locutus> <1065129913.15489.27.camel@locutus> <1065134595.3164.79.camel@mentor.gurulabs.com> Message-ID: <3F8716ED.4070707@cypress.com> Dax Kelson wrote: > "most common use" == "secure replacement" for telnet, r*, and ftp > > "secure replacement" == Encryption and Authentication (host and user) So kerberized rlogin is fully encrypted? What encryption is used? Not, can k-rlogin be encrypted, but does the fact that k-rlogin uses kerberos for authentication guaranty that the session is encrypted? Could I write a version of k-rlogin that does not encrypt the connection? Will you server, that normaly uses encrypted connections, allow a non-encrypted connection? Can it be forced to not allow one? > In other words, a Kerberized environment provides all the commonly used > functionality of SSH on an intranet plus a whole whole lot more. Commonly used in youe environment, but not others. The most common uses I've seen are, secure (fully encrypted) rlogin and rcp replacements. The next most common is X11 forwarding. -Thomas From bwheadley at earthlink.net Fri Oct 10 20:43:48 2003 From: bwheadley at earthlink.net (Bryan W. Headley) Date: Fri, 10 Oct 2003 15:43:48 -0500 Subject: rhgb-0.10.2-1 In-Reply-To: <3F870991.2030605@cypress.com> References: <20031010182538.26975.qmail@linuxmail.org> <1065813260.2417.19.camel@va.local.linuxlobbyist.org> <3F870991.2030605@cypress.com> Message-ID: <3F871A04.9040706@earthlink.net> Thomas Dodd wrote: > > > Paul Iadonisi wrote: > >> On Fri, 2003-10-10 at 14:25, Kevin Worthington wrote: >> >>> 2. Why is there a pause between the bootup, and the graphical login >>> screen? >>> It seems like X kicks out, and then restarts. It seems a little >>> "un-refined", >>> for lack of better words. >> >> proposal is to have a '--hide-login-screen' (or whatever) option to gdm >> so that gdm can start X, but not start the greeter. Then, rhgb could > > <...> > >> easy answer to this with the current initscripts model (as well as other >> factors, I'm sure). All of this avoids the real issue: rhgb is incredibly slow. It takes this thing 6 seconds to appear and put up the panel that says what's starting up in initscripts. And while it's thrashing, coming up, it's impeding the startup of other services. It's ill-advised; you can go to SVGA or the framebuffer faster and with less footprint to put up a blue background and a newt panel... Add to that the complaint that rhgb starts and X server, stops it, and allows gdm to start another. If things remain as they are, rhgb should start up X, do it's thing, then hand over responsibility of that X server to gdm. -- ____ .:. ____ Bryan W. Headley - bwheadley at earthlink.net From ted at cypress.com Fri Oct 10 20:38:22 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 10 Oct 2003 15:38:22 -0500 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <1065040471.8034.16.camel@locutus> References: <1065016443.6301.37.camel@locutus> <20031001141039.GA5485@dudweiler.stuttgart.redhat.com> <1065040471.8034.16.camel@locutus> Message-ID: <3F8718BE.8080409@cypress.com> Bill Anderson wrote: > On Wed, 2003-10-01 at 08:10, Florian La Roche wrote: >>You can use rpm flags at recompile time to throw many things out: >>- openldap >>- sasl >>- gdbm >>- tcp_wrappers >>- kerberos >>- pam >> >>I don't think it makes sense to pull these things out of Fedora, but >>it is true that from a source code level these things should be modular >>and thus optional. I think they should be runtime modular. So If I have kerberos libs installed, thay can be used. If not, somother method is used. I don't believe I need ldap anything to use mozilla. If I have ldap, mozilla can be told to use it, but it's not required. Same for encrypting the ldap connection. It could use no authentication, clear transmission, to strong authentication, encrypted connections, or any where in between. Changes should not require the app to be recompiled, just a new library installed. -Thomas From dcbw at redhat.com Fri Oct 10 20:39:53 2003 From: dcbw at redhat.com (Dan Williams) Date: Fri, 10 Oct 2003 16:39:53 -0400 Subject: GCC-3.3 and OO.org In-Reply-To: <3F87063A.9000408@cypress.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> Message-ID: <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> Hi, OOo 1.1 packages shipped from Red Hat ship with Java support disabled, since Red Hat does not ship the Sun JDK or JRE. I use patches from the Debian project to accomplish this. Most anything relating to Java in OOo (ie DocBook XML filters, JDBC support, etc) will not work as expected. Dan On Fri, 2003-10-10 at 15:19, Thomas Dodd wrote: > Dan Williams wrote: > > Thomas, > > > > I will change this. AFAIK only 3.2.3 has an issue with symbol > > generation, this was corrected for most cases but not all. I will be > > setting the build requirement for OOo to gcc 3.2.2-5. > > Cool. I tried to rebuild it on my mostly RHL9 box. > No go so far. I grabbed the build from rawhide and it seams to run OK so > far. I'm having some trouble with ODBC/MySQL though I see the same > problem in Solaris with the OO.org build. > > Interesting I don't have problems using JDBC in Solaris (other than > speed :( ) or ODBC in Win98 and Excel (97 I think). > Time to get back on the OO.org lists... > > -Thomas > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From jason at geshp.com Fri Oct 10 20:48:22 2003 From: jason at geshp.com (Jason Luka) Date: Fri, 10 Oct 2003 15:48:22 -0500 Subject: rhgb-0.10.2-1 In-Reply-To: <20031010182538.26975.qmail@linuxmail.org> References: <20031010182538.26975.qmail@linuxmail.org> Message-ID: <3F871B16.7000105@geshp.com> Kevin Worthington wrote: >I've been reading about how nice the new graphical boot up looks, so I just installed the latest (to my knowledge) rhgb (rhgb-0.10.2-1) via yum, and changed my runlevel in /etc/inittab to 5. (I usually just ssh in to the box on runlevel 3) The boot process looks very clean and professional. I really like the way it is shaping up. Many newbies will feel comfortable with the look and feel of the graphical boot, rather that the "cold white on black" console mode. >I have a few suggestions and questions, in order of the boot process (excuse me if some or all of these have been addressed before): >1. Is it possible to suppress the initial "console-ish" dmesg, before the graphical interface kicks in? >2. Why is there a pause between the bootup, and the graphical login screen? It seems like X kicks out, and then restarts. It seems a little "un-refined", for lack of better words. >3. Now that there is a nice looking boot up process, what about a nice shutdown process? Are there any plans to make the shutdown/reboot look as nice as the graphical boot up? Would anybody else be interested in something like this? > >Thanks in advance... >-Kev >--- >Kevin Worthington - >Faithful Red Hat Linux user since April 1998 >Registered Linux User #218689 - http://counter.li.org > > > There's a kernel patch for a bootsplash screen available on the internet. (bootsplash.org) I sent a modification of it for kernel-2.4.22 to the kernel people at Red Hat, but they seem divided about whether or not to put it in. This patch would put a full-screen JPG on the screen instead of the normal b/w console input, starting before the kernel puts a word on the screen. There's also a command line utility which could easily be used to put in a shutdown screen. And also it can bypassed with F2 key. I've got it working on my box, but the graphics I have are nothing more than the generic Linux penguin. If anyone wants help about how to get it to work, just email jason at geshp.com. Jason Luka From edwardam at interlix.com Fri Oct 10 20:49:51 2003 From: edwardam at interlix.com (Edward Muller) Date: Fri, 10 Oct 2003 15:49:51 -0500 Subject: Additional Mozilla Request [was Re: rawhide report: 20031010 changes] In-Reply-To: <1065805796.9792.126.camel@palin> References: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> <1065805796.9792.126.camel@palin> Message-ID: <1065818990.9792.135.camel@palin> So anyone know how to register a component with mozilla without a UI? I took a look at the install.js script in the mozex xpi file and paired it down so that it would just install the component globally, but you still need to run mozilla and you have to okay the install of the component. How is the spellchecker installed automagically? Was the various rdf,reg,etc,etc files just patched? On Fri, 2003-10-10 at 12:09, Edward Muller wrote: > Would it be possible to add mozex to the Mozilla RPM or a separate RPM? > > Using mozex it is possible to define external programs that can handle > various tasks like: mailto:, news:, telnet:, and ftp: urls; view source; > edit content areas & download files. > > If people think it should be in a separate RPM I will take a go at > packaging it > > Mozex can be found at: > http://mozex.mozdev.org/ > > On Fri, 2003-10-10 at 04:49, Build System wrote: > > mozilla-1.4.1-7 > > --------------- > > * Thu Oct 09 2003 Christopher Blizzard 37:1.4.1-7 > > > > - move spellchecker from mail package into main package so composer > > picks it up -- Edward Muller - http://www.interlix.com - "Open Source Specialists" Dedicated Zope Hosting - Web Hosting - Open Source Consulting Network & PC Service & Support - Custom Programming Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572 Jabber: edwardam at jabber.interlix.com - AIM: edwardam453 - ICQ: 287033 From pauln at truemesh.com Fri Oct 10 20:51:44 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Fri, 10 Oct 2003 21:51:44 +0100 Subject: GCC-3.3 and OO.org In-Reply-To: <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> Message-ID: <20031010205143.GE24349@shitake.truemesh.com> On Fri, Oct 10, 2003 at 04:39:53PM -0400, Dan Williams wrote: > OOo 1.1 packages shipped from Red Hat ship with Java support disabled, > since Red Hat does not ship the Sun JDK or JRE. I use patches from the > Debian project to accomplish this. Most anything relating to Java in > OOo (ie DocBook XML filters, JDBC support, etc) will not work as > expected. Hmm, is there any way to sub-package java stuff, the rhug group seems to have gotten pretty far with quite a lot of packages (they've hit tarroon), plus it is still possible to compile stuff with gcj/jikes/etc. Sadly java distribution is problematic, but if we can put things into Fedora Extras or JPackage which require a bit more user interaction (dowloading binaries after clickthrough) it might be useful/beneficial to the end user. Paul From edwardam at interlix.com Fri Oct 10 20:58:28 2003 From: edwardam at interlix.com (Edward Muller) Date: Fri, 10 Oct 2003 15:58:28 -0500 Subject: PSI on Fedora Message-ID: <1065819508.24149.4.camel@palin> I have rpms of PSI for Fedora and they work fine so far, except that when using the docklet I have an additional 'psi' item in my window list. I am logging into gnome. Not sure if this is a Gnome issue, Metacity issue, PSI issue or Qt issue. -- Edward Muller - http://www.interlix.com - "Open Source Specialists" Dedicated Zope Hosting - Web Hosting - Open Source Consulting Network & PC Service & Support - Custom Programming Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572 Jabber: edwardam at jabber.interlix.com - AIM: edwardam453 - ICQ: 287033 From Nicolas.Mailhot at laPoste.net Fri Oct 10 20:59:18 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 10 Oct 2003 22:59:18 +0200 Subject: GCC-3.3 and OO.org In-Reply-To: <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> Message-ID: <1065819558.11680.43.camel@rousalka.dyndns.org> Le ven 10/10/2003 ? 22:39, Dan Williams a ?crit : > Hi, > > OOo 1.1 packages shipped from Red Hat ship with Java support disabled, > since Red Hat does not ship the Sun JDK or JRE. I use patches from the > Debian project to accomplish this. Most anything relating to Java in > OOo (ie DocBook XML filters, JDBC support, etc) will not work as > expected. If you have some java-related packages you'd like to upload somewhere we at the jpackage project (http://www.jpackage.org/) would love to host it. (of course they're the slight matter of spec review first but we are much less strict than fedora.us right now - we simply do not have the manpower to do so) 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 dcbw at redhat.com Fri Oct 10 21:15:28 2003 From: dcbw at redhat.com (Dan Williams) Date: Fri, 10 Oct 2003 17:15:28 -0400 Subject: GCC-3.3 and OO.org In-Reply-To: <20031010205143.GE24349@shitake.truemesh.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> <20031010205143.GE24349@shitake.truemesh.com> Message-ID: <1065820528.4800.12.camel@dhcp64-188.boston.redhat.com> Hi, It is not possible to compile the java bits of OOo right now with a non-Sun Java solution. Kaffe is the closes some have gotten (Debian project) but there are still major issues with it. Compiling OOo with gcj would require major patching because gcj is not set up like the Sun JDK, which OOo expects to find. At this point, I don't have the resources nor the time to make building with either Kaffe or gcj a priority. There is ongoing work in this area however. As you suggest, the alternative would be to allow individuals to compile with Java support, using the Red Hat SRPM. This should not be too hard to do, provided the Sun JDK is in its standard place. I expect a simple variable switch at the beginning of the specfile would be all that a user would need to set to compile with Java support in OOo. That I could do in the near future. Dan On Fri, 2003-10-10 at 16:51, Paul Nasrat wrote: > On Fri, Oct 10, 2003 at 04:39:53PM -0400, Dan Williams wrote: > > > OOo 1.1 packages shipped from Red Hat ship with Java support disabled, > > since Red Hat does not ship the Sun JDK or JRE. I use patches from the > > Debian project to accomplish this. Most anything relating to Java in > > OOo (ie DocBook XML filters, JDBC support, etc) will not work as > > expected. > > Hmm, is there any way to sub-package java stuff, the rhug group seems to have > gotten pretty far with quite a lot of packages (they've hit tarroon), > plus it is still possible to compile stuff with gcj/jikes/etc. > > Sadly java distribution is problematic, but if we can put things into > Fedora Extras or JPackage which require a bit more user interaction > (dowloading binaries after clickthrough) it might be useful/beneficial > to the end user. > > Paul > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From alan at redhat.com Fri Oct 10 21:24:04 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 10 Oct 2003 17:24:04 -0400 (EDT) Subject: GCC-3.3 and OO.org In-Reply-To: <20031010205143.GE24349@shitake.truemesh.com> from "Paul Nasrat" at Hyd 10, 2003 09:51:44 Message-ID: <200310102124.h9ALO4s01061@devserv.devel.redhat.com> > Sadly java distribution is problematic, but if we can put things into > Fedora Extras or JPackage which require a bit more user interaction > (dowloading binaries after clickthrough) it might be useful/beneficial > to the end user. The way Fedora is specified means you need to be able to build everything in Fedora with Fedora and everything in Fedora Extras with Fedora + Extras and so on. From Nicolas.Mailhot at laPoste.net Fri Oct 10 21:27:57 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 10 Oct 2003 23:27:57 +0200 Subject: GCC-3.3 and OO.org In-Reply-To: <1065820528.4800.12.camel@dhcp64-188.boston.redhat.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> <20031010205143.GE24349@shitake.truemesh.com> <1065820528.4800.12.camel@dhcp64-188.boston.redhat.com> Message-ID: <1065821277.13284.4.camel@rousalka.dyndns.org> Le ven 10/10/2003 ? 23:15, Dan Williams a ?crit : > Hi, > > It is not possible to compile the java bits of OOo right now with a > non-Sun Java solution. Kaffe is the closes some have gotten (Debian > project) but there are still major issues with it. Compiling OOo with > gcj would require major patching because gcj is not set up like the Sun > JDK, which OOo expects to find. Well really it's not the app job to be adapted to gcj but gcj's one to appear just like another jvm. We have a large cross-jvm rpm repository where people can use any of Sun/IBM/Bea/Blackdown 1.3/1.4 jvms, but sadly there is not gcj jvm provider right now. If you do build oo parts with support for non-gcj jvms, please use the jpackage file layout not the Sun one - it'd be stupid two have two incompatible repositories of java packages. 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 Fri Oct 10 21:33:54 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 10 Oct 2003 23:33:54 +0200 Subject: GCC-3.3 and OO.org In-Reply-To: <200310102124.h9ALO4s01061@devserv.devel.redhat.com> References: <200310102124.h9ALO4s01061@devserv.devel.redhat.com> Message-ID: <1065821634.13284.11.camel@rousalka.dyndns.org> Le ven 10/10/2003 ? 23:24, Alan Cox a ?crit : > > Sadly java distribution is problematic, but if we can put things into > > Fedora Extras or JPackage which require a bit more user interaction > > (dowloading binaries after clickthrough) it might be useful/beneficial > > to the end user. > > The way Fedora is specified means you need to be able to build everything > in Fedora with Fedora and everything in Fedora Extras with Fedora + Extras > and so on. Which means java packages must go somewhere else ie jpackage right now. Which as jpackage member is perfectly ok with me;) Hopefully we'll get to the point where each non-free bit of our repository got a free alternative, and the huge jakarta, objectweb, jboss etc pool of free java software can be distributed alongside fedora. (not a jpp/fdr merger - the mandrake members would object - but maybe a cooperation like the one we have with Mandrake right 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 pauln at truemesh.com Fri Oct 10 21:35:01 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Fri, 10 Oct 2003 22:35:01 +0100 Subject: GCC-3.3 and OO.org In-Reply-To: <1065820528.4800.12.camel@dhcp64-188.boston.redhat.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> <20031010205143.GE24349@shitake.truemesh.com> <1065820528.4800.12.camel@dhcp64-188.boston.redhat.com> Message-ID: <20031010213500.GF24349@shitake.truemesh.com> On Fri, Oct 10, 2003 at 05:15:28PM -0400, Dan Williams wrote: > At this point, I don't have the resources nor the time to make building > with either Kaffe or gcj a priority. There is ongoing work in this area > however. Fair enough. > As you suggest, the alternative would be to allow individuals to compile > with Java support, using the Red Hat SRPM. This should not be too hard > to do, provided the Sun JDK is in its standard place. I follow you up to "standard place", which intrests me. The JPackage project try and package to FHS the JDK, I'd assume given a sane JAVA_HOME the OO.org compile should work, but I haven't really tried to build OO.org. Any pointers to docs onthe OO.o/Java integration appreciated. > I expect a simple > variable switch at the beginning of the specfile would be all that a > user would need to set to compile with Java support in OOo. That I > could do in the near future. Sounds good. Always happy to test. Paul From derek.moore at sbcglobal.net Fri Oct 10 20:38:25 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Fri, 10 Oct 2003 13:38:25 -0700 (PDT) Subject: Art of demagogics Re: Gentoo Linux faster app-load than (Mandrake|Fedora) In-Reply-To: <1065767881.1477.30.camel@agnes.fremen.dune> Message-ID: <20031010203825.86427.qmail@web80001.mail.yahoo.com> > Another point is that in my experience people who write articles > in Linux magazines are completely incompetent at benchamrking. Or just completely incompetent in general? (See for one case in point. Why the author felt inclined to leave eth0 unset and do everything on eth0:0 is beyond me. Maybe he just wanted to confuse the help out of his audience [or himself].) Okay, I'm done now, Derek From pauln at truemesh.com Fri Oct 10 21:53:04 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Fri, 10 Oct 2003 22:53:04 +0100 Subject: GCC-3.3 and OO.org In-Reply-To: <1065821277.13284.4.camel@rousalka.dyndns.org> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> <20031010205143.GE24349@shitake.truemesh.com> <1065820528.4800.12.camel@dhcp64-188.boston.redhat.com> <1065821277.13284.4.camel@rousalka.dyndns.org> Message-ID: <20031010215302.GG24349@shitake.truemesh.com> On Fri, Oct 10, 2003 at 11:27:57PM +0200, Nicolas Mailhot wrote: > Well really it's not the app job to be adapted to gcj but gcj's one to > appear just like another jvm. We have a large cross-jvm rpm repository > where people can use any of Sun/IBM/Bea/Blackdown 1.3/1.4 jvms, but > sadly there is not gcj jvm provider right now. This may be OT for fedora-devel, but there will be rhug/native eclipse/gcj people who may be able to comment. I'm wondering how hard it would be to provide a jpackage/fedora functional (to a point) libgcj/gnu classpath system. I've seen the posts on the sources.redhat.com/eclipse/ archives about how to massage gcj into acting as a standard java executable for eclipse. Theoretically it should be feasible to interoperate. I assume taroon/RHES is going to be fairly java/gcj centric so fedora providing an environment to trial gcj interoperability in. Paul From dcbw at redhat.com Fri Oct 10 21:56:02 2003 From: dcbw at redhat.com (Dan Williams) Date: Fri, 10 Oct 2003 17:56:02 -0400 Subject: GCC-3.3 and OO.org In-Reply-To: <20031010213500.GF24349@shitake.truemesh.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> <20031010205143.GE24349@shitake.truemesh.com> <1065820528.4800.12.camel@dhcp64-188.boston.redhat.com> <20031010213500.GF24349@shitake.truemesh.com> Message-ID: <1065822962.4800.36.camel@dhcp64-188.boston.redhat.com> On Fri, 2003-10-10 at 17:35, Paul Nasrat wrote: > I follow you up to "standard place", which intrests me. The JPackage > project try and package to FHS the JDK, I'd assume given a sane > JAVA_HOME the OO.org compile should work, but I haven't really tried to > build OO.org. Any pointers to docs onthe OO.o/Java integration > appreciated. Well, normally to get OOo to work with Java, you have to pass --with-jdk-home= to the configure script in config_office/ directory. Since I pass in --disable-java to this script, I could make a switch to allow one to pass in --with-jdk-home, but where would the RPM get the path from? What do you think is the best way to do that? OOo will disregard a value in JAVA_HOME and find that path itself. The alternative is for the user to make sure 'java' and 'javac' are in their PATH, since OOo will pick those up: AC_PATH_PROG(JAVAC, javac) AC_PATH_PROG(JAVA, java) and autodetect the path to the JDK from that. Dan From derek.moore at sbcglobal.net Fri Oct 10 22:06:13 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Fri, 10 Oct 2003 15:06:13 -0700 (PDT) Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <3F8716ED.4070707@cypress.com> Message-ID: <20031010220613.39593.qmail@web80005.mail.yahoo.com> > So kerberized rlogin is fully encrypted? What encryption is used? Yes. Kerberized applications have full session-level encryption, similar to TLS/SSL or SSH-TRANS (that is, if the application is Kerberized fully and/or properly). The cipher used depends on how you setup Kerberos and what you tell Kerberos to use. See: http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3.1/doc/krb5-admin.html#Supported%20Encryption%20Types > Not, can k-rlogin be encrypted, but does the fact that k-rlogin uses > kerberos for authentication guaranty that the session is encrypted? Some kerberized applications use session-level encryption by default. Some don't. > Could I write a version of k-rlogin that does not encrypt the connection? > > Will you server, that normaly uses encrypted connections, allow a > non-encrypted connection? There's usually a command line option to turn session encryption on or off, as the case may be (-x in most cases, I think). And the same kerberized daemons accept encrypted and unencrypted connections. For the default operation and command line options of kerberized utilities in MIT's Kerberos distribution, see: http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3.1/doc/krb5-user.html#Kerberos%20V5%20Applications > Can it be forced to not allow one? I haven't a clue. But, probably. > The next most common is X11 forwarding. So far as I know, there isn't yet a standalone, kerberized X11 forwarding application. So kerberized SSH is still very useful on kerberized networks if for no other reason than that. Okay, I'm done now, Derek From Nicolas.Mailhot at laPoste.net Fri Oct 10 22:22:46 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 11 Oct 2003 00:22:46 +0200 Subject: GCC-3.3 and OO.org In-Reply-To: <1065822962.4800.36.camel@dhcp64-188.boston.redhat.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> <20031010205143.GE24349@shitake.truemesh.com> <1065820528.4800.12.camel@dhcp64-188.boston.redhat.com> <20031010213500.GF24349@shitake.truemesh.com> <1065822962.4800.36.camel@dhcp64-188.boston.redhat.com> Message-ID: <1065824566.13648.17.camel@rousalka.dyndns.org> Le ven 10/10/2003 ? 23:56, Dan Williams a ?crit : > On Fri, 2003-10-10 at 17:35, Paul Nasrat wrote: > > I follow you up to "standard place", which intrests me. The JPackage > > project try and package to FHS the JDK, I'd assume given a sane > > JAVA_HOME the OO.org compile should work, but I haven't really tried to > > build OO.org. Any pointers to docs onthe OO.o/Java integration > > appreciated. > > Well, normally to get OOo to work with Java, you have to pass > --with-jdk-home= to the configure script in config_office/ > directory. Since I pass in --disable-java to this script, I could make > a switch to allow one to pass in --with-jdk-home, but where would the > RPM get the path from? What do you think is the best way to do that? 1. at jpackage if a jpp-compatible jvm is installed the /usr/lib/jvm/java symlink exists (and handled by alternative). We also provide lots of symlinks like /usr/lib/jvm/java-sun, /usr/lib/jvm/java-1.4.2 and so on. This symlink can always be used as the ultimate fallback 2. We have a system-wide /etc/java/java.conf rcfile where the user can specify his prefered jvm (with JAVA_HOME) We used to put java binaries in /usr/bin but it proved too messy : a. gcj already did it in an incompatible way (ie it randomly stomped on our links) b. when you start allowing parallel install of multiple jvms - as is often necessary in the real world(tm) - it gets really messy. Sure one can use alternatives for this but even getting a single directory symlink to work all right proved difficult (have to handle all the install/removal scenarii). Most java packages are happier with JAVA_HOME anyway - if you give them java executables in the path they'll initiate real ugly shell euristics to try to guess the actual JAVA_HOME value. 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 pauln at truemesh.com Fri Oct 10 22:32:25 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Fri, 10 Oct 2003 23:32:25 +0100 Subject: GCC-3.3 and OO.org In-Reply-To: <1065822962.4800.36.camel@dhcp64-188.boston.redhat.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> <20031010205143.GE24349@shitake.truemesh.com> <1065820528.4800.12.camel@dhcp64-188.boston.redhat.com> <20031010213500.GF24349@shitake.truemesh.com> <1065822962.4800.36.camel@dhcp64-188.boston.redhat.com> Message-ID: <20031010223220.GI24349@shitake.truemesh.com> On Fri, Oct 10, 2003 at 05:56:02PM -0400, Dan Williams wrote: > Well, normally to get OOo to work with Java, you have to pass > --with-jdk-home= to the configure script in config_office/ > directory. Since I pass in --disable-java to this script, I could make OK that's all usefull to me to play with. > a switch to allow one to pass in --with-jdk-home, but where would the > RPM get the path from? What do you think is the best way to do that? > OOo will disregard a value in JAVA_HOME and find that path itself. I won't address that right now although there probably are some evil expansions you can do. > The alternative is for the user to make sure 'java' and 'javac' are in > their PATH, since OOo will pick those up: In terms for rebuilding - assuming the java specific parts of OO.o can be neatly packaged, the way JPackage JDK's work is that we use alternatives (yes they can aren't right for everyything but for multiple vendor java/javac I think it is a good solution) so java/javac are in standard paths. The autoconf macros are worth considering, too. Paul From aoliva at redhat.com Fri Oct 10 21:45:05 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 10 Oct 2003 18:45:05 -0300 Subject: rhgb-0.10.2-1 In-Reply-To: <3F871A04.9040706@earthlink.net> References: <20031010182538.26975.qmail@linuxmail.org> <1065813260.2417.19.camel@va.local.linuxlobbyist.org> <3F870991.2030605@cypress.com> <3F871A04.9040706@earthlink.net> Message-ID: On Oct 10, 2003, "Bryan W. Headley" wrote: > All of this avoids the real issue: rhgb is incredibly slow. It takes > this thing 6 seconds to appear and put up the panel that says what's > starting up in initscripts. And while it's thrashing, coming up, it's > impeding the startup of other services. But then, gdm start-up becomes incredibly faster, because all of the XFree86 code is already in memory! I'm told one of the greatest start-up time hogs in rhgb has to do with the font cache, that gets trashed. A fix for this is already in the works, maybe even already in rawhide. That said, it would be very nice if the time rhgb takes to start up didn't prevent other init services from getting started. -- 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 bwheadley at earthlink.net Fri Oct 10 22:53:10 2003 From: bwheadley at earthlink.net (Bryan W. Headley) Date: Fri, 10 Oct 2003 17:53:10 -0500 Subject: rhgb-0.10.2-1 In-Reply-To: <3F871B16.7000105@geshp.com> References: <20031010182538.26975.qmail@linuxmail.org> <3F871B16.7000105@geshp.com> Message-ID: <3F873856.1000204@earthlink.net> Jason Luka wrote: > There's a kernel patch for a bootsplash screen available on the > internet. (bootsplash.org) I sent a modification of it for > kernel-2.4.22 to the kernel people at Red Hat, but they seem divided > about whether or not to put it in. I'm looking at this debian package, boot-icons, which pops up images using the framebuffer, at the bequest of SysVinit scripts invoked during the bootup procedure. No kernel patches. -- ____ .:. ____ Bryan W. Headley - bwheadley at earthlink.net From bwheadley at earthlink.net Fri Oct 10 23:00:16 2003 From: bwheadley at earthlink.net (Bryan W. Headley) Date: Fri, 10 Oct 2003 18:00:16 -0500 Subject: rhgb-0.10.2-1 In-Reply-To: References: <20031010182538.26975.qmail@linuxmail.org> <1065813260.2417.19.camel@va.local.linuxlobbyist.org> <3F870991.2030605@cypress.com> <3F871A04.9040706@earthlink.net> Message-ID: <3F873A00.9060704@earthlink.net> Alexandre Oliva wrote: > On Oct 10, 2003, "Bryan W. Headley" wrote: > > >>All of this avoids the real issue: rhgb is incredibly slow. It takes >>this thing 6 seconds to appear and put up the panel that says what's >>starting up in initscripts. And while it's thrashing, coming up, it's >>impeding the startup of other services. > But then, gdm start-up becomes incredibly faster, because all of the > XFree86 code is already in memory! I agree, but... If you are dealing with corporate standards where they like seeing a graphical image of something (like their logo) other than driver versions/initscript startups, then you'll want to get that blue screen up as fast as possible. It's nice that it's helping gdm's startup time, but that's several seconds in the future :-) > That said, it would be very nice if the time rhgb takes to start up > didn't prevent other init services from getting started. Put it in the background, immediately. But the other services still deal with the thrashing... -- ____ .:. ____ Bryan W. Headley - bwheadley at earthlink.net From scott at ucolick.org Fri Oct 10 22:58:21 2003 From: scott at ucolick.org (Scott Seagroves) Date: Fri, 10 Oct 2003 15:58:21 -0700 Subject: GCC-3.3 and OO.org In-Reply-To: <200310102124.h9ALO4s01061@devserv.devel.redhat.com> References: <200310102124.h9ALO4s01061@devserv.devel.redhat.com> Message-ID: <1065826701.6640.4.camel@lobos> On Fri, 2003-10-10 at 14:24, Alan Cox wrote: > The way Fedora is specified means you need to be able to build everything > in Fedora with Fedora and everything in Fedora Extras with Fedora + Extras > and so on. > But what about some-fedora-package.src.rpm which rebuilds fine on Fedora alone, but also has some things in the specfile like "uncomment this next line if you have a JRE from jpackage"? Would that be OK with the current policies? SS From jaap_haitsma at zonnet.nl Fri Oct 10 23:13:09 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Sat, 11 Oct 2003 01:13:09 +0200 Subject: Suggestion for initscripts Message-ID: <3F873D05.3010004@zonnet.nl> Probably people dealing with the initscripts know this stuff, but I I just post this just in case they haven't Richard Gooch and co. have a very elegant solution for the initscripts See: http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/index.html The nice thing is that you don't need these S[number][service] and K[number][service] scripts in the /etc/rc.[number] directories. Every service just tells which service it needs to have running. And if that doesn't run yet it just tries to start it. Possible other advantage I see, is that you might start services in parallel, which can save some time during booting :-) Jaap From nhruby at uga.edu Fri Oct 10 23:36:24 2003 From: nhruby at uga.edu (nathan r. hruby) Date: Fri, 10 Oct 2003 19:36:24 -0400 (EDT) Subject: Suggestion for initscripts In-Reply-To: <3F873D05.3010004@zonnet.nl> References: <3F873D05.3010004@zonnet.nl> Message-ID: On Sat, 11 Oct 2003, Jaap A. Haitsma wrote: > > Every service just tells which service it needs to have running. And if > that doesn't run yet it just tries to start it. > > Possible other advantage I see, is that you might start services in > parallel, which can save some time during booting :-) > OSX's SystemStarter is similar in operation to this. It sucks, mostly because of the implementation, but sometimes you have to rig the StartupItems to get the dep order right else it'll toss up the loginwindow while doing something like resyncing your DNS cache files for the secondaries it serves (which can be CPU intensive if you are a secondary for 500 zones :) Personally, chkconfig works well for me, I'm happy on my linux system and the Solaris weenies can still figure out what's starting up and when which keeps them from cluttering my cube. -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From jason at geshp.com Fri Oct 10 23:36:11 2003 From: jason at geshp.com (Jason Luka) Date: Fri, 10 Oct 2003 18:36:11 -0500 Subject: rhgb-0.10.2-1 In-Reply-To: <3F873856.1000204@earthlink.net> References: <20031010182538.26975.qmail@linuxmail.org> <3F871B16.7000105@geshp.com> <3F873856.1000204@earthlink.net> Message-ID: <3F87426B.3060206@geshp.com> Bryan W. Headley wrote: > Jason Luka wrote: > >> There's a kernel patch for a bootsplash screen available on the >> internet. (bootsplash.org) I sent a modification of it for >> kernel-2.4.22 to the kernel people at Red Hat, but they seem divided >> about whether or not to put it in. > > > I'm looking at this debian package, boot-icons, which pops up images > using the framebuffer, at the bequest of SysVinit scripts invoked > during the bootup procedure. No kernel patches. > > The kernel patch in question, though, pops up the image using the framebuffer before it gets to SysVinit scripts, namely when the kernel initializes the video. From xose at wanadoo.es Sat Oct 11 00:21:58 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sat, 11 Oct 2003 02:21:58 +0200 Subject: Suggestion for initscripts References: <3F873D05.3010004@zonnet.nl> Message-ID: <3F874D26.9040601@wanadoo.es> Jaap A. Haitsma wrote: > Richard Gooch and co. have a very elegant solution for the initscripts > See: > http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/index.html There is a open RFE at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99540 -- Software is like sex, it's better when it's bug free. From behdad at cs.toronto.edu Sat Oct 11 01:58:58 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Fri, 10 Oct 2003 21:58:58 -0400 Subject: rhgb-0.10.2-1 In-Reply-To: <20031010150421.C16771@devserv.devel.redhat.com> References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> Message-ID: On Fri, 10 Oct 2003, Bill Nottingham wrote: > Kevin Worthington (kworthington at linuxmail.org) said: > > 1. Is it possible to suppress the initial "console-ish" > > dmesg, before the graphical interface kicks in? > > Boot with 'quiet'. I know this is too windowsish, but it would be nice if the kernel would boot quietly if there have been a clean shutdown. I don't know how to implement this cleanly yet, as if we get a panic, no one has removed the flag and it would boot quiet again... A related question: Can't one ask kudzu to scan just a few buses? Say, USB and firewire only? Another one (unrelated this time): Times to times applications crash and leave sockets in /tmp that prevents them from starting next time (I had the problem with xmms-1.2.7 atleast), is there any problem with cleaning /tmp completely during boot time? > Bill behdad From goeran at uddeborg.se Sat Oct 11 08:36:08 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Sat, 11 Oct 2003 10:36:08 +0200 Subject: xfs initscript enhancements, take 5 In-Reply-To: References: <20031009080713.57674.qmail@web80007.mail.yahoo.com> Message-ID: <16263.49400.139633.421366@uebn.uddeborg.se> Mike A. Harris writes: > There was a tool called type1inst which was not > part of XFree86, however I don't recall the story on that tool. > I presume it sucked because it's never been shipped and nobody > seems to use it out there. FWIW, it works fine for me. I use it in a local version of the fonts-are-(un)installed-so-metadata-needs-to-be-updated-script which has been touched upon here. I did one minor patch once to let the perl patterns handle a slightly unusual use of whitespace in some font file, but that's all. > mkfontscale supports Type1 fonts > however, But if there is a tool with the core package now (I had missed that), that's of course a simpler way to handle things. From julo at altern.org Sat Oct 11 08:42:25 2003 From: julo at altern.org (Julien Olivier) Date: Sat, 11 Oct 2003 09:42:25 +0100 Subject: rhgb-0.10.2-1 In-Reply-To: References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> Message-ID: <1065861744.3616.5.camel@localhost.localdomain> On Sat, 2003-10-11 at 02:58, Behdad Esfahbod wrote: > On Fri, 10 Oct 2003, Bill Nottingham wrote: > > > Kevin Worthington (kworthington at linuxmail.org) said: > > > 1. Is it possible to suppress the initial "console-ish" > > > dmesg, before the graphical interface kicks in? > > > > Boot with 'quiet'. > > I know this is too windowsish, but it would be nice if the kernel > would boot quietly if there have been a clean shutdown. I don't > know how to implement this cleanly yet, as if we get a panic, no > one has removed the flag and it would boot quiet again... > Hmmm... I think the best way to handle that would be to put a flag when the computer has started cleanly and remove it when it has be shut down cleanly. This, way, if it kernel-panics or crashes, the flag is still there. From mharris at redhat.com Sat Oct 11 09:37:38 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 11 Oct 2003 05:37:38 -0400 (EDT) Subject: XFree86 spec file for develoment snapshots ? In-Reply-To: <3F86F7CA.5010505@cypress.com> References: <1065804368.11058.16.camel@rousalka.dyndns.org> <3F86F7CA.5010505@cypress.com> Message-ID: On Fri, 10 Oct 2003, Thomas Dodd wrote: >> I currently do not have a 4.3.99.x src.rpm, however I have been >> fairly slowly working on one for about a week. I don't have a >> lot of time to devote to it for about 2-3 weeks, so while waiting >> for a build to compile and whatnot, I've been test building >> 4.3.99.x on another machine and getting rid of patches one at a >> time that are no longer needed. The bigger part of the work will >> be forward porting patches that are still needed, and isolating >> small pieces of patches that are mostly unneeded, but which a few >> bits are still needed. > >I think he was asking for more of a easy to remove build of the CVS >tree. No RedHat patches. Just what you get if you downloaded and did >make world, but that was then used as an RPM payload. That allows easier >installation, and removal (when it breaks). I wish you, or anyone good luck finding anything like that anywhere. Even better luck spending the time to create it. ;o) The funny part is, that I'm more likely to have rawhide rpms of 4.3.99.x before someone produced sane rpms themselves, and i can reasonably guarantee mine will be much saner. ;o) >Perhaps with a minimal set of patches to fit the Red Hat/Fedora layout. >Not sure ny more, but there used to be some differeces in the XF86 and >Red Hat directory structure. XF86 didn't use /etc/X11/ for everything >Red Hat did. I think font locations too. Red Hat does not have a Red Hat/Fedora layout, but rather, we use the File Heirarchy Standard locations for X11. Any Linux OS distribution out there which does not put the X11 files in the locations they are in Red Hat Linux, is not FHS and thus also not LSB compliant. http://www.pathname.com/fhs http://www.linuxbase.org XFree86 itself however, is not a piece of Linux-only software, but rather it is portable to pretty much any relevant operating system out there, and even many irrelevant ones. Each of those OSs have their own standards for things. Also, I've no idea if the XFree86.org supplied Linux binaries follow the FHS or LSB standards or not. What matters to us however, is the FHS and LSB, not random upstream projects own personal preferences for where they think their files should go. >This is kind of what the current 2.6 kernels from Arjan do. Alan >added a rpm target to the kerenl somtime back as well, but I >think it was more generic than what Arjan is doing. Several >packages include their own spec file already, but XF86 isn't one >of them. Someone could create a generic XFree86 spec file that contained no patches, however it would still need to be updated every single release, and well maintained. It would be highly distribution specific, and almost certainly never considered for inclusion in XFree86 itself. Feel free to produce rpms of XFree86 CVS based upon my 4.3.0 rpms if you (or anyone else) wishes. If nothing else, you'll become very familiar with building XFree86 rpms, and the complexities and problems that are involved, and with any luck, I can sucker you (or anyone else interested) into fixing bugs. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From bwheadley at earthlink.net Sat Oct 11 14:17:46 2003 From: bwheadley at earthlink.net (Bryan W. Headley) Date: Sat, 11 Oct 2003 09:17:46 -0500 Subject: rhgb-0.10.2-1 In-Reply-To: <3F87426B.3060206@geshp.com> References: <20031010182538.26975.qmail@linuxmail.org> <3F871B16.7000105@geshp.com> <3F873856.1000204@earthlink.net> <3F87426B.3060206@geshp.com> Message-ID: <3F88110A.2040006@earthlink.net> Jason Luka wrote: > Bryan W. Headley wrote: > >> Jason Luka wrote: >> >>> There's a kernel patch for a bootsplash screen available on the >>> internet. (bootsplash.org) I sent a modification of it for >>> kernel-2.4.22 to the kernel people at Red Hat, but they seem divided >>> about whether or not to put it in. >> >> >> >> I'm looking at this debian package, boot-icons, which pops up images >> using the framebuffer, at the bequest of SysVinit scripts invoked >> during the bootup procedure. No kernel patches. >> >> > The kernel patch in question, though, pops up the image using the > framebuffer before it gets to SysVinit scripts, namely when the kernel > initializes the video. Yes, whereas boot-icons seems to be 100% userland, although it also uses the fb. Might help placate those who are disturbed by the kernel patch, although bootsplash IS used by SuSE (supposively) with no ill effects. -- ____ .:. ____ Bryan W. Headley - bwheadley at earthlink.net From behdad at cs.toronto.edu Sat Oct 11 20:38:42 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sat, 11 Oct 2003 16:38:42 -0400 Subject: rhgb-0.10.2-1 In-Reply-To: <1065861744.3616.5.camel@localhost.localdomain> References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <1065861744.3616.5.camel@localhost.localdomain> Message-ID: On Sat, 11 Oct 2003, Julien Olivier wrote: > On Sat, 2003-10-11 at 02:58, Behdad Esfahbod wrote: > > On Fri, 10 Oct 2003, Bill Nottingham wrote: > > > > > Kevin Worthington (kworthington at linuxmail.org) said: > > > > 1. Is it possible to suppress the initial "console-ish" > > > > dmesg, before the graphical interface kicks in? > > > > > > Boot with 'quiet'. > > > > I know this is too windowsish, but it would be nice if the kernel > > would boot quietly if there have been a clean shutdown. I don't > > know how to implement this cleanly yet, as if we get a panic, no > > one has removed the flag and it would boot quiet again... > > > > Hmmm... I think the best way to handle that would be to put a flag when > the computer has started cleanly and remove it when it has be shut down > cleanly. This, way, if it kernel-panics or crashes, the flag is still > there. I guess you misunderstood what I meant. I cannot see how you can handle the panics when you have no write access anywhere. The clean way to handle this is to have a bios register for that, which OS and BIOS can interact and they both would skip most diagnostics if everything is find. MS has published such a spec, called Simple Boot Flag Spec v2., it's one of those patented ones I guess. Man in a few years they would patent the concept of a "variable"... Lets wait for bios designers to implement that... behdad, From mike at theoretic.com Sat Oct 11 22:22:42 2003 From: mike at theoretic.com (Mike Hearn) Date: Sat, 11 Oct 2003 23:22:42 +0100 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065304168.2226.13.camel@dhcppc3> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> Message-ID: <1065910961.27674.60.camel@littlegreen> On Sat, 2003-10-04 at 22:49, Havoc Pennington wrote: > The solution to end-user dependency problems is very simple, and it is > the same one used on Windows. I've come late to this thread, blame freshers week at my university :) Anyway, I respectfully disagree. We're in a fundamentally different scenario to that of Win32 developers, namely that: a) We're massively outnumbered b) Linux users tend to have a lot more software installed than Windows users do c) Software is a lot more modular Simply bundling everything with the app really is not acceptable, especially for dialup users. Example: Gaim for Linux - RPM is 1.7mb (i think), Gaim for Windows - self extracting EXE with GTK+ is 6.7mb OK, so that makes little difference when you have half a megabit piped into your house or room, but it makes all the difference for the majority of the world who don't. Obviously Gaim is a program with few dependencies. Another simple example - statically linking the Jamboree gnome music player would change the size of the binary from 600k to 24mb, which is clearly insane. Now, you can say "Linux is a platform, which consists of libraries A, B and C - do not depend on anything else". That approach basically works, but is kind of difficult to force through. One mans essential library is anothers bloat, it may be that some libraries cannot commit to the ABI guarantees needed etc. I have 151 packages installed with "lib" in their name, it'd be pretty hard to get them all into even a tiered platform, though it could be done. > It's also what an LSB-compliant package _must_ do. But of course, nobody > seems to make LSB-compliant packages, instead they just complain about > how packages are distribution-dependent. ;-) People, this is the whole > point of the LSB... Well, have you tried to make an LSB compliant package? It is really quite hard. For instance, a standard compile of any non-trivial C app on RH9 will pull in the thread-local locale model stuff from glibc 2.3. You can use the lsb tools to statically link everything needed, but it really does have to be *everything*, you cannot say "well everybody has GTK, i'll skip that" - the way the tools work mean the build will fail if you link against libraries that were not LSB compiled themselves. That's not really intentional, it's just because ld wants to completely close the symbol set. We figured out a way around that with apbuild, but the LSB weren't interested of course - they *want* people to be forced to only use their base set (they need to be able to guarantee what an LSB app is and isn't). Not to mention that the LSB headers are not the same as the glibc ones, for instance I once tried to compile DBUS (i think v0.1 or something quite old now) as an LSB app to see what it was like, but the build failed due to obscure bugs in the LSB headers. Something to do with sunrpc iirc, which was wierd but there you go. I should try again sometime, as I reported the bug. Then you have to be able to make an RPMv3 package that meets their stringent restrictions etc... So back to my original example, an LSB package of Jamboree would have taken most of the day to download on a 56kbit connection, as opposed to approx 5 mins for a non-LSB package that simply depended on the right libraries. > Unfortunately, for moving around and launching you're using a .desktop > file. For install/uninstall you're using the r-c-p "comps group" concept > sometimes, and "foo.rpm" files sometimes. Yes, this is not ideal. The way I was planning to tackle this (when someday autopackage doesn't suck) was to embed package information into the .desktop file, then teach Nautilus/Konqueror about that. They could read the .desktop file, see that the relevant program was not installed and perhaps gray it out to show that it'd take some time to launch (because it'd need to be downloaded). The launcher, when clicked, takes care of download, verification, installation, dep resolution and so on. You could also use the launcher to uninstall, though the idea of garbage collecting packages appeals to me in some vague way. In this scenario you have only one concept as a user, that of "the application" (or launcher) - you can click it, email it to friends, drop it on a disk etc, and the details of what CPU arch and deps you have etc are sorted out by the system. It's kind of like the MacOS X AppFolders system UI wise, except without the massive bloat and suckyness that accompanies a pure NeXT style system. > So ways to improve this might include: > > - a way to bundle a set of RPMs into a single user-visible file, > so you can have an "uninstalled app" visible in the file manager Too large for dialup users I think :( > - have ways to install/uninstall a package by manipulating the thing > implemented now as a .desktop file (the menu/filemanager entry) Seems the easiest way forward, though it'd be easier still if there were standards for packaging. > - try to ensure packages for "end user apps" always have names that > match the primary desktop file in the package; so e.g. the Gnumeric > .rpm package would show up in file manager as "Gnumeric Spreadsheet" > and once installed you get same in menu Kind of icky. What happens if you click an installed RPM? It'd look like it should run the app, but then how do you remove it? It also relies on something that could be broken quite easily (the name mapping). > Those are just some possibilities, not well-researched proposals. The > general idea is to fix the "leakiness" of the current abstraction; > ideally, a naive end user doesn't have to learn 3 implementation details > when a single concept of "an application" should be sufficient. Right. I quite like the idea of a non-technical user browsing to frozen-bubble.org, and seeing the icon embedded in the web page. They drag it to the panel, or perhaps even just click it in the webpage directly. The button starts glowing or something to indicate that the computer is working, and the process of installation gets going in the background. When it's done, the icon goes coloured, maybe with some pretty sparkly effect to indicate "newness", and the program launches. The app is now available from the menu, the web page, can be dragged to the panel/desktop/whatever. User decides frozen bubble is really cute, and opens up their chat program and drops the icon (the application, in effect) into the chat window, where it appears the other end grayed out and the process begins again. If that other user is on PowerPC and lives the opposite end of the planet, no problems, the right download is selected from the right mirror. A lot of work, obviously, but all doable. First of all you need an easy way to build distro-neutral packages. From my experiences, I'd say the LSB is not it.... thanks -mike From elanthis at awesomeplay.com Sat Oct 11 23:14:44 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 11 Oct 2003 19:14:44 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065910961.27674.60.camel@littlegreen> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> Message-ID: <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> On Sat, 2003-10-11 at 18:22, Mike Hearn wrote: > Another simple example - statically linking the Jamboree gnome music > player would change the size of the binary from 600k to 24mb, which is > clearly insane. Statically linking isn't the answer proposed at all. Anyone trying to do that will make the situation *much* worse. I'm ASSuming Havoc meant bundling with as how many Windows apps do it - they come (metaphorically speaking) as a bundle of RPMs, and the dependencies are then installed as needed. With our world of up2date/yum/apt we don't need to bundle the dependencies. We just need to not keep breaking them so they stop working unless you recompile half the machine. i.e., if mydep 1.1 isn't API/ABI compatable with mydep 1.0, they must be coinstallable, and the library versions updated. > > Now, you can say "Linux is a platform, which consists of libraries A, B > and C - do not depend on anything else". That approach basically works, > but is kind of difficult to force through. One mans essential library is LSB is just this, and many distros are LSB compliant these days. > anothers bloat, it may be that some libraries cannot commit to the ABI > guarantees needed etc. I have 151 packages installed with "lib" in their > name, it'd be pretty hard to get them all into even a tiered platform, > though it could be done. Those that can't keep a stable ABI simply need to reflect this in some meaningful way to both developers and users - soversions and co-installable data, big warning labels, etc. > > > It's also what an LSB-compliant package _must_ do. But of course, nobody > > seems to make LSB-compliant packages, instead they just complain about > > how packages are distribution-dependent. ;-) People, this is the whole > > point of the LSB... > > Well, have you tried to make an LSB compliant package? It is really > quite hard. For instance, a standard compile of any non-trivial C app on > RH9 will pull in the thread-local locale model stuff from glibc 2.3. This sounds like it needs to be fixed; i.e., an easy way to disable that. I know apps linked against older libcs work on RH9 (usually, the occasional odd app fails, which is quite unfortunate). > > You can use the lsb tools to statically link everything needed, but it > really does have to be *everything*, you cannot say "well everybody has > GTK, i'll skip that" - the way the tools work mean the build will fail > if you link against libraries that were not LSB compiled themselves. > That's not really intentional, it's just because ld wants to completely > close the symbol set. We figured out a way around that with apbuild, but > the LSB weren't interested of course - they *want* people to be forced > to only use their base set (they need to be able to guarantee what an > LSB app is and isn't). Which is good. The LSB just needs to define more packages. But that's just LSB. LSB is, again, most useful for commercial software. When talking open-source apps, we have a lot more leeway. Namely, the upstream devs can provide the "standard". Example, so long as the GTK devs don't break their excellent track record of sane API/ABI versioning, and so long as people package it properly (which, so far, is the case on RH/Fedora), software can rely on GTK. The same goes for any other dependency in which the upstream authors apply proper release techniques. > > Not to mention that the LSB headers are not the same as the glibc ones, > for instance I once tried to compile DBUS (i think v0.1 or something > quite old now) as an LSB app to see what it was like, but the build > failed due to obscure bugs in the LSB headers. Something to do with > sunrpc iirc, which was wierd but there you go. I should try again > sometime, as I reported the bug. LSB, I should note, also isn't for low-level system stuff. It's really for monolithic apps. I don't even see the point in installing something like, say, apache, as an LSB package - its not really the target audience. > > Then you have to be able to make an RPMv3 package that meets their > stringent restrictions etc... > > So back to my original example, an LSB package of Jamboree would have > taken most of the day to download on a 56kbit connection, as opposed to > approx 5 mins for a non-LSB package that simply depended on the right > libraries. > > > Unfortunately, for moving around and launching you're using a .desktop > > file. For install/uninstall you're using the r-c-p "comps group" concept > > sometimes, and "foo.rpm" files sometimes. > > Yes, this is not ideal. The way I was planning to tackle this (when > someday autopackage doesn't suck) was to embed package information into > the .desktop file, then teach Nautilus/Konqueror about that. They could > read the .desktop file, see that the relevant program was not installed > and perhaps gray it out to show that it'd take some time to launch > (because it'd need to be downloaded). The launcher, when clicked, takes > care of download, verification, installation, dep resolution and so on. That would be interesting. The problem is, then, every single app that possibly exists in the application/dependency archive would be in the menues. Ick. While I understand the use cases, as I've said on the autopackage lists, and real Application Manager is needed (which I've some new ideas for, i'll post those to the ap list). > > You could also use the launcher to uninstall, though the idea of garbage > collecting packages appeals to me in some vague way. Which isn't really possible. The best you could do is inform the user that the system doesn't *appear* to be using the app anymore (no users have a launcher for it, if you can even determine that easily) and let them optionally uninstall it. The same is true to libraries/dependencies - sure, normal users might not need them if no other packages are using them, but hackers/admins probably have a lot of stuff installed from source. So automatic dependency "garbage" collection isn't really feasible, at least not without lots and lots of user interaction and such. > > In this scenario you have only one concept as a user, that of "the > application" (or launcher) - you can click it, email it to friends, drop > it on a disk etc, and the details of what CPU arch and deps you have etc > are sorted out by the system. > > It's kind of like the MacOS X AppFolders system UI wise, except without > the massive bloat and suckyness that accompanies a pure NeXT style > system. > > > So ways to improve this might include: > > > > - a way to bundle a set of RPMs into a single user-visible file, > > so you can have an "uninstalled app" visible in the file manager > > Too large for dialup users I think :( It could be useful for on-disk management, corporate deployment, CDs, etc. But probably not useful enough if the tools just become more intelligent; i.e., if I click on a package in Nautilus and redhat-install-packages sees I'm missing a dependency, it should try looking in the folder the main package is in to find them. That would make a lot of "off the 'net" RPM installations easier, for one. If the package could point to URLs that have a list of packages for dependency resolution, it would get even cooler (tho then GPG security and such would probably be more important - I can just see the "Trust content from Macromedia" dialogs and such one's accustomed to in Windows... but then, blindly trusting an entire distro which is community based and in which nearly anyone can eventually get access to upload packages, those incessant dialogs are probably a better approach...) > > > - have ways to install/uninstall a package by manipulating the thing > > implemented now as a .desktop file (the menu/filemanager entry) > > Seems the easiest way forward, though it'd be easier still if there were > standards for packaging. yay standards! ;-) > > > - try to ensure packages for "end user apps" always have names that > > match the primary desktop file in the package; so e.g. the Gnumeric > > .rpm package would show up in file manager as "Gnumeric Spreadsheet" > > and once installed you get same in menu > > Kind of icky. What happens if you click an installed RPM? It'd look like > it should run the app, but then how do you remove it? It also relies on > something that could be broken quite easily (the name mapping). Fortunately, the file name of an RPM is completely arbitrary. In large collections with comps file (or whatever), "specific" naming is possible; but if I want to put an RPM of some single piece of software on my site, I'm quite free to call it anything. > > Those are just some possibilities, not well-researched proposals. The > > general idea is to fix the "leakiness" of the current abstraction; > > ideally, a naive end user doesn't have to learn 3 implementation details > > when a single concept of "an application" should be sufficient. > > Right. I quite like the idea of a non-technical user browsing to > frozen-bubble.org, and seeing the icon embedded in the web page. They > drag it to the panel, or perhaps even just click it in the webpage > directly. The button starts glowing or something to indicate that the > computer is working, and the process of installation gets going in the > background. When it's done, the icon goes coloured, maybe with some > pretty sparkly effect to indicate "newness", and the program launches. Hmm, a bit farther than I had in mind, but it would certainly work; one can imagine the "RPM Installer" Mozilla plugin. ;-) If we even get to the point tho where the user can click the website icon, and the Browser pops up a "Install Application?" dialog that downloads and installs without the glitz, we'd be a long way ahead of where we are now (click icon, get RPM, watch it not work, realize some goof made the libinsane1 on OS release 2 completely incompatible with libinsane1 on OS release 1, spend time figuring out whether the lib or the app is easier to rebuild, find out the rebuild needs tons of build dependencies which the tools don't bother to grab for you, etc. etc.). > > The app is now available from the menu, the web page, can be dragged to > the panel/desktop/whatever. User decides frozen bubble is really cute, > and opens up their chat program and drops the icon (the application, in > effect) into the chat window, where it appears the other end grayed out > and the process begins again. If that other user is on PowerPC and lives > the opposite end of the planet, no problems, the right download is > selected from the right mirror. That would certainly be nifty. Really, all that would require a small .desktop-like file describing the package, and the mirror-net its on. The install app just finds a mirror, looks up the real package (and dependencies, possibly querying not only the app's mirror but also the distro's repository), etc. Heck, I think there are a couple (not nearly done) apps that do just this, minus the high-level of desktop integration. > > A lot of work, obviously, but all doable. First of all you need an easy > way to build distro-neutral packages. From my experiences, I'd say the > LSB is not it.... Agreed. Most of the responsibility has to lay with the upstream developers. If the authors of libfoobar are goofs and refuse to put the 3 seconds of effort forth to make their software at least co-installable with other versions, than any upstream dev who relies on libfoobar is just as guilty of bad practices. A good guide on packaging might help resolve a number of such situation. One of the biggest problems with RPMs isn't even that the software is actually incompatible, just that the packaging *makes* it incompatible; packages putting things in different locations, packages that conflict with each other in order to provide different optional featuresets (why in all the world should a user have to unisntall an app to add features? sounds dumb, but yet we have to do it many times, because make packages like someapp-nofeatures, someapp-feature1, someapp-feature2, someapp-allfeatures, etc. not necessary!) Evangelism on the importance of proper development practices could be useful, too. Probably the only place I've seen describing library versioning in detail is the innards of the libtool manual. No wonder lots of devs don't do it right, eh? Something like the war on drugs is needed: DARP, Developers Against Ramshackle Packages. ;-) > > thanks -mike > > > -- > 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 Nicolas.Mailhot at laPoste.net Sat Oct 11 23:40:04 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 12 Oct 2003 01:40:04 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065910961.27674.60.camel@littlegreen> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> Message-ID: <1065915603.3181.70.camel@rousalka.dyndns.org> Le dim 12/10/2003 ? 00:22, Mike Hearn a ?crit : > Right. I quite like the idea of a non-technical user browsing to > frozen-bubble.org, and seeing the icon embedded in the web page. They > drag it to the panel, or perhaps even just click it in the webpage > directly. The button starts glowing or something to indicate that the > computer is working, and the process of installation gets going in the > background. When it's done, the icon goes coloured, maybe with some > pretty sparkly effect to indicate "newness", and the program launches. Yeah and when you've done this you've also got virus, trojans, worms and general system instability. You can not trust just any random web page/gpg key/packager/whatever. Distributions provide quality packaging, software review, system consistency, etc (that's one of the reasons all the distributed software projects that were proposed won't ever fly IMHO - there is no way so many different actors with different priorities, backgrounds, deadlines, etc can agree on a common set of rules strong enough to maintain the overall quality a current distribution provides) Now in the past one could say distros do not cover a large enough spectrum. With projects like Fedora this is no longer true - you want your app in Fedora just submit a quality package and it'll get in. Then people will install it because they *trust* the Fedora signature/label. Making a quality package is *hard*. Computer systems are *complex*. And working outside of a big distribution-like project only makes packaging *harder*. Most of people who complain just want to offload crap packages on the user like in the windows world. As someone who is regularly called to clean up the damage these habits cause I respectfully disagree. It says a lot that an experimental system like Rawhide often behaves better than your average windows setup. If you want to enlarge the packaged perimeter just mount a packager group on which upstream projects can offload packaging problems. If you think distributions are the problem (like autopackage people obviously do) just get all people that think like you together and have them agree on a common distribution method. I predict that the best outcome will be yet another distribution (and the probable one utter failure - people who don't want to package stuff cleanly now won't do it tomorrow in another organisation) There is one point I agree with you - it'd be cool if upstream projects could more easily provide install profiles so people can use their stuff after reading the web site. And this can be done pretty easily by a comps.xml adaptation that would be fed to the local apt/yum/urpm that would then pull relevant package_s_ from the *distribution* repository. (and yes the package/profile separation is needed. I want to be able to provide a artist profile and a tester profile, for example, and they will both include the gimp package, because testers need to provide annotated screenshots too) And while there is room for gfx effects the core engine must be CLI/GUI independent. I can assure you after the second installation you quickly tire of the bloody widgets and yearn after something you can just run in a ssh window/crontab/script. People will probably want to collect all the profiles they commonly use on a floppy and feed all of them in a single operation to the package manager of their new computer. (think "modular kickstart") > The app is now available from the menu, the web page, can be dragged to > the panel/desktop/whatever. User decides frozen bubble is really cute, > and opens up their chat program and drops the icon (the application, in > effect) into the chat window, where it appears the other end grayed out > and the process begins again. If that other user is on PowerPC and lives > the opposite end of the planet, no problems, the right download is > selected from the right mirror. > > A lot of work, obviously, but all doable. First of all you need an easy > way to build distro-neutral packages. From my experiences, I'd say the > LSB is not it.... There is no easy way. You want to do distro-neutral packages ? Fine. Just be damn good. The day someone in one of your target distros release a better package than yours poof you've instantly lost part of your target audience. Remember : distro-specific packagers have this advantage they can use all kind of fun "extensions" when you can't. Realistically that means : 1. do not try to repackage stuff that's already in the distributions 2. follow strictly FHS and the parts of LSB that make sense - be stricter than the others packagers you'll compete with 3. package a large enough pool of interdependent software people won't be able to take "just one bit" and make it distro-specific easily 4. have a team with people that regularly use all target distros 5. use file names not package names as dependencies - distros will rename/split/merge packages but the FHS will force them to use the same file locations 6. use an apt+yum+urpmi repository to reach as much people as possible 7. whenever disto X has cool extension Y you want to use gently push Y for inclusion in the other target distributions 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 hp at redhat.com Sat Oct 11 23:40:14 2003 From: hp at redhat.com (Havoc Pennington) Date: 11 Oct 2003 19:40:14 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065910961.27674.60.camel@littlegreen> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> Message-ID: <1065915613.21825.44.camel@dhcppc3> On Sat, 2003-10-11 at 18:22, Mike Hearn wrote: > Simply bundling everything with the app really is not acceptable, > especially for dialup users. Example: Gaim for Linux - RPM is 1.7mb (i > think), Gaim for Windows - self extracting EXE with GTK+ is 6.7mb Oh, I agree. Nonetheless it's a solution to "dependency hell." My argument: there's a tradeoff. One shouldn't whine about dependencies unless you can live with duplication. Because you win one or the other and you may as well suck it up and live with this reality. > Now, you can say "Linux is a platform, which consists of libraries A, B > and C - do not depend on anything else". Right, this is what I mean by the placeholder term "LSB." LSB in practice is lagging the actual platform people want to use by quite a bit and seems to have some implementation issues as you mentioned. But LSB is only one possible token of the type "define a core guaranteed dependency set that will always exist, and apps must internalize anything not in that core set" - which is the general approach for avoiding "dependency hell" used by Windows/Mac. To clarify dependency hell; if by that one simply means having to find dependencies and install them, then you either internalize non-core-platform deps, or you have external dependencies. That tradeoff will never go away. Best you can do is have tools such as yum/up2date/apt to simplify things. If by dependency hell one means having to choose between set of apps requiring library Foo version 1 and set of apps requiring library Foo version 2, the solution to that is also known: http://ometer.com/parallel.html and/or "compat" packages and soname changes. Unfortunately the upstream maintainers of many libraries are uncooperative when it comes to solving this problem. Some people seem to think there's a magic bullet here or that solutions aren't known. I would say the solutions and tradeoffs _are_ known, and people are just unwilling to accept them. I don't believe the packaging format (RPM vs. whatever) has a *thing* to do with it. RPM allows you to express dependencies to automated tools. However, it doesn't _create_ the dependencies; you are free to have them or not as you see fit. So blaming dependency hell on RPM is just shooting the messenger. Havoc From blocke at shivan.org Sun Oct 12 05:39:54 2003 From: blocke at shivan.org (Bruce A. Locke) Date: Sun, 12 Oct 2003 01:39:54 -0400 Subject: gtkmm? Message-ID: <1065937194.417.3.camel@kodiak.shivan.org> I was attempting to build some RPMs to try out fwbuilder when I noticed RedHat/Fedora still does not appear to provide gtkmm. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82473 Any reason not to include it these days? Thanks. -- --------------------------------------------------------------------- Bruce A. Locke blocke at shivan.org From michael at koziarski.com Sun Oct 12 07:59:19 2003 From: michael at koziarski.com (Michael A. Koziarski) Date: Sun, 12 Oct 2003 20:59:19 +1300 Subject: gtkmm? In-Reply-To: <1065937194.417.3.camel@kodiak.shivan.org> References: <1065937194.417.3.camel@kodiak.shivan.org> Message-ID: <3F8909D7.1030502@koziarski.com> Bruce A. Locke wrote: >I was attempting to build some RPMs to try out fwbuilder when I noticed >RedHat/Fedora still does not appear to provide gtkmm. > >http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82473 > >Any reason not to include it these days? > >Thanks. > > > We're currently working on getting gtkmm into fedora, if you'd like to jump the gun, there's a .src.rpm available at http://www.koziarski.org/gtkmm2-2.2.8-0.fdr.3.src.rpm Linked from https://bugzilla.fedora.us/show_bug.cgi?id=727. I'd appreciate any reports of success or failure. Cheers Koz From windi at myrealbox.com Sun Oct 12 09:12:18 2003 From: windi at myrealbox.com (Stephan Windischmann) Date: Sun, 12 Oct 2003 11:12:18 +0200 Subject: Suggestions for the Installer (regarding network installs) Message-ID: <1065949938.1417.15.camel@homer.home> Recently, I installed the Fedora beta on my laptop to replace Debian unstable, and since I'm not going to download 3 ISO's on my 128kbit connection, I decided to try the netinstall using the 4MB boot.iso. It seems as if the netinstall function is only there as an afterthought (or maybe I'm just used to Debian). Instead of a 4MB boot CD that has to download the installer itself, a dedicated Fedora Netinstall CD (~100-150MB) that has the graphical installer and perhaps a minimal file system on it would be really helpful for those that don't want to get all 3 CD's. Having to enter the FTP mirror details by hand isn't especially user friendly either, and it doesn't really fit together with the rest of the Fedora installer, which is excellent. Also, would it be possible to do a netinstall of rawhide directly, instead of having to first install the latest beta/release and then upgrading to it? I'm a software version junky. ;) Enough ramblings for now. -windi From Nicolas.Mailhot at laPoste.net Sun Oct 12 09:37:29 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 12 Oct 2003 11:37:29 +0200 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <1065949938.1417.15.camel@homer.home> References: <1065949938.1417.15.camel@homer.home> Message-ID: <1065951449.25340.7.camel@rousalka.dyndns.org> Le dim 12/10/2003 ? 11:12, Stephan Windischmann a ?crit : > Recently, I installed the Fedora beta on my laptop to replace Debian > unstable, and since I'm not going to download 3 ISO's on my 128kbit > connection, I decided to try the netinstall using the 4MB boot.iso. > > It seems as if the netinstall function is only there as an afterthought > (or maybe I'm just used to Debian). Netinstall is *old*. It's used by the kind of people who deeply despise gfx effects so there has not been many calls to "enhance" it I think. > Instead of a 4MB boot CD that has to download the installer itself, a > dedicated Fedora Netinstall CD (~100-150MB) that has the graphical > installer and perhaps a minimal file system on it would be really > helpful for those that don't want to get all 3 CD's. I have a foggy memory of it only needing a few floppies in RH 5.2 time > Having to enter the FTP mirror details by hand isn't especially user > friendly either, and it doesn't really fit together with the rest of the > Fedora installer, which is excellent. This means you can use your own local intranet ftp serveur for network installations, which is good(tm). How would you do it with debian ? > Also, would it be possible to do a netinstall of rawhide directly, > instead of having to first install the latest beta/release and then > upgrading to it? I'm a software version junky. ;) I think in theory you might, in the real world it's always a good idea to start with a working system before rawhidizing it;). (don't be fooled by rawhide current state - it's always gentler at beta time) 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 buildsys at porkchop.devel.redhat.com Sun Oct 12 09:42:32 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sun, 12 Oct 2003 05:42:32 -0400 Subject: rawhide report: 20031012 changes Message-ID: <200310120942.h9C9gWq29478@porkchop.devel.redhat.com> Updated Packages: bind-9.2.2.P3-8 --------------- * Sun Oct 12 2003 Florian La Roche - do not link against libnsl, not needed for Linux coreutils-5.0-24 ---------------- * Sun Oct 12 2003 Florian La Roche - allow compiling without pam support rawhide-release-20031012-1 -------------------------- vsftpd-1.2.0-5 -------------- * Sun Oct 12 2003 Florian La Roche - allow compiling without tcp_wrappers support xinetd-2.3.12-4.10.0 -------------------- * Sun Oct 12 2003 Florian La Roche - allow compiling without tcp_wrappers From mkt2022 at hotmail.com Sun Oct 12 10:23:26 2003 From: mkt2022 at hotmail.com (mako20) Date: Sun, 12 Oct 2003 19:23:26 +0900 Subject: =?iso-2022-jp?B?GyRCJUclIyU5JVclbCUkJUklaSUkJVAkSzRYJDckRhsoQg==?= Message-ID: ???????? ??PC?FMV?CE22D ????? ????????????SiS 740????????? ?TEXT?????????????(???????????)?????????? ?????????????????? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkt2022 at hotmail.com Sun Oct 12 10:29:34 2003 From: mkt2022 at hotmail.com (mako20) Date: Sun, 12 Oct 2003 19:29:34 +0900 Subject: For display driver Message-ID: Those who contribute: UEDA MAKOTO PC:FMV CE22D contribution: Though the display driver (sisters 740) is recognized It doesn't correspond to a graphic display though it is displayed in the installation (text of the content of the start) by the text option. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at theoretic.com Sun Oct 12 13:07:44 2003 From: mike at theoretic.com (Mike Hearn) Date: Sun, 12 Oct 2003 14:07:44 +0100 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065915613.21825.44.camel@dhcppc3> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065915613.21825.44.camel@dhcppc3> Message-ID: <1065964064.3038.7.camel@littlegreen> On Sun, 2003-10-12 at 00:40, Havoc Pennington wrote: > which is the general approach for > avoiding "dependency hell" used by Windows/Mac. Mmm. I have a feeling it simply replaces it with other types of hell. On MacOS X the glacial rollout of weak symbols mean that apps frequently depend on point releases of the whole OS. On Windows, the situation is somewhat better, but only because Microsoft release updates for OSs that are over 5 years old. > To clarify dependency hell; if by that one simply means having to find > dependencies and install them, then you either internalize > non-core-platform deps, or you have external dependencies. That tradeoff > will never go away. Best you can do is have tools such as > yum/up2date/apt to simplify things. Of course that's correct, but the problem is people have used tools like apt and see that they work well, and are convenient. They want them to work well all the time, instead of just some of the time. I think boosting the success rate of these types of tools is certainly doable. > If by dependency hell one means having to choose between set of apps > requiring library Foo version 1 and set of apps requiring library Foo > version 2, the solution to that is also known: > http://ometer.com/parallel.html and/or "compat" packages and soname > changes. Right - I wasn't really meaning this, but parallel installability is clearly an educational issue. > I don't believe the packaging format (RPM vs. whatever) has a *thing* to > do with it. RPM allows you to express dependencies to automated tools. > However, it doesn't _create_ the dependencies; you are free to have them > or not as you see fit. So blaming dependency hell on RPM is just > shooting the messenger. It's reasonable that RPM gets beat up a bit - this particular messenger sometimes gets it wrong (for instance when you install from source). Perhaps some of the blame lies with developers for going overboard with dependencies, but perhaps also it is up to us to technically manage this situation better (which I think can be done). thanks -mike From mike at theoretic.com Sun Oct 12 13:54:29 2003 From: mike at theoretic.com (Mike Hearn) Date: Sun, 12 Oct 2003 14:54:29 +0100 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065915603.3181.70.camel@rousalka.dyndns.org> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065915603.3181.70.camel@rousalka.dyndns.org> Message-ID: <1065966868.3051.55.camel@littlegreen> On Sun, 2003-10-12 at 00:40, Nicolas Mailhot wrote: > Yeah and when you've done this you've also got virus, trojans, worms and > general system instability. Consider: somebody wishes to play a game. It is written in C. There is no package for their distribution. They can either: a) Not play it. b) Create a package, submit it to Fedora, ram it through the QA process etc c) Install from source and just play it. Realistically, the vast majority will choose (c), and this is the situation we are in now. It's really easy to get viruses, worms and trojans into a system using source packages - a typical configure script can be >100,000 lines long. So, not having a package at all is probably more harmful in this respect than having a binary package produced by the team that made the game. > You can not trust just any random web page/gpg key/packager/whatever. Well, people can and do every day. The number of people who get viruses/worms/whatever from bad installers on Windows is really low - it almost invariably comes in through email or spyware in the apps itself. Fedora QA does not actually audit the app obviously, just the package, so it won't catch spyware embedded in the app. > Now in the past one could say distros do not cover a large enough > spectrum. With projects like Fedora this is no longer true - you want > your app in Fedora just submit a quality package and it'll get in. 99% of users cannot, will not package things. They will install things in the easiest way possible, or leave the platform altogether if it's too hard. Fedora cannot and will not package every piece of software in the world, and keep it at the latest version. Debian has never managed it, I see no reason to believe this time will be any different. > Making a quality package is *hard*. Computer systems are *complex*. And > working outside of a big distribution-like project only makes packaging > *harder*. Writing quality software is far harder than writing quality packages, yet somehow people manage. I don't see any reason why the same people who create the software in the first place (and presumably the website and documentation) cannot also create quality packages. Of course you will get bad packages just as you get bad software, but this is life. > If you think distributions are the problem (like autopackage people > obviously do) No, I don't know why you think that. We think distributions attempting to package every piece of software they can is a problem, because it doesn't scale. Windows and MacOS do not try this, neither should we. Packaging is as much an integral part of building software as writing documentation, test cases or the website is - there's no reason for it to be separated. > There is one point I agree with you - it'd be cool if upstream projects > could more easily provide install profiles so people can use their stuff > after reading the web site. And this can be done pretty easily by a > comps.xml adaptation that would be fed to the local apt/yum/urpm that > would then pull relevant package_s_ from the *distribution* repository. And if it isn't there? The user is still screwed. Worse, you get a bent market - people will use Red Hat, Debian, SuSE or whatever not because they are the best, but because there are more packages available for that distribution. Clearly this is not desirable - look at the problems caused by the apps market being distorted. > And while there is room for gfx effects the core engine must be CLI/GUI > independent. Sure. It already is. > There is no easy way. > You want to do distro-neutral packages ? Fine. > Just be damn good. > The day someone in one of your target distros release a better package > than yours poof you've instantly lost part of your target audience. > > Remember : distro-specific packagers have this advantage they can use > all kind of fun "extensions" when you can't. Sure, and this is acknowledged in the FAQ - I'm not saying distro-specific packages are bad, just that *only* having distro packages is bad. If somebody wants to produce a Fedora only package that uses cool extensions, more power to them - I'll probably use it. thanks -mike From jfm512 at free.fr Sun Oct 12 14:40:43 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 12 Oct 2003 16:40:43 +0200 Subject: Fedora and RedHat's autism toward personal users Message-ID: <1065969643.2836.25.camel@agnes.fremen.dune> Probably because RedHat thought that personal users wouldn't buy support it has ever tended to neglect them: let's remember the good old times where RedHat ignored dial-up users and assumed everyone was on Ethernet. :-)

In RedHat 9 we still have no tools to configure ADSL modems on USB and it still does not provide for masquerading. Software selection also tends to be quite austere. Since Fedora is a community project and doesn't have the same constraints than RedHat (make PAYING users happy or bankrupt) I think it would be time to pay more attention to personal users through solving their specific problems (see above) and with a sexier, funnier software selection. One of this would be Blender. Also take a look at what is included in Mandrake BTW I am NOT for advocating for including every piece of cr.p, like Debian does (in an ideal world Feddora would include only one program for a task: the best one, in real world it is more complex) and I am quite conscious that it is not possible to cover every need in world. -- Jean Francois Martinez From alan at redhat.com Sun Oct 12 15:12:57 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 12 Oct 2003 11:12:57 -0400 (EDT) Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065966868.3051.55.camel@littlegreen> from "Mike Hearn" at Hyd 12, 2003 02:54:29 Message-ID: <200310121512.h9CFCvT18539@devserv.devel.redhat.com> > Well, people can and do every day. The number of people who get > viruses/worms/whatever from bad installers on Windows is really low - it > almost invariably comes in through email or spyware in the apps itself. Don't lose sight of the fact viruses and worms evolve (or are evolved) to target the fundamental weaknesses that work. Right now they tend to target tools like windows email because the mailer was a weak link, and the user too. When that ceases to be the weak link you'll see techniques change - as is happening with spyware for example. In the long term the user may not be the weak link either - SELinux type stuff lets the administrator shield users from many of the mistakes they would otherwise make. Alan From mike at theoretic.com Sun Oct 12 15:56:54 2003 From: mike at theoretic.com (Mike Hearn) Date: Sun, 12 Oct 2003 16:56:54 +0100 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> Message-ID: <1065974214.3037.81.camel@littlegreen> On Sun, 2003-10-12 at 00:14, Sean Middleditch wrote: > LSB is just this, and many distros are LSB compliant these days. Yeah, but LSB is really really LCD. No GUI libs (yet) for instance. > This sounds like it needs to be fixed; i.e., an easy way to disable > that. I know apps linked against older libcs work on RH9 (usually, the > occasional odd app fails, which is quite unfortunate). That's what apbuild/apgcc do - ideally of course upgrading glibc would be just like any other library but for some reason it isn't, so we have to wind back the clock a little bit. Fortunately thread-local locales is a features mostly useful for servers I think, so client side apps don't need to worry about losing it. > That would be interesting. The problem is, then, every single app that > possibly exists in the application/dependency archive would be in the > menues. Ick. No, only stuff the user had installed. > While I understand the use cases, as I've said on the autopackage lists, > and real Application Manager is needed (which I've some new ideas for, > i'll post those to the ap list). Please do so. I'm not sold that we need any specific app management program - it's the sort of thing users just never think about (much like uninstalling stuff they no longer use). > Which isn't really possible. The best you could do is inform the user > that the system doesn't *appear* to be using the app anymore (no users > have a launcher for it, if you can even determine that easily) and let > them optionally uninstall it. > > The same is true to libraries/dependencies - sure, normal users might > not need them if no other packages are using them, but hackers/admins > probably have a lot of stuff installed from source. So automatic > dependency "garbage" collection isn't really feasible, at least not > without lots and lots of user interaction and such. Maybe.... still, it's been done in Java/C# for ages, despite the difficulties. It seems unintuitive that it's possible with objects but not packages. > Evangelism on the importance of proper development practices could be > useful, too. Probably the only place I've seen describing library > versioning in detail is the innards of the libtool manual. No wonder > lots of devs don't do it right, eh? Something like the war on drugs is > needed: DARP, Developers Against Ramshackle Packages. ;-) Yeah, I want to do this too at some point, probably as part of the packagers/developers guide we're writing for AP. There is a good paper by Ulrich Drepper on writing DSOs, but it's basically impossible to find unless somebody shows you. Other bad techniques are compile time options, non-relocatability and so on. Developer education is definately a part of the solution. thanks -mike From Nicolas.Mailhot at laPoste.net Sun Oct 12 16:51:44 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 12 Oct 2003 18:51:44 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065974214.3037.81.camel@littlegreen> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> <1065974214.3037.81.camel@littlegreen> Message-ID: <1065977504.2687.26.camel@rousalka.dyndns.org> Le dim 12/10/2003 ? 17:56, Mike Hearn a ?crit : > On Sun, 2003-10-12 at 00:14, Sean Middleditch wrote: > > That would be interesting. The problem is, then, every single app that > > possibly exists in the application/dependency archive would be in the > > menues. Ick. > > No, only stuff the user had installed. Please keep unstalling/uninstalling out of menus. Windows only does it because for a long time they installation manager panel missed most apps (and still misses some of them). So people had to put uninstall links somewhere else. Really it's amazing how people forget history and comme to accept ugly workarounds as the natural way to do things. We don't need no windowish in-your-face uninstall solutions, we don't need popup eulas, change-install-location dialogs, here-is-the-disc-size-I-need-please-check windows, you-think-I'm-installed-but-check-my-20-pages-readme popups, don't-bother-with-permissions-and-run-everything-as-admin (I case people wonder - I've just documented the installation of an app that used a custom installer clearly written by a brainwashed monopolysoft user. Just documenting this single installation took as many pages as the ones devoted to updating the whole multi-hundred rpm system) Anyway I don't know why I bother - just do your thing and I'll watch HiG people shot it down. > > While I understand the use cases, as I've said on the autopackage lists, > > and real Application Manager is needed (which I've some new ideas for, > > i'll post those to the ap list). > > Please do so. I'm not sold that we need any specific app management > program - it's the sort of thing users just never think about (much like > uninstalling stuff they no longer use). Sure - why use a single consistent working solution when you can let everyone reinvent incompatible wheels ? > > Which isn't really possible. The best you could do is inform the user > > that the system doesn't *appear* to be using the app anymore (no users > > have a launcher for it, if you can even determine that easily) and let > > them optionally uninstall it. > > > > The same is true to libraries/dependencies - sure, normal users might > > not need them if no other packages are using them, but hackers/admins > > probably have a lot of stuff installed from source. So automatic > > dependency "garbage" collection isn't really feasible, at least not > > without lots and lots of user interaction and such. > > Maybe.... still, it's been done in Java/C# for ages, despite the > difficulties. It seems unintuitive that it's possible with objects but > not packages. Well I can tell you we have *nothing* to learn from java packaging, quite the contrary. In fact the java world right now is a motherload of bad packaging examples. > > Evangelism on the importance of proper development practices could be > > useful, too. Probably the only place I've seen describing library > > versioning in detail is the innards of the libtool manual. No wonder > > lots of devs don't do it right, eh? Something like the war on drugs is > > needed: DARP, Developers Against Ramshackle Packages. ;-) > > Yeah, I want to do this too at some point, probably as part of the > packagers/developers guide we're writing for AP. There is a good paper > by Ulrich Drepper on writing DSOs, but it's basically impossible to find > unless somebody shows you. Other bad techniques are compile time > options, non-relocatability and so on. Developer education is definately > a part of the solution. Developer education will *always* be a problem. Developing and packaging are just two different CS specialities (just like developing and QA). Some people will do both, most won't, expecting every single developer to be able to package things is just a recipe for bad packaging. 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 Sun Oct 12 16:55:42 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 12 Oct 2003 18:55:42 +0200 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <1065969643.2836.25.camel@agnes.fremen.dune> References: <1065969643.2836.25.camel@agnes.fremen.dune> Message-ID: <1065977742.2687.31.camel@rousalka.dyndns.org> Le dim 12/10/2003 ? 16:40, Jean Francois Martinez a ?crit : > BTW I am NOT for advocating for including every piece of cr.p, like > Debian does (in an ideal world Feddora would include only one program > for a task: the best one, in real world it is more complex) and I am > quite conscious that it is not possible to cover every need in world. Just allow only well-packaged software in the repository and people won't bother packaging crap (since crap is usually more difficult to package properly) -- 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 thomas at apestaart.org Sun Oct 12 20:19:23 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 12 Oct 2003 22:19:23 +0200 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <1065969643.2836.25.camel@agnes.fremen.dune> References: <1065969643.2836.25.camel@agnes.fremen.dune> Message-ID: <1065989939.2257.24.camel@ana.onshuis> On Sun, 2003-10-12 at 16:40, Jean Francois Martinez wrote: > Probably because RedHat thought that personal users wouldn't buy > support it has ever tended to neglect them: let's remember > the good old times where RedHat ignored dial-up users and assumed > everyone was on Ethernet. :-) >

One suggestion in getting anywhere is to lay off the negativity. Your mail did not make me want to read much in the rest of it, but I pressed on still. > Since Fedora is a community project and doesn't have the same > constraints than RedHat (make PAYING users happy or bankrupt) I > think it would be time to pay more attention to personal users > through solving their specific problems (see above) and with a sexier, > funnier software selection. One of this would be Blender. Also take > a look at what is included in Mandrake Blender isn't very sexy UI-wise and hard to integrate desktop-wise. > BTW I am NOT for advocating for including every piece of cr.p, like > Debian does (in an ideal world Feddora would include only one program > for a task: the best one, in real world it is more complex) and I am > quite conscious that it is not possible to cover every need in world. Your actual help will get all of us quite far along. Start with specific bits to work on, it will get us there quicker :) Thomas Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> Cos I feel like a fake when I feel any feeling And I wouldn't wanna happen to you Cos I know that you mean it <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From jfm512 at free.fr Sun Oct 12 20:25:53 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 12 Oct 2003 22:25:53 +0200 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <1065977742.2687.31.camel@rousalka.dyndns.org> References: <1065969643.2836.25.camel@agnes.fremen.dune> <1065977742.2687.31.camel@rousalka.dyndns.org> Message-ID: <1065990353.2836.66.camel@agnes.fremen.dune> On Sun, 2003-10-12 at 18:55, Nicolas Mailhot wrote: > Le dim 12/10/2003 ? 16:40, Jean Francois Martinez a ?crit : > > > BTW I am NOT for advocating for including every piece of cr.p, like > > Debian does (in an ideal world Feddora would include only one program > > for a task: the best one, in real world it is more complex) and I am > > quite conscious that it is not possible to cover every need in world. > > Just allow only well-packaged software in the repository and people > won't bother packaging crap (since crap is usually more difficult to > package properly) > Not necessarily. I was thinking in the web servers in an old Debian. There were six of them: -Apache of course. -Boa because it was faster than Apache -Another one whose main merit was to be zero conf And three other ones I don't remember but who had no particular merit (one of them being the obsolete NCSA server). I don't doubt they have more than six by now When you put six programs for the same task you end noticing 1) that after a time some of them are no longer maintained: keeping them in the distro becomes increasingly difficult as the programs fall back behind the libraries, compiler and kernel. This also means nobody is checking that it remains state of the art for security (eg the problem of formatted strings). But the people who are using them because "it was in the distro" (ie it is partly your fault) won't be happy if you remove them 2) That six programs doing the same thing means six times more resources spent at packaging them and six times more security problems. 3) That some features lose most of their importance: zero conf when Apache gets a simple configurator, speed when a 500$ machine has three times more power than needed. 4) That users get headaches while shifting through six web servers, twenty window managers and thirty editors -- Jean Francois Martinez From elanthis at awesomeplay.com Sun Oct 12 20:59:45 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 12 Oct 2003 16:59:45 -0400 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <1065990353.2836.66.camel@agnes.fremen.dune> References: <1065969643.2836.25.camel@agnes.fremen.dune> <1065977742.2687.31.camel@rousalka.dyndns.org> <1065990353.2836.66.camel@agnes.fremen.dune> Message-ID: <1065992385.24534.3.camel@stargrazer.home.awesomeplay.com> On Sun, 2003-10-12 at 16:25, Jean Francois Martinez wrote: > On Sun, 2003-10-12 at 18:55, Nicolas Mailhot wrote: > > Le dim 12/10/2003 ? 16:40, Jean Francois Martinez a ?crit : > > > > > BTW I am NOT for advocating for including every piece of cr.p, like > > > Debian does (in an ideal world Feddora would include only one program > > > for a task: the best one, in real world it is more complex) and I am > > > quite conscious that it is not possible to cover every need in world. > > > > Just allow only well-packaged software in the repository and people > > won't bother packaging crap (since crap is usually more difficult to > > package properly) > > > > Not necessarily. I was thinking in the web servers in an old Debian. > There were six of them: -Apache of course. -Boa because it was > faster than Apache -Another one whose main merit was to be zero conf > And three other ones I don't remember but who had no particular merit > (one of them being the obsolete NCSA server). I don't doubt they have > more than six by now > > When you put six programs for the same task you end noticing 1) that > after a time some of them are no longer maintained: keeping them in > the distro becomes increasingly difficult as the programs fall back > behind the libraries, compiler and kernel. This also means nobody is > checking that it remains state of the art for security (eg the problem > of formatted strings). But the people who are using them because "it > was in the distro" (ie it is partly your fault) won't be happy if you > remove them > > 2) That six programs doing the same thing means six times more resources > spent at packaging them and six times more security problems. > > 3) That some features lose most of their importance: zero conf when > Apache gets a simple configurator, speed when a 500$ machine has three > times more power than needed. > > 4) That users get headaches while shifting through six web servers, > twenty window managers and thirty editors and 5) over-engineering in the distro to accomodate all these alternatives. Debian had several sick sub-systems for handling 3 versions of the 'more' command, alnog with the obscene number of versions of apps for web browsing, mail, help, compilers, awks, seds, tars, etc. This is because those alternatives weren't addons or replacements, but in fact parts of the OS itself; i.e., the OS wasn't built for, say, Mozilla for browsing, or any of the other browsers as an optional add-on, but instead was built for *any* browser at all. The configuration, package management, and existance of sub-systems like the 'alternatives' section just shows how much work went into dealing with a sub-optimal situation. -- Sean Middleditch AwesomePlay Productions, Inc. From Nicolas.Mailhot at laPoste.net Sun Oct 12 21:04:20 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 12 Oct 2003 23:04:20 +0200 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <1065990353.2836.66.camel@agnes.fremen.dune> References: <1065969643.2836.25.camel@agnes.fremen.dune> <1065977742.2687.31.camel@rousalka.dyndns.org> <1065990353.2836.66.camel@agnes.fremen.dune> Message-ID: <1065992660.4413.12.camel@rousalka.dyndns.org> Le dim 12/10/2003 ? 22:25, Jean Francois Martinez a ?crit : > On Sun, 2003-10-12 at 18:55, Nicolas Mailhot wrote: > > Le dim 12/10/2003 ? 16:40, Jean Francois Martinez a ?crit : > > > > > BTW I am NOT for advocating for including every piece of cr.p, like > > > Debian does (in an ideal world Feddora would include only one program > > > for a task: the best one, in real world it is more complex) and I am > > > quite conscious that it is not possible to cover every need in world. > > > > Just allow only well-packaged software in the repository and people > > won't bother packaging crap (since crap is usually more difficult to > > package properly) > > > > Not necessarily. I was thinking in the web servers in an old Debian. But often yes. Postfix for example is archetypal of a program that's a pleasure to secure, use, configure *and* build/package [..] > When you put six programs for the same task you end noticing 1) that > after a time some of them are no longer maintained: ie they're not worthy enough for someone to package them correctly -> just kick them out until someone repackages a current version. That's evolution at work. (and I'm not advocating this for RH, obviously RH ES will only include selected components, but for a volunteer/community project like Fedora the only road to go and stay in should be package quality. You can write all the roadmaps you want people will work on what they're interested in period) Users will have to change whether you keep one or twenty apps in the repository -> see the one true Gnome WM saga, which was enlightement, then sawfish, and now metacity. 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 Sun Oct 12 21:05:28 2003 From: julo at altern.org (Julien Olivier) Date: Sun, 12 Oct 2003 22:05:28 +0100 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065977504.2687.26.camel@rousalka.dyndns.org> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> <1065974214.3037.81.camel@littlegreen> <1065977504.2687.26.camel@rousalka.dyndns.org> Message-ID: <1065992727.4411.1.camel@localhost.localdomain> (snip) > Well I can tell you we have *nothing* to learn from java packaging, > quite the contrary. In fact the java world right now is a motherload of > bad packaging examples. > I think Mike was talking of Java's memory management (automatic removal of unused objects), not package management. I could be wrong though... From paul at gear.dyndns.org Sun Oct 12 21:10:24 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Mon, 13 Oct 2003 07:10:24 +1000 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <1065992385.24534.3.camel@stargrazer.home.awesomeplay.com> References: <1065969643.2836.25.camel@agnes.fremen.dune> <1065977742.2687.31.camel@rousalka.dyndns.org> <1065990353.2836.66.camel@agnes.fremen.dune> <1065992385.24534.3.camel@stargrazer.home.awesomeplay.com> Message-ID: <3F89C340.7040506@gear.dyndns.org> Sean Middleditch wrote: > ... > and 5) over-engineering in the distro to accomodate all these > alternatives. Debian had several sick sub-systems for handling 3 > versions of the 'more' command, alnog with the obscene number of > versions of apps for web browsing, mail, help, compilers, awks, seds, > tars, etc. This is because those alternatives weren't addons or > replacements, but in fact parts of the OS itself; i.e., the OS wasn't > built for, say, Mozilla for browsing, or any of the other browsers as an > optional add-on, but instead was built for *any* browser at all. The > configuration, package management, and existance of sub-systems like the > 'alternatives' section just shows how much work went into dealing with a > sub-optimal situation. A web browser is quite a bit different from a web server, or tar/awk/more/etc. You need to support a wide variety of browsers, because it is an personal decision (i get really annoyed when i have to switch from Galeon to anything), and you need to support multiple browsers per system, since multiple people might different ones (at once on large systems). But you can only run one web server or mail server at once (at least on the standard ports), and it makes sense to limit the number of this type of packages. -- Paul http://paulgear.webhop.net A: Because we read from top to bottom, left to right. Q: Why should i start my 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 rok.papez at lugos.si Sun Oct 12 21:20:33 2003 From: rok.papez at lugos.si (Rok =?iso-8859-15?q?Pape=B8?=) Date: Sun, 12 Oct 2003 23:20:33 +0200 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <1065990353.2836.66.camel@agnes.fremen.dune> References: <1065969643.2836.25.camel@agnes.fremen.dune> <1065977742.2687.31.camel@rousalka.dyndns.org> <1065990353.2836.66.camel@agnes.fremen.dune> Message-ID: <200310122320.33929.rok.papez@lugos.si> Hello. Dne nedelja 12 oktober 2003 22:25 je Jean Francois Martinez napisal(a): > 4) That users get headaches while shifting through six web servers, > twenty window managers and thirty editors UNIX is about choice. Obsolete product have less and less users and they get dropped. Developing software is about evolution, not revolution. And at any time of it.. you have products that are at the peak of their life cycle, at the beginning and at the end. So it is very natural to have a lot of different applications :). -- best regards, Rok Pape? From Nicolas.Mailhot at laPoste.net Sun Oct 12 21:29:43 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 12 Oct 2003 23:29:43 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065992727.4411.1.camel@localhost.localdomain> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> <1065974214.3037.81.camel@littlegreen> <1065977504.2687.26.camel@rousalka.dyndns.org> <1065992727.4411.1.camel@localhost.localdomain> Message-ID: <1065994182.4413.16.camel@rousalka.dyndns.org> Le dim 12/10/2003 ? 23:05, Julien Olivier a ?crit : > (snip) > > > Well I can tell you we have *nothing* to learn from java packaging, > > quite the contrary. In fact the java world right now is a motherload of > > bad packaging examples. > > > > I think Mike was talking of Java's memory management (automatic removal > of unused objects), not package management. > > I could be wrong though... I understood it this way too;) I just didn't want anyone to translate it into "java packaging is good" (which just proves you can have terrific developers and piss-poor packagers) 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 elanthis at awesomeplay.com Sun Oct 12 21:34:14 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 12 Oct 2003 17:34:14 -0400 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <3F89C340.7040506@gear.dyndns.org> References: <1065969643.2836.25.camel@agnes.fremen.dune> <1065977742.2687.31.camel@rousalka.dyndns.org> <1065990353.2836.66.camel@agnes.fremen.dune> <1065992385.24534.3.camel@stargrazer.home.awesomeplay.com> <3F89C340.7040506@gear.dyndns.org> Message-ID: <1065994454.24534.18.camel@stargrazer.home.awesomeplay.com> On Sun, 2003-10-12 at 17:10, Paul Gear wrote: > Sean Middleditch wrote: > > ... > > and 5) over-engineering in the distro to accomodate all these > > alternatives. Debian had several sick sub-systems for handling 3 > > versions of the 'more' command, alnog with the obscene number of > > versions of apps for web browsing, mail, help, compilers, awks, seds, > > tars, etc. This is because those alternatives weren't addons or > > replacements, but in fact parts of the OS itself; i.e., the OS wasn't > > built for, say, Mozilla for browsing, or any of the other browsers as an > > optional add-on, but instead was built for *any* browser at all. The > > configuration, package management, and existance of sub-systems like the > > 'alternatives' section just shows how much work went into dealing with a > > sub-optimal situation. > > A web browser is quite a bit different from a web server, or > tar/awk/more/etc. Not when it comes to the packaging. > > You need to support a wide variety of browsers, because it is an > personal decision (i get really annoyed when i have to switch from > Galeon to anything), and you need to support multiple browsers per > system, since multiple people might different ones (at once on large > systems). You are confusing "support" or "integration" with "availability." Fedora doesn't need to ship 8 web browsers. If a user doesn't like the one picked for them, they can install the other web browsers from an Extras archive or from the browser's website. Nothing should stop you from installing, say, Opera - there's just no need for the whole system to be designed to support one of 20 browsers. (Also, RH/Fedora solves the browser problem to a large degree with the 'htmlview' utility - it does the same thing as teh Debian alternatives system, except its per user, like you want, plus its not a sick hack integrated into the low-level system.) > > But you can only run one web server or mail server at once (at least on > the standard ports), and it makes sense to limit the number of this type > of packages. The use case isn't any different really. Normal people only need one web server, and they usually pick Apache. Likewise, normal people only need one web browser. I don't claim to know which is the most popular, but there's no real reason to ship more than one (save those that are "part" of the DE, like Epiphany and GNOME 2.4 or Konquerer and KDE) - if you need a different browser, it can be installed on your own, and you would be capable of making it work as you need. Really, the only big differences are that the system can be "optimized" for one browser, and the base ISO set can be made smaller (versus the 3 CDs for RH9). Debian's way makes a mess of everything - the user, at install time, is bombarded with a choice of web browsers. If you install any browser, even if you just want it as an add-on (say, for web development testing) it becomes the system default until you manually correct the alternatives system. Users can't select their favorite browser easily, but instead have to rely on per-app/desktop configuration and BROWSER environment variables. -- Sean Middleditch AwesomePlay Productions, Inc. From alan at redhat.com Sun Oct 12 21:50:46 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 12 Oct 2003 17:50:46 -0400 (EDT) Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <3F89C340.7040506@gear.dyndns.org> from "Paul Gear" at Hyd 13, 2003 07:10:24 Message-ID: <200310122150.h9CLok121788@devserv.devel.redhat.com> > But you can only run one web server or mail server at once (at least on > the standard ports), and it makes sense to limit the number of this type > of packages. In many cases that simply isnt true - the feature set of products is very varied and you need to match features to those you need. From katzj at redhat.com Mon Oct 13 02:34:18 2003 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 12 Oct 2003 22:34:18 -0400 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <1065949938.1417.15.camel@homer.home> References: <1065949938.1417.15.camel@homer.home> Message-ID: <1066012457.1916.84.camel@edoras.local.net> On Sun, 2003-10-12 at 05:12, Stephan Windischmann wrote: > It seems as if the netinstall function is only there as an afterthought > (or maybe I'm just used to Debian). > Instead of a 4MB boot CD that has to download the installer itself, a > dedicated Fedora Netinstall CD (~100-150MB) that has the graphical > installer and perhaps a minimal file system on it would be really > helpful for those that don't want to get all 3 CD's. Actually, the rescuecd.iso can also be used for kicking off an install and has all of the second stage. Installing packages from FTP/HTTP with the graphical installer is a new feature -- I'm guessing using the rescuecd.iso to kick off an install will get more popular in the future :-) Graphical network installs in the past have been restricted to NFS where you just loopback mount the second stage off the NFS mount and don't have to do the large download. > Having to enter the FTP mirror details by hand isn't especially user > friendly either, and it doesn't really fit together with the rest of the > Fedora installer, which is excellent. The problem with this (historically) is the lack of an updated, reliable mirror list in a location with the bandwidth to support being probed during install. There's also a slight problem with correlating what your boot media matches to where to install from, but that's probably a solvable technical problem if there was movement on the first. > Also, would it be possible to do a netinstall of rawhide directly, > instead of having to first install the latest beta/release and then > upgrading to it? I'm a software version junky. ;) We're looking at turning on installer images for rawhide. I've been reluctant to do so just because there are nights when things are broken because of typos that don't catch them until the next day and then having people file bugs for three days could be annoying, but we'll come up with some way of dealing with that when it starts to become a problem ;-) Cheers, Jeremy From katzj at redhat.com Mon Oct 13 02:37:40 2003 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 12 Oct 2003 22:37:40 -0400 Subject: Additional Mozilla Request [was Re: rawhide report: 20031010 changes] In-Reply-To: <1065811344.3564.4.camel@localhost> References: <200310100949.h9A9nmi24373@porkchop.devel.redhat.com> <1065805796.9792.126.camel@palin> <1065811344.3564.4.camel@localhost> Message-ID: <1066012660.1916.95.camel@edoras.local.net> On Fri, 2003-10-10 at 14:42, Andr? Kelpe wrote: > BTW.: Are there any plans to move to python-2.3.x in the near future (in > rawhide)? The plan is to move to python 2.3.x after Fedora Core 1 is released. With everything else going on, there just weren't the cycles to switch to it and verify that things all continued to be happy with the schedule for Fedora Core 1. Cheers, Jeremy From katzj at redhat.com Mon Oct 13 02:41:11 2003 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 12 Oct 2003 22:41:11 -0400 Subject: GCC-3.3 and OO.org In-Reply-To: <1065822962.4800.36.camel@dhcp64-188.boston.redhat.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> <20031010205143.GE24349@shitake.truemesh.com> <1065820528.4800.12.camel@dhcp64-188.boston.redhat.com> <20031010213500.GF24349@shitake.truemesh.com> <1065822962.4800.36.camel@dhcp64-188.boston.redhat.com> Message-ID: <1066012871.1916.105.camel@edoras.local.net> On Fri, 2003-10-10 at 17:56, Dan Williams wrote: > Well, normally to get OOo to work with Java, you have to pass > --with-jdk-home= to the configure script in config_office/ > directory. Since I pass in --disable-java to this script, I could make > a switch to allow one to pass in --with-jdk-home, but where would the > RPM get the path from? What do you think is the best way to do that? > OOo will disregard a value in JAVA_HOME and find that path itself. The easiest thing to do if the goal is to allow people to rebuild it is probably to allow the value for the jdk home to be passed as a define on the rpmbuild command line. Something like `rpmbuild --define 'jdkhome /path/to/jdkhome'` and then you can have a check for the existence of %{jdkhome} in the specfile Cheers, Jeremy From katzj at redhat.com Mon Oct 13 02:42:21 2003 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 12 Oct 2003 22:42:21 -0400 Subject: GCC-3.3 and OO.org In-Reply-To: <1065826701.6640.4.camel@lobos> References: <200310102124.h9ALO4s01061@devserv.devel.redhat.com> <1065826701.6640.4.camel@lobos> Message-ID: <1066012941.1916.109.camel@edoras.local.net> On Fri, 2003-10-10 at 18:58, Scott Seagroves wrote: > On Fri, 2003-10-10 at 14:24, Alan Cox wrote: > > > The way Fedora is specified means you need to be able to build everything > > in Fedora with Fedora and everything in Fedora Extras with Fedora + Extras > > and so on. > > > > But what about some-fedora-package.src.rpm which rebuilds fine on Fedora > alone, but also has some things in the specfile like "uncomment this > next line if you have a JRE from jpackage"? Would that be OK with the > current policies? Doesn't seem unreasonable to me -- there have been macros in specfiles in the past for things that couldn't be shipped directly. Cheers, Jeremy From katzj at redhat.com Mon Oct 13 02:45:17 2003 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 12 Oct 2003 22:45:17 -0400 Subject: Since Fedora is not aimed at enterpise/business .. In-Reply-To: <3F8718BE.8080409@cypress.com> References: <1065016443.6301.37.camel@locutus> <20031001141039.GA5485@dudweiler.stuttgart.redhat.com> <1065040471.8034.16.camel@locutus> <3F8718BE.8080409@cypress.com> Message-ID: <1066013117.1916.114.camel@edoras.local.net> On Fri, 2003-10-10 at 16:38, Thomas Dodd wrote: > I don't believe I need ldap anything to use mozilla. If I have ldap, > mozilla can be told to use it, but it's not required. Same for > encrypting the ldap connection. It could use no authentication, clear > transmission, to strong authentication, encrypted connections, or any > where in between. You don't need ldap anything because mozilla has its own built-in LDAP support which doesn't use system libraries :) As far as the encryption bits, mozilla has a huge infrastructure that the PSM (which is mozilla's SSL support) plugs into. I'm not entirely sure the massiveness that is mozilla is something that you really want to emulate across the entire system, though ;) Cheers, Jeremy From jfm512 at free.fr Mon Oct 13 05:20:56 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 13 Oct 2003 07:20:56 +0200 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <200310122320.33929.rok.papez@lugos.si> References: <1065969643.2836.25.camel@agnes.fremen.dune> <1065977742.2687.31.camel@rousalka.dyndns.org> <1065990353.2836.66.camel@agnes.fremen.dune> <200310122320.33929.rok.papez@lugos.si> Message-ID: <1066022456.1183.17.camel@agnes.fremen.dune> On Sun, 2003-10-12 at 23:20, Rok Pape? wrote: > Hello. > > Dne nedelja 12 oktober 2003 22:25 je Jean Francois Martinez napisal(a): > > > 4) That users get headaches while shifting through six web servers, > > twenty window managers and thirty editors > > UNIX is about choice. Obsolete product have less and less users and they get > dropped. > Developing software is about evolution, not revolution. And at any time of > it.. you have products that are at the peak of their life cycle, at the > beginning and at the end. So it is very natural to have a lot of different > applications :). There is a thing called the law of decreasing marginal usefulness. For a man about to die from thirst a glass of water has more value than diamonds, by the third or fourth glass he will go for the diamonds, at one point water will become harmful (negative marginal usefulness). Another point is that having six web servers in a repository is one thing (only people who _really_ need something else will take the effort to look at them) and another one is to include them in the distro and force the 99% of users who either don't need one or would be happy with the defending champion to shift through them -- Jean Francois Martinez From tdiehl at rogueind.com Mon Oct 13 05:27:38 2003 From: tdiehl at rogueind.com (Tom Diehl) Date: Mon, 13 Oct 2003 01:27:38 -0400 (EDT) Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <20031009154130.A29659@devserv.devel.redhat.com> Message-ID: On Thu, 9 Oct 2003, Bill Nottingham wrote: > Jaap A. Haitsma (jaap_haitsma at zonnet.nl) said: > > I still have to minor issues: > > > > 1. If I show details then after a while when the service keytable gets > > loaded "[ OK ]" changes to "A OK U" (actually it are an A and an U with > > two dots on top, don't know how you call those letters in English) > > Yup, just disable the keytable script. It probably needs to be > removed anyway (it's superfluous). why is it superfluous?? I actually remap the del and backspace keys. Is there a better way to do this?? -- ......Tom Registered Linux User #14522 http://counter.li.org tdiehl at rogueind.com My current SpamTrap -------> mtd123 at rogueind.com From jfm512 at free.fr Mon Oct 13 05:59:48 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 13 Oct 2003 07:59:48 +0200 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <200310122150.h9CLok121788@devserv.devel.redhat.com> References: <200310122150.h9CLok121788@devserv.devel.redhat.com> Message-ID: <1066024788.1183.56.camel@agnes.fremen.dune> On Sun, 2003-10-12 at 23:50, Alan Cox wrote: > > But you can only run one web server or mail server at once (at least on > > the standard ports), and it makes sense to limit the number of this type > > of packages. > > In many cases that simply isnt true - the feature set of products is very > varied and you need to match features to those you need. Linus has said his main job was to say NO since every new feature forces the kernel people to have to cope with it in the future. There is nothing wrong with having dozens of web servers in an "everything for web serving" repository but in Fedora Core that is another thing: because of the drawbacks I mentioned you have to think in how useful are the features of teh additional program, how many people BADLY need them, how active is the maintenance of the program. And once you have thought about it you have to think again and again. -- Jean Francois Martinez From alan at redhat.com Mon Oct 13 07:52:07 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 13 Oct 2003 03:52:07 -0400 (EDT) Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <1066024788.1183.56.camel@agnes.fremen.dune> from "Jean Francois Martinez" at Hyd 13, 2003 07:59:48 Message-ID: <200310130752.h9D7q7o10819@devserv.devel.redhat.com> > There is nothing wrong with having dozens of web servers in an > "everything for web serving" repository but in Fedora Core that is > another thing: because of the drawbacks I mentioned you have to think in > how useful are the features of teh additional program, how many people > BADLY need them, how active is the maintenance of the program. And once > you have thought about it you have to think again and again. Linux is a program and not a collection. It does include lots of sound drivers, lots of disk drivers etc because there is a need to. To take another example - which should we throw out of fedora core vi or emacs .... Clearly the answer is neither. I do broadly agree with you however. In the case of apache we have a web server which does everything in the generic web serving space. From mike at theoretic.com Mon Oct 13 08:35:48 2003 From: mike at theoretic.com (Mike Hearn) Date: Mon, 13 Oct 2003 09:35:48 +0100 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065977504.2687.26.camel@rousalka.dyndns.org> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> <1065974214.3037.81.camel@littlegreen> <1065977504.2687.26.camel@rousalka.dyndns.org> Message-ID: <1066034146.3018.5.camel@littlegreen> On Sun, 2003-10-12 at 17:51, Nicolas Mailhot wrote: > Please keep unstalling/uninstalling out of menus. We intend to. Currently we use the .desktop specs Actions part to do uninstall/upgrade etc, unfortunately no desktop supports it yet. At some point I'll sit down and hack out support for Gnome if nobody else does, I expect somebody is up for doing it in KDE. Right clicking on a menu item has piss poor discoverability of course. I'm warming to Seths application manager program a bit. > We don't need no windowish in-your-face uninstall solutions, we don't > need popup eulas This is getting rather offtopic, but the "makeinstaller" utility prints warnings if you use the EULA functionality (not fully implemented yet).. > , change-install-location dialogs, Don't have one, if you want to change the prefix you have to use the command line... > here-is-the-disc-size-I-need-please-check windows, ... automatic > you-think-I'm-installed-but-check-my-20-pages-readme popups, ... not done > don't-bother-with-permissions-and-run-everything-as-admin ... can choose (user vs root) > (I case people wonder - I've just documented the installation of an app > that used a custom installer clearly written by a brainwashed > monopolysoft user. Just documenting this single installation took as > many pages as the ones devoted to updating the whole multi-hundred rpm > system) We're aiming for a 100% automatic install. User interaction is possible but treated very carefully. > Anyway I don't know why I bother - just do your thing and I'll watch HiG > people shot it down. You do that. Just remember that most of us have read the HIG and taken it to heart. > Sure - why use a single consistent working solution when you can let > everyone reinvent incompatible wheels ? There would be a consistant working solution, but so far I've not been able to come up with one that I feel integrates nicely. We'll prolly end up doing an "app manager" (which BTW should really be standards based), but even so this is kind of hackish IMHO - for the user the model is that the launcher IS the application, so integrating app management with the launcher feels like the right way to do things. thanks -mike From buildsys at porkchop.devel.redhat.com Mon Oct 13 09:47:23 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Mon, 13 Oct 2003 05:47:23 -0400 Subject: rawhide report: 20031013 changes Message-ID: <200310130947.h9D9lNS26575@porkchop.devel.redhat.com> Updated Packages: nautilus-cd-burner-0.5.3-1 -------------------------- * Mon Oct 13 2003 Alexander Larsson 0.5.3-1 - Update to final gnome 2.4 release - Has one crash fix and new translations rawhide-release-20031013-1 -------------------------- From behdad at cs.toronto.edu Mon Oct 13 10:16:42 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 13 Oct 2003 06:16:42 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: References: Message-ID: On Mon, 13 Oct 2003, Tom Diehl wrote: > On Thu, 9 Oct 2003, Bill Nottingham wrote: > > > Jaap A. Haitsma (jaap_haitsma at zonnet.nl) said: > > > I still have to minor issues: > > > > > > 1. If I show details then after a while when the service keytable gets > > > loaded "[ OK ]" changes to "A OK U" (actually it are an A and an U with > > > two dots on top, don't know how you call those letters in English) > > > > Yup, just disable the keytable script. It probably needs to be > > removed anyway (it's superfluous). So how is keyboard mapping going to be done in console? > why is it superfluous?? I actually remap the del and backspace keys. Is there a > better way to do this?? behdad, who is going to study after finishing this mail. From thomas at apestaart.org Mon Oct 13 10:37:27 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 13 Oct 2003 12:37:27 +0200 Subject: new release Message-ID: <1066041447.4617.66.camel@ana.onshuis> Hello, I released a new version of mach. 0.4.1, "Get A Room", is out the door. mach is a tool that's useful for setting up clean root environments, and build clean packages in them as well. Changes since last release: - added Red Hat 7.0, 7.1 - added Yellowdog 2.3, 3.0 - added Fedora Core 0.94 - added FreshRPMS targets - make "mach apt-get" run interactive - implemented "mach status" - fix permissions on copied sources - unlock root on successful build - allow "." in mach-helper Release notes are attached. Homepage is at http://thomas.apestaart.org/projects/mach Enjoy and give me feedback. Thomas Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> P.S. You rock my world <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ -------------- next part -------------- mach - make a chroot - RELEASE NOTES ------------------------------------ Announcing the release of mach 0.4.1 - "Get A Room" WHAT IS IT ---------- mach allows you to set up clean roots from scratch for any distribution or distribution variation supported. This clean build root can be used to run jailed services, create disk images, or build clean packages. mach can currently set up roots for the following distributions: - Red Hat 7.0 (basic, updated, FreshRPMS) - Red Hat 7.1 (basic, updated, FreshRPMS) - Red Hat 7.2 (basic, updated, FreshRPMS, JPackage) - Red Hat 7.3 (basic, updated, FreshRPMS, JPackage) - Red Hat 8.0 (basic, updated, Fedora, JPackage, GStreamer, FreshRPMS) - Red Hat 9 (basic, updated, Fedora, JPackage, GStreamer, FreshRPMS) - Fedora Core 0.94 (basic, updated) - SuSE 8.1/8.2 - Yellowdog Linux 2.3 (basic, updated, FreshRPMS) - Yellowdog Linux 3.0 (basic, updated, FreshRPMS) - Dave/Dina oven/fridge Read the README included in the distribution for a better overview. WHY WOULD YOU USE IT -------------------- mach is helpful: - to create minimal chroot environments to jail services in - to create clean packages for distributions - to catch spec file mistakes, missing buildrequires, and more INFORMATION ----------- mach's homepage is at http://thomas.apestaart.org/projects/mach/ mach is hosted on SourceForge; the project page is http://www.sourceforge.net/projects/mach/ There is a mailing list for development and use of mach. See http://lists.sourceforge.net/lists/listinfo/mach-devel QUICKSTART ---------- a) On a Red Hat 9 system, install the mach rpm from http://thomas.apestaart.org/download/mach b) su - mach c) mach setup base d) mach chroot poke around a bit in the fresh root e) exit f) mach rebuild http://ayo.freshrpms.net/redhat/9/i386/SRPMS.os/vorbis-tools-1.0-3.src.rpm If all goes well, you'll get a nice freshly built vorbis-tools package. Now go out, experiment and bug report ! BUGS ---- Please report all bugs to me at thomas (at) apestaart (dot) org. Always state what platform you are running on, if it's a clean install or somehow updated, how I can reproduce the bug, and output of a run of the failed command with -d (debugging). From nutello at sweetness.com Mon Oct 13 11:53:35 2003 From: nutello at sweetness.com (Rudi Chiarito) Date: Mon, 13 Oct 2003 13:53:35 +0200 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <1066012457.1916.84.camel@edoras.local.net> References: <1065949938.1417.15.camel@homer.home> <1066012457.1916.84.camel@edoras.local.net> Message-ID: <20031013115334.GM17160@server4.8080.it> On Sun, Oct 12, 2003 at 10:34:18PM -0400, Jeremy Katz wrote: > Actually, the rescuecd.iso can also be used for kicking off an install > and has all of the second stage. Installing packages from FTP/HTTP with On a related note, would you accept patches to create "USB boot images", for kickstarting purposes? E.g. in a cluster you could dump floppies and CDs altogether, booting installations from removable Flash storage (you can still use USB floppy or CD drives if you really miss those long startup times). Yes, you could as well set up nodes to boot from the net, but some might prefer kickstart's kssendmac option to register an Ethernet address (and enable DHCP/netboot for it afterwards). I have been hacking the anaconda-runtime scripts to sneak a given network driver onto the boot floppy. You need to take out the splash screen to make room for the extra module - no problem, as it's for headless systems anyway. It's not much more than an experiment, because this way only the smallest modules can be crammed in. Not to mention that floppies are slooooooow. Still, one might have legacy systems whose BIOS can't boot from USB, so it's not necessarily a waste of time. The real deal, though, is an image that basically combines bootdisk and the driver disks. The 65MB of rescuecd.iso - at least in this case - are overkill. Instead, with something of intermediate size, you could create a small bootable partition for kickstart, while the rest of the drive is used by a data partition. > We're looking at turning on installer images for rawhide. I've been > reluctant to do so just because there are nights when things are broken > because of typos that don't catch them until the next day and then > having people file bugs for three days could be annoying, but we'll come > up with some way of dealing with that when it starts to become a problem > ;-) Here's a mostly harmless bug for you. In mk-images::makeinitrd() you initialise INITRDMODULES, but proceed to use LOADERMODULES. Rudi From Axel.Thimm at physik.fu-berlin.de Mon Oct 13 13:18:44 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 13 Oct 2003 15:18:44 +0200 Subject: up2date: Invalid Architecture and OS release combination (0.95, i686-redhat-linux). Message-ID: <20031013131844.GA9323@puariko.nirvana> Hi, I am using rawhide from the 10th of October and wanted to test up2date. Upon registration via up2date I got the above error. The system is an athlon (Duron/700). $ rpm -qf /etc/fedora-release fedora-release-0.95-1 -- 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 elanthis at awesomeplay.com Mon Oct 13 13:55:49 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 13 Oct 2003 09:55:49 -0400 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <200310130752.h9D7q7o10819@devserv.devel.redhat.com> References: <200310130752.h9D7q7o10819@devserv.devel.redhat.com> Message-ID: <1066053349.524.9.camel@support02.civic.twp.ypsilanti.mi.us> On Mon, 2003-10-13 at 03:52, Alan Cox wrote: > > There is nothing wrong with having dozens of web servers in an > > "everything for web serving" repository but in Fedora Core that is > > another thing: because of the drawbacks I mentioned you have to think in > > how useful are the features of teh additional program, how many people > > BADLY need them, how active is the maintenance of the program. And once > > you have thought about it you have to think again and again. > > Linux is a program and not a collection. It does include lots of sound > drivers, lots of disk drivers etc because there is a need to. > > To take another example - which should we throw out of fedora core > vi or emacs .... Clearly the answer is neither. I'm not sure vi or emacs are good examples for this. We're talking largely about over-lapping need. Need is defined in many ways - I *need* my web server to support auth over LDAP, SSL, PHP/CGI, virtual domains, etc. My text editor, on the other hand, I *need* to use vi interface, since that's what I've used for almost 10 years now, and its near impossible for me to get work done in emacs. The reason to use vi vs emacs or pico or gedit or whatnot is based on the interface feature, *not* the actual capabilities - in this case, there is no overlap in needs. We could also say that since we have cat, we shouldn't offer any text editors - problem is, the feature sets between cat and vi (or any "text editor") are *very* different. Overlap might be offering several versions of vi (like Debian), not in offering vi plus other editors with completely different interface designs and target audiences. When we start talking about gedit vs jedit vs kate vs gnotepad vs textedit and so on, now we're talking more or less identical programs; offering two GUI text editors that do the almost exact same thing with almost the exact same interface is pretty goofy. > > I do broadly agree with you however. In the case of apache we have a > web server which does everything in the generic web serving space. > > > -- > 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 ms-nospam-0306 at arcor.de Mon Oct 13 14:02:40 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 13 Oct 2003 16:02:40 +0200 Subject: up2date: Invalid Architecture and OS release combination (0.95, i686-redhat-linux). In-Reply-To: <20031013131844.GA9323@puariko.nirvana> References: <20031013131844.GA9323@puariko.nirvana> Message-ID: <20031013160240.01b9b165.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 13 Oct 2003 15:18:44 +0200, Axel Thimm wrote: > I am using rawhide from the 10th of October and wanted to test > up2date. Upon registration via up2date I got the above error. > > The system is an athlon (Duron/700). > $ rpm -qf /etc/fedora-release > fedora-release-0.95-1 There is no 0.95 channel yet. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/irCA0iMVcrivHFQRAtsmAJ99b205QONkd5kfM3KIvFPYLrDreACfek6T oXRUQNH4BHBizKgU0s/dCV4= =WHpJ -----END PGP SIGNATURE----- From janina at rednote.net Mon Oct 13 14:09:24 2003 From: janina at rednote.net (Janina Sajka) Date: Mon, 13 Oct 2003 10:09:24 -0400 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <1066012457.1916.84.camel@edoras.local.net> References: <1065949938.1417.15.camel@homer.home> <1066012457.1916.84.camel@edoras.local.net> Message-ID: <20031013140923.GD27508@rednote.net> I should think that one of the chief issues to resolve with network installations should be the ability to resume. I've done many net installs over my lan, and have even run into this issue there--as with a portable going to sleep for some reason. So, if it can crop up in a local environment, it should be even more important over the Internet, imho. Jeremy Katz writes: > From: Jeremy Katz > > On Sun, 2003-10-12 at 05:12, Stephan Windischmann wrote: > > It seems as if the netinstall function is only there as an afterthought > > (or maybe I'm just used to Debian). > > Instead of a 4MB boot CD that has to download the installer itself, a > > dedicated Fedora Netinstall CD (~100-150MB) that has the graphical > > installer and perhaps a minimal file system on it would be really > > helpful for those that don't want to get all 3 CD's. > > Actually, the rescuecd.iso can also be used for kicking off an install > and has all of the second stage. Installing packages from FTP/HTTP with > the graphical installer is a new feature -- I'm guessing using the > rescuecd.iso to kick off an install will get more popular in the future > :-) Graphical network installs in the past have been restricted to NFS > where you just loopback mount the second stage off the NFS mount and > don't have to do the large download. > > > Having to enter the FTP mirror details by hand isn't especially user > > friendly either, and it doesn't really fit together with the rest of the > > Fedora installer, which is excellent. > > The problem with this (historically) is the lack of an updated, reliable > mirror list in a location with the bandwidth to support being probed > during install. There's also a slight problem with correlating what > your boot media matches to where to install from, but that's probably a > solvable technical problem if there was movement on the first. > > > Also, would it be possible to do a netinstall of rawhide directly, > > instead of having to first install the latest beta/release and then > > upgrading to it? I'm a software version junky. ;) > > We're looking at turning on installer images for rawhide. I've been > reluctant to do so just because there are nights when things are broken > because of typos that don't catch them until the next day and then > having people file bugs for three days could be annoying, but we'll come > up with some way of dealing with that when it starts to become a problem > ;-) > > Cheers, > > Jeremy > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka Email: janina at rednote.net Phone: (202) 408-8175 Director, Technology Research and Development American Foundation for the Blind (AFB) http://www.afb.org Chair, Accessibility Work Group Free Standards Group http://accessibility.freestandards.org From elanthis at awesomeplay.com Mon Oct 13 14:54:12 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 13 Oct 2003 10:54:12 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1065977504.2687.26.camel@rousalka.dyndns.org> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> <1065974214.3037.81.camel@littlegreen> <1065977504.2687.26.camel@rousalka.dyndns.org> Message-ID: <1066056852.524.72.camel@support02.civic.twp.ypsilanti.mi.us> On Sun, 2003-10-12 at 12:51, Nicolas Mailhot wrote: > Le dim 12/10/2003 ?? 17:56, Mike Hearn a ??crit : > > On Sun, 2003-10-12 at 00:14, Sean Middleditch wrote: > > > > That would be interesting. The problem is, then, every single app that > > > possibly exists in the application/dependency archive would be in the > > > menues. Ick. > > > > No, only stuff the user had installed. > > Please keep unstalling/uninstalling out of menus. > > Windows only does it because for a long time they installation manager > panel missed most apps (and still misses some of them). So people had to > put uninstall links somewhere else. Really it's amazing how people > forget history and comme to accept ugly workarounds as the natural way > to do things. I think perhaps you aren't following Mike's intent - the Windows way, adding big menu options for "Uninstall", is not what he meant. More, when you context-click on an app in the menu, several options pop up (copy launcher, remove from menu, etc.) - one of those would (could) be "Uninstall application". Completely out of the way unless you're looking for it. > > We don't need no windowish in-your-face uninstall solutions, we don't > need popup eulas, change-install-location dialogs, > here-is-the-disc-size-I-need-please-check windows, > you-think-I'm-installed-but-check-my-20-pages-readme popups, > don't-bother-with-permissions-and-run-everything-as-admin In many cases, we *do* need some of those. We *do* need EULA support, for example, since applications I install often have them. Whether or not you think they're evil, others need an installer that supports them (versus the RPM way, which requires packagers to wrap the RPM in a shell script which I then have to run in a command line to open, agree to the EULA, and then install) as they use applications that have them, and need to continue doing so. > > (I case people wonder - I've just documented the installation of an app > that used a custom installer clearly written by a brainwashed > monopolysoft user. Just documenting this single installation took as > many pages as the ones devoted to updating the whole multi-hundred rpm > system) Ya... let's keep this to technical facts, not "brainwashed Free Software user" paranoia. Thanks. ;-) Installation problems on Linux I've run into are almost always because of RPM. If RPMs usually supported more than on particular snapshot of a particular distro, if RPMs actually worked on all distros, and if RPM had abilities to ask users install questions, select software components, agree to legally-required EULAs (there's doubt that even the GPL is really valid if the user is never forced to agree to it, or even *see* it, to use the software), etc. then software developers probably wouldn't need to rely on hacked-up installers. As is, even most of the companies that ship RPMs generally need to wrap them in shell scripts or other hacks in order to "add" the features RPM denies them. Look at the Macromedia Flash, Adobe Acrobat Reader, or Sun Java installs (I think those are the ones that use wrapped RPMs), for example. > > Anyway I don't know why I bother - just do your thing and I'll watch HiG > people shot it down. > > > > While I understand the use cases, as I've said on the autopackage lists, > > > and real Application Manager is needed (which I've some new ideas for, > > > i'll post those to the ap list). > > > > Please do so. I'm not sold that we need any specific app management > > program - it's the sort of thing users just never think about (much like > > uninstalling stuff they no longer use). > > Sure - why use a single consistent working solution when you can let > everyone reinvent incompatible wheels ? That isn't the intent. The idea is to put the "single working solution" somewhere other than a monolithic GUI manager. Altho, personally, I still think the GUI manager is a necessity. > > > > Which isn't really possible. The best you could do is inform the user > > > that the system doesn't *appear* to be using the app anymore (no users > > > have a launcher for it, if you can even determine that easily) and let > > > them optionally uninstall it. > > > > > > The same is true to libraries/dependencies - sure, normal users might > > > not need them if no other packages are using them, but hackers/admins > > > probably have a lot of stuff installed from source. So automatic > > > dependency "garbage" collection isn't really feasible, at least not > > > without lots and lots of user interaction and such. > > > > Maybe.... still, it's been done in Java/C# for ages, despite the > > difficulties. It seems unintuitive that it's possible with objects but > > not packages. There are *huge* differences, unfortunately, between an application running and applications spread all over the file system. Garbage collection in Java/C# doesn't happen across two apps connected over the network, yet application garbage collection would need that for mounted shares/volumes. Memory garbage collectors also have access to all objects in existence, and (in good implementations) know when object relationships are formed or broken - an application garbage collector would need to somehow find out whenever any reference to an app has changed. Memory collectors also don't support fancy memory tricks like "hidden" pointers and such, but an application garbage collector would need to know about "fancy tricks" like users using an app from the command line or a script and not .desktop files. Memory GC and application GC are really just two completely different things. > > Well I can tell you we have *nothing* to learn from java packaging, > quite the contrary. In fact the java world right now is a motherload of > bad packaging examples. > > > > Evangelism on the importance of proper development practices could be > > > useful, too. Probably the only place I've seen describing library > > > versioning in detail is the innards of the libtool manual. No wonder > > > lots of devs don't do it right, eh? Something like the war on drugs is > > > needed: DARP, Developers Against Ramshackle Packages. ;-) > > > > Yeah, I want to do this too at some point, probably as part of the > > packagers/developers guide we're writing for AP. There is a good paper > > by Ulrich Drepper on writing DSOs, but it's basically impossible to find > > unless somebody shows you. Other bad techniques are compile time > > options, non-relocatability and so on. Developer education is definately > > a part of the solution. > > Developer education will *always* be a problem. Developing and packaging > are just two different CS specialities (just like developing and QA). > Some people will do both, most won't, expecting every single developer > to be able to package things is just a recipe for bad packaging. Developers don't necessarily need to package. They *do* need to not be so boneheaded as to make packaging impossible. i.e., when the packager comes along and finds out that the only way to get "lite version" and "full version" of the application packaged is to make them conflict with each other, thus requiring a user to uninstall and reinstall the app to "enable" features, the packager should bring the issue up with the developer, who then should go, "oh, oops, will fix this!" and resolve the problem on his end, allowing the packager to make sane, working packagers that people besides l337 h4ck3r5 and sysadmins can install and use. As is now, the developer tends not to give a flying hoot (or just not know any better), the packager can't resolve the issue with the developer (or they themselves don't really understand the problem), and we end up with tons of packages that don't really work unless installed in one specific OS setup, when the moon is full, the stars are aligned properly, the wind is blowing from the south-southeast at 45 knots, and you've your ritual RPM body paint on with shell script incants written all over your forehead. Evangelism and education can help this. Simply not packaging brain-dead broken software helps too; or, at least, understand that packages of software like that should be the *exception*, not the rule. We'll probably always have a couple pieces of popular software written by dinks that think Linux should only be for the technologically elite and kept away from "dr00ling lusers," but hopefully we can keep that to a minimum. > > Cheers, -- Sean Middleditch AwesomePlay Productions, Inc. From Nicolas.Mailhot at laPoste.net Mon Oct 13 16:01:25 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 13 Oct 2003 18:01:25 +0200 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1066056852.524.72.camel@support02.civic.twp.ypsilanti.mi.us> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> <1065974214.3037.81.camel@littlegreen> <1065977504.2687.26.camel@rousalka.dyndns.org> <1066056852.524.72.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1066060884.27219.52.camel@ulysse.olympe.o2t> Le lun 13/10/2003 ? 16:54, Sean Middleditch a ?crit : > On Sun, 2003-10-12 at 12:51, Nicolas Mailhot wrote: > > > > (I case people wonder - I've just documented the installation of an app > > that used a custom installer clearly written by a brainwashed > > monopolysoft user. Just documenting this single installation took as > > many pages as the ones devoted to updating the whole multi-hundred rpm > > system) > > Ya... let's keep this to technical facts, not "brainwashed Free Software > user" paranoia. Thanks. ;-) Sure. Call all the useless screens I've had to document parano?a if you wish. I do know the exact cost user-wise of the two approaches, because I had to document it, and then validate the doc with test users. I do not assume anything. I spent lots of time validating this. Did you? > Installation problems on Linux I've run into are almost always because > of RPM. If RPMs usually supported more than on particular snapshot of a > particular distro, if RPMs actually worked on all distros, and if RPM > had abilities to ask users install questions, select software > components, agree to legally-required EULAs (there's doubt that even the > GPL is really valid if the user is never forced to agree to it, or even > *see* it, to use the software), etc No. There is absolutely no doubt in any lawyer mind that click-thoughts are totally irrelevant legally (or at least in most of the sane world). The function they serve is purely to frighten users into doing slavishly whatever the vendor wants them to do (see the Dell EULA-in-BIOS story - the EULA was so extreme there was no way anyone could reasonably abide by it). Plus of course they target specifically the US legal system, even for software that distributed half a world away. > . then software developers probably > wouldn't need to rely on hacked-up installers. Yep. And most of the people here would be using something else. You put the garbage into the installer - sane people will jump out of your ship. > As is, even most of the companies that ship RPMs generally need to wrap > them in shell scripts or other hacks in order to "add" the features RPM > denies them. Look at the Macromedia Flash, Adobe Acrobat Reader, or Sun > Java installs (I think those are the ones that use wrapped RPMs), for > example. So what ? A commercial house will put whatever it can get by in the installer. The big difference between Windows and Linux is so far it can get by with a lot less dirty tricks. (and don't bring the thing Sun calls a java rpm in the discussion - I can assure you I spent enough time refactoring it into sanity I know it by heart) The nice RH people have proved over time you can package anything in rpms - from web server to office suites, from home-developed apps to big commercial bloatware (oo) All the things you're clamouring for *have not a single technical justification*. Period. You don't want them because the user needs or wants them, or because they will improve the system. You want them so people can use Linux just like another windows, with just the same habits that ruin everyday windows user life, and so commercial houses can issue the same junk as they are used to. And you can write all you want about it not being as bad as I describe it. A lot of other people here have enough daily exposition to that other OS to know what it can do and how. -- 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 roozbeh at sharif.edu Mon Oct 13 15:11:07 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Mon, 13 Oct 2003 18:41:07 +0330 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1066056852.524.72.camel@support02.civic.twp.ypsilanti.mi.us> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> <1065974214.3037.81.camel@littlegreen> <1065977504.2687.26.camel@rousalka.dyndns.org> <1066056852.524.72.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1066057867.4053.21.camel@guava.bamdad.org> On Mon, 2003-10-13 at 18:24, Sean Middleditch wrote: > (there's doubt that even the > GPL is really valid if the user is never forced to agree to it, or even > *see* it, to use the software) I'm sorry, you are very mistaken. GPL is completely irrelevant to the *user*, it's only relevant if you want to *copy* the software. And if you want to copy the software, you are automatically bound by the copyright "law" (whether or not you've seen an EULA), which doesn't give you the right to copy the software for some certain purposes. If somebody copies the software without seeing the license, he may have already been breaking the law. In short, if you don't see the license, you may *use* the software for any purpose (which is allowed by GPL), but you may not *copy* it. If you see it, you may do whatever it allows you to do. I agree that certain proprietary pieces of software need EULAs, but we're not talking about GPL, or most of Free Software licenses for that matter. Roozbeh From katzj at redhat.com Mon Oct 13 16:52:09 2003 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Oct 2003 12:52:09 -0400 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <20031013115334.GM17160@server4.8080.it> References: <1065949938.1417.15.camel@homer.home> <1066012457.1916.84.camel@edoras.local.net> <20031013115334.GM17160@server4.8080.it> Message-ID: <1066063929.24321.6.camel@mirkwood.devel.redhat.com> On Mon, 2003-10-13 at 07:53, Rudi Chiarito wrote: > On Sun, Oct 12, 2003 at 10:34:18PM -0400, Jeremy Katz wrote: > > Actually, the rescuecd.iso can also be used for kicking off an install > > and has all of the second stage. Installing packages from FTP/HTTP with > > On a related note, would you accept patches to create "USB boot images", > for kickstarting purposes? E.g. in a cluster you could dump floppies and > CDs altogether, booting installations from removable Flash storage (you > can still use USB floppy or CD drives if you really miss those long > startup times). Yes, you could as well set up nodes to boot from the > net, but some might prefer kickstart's kssendmac option to register an > Ethernet address (and enable DHCP/netboot for it afterwards). I've thought about it -- I'm just not 100% convinced of the usefulness of doing so (since it takes up another 4 or 5 megs on the first CD). I just got a USB pendrive over the weekend, so figured I'd at least look at it. Should basically require making a fs, copying the files from the isolinux/ directory on the CD, mv isolinux.cfg syslinux.cfg and then run syslinux on the filesystem. Or that would be my hope :-) > I have been hacking the anaconda-runtime scripts to sneak a given > network driver onto the boot floppy. You need to take out the splash > screen to make room for the extra module - no problem, as it's for > headless systems anyway. It's not much more than an experiment, because > this way only the smallest modules can be crammed in. Not to mention > that floppies are slooooooow. Still, one might have legacy systems whose > BIOS can't boot from USB, so it's not necessarily a waste of time. Unfortunately, this release is probably the last where floppies have any relevance. From 2.6 kernels so far, I really don't see how we're going to be able to continue to have boot disks after moving to a 2.6 kernel. [snip] > Here's a mostly harmless bug for you. > > In mk-images::makeinitrd() you initialise INITRDMODULES, but proceed to > use LOADERMODULES. Thanks, fixed. Bugzilla helps in the future (to avoid losing things) Cheers, Jeremy From katzj at redhat.com Mon Oct 13 16:53:22 2003 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Oct 2003 12:53:22 -0400 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <20031013140923.GD27508@rednote.net> References: <1065949938.1417.15.camel@homer.home> <1066012457.1916.84.camel@edoras.local.net> <20031013140923.GD27508@rednote.net> Message-ID: <1066064002.24321.8.camel@mirkwood.devel.redhat.com> On Mon, 2003-10-13 at 10:09, Janina Sajka wrote: > I should think that one of the chief issues to resolve with network > installations should be the ability to resume. I've done many net > installs over my lan, and have even run into this issue there--as with a > portable going to sleep for some reason. So, if it can crop up in a > local environment, it should be even more important over the Internet, > imho. Resume how exactly? At this point, we handle every error condition I know of and give a chance to retry at which point things start returning to normal. One of our QA guys even does things like put firewall rules on servers to stop his install cases from being able to proceed "normally" :-) cheers, Jeremy From alan at redhat.com Mon Oct 13 16:54:48 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 13 Oct 2003 12:54:48 -0400 (EDT) Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1066057867.4053.21.camel@guava.bamdad.org> from "Roozbeh Pournader" at Hyd 13, 2003 06:41:07 Message-ID: <200310131654.h9DGsmO12189@devserv.devel.redhat.com> > In short, if you don't see the license, you may *use* the software for > any purpose (which is allowed by GPL), but you may not *copy* it. If you > see it, you may do whatever it allows you to do. > > I agree that certain proprietary pieces of software need EULAs, but > we're not talking about GPL, or most of Free Software licenses for that > matter. It in part varies by country. The GPL is a copyright license not a contract and that actually also restricts what it can do. From elanthis at awesomeplay.com Mon Oct 13 17:12:32 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 13 Oct 2003 13:12:32 -0400 Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1066060884.27219.52.camel@ulysse.olympe.o2t> References: <1065252308.4488.116.camel@andy> <20031004161511.10275871.ms-nospam-0306@arcor.de> <1065282693.5142.4.camel@stargrazer.home.awesomeplay.com> <20031004192021.7a7b3cf3.ms-nospam-0306@arcor.de> <1065290312.4488.130.camel@andy> <20031004203936.42e69624.ms-nospam-0306@arcor.de> <1065294635.4488.313.camel@andy> <20031004222927.3e69de95.ms-nospam-0306@arcor.de> <1065304168.2226.13.camel@dhcppc3> <1065910961.27674.60.camel@littlegreen> <1065914084.2169.79.camel@stargrazer.home.awesomeplay.com> <1065974214.3037.81.camel@littlegreen> <1065977504.2687.26.camel@rousalka.dyndns.org> <1066056852.524.72.camel@support02.civic.twp.ypsilanti.mi.us> <1066060884.27219.52.camel@ulysse.olympe.o2t> Message-ID: <1066065152.524.95.camel@support02.civic.twp.ypsilanti.mi.us> On Mon, 2003-10-13 at 12:01, Nicolas Mailhot wrote: > The nice RH people have proved over time you can package anything in > rpms - from web server to office suites, from home-developed apps to big > commercial bloatware (oo) > > All the things you're clamouring for *have not a single technical > justification*. Period. You don't want them because the user needs or Software components: Take a look at OOo, Mozilla, GNOME, etc. - a user installing these has to manually pick apart and selected packages. A user-friendly approach would, upon opening the installer, give them options to select among options - i.e., do I want just the browser, or the mailer as well, or the browser, mailer, calendar but not the chat program, etc. When we get into managing packages, the user will see a list of things like: mozilla-browser mozilla-mailnews mozilla-chat mozilla mozilla-nspr mozilla-nss etc. That's just insane. Those are all "Mozilla", just different sub-components. When you toss in things like virtual packages that exist solely to depend on everything (common in Debian, less common in RPMs), the user model *really* starts to suffer. What happens when an application spans multiple CDs? I have tons of software like that - games, music composition applications, etc. - how does RPM handle that? Oh, right, it *doesn't*. Unless the author breaks the app into multiple RPMs, which is (a) insane, and (b) pollutes the package space. > wants them, or because they will improve the system. You want them so > people can use Linux just like another windows, with just the same > habits that ruin everyday windows user life, and so commercial houses > can issue the same junk as they are used to. Seriously, this is nothing but paranoid rambling. I'm not going to waste time trying to debate with a raving zealot - discussion over. -- Sean Middleditch AwesomePlay Productions, Inc. From ted at cypress.com Mon Oct 13 18:10:26 2003 From: ted at cypress.com (Thomas Dodd) Date: Mon, 13 Oct 2003 13:10:26 -0500 Subject: GCC-3.3 and OO.org In-Reply-To: <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> Message-ID: <3F8AEA92.8010308@cypress.com> Dan Williams wrote: > Hi, > > OOo 1.1 packages shipped from Red Hat ship with Java support disabled, > since Red Hat does not ship the Sun JDK or JRE. I use patches from the > Debian project to accomplish this. Most anything relating to Java in > OOo (ie DocBook XML filters, JDBC support, etc) will not work as > expected. I'm not sure what parts of OO.org need java, but I wasn't talkingabout JDBC in linux. > On Fri, 2003-10-10 at 15:19, Thomas Dodd wrote: >>far. I'm having some trouble with ODBC/MySQL though I see the same >>problem in Solaris with the OO.org build. >> >>Interesting I don't have problems using JDBC in Solaris (other than >>speed :( ) or ODBC in Win98 and Excel (97 I think). >>Time to get back on the OO.org lists... Notice MySQL+ODBC is problematic on Solaris too. This is with an OO.org build and Sun's JVM configured. The Solaris setup works fine with JDBC, but not ODBC. In linux, using the FC build of OOo1.1, I'm having trouble with MySQL+ODBC as well. I haven't tried JDBC yet. Win98+Excel97+ODBC+MySQL works fine though. I think I'll try OOo1.1 on Win98 to see if it's OOo1.1 + ODBC or the unixODBC+MySQL combination. Strange thing is, ODBC appears to be OK. Using isql, everything functions fine. I'm wondering if what the real difference in using ODBC in OOo and the MySQL driver is. Both appear to to use ODBC and odbc.ini to locate the data. The problem on Solaris is speed. Using JDBC takes for ever. The mysql:odbc driver takes a long time to fail, same for just using odbc the odbc interface. Win98+Excel+ODBC (SunPCI card w/ K6 and 64MB ram) is much faster. I did some testing while writing this. Now I can use the datasources in linux. I just have to setup queries, and use them. Either ODBC or MySQL works this way. But I still cannot select a table in the data sources veiw and see the columns in a give table. It is faster than Solaris though. -Thomas From ted at cypress.com Mon Oct 13 18:22:12 2003 From: ted at cypress.com (Thomas Dodd) Date: Mon, 13 Oct 2003 13:22:12 -0500 Subject: rhgb-0.10.2-1 In-Reply-To: References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <1065861744.3616.5.camel@localhost.localdomain> Message-ID: <3F8AED54.8040602@cypress.com> Behdad Esfahbod wrote: > On Sat, 11 Oct 2003, Julien Olivier wrote: >>Hmmm... I think the best way to handle that would be to put a flag when >>the computer has started cleanly and remove it when it has be shut down >>cleanly. This, way, if it kernel-panics or crashes, the flag is still >>there. > > > I guess you misunderstood what I meant. I cannot see how you can > handle the panics when you have no write access anywhere. The Looks like you missed it. This flag is set on boot, and cleared on shutdown. If a panic happens, it's not cleared, and stiull set next boot. During boot if the flag is set, you know you had a problem in the shudown. Don't we already have similar flags in / now? Like .autofsck, which is cleared on shutdown/unmount. Other flags I see in a quick glance at rc.sysinit include forcefsck, fsckoptions, fastboot. -Thomas From notting at redhat.com Mon Oct 13 18:25:02 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Oct 2003 14:25:02 -0400 Subject: Updated Fedora Core test release: Severn Message-ID: <20031013142502.A18694@devserv.devel.redhat.com> WONDER ... at the bugs that have been fixed! GROAN ... at the bugs that haven't been fixed! MARVEL ... at Bill actually getting the download location and torrent names right! Yes, it's another update of the Fedora Core test release, SEVERN. Problems with SEVERN should be reported via bugzilla, at: http://bugzilla.redhat.com/bugzilla/ Please report bugs against 'Fedora Core', release 'test3'. For more information on just what the Fedora Project and Fedora Core is, please see: http://fedora.redhat.com/ For discussion of SEVERN, send mail to: fedora-test-list-request at redhat.com with subscribe in the subject line. You can leave the body empty. Or see: https://listman.redhat.com/mailman/listinfo/fedora-test-list/ As always, you can get SEVERN at redhat.com, specifically: ftp://ftp.redhat.com/pub/redhat/linux/beta/severn/ Or the following mirrors: North America: United States: - ftp://redhat.dulug.duke.edu/pub/redhat/linux/beta/severn/ - ftp://mirror.hiwaay.net/redhat/redhat/linux/beta/severn/ - http://mirror.hiwaay.net/redhat/redhat/linux/beta/severn/ - http://www.gtlib.cc.gatech.edu/pub/redhat/linux/beta/severn/ - ftp://ftp.gtlib.cc.gatech.edu/pub/redhat/linux/beta/severn/ - rsync://rsync.gtlib.cc.gatech.edu/redhat/linux/beta/severn/ - ftp://linux.nssl.noaa.gov/linux/redhat/linux/beta/severn/ Europe: Czech Republic: - ftp://sunsite.mff.cuni.cz/MIRRORS/ftp.redhat.com/redhat/linux/beta/severn/ - ftp://ultra.linux.cz/MIRRORS/ftp.redhat.com/redhat/linux/beta/severn/ - ftp://ftp.linux.cz/pub/linux/redhat/linux/beta/severn/ - ftp://ftp6.linux.cz/pub/linux/redhat/linux/beta/severn/ Denmark: - ftp://klid.dk/pub/redhat/linux/beta/severn/ Finland: - ftp://ftp.funet.fi/pub/mirrors/ftp.redhat.com/redhat/linux/beta/severn/ - http://ftp.funet.fi/pub/mirrors/ftp.redhat.com/redhat/linux/beta/severn/ Germany: - ftp://ftp-stud.fht-esslingen.de/pub/redhat/beta/severn/ - http://ftp-stud.fht-esslingen.de/pub/redhat/beta/severn/ - ftp://ftp.tu-chemnitz.de/pub/linux/redhat-ftp/redhat/linux/beta/severn/ - http://wftp.tu-chemnitz.de/pub/linux/redhat-ftp/redhat/linux/beta/severn/ Netherlands: - ftp://alviss.et.tudelft.nl/pub/redhat/beta/severn/ - ftp://ftp.quicknet.nl/pub/Linux/ftp.redhat.com/beta/severn/ Portugal: - ftp://tux.cprm.net/pub/ftp.redhat.com/beta/severn/ One additional feature provided by the Linux community is the availability of SEVERN via BitTorrent. http://torrent.dulug.duke.edu/severn-binary-iso.torrent http://torrent.dulug.duke.edu/severn-src-iso.torrent RPMS for Red Hat Linux 7.3 through 9 of BitTorrent are available from: http://torrent.dulug.duke.edu/btrpms/ Usage is simple: btdownloadcurses.py --url http://URL.torrent Allow incoming TCP 6881 - 6889 to join the torrent swarm. http://torrent.dulug.duke.edu/ From lowen at pari.edu Mon Oct 13 19:29:52 2003 From: lowen at pari.edu (Lamar Owen) Date: Mon, 13 Oct 2003 15:29:52 -0400 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <1065990353.2836.66.camel@agnes.fremen.dune> References: <1065969643.2836.25.camel@agnes.fremen.dune> <1065977742.2687.31.camel@rousalka.dyndns.org> <1065990353.2836.66.camel@agnes.fremen.dune> Message-ID: <200310131529.52262.lowen@pari.edu> On Sunday 12 October 2003 04:25 pm, Jean Francois Martinez wrote: > Not necessarily. I was thinking in the web servers in an old Debian. > There were six of them: -Apache of course. -Boa because it was > faster than Apache -Another one whose main merit was to be zero conf > And three other ones I don't remember but who had no particular merit > (one of them being the obsolete NCSA server). I don't doubt they have > more than six by now One would have been AOLserver, which has a very good niche in the form of the OpenACS community system. AOLserver is a quite wonderful piece of multithreaded code (and has been since 1995). www.aolserver.com. It is much more lightweight than Apache, and for simple things or complex things is very fast. Embedded Tcl scripts in the web page is the norm; the config file is full tcl code and can include arbitrary tcl scripts. It's database connection capabilities are state of the art: true pooled connections allow you to serve many concurrent hits without connection startup penalties for each hit. Quite a piece of work. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From notting at redhat.com Mon Oct 13 20:04:01 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Oct 2003 16:04:01 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: ; from tdiehl@rogueind.com on Mon, Oct 13, 2003 at 01:27:38AM -0400 References: <20031009154130.A29659@devserv.devel.redhat.com> Message-ID: <20031013160401.A2400@devserv.devel.redhat.com> Tom Diehl (tdiehl at rogueind.com) said: > > Yup, just disable the keytable script. It probably needs to be > > removed anyway (it's superfluous). > > why is it superfluous?? I actually remap the del and backspace keys. Is there a > better way to do this?? keymaps are loaded in rc.sysinit already. Bill From dcbw at redhat.com Mon Oct 13 20:18:39 2003 From: dcbw at redhat.com (Dan Williams) Date: Mon, 13 Oct 2003 16:18:39 -0400 Subject: GCC-3.3 and OO.org In-Reply-To: <3F8AEA92.8010308@cypress.com> References: <3F86B58B.7080807@cypress.com> <1065811119.5001.1.camel@dhcp64-188.boston.redhat.com> <3F87063A.9000408@cypress.com> <1065818393.4800.6.camel@dhcp64-188.boston.redhat.com> <3F8AEA92.8010308@cypress.com> Message-ID: <1066076319.4213.17.camel@dhcp64-188.boston.redhat.com> Thomas, You may try mailing to users at dba.openoffice.org or dev at dba.openoffice.org since that's where the Sun OOo database engineers hang out. Dan On Mon, 2003-10-13 at 14:10, Thomas Dodd wrote: > Dan Williams wrote: > > Hi, > > > > OOo 1.1 packages shipped from Red Hat ship with Java support disabled, > > since Red Hat does not ship the Sun JDK or JRE. I use patches from the > > Debian project to accomplish this. Most anything relating to Java in > > OOo (ie DocBook XML filters, JDBC support, etc) will not work as > > expected. > > I'm not sure what parts of OO.org need java, but I wasn't talkingabout > JDBC in linux. > > > On Fri, 2003-10-10 at 15:19, Thomas Dodd wrote: > >>far. I'm having some trouble with ODBC/MySQL though I see the same > >>problem in Solaris with the OO.org build. > >> > >>Interesting I don't have problems using JDBC in Solaris (other than > >>speed :( ) or ODBC in Win98 and Excel (97 I think). > >>Time to get back on the OO.org lists... > > Notice MySQL+ODBC is problematic on Solaris too. > This is with an OO.org build and Sun's JVM configured. > The Solaris setup works fine with JDBC, but not ODBC. > > In linux, using the FC build of OOo1.1, I'm having trouble with > MySQL+ODBC as well. I haven't tried JDBC yet. > > Win98+Excel97+ODBC+MySQL works fine though. I think I'll try OOo1.1 on > Win98 to see if it's OOo1.1 + ODBC or the unixODBC+MySQL combination. > > Strange thing is, ODBC appears to be OK. Using isql, everything > functions fine. > > I'm wondering if what the real difference in using ODBC in OOo and the > MySQL driver is. Both appear to to use ODBC and odbc.ini to locate the data. > > The problem on Solaris is speed. Using JDBC takes for ever. The > mysql:odbc driver takes a long time to fail, same for just using odbc > the odbc interface. Win98+Excel+ODBC (SunPCI card w/ K6 and 64MB ram) is > much faster. > > I did some testing while writing this. Now I can use the datasources in > linux. I just have to setup queries, and use them. Either ODBC or MySQL > works this way. But I still cannot select a table in the data sources > veiw and see the columns in a give table. It is faster than Solaris though. > > -Thomas > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From derek.moore at sbcglobal.net Mon Oct 13 20:24:11 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Mon, 13 Oct 2003 13:24:11 -0700 (PDT) Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <3F89C340.7040506@gear.dyndns.org> Message-ID: <20031013202411.74299.qmail@web80008.mail.yahoo.com> > But you can only run one web server or mail server at once (at least on > the standard ports), and it makes sense to limit the number of this type > of packages. I would say that the web servers (and mail servers) are largely personal (or religious) choices. There are numerous quality web servers in existence: Apache, Cadium, thttpd, AOLserver, Boa, etc. While I'm an Apache man myself, I'd have to say I don't have any particularly solid reasons for using Apache over any of the other servers (other than I learned Apache first). I also don't see how having multiple web (or mail) servers in Fedora would be any sort of pain... Especially assuming Fedora is maintained by a large enough community. I'm also a sendmail man; I still haven't switched to Postfix (though I'm looking to). And I'm interested in giving Cadium a fair examination (because Pike looks damned interesting). Anyways, I just don't see how the web browsers situation is any different from the web servers situations (or how the mail clients situation is any different from the mail servers situation [I definately think Fedora should provide at least Sendmail, Postfix, and qmail {hotmail.com wouldn't use qmail if it wasn't good for something}]). Okay, I'm done now, Derek From derek.moore at sbcglobal.net Mon Oct 13 20:53:50 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Mon, 13 Oct 2003 13:53:50 -0700 (PDT) Subject: sane dependencies -- a positive look at 'fix your packages' In-Reply-To: <1066065152.524.95.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <20031013205350.73659.qmail@web80002.mail.yahoo.com> > Seriously, this is nothing but paranoid rambling. I'm not going to > waste time trying to debate with a raving zealot - discussion over. Just to be fair: From what I've read of your posts on this list, you sound like just as much of a raving zealot (if not more so). Discussion over. Okay, I'm done now, Derek From jfm512 at free.fr Mon Oct 13 19:52:10 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 13 Oct 2003 21:52:10 +0200 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <200310130752.h9D7q7o10819@devserv.devel.redhat.com> References: <200310130752.h9D7q7o10819@devserv.devel.redhat.com> Message-ID: <1066074729.1155.19.camel@agnes.fremen.dune> On Mon, 2003-10-13 at 09:52, Alan Cox wrote: > > There is nothing wrong with having dozens of web servers in an > > "everything for web serving" repository but in Fedora Core that is > > another thing: because of the drawbacks I mentioned you have to think in > > how useful are the features of teh additional program, how many people > > BADLY need them, how active is the maintenance of the program. And once > > you have thought about it you have to think again and again. > > Linux is a program and not a collection. It does include lots of sound > drivers, lots of disk drivers etc because there is a need to. > > To take another example - which should we throw out of fedora core > vi or emacs .... Clearly the answer is neither. Vi or Emacs cannot be thrown: too many people depend on one of them. On another hand an editor used by 0.1% of people would need to have LOTS of features not found in either VI or Emacs in order to be included. At 0.1% of user share if a program is included it should be because the distrib maintainer thinks a larger adoption of this program would be important for the future of Linux and not merely because it has a couple of nice features not found in the defending champion. > > I do broadly agree with you however. In the case of apache we have a > web server which does everything in the generic web serving space. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jean Francois Martinez From notting at redhat.com Mon Oct 13 20:07:10 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Oct 2003 16:07:10 -0400 Subject: rhgb-0.10.2-1 In-Reply-To: ; from behdad@cs.toronto.edu on Fri, Oct 10, 2003 at 09:58:58PM -0400 References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> Message-ID: <20031013160710.B2400@devserv.devel.redhat.com> Behdad Esfahbod (behdad at cs.toronto.edu) said: > A related question: Can't one ask kudzu to scan just a few > buses? Say, USB and firewire only? Setting SAFE=yes in /etc/sysconfig/kudzu turns off the PS/2 and serial probes, which are the big time sinks. > Another one (unrelated this time): Times to times applications > crash and leave sockets in /tmp that prevents them from starting > next time (I had the problem with xmms-1.2.7 atleast), is there > any problem with cleaning /tmp completely during boot time? Not at a system level, I believe, just at level of annoying people who put stuff there. :) Bill From ml at bendler-net.de Mon Oct 13 20:09:46 2003 From: ml at bendler-net.de (Thomas Bendler) Date: Mon, 13 Oct 2003 22:09:46 +0200 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924185857.A12115@devserv.devel.redhat.com> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <20030924201232.GB2764@pua.nirvana> <20030924163450.A7212@devserv.devel.redhat.com> <20030924223908.GG2764@pua.nirvana> <20030924185857.A12115@devserv.devel.redhat.com> Message-ID: <20031013200946.GB4874@ds9.private.bendler-net.de> Hi, On Mi, 24 Sep 2003, Bill Nottingham sent incredible lines: [...] > Such a script can be *easily* modifed to work with Fedora Core > in this case. It can key off of: > > a) 'Fedora Core' in /etc/redhat-release > b) the presence of /etc/fedora-release > c) the fact that fedora-release provides /etc/redhat-release [...] why not /etc/release?? Fedora/Red Hat is part of the content of /etc/redhat-release. So I don't see the sense of this construct but I see an advantage of /etc/release if other distros will follow your this approach. ... may the Tux be with you! =Thomas= -- Thomas Bendler \\:// ml at bendler-net.de Mettlerkampsweg 21 (o -) http://www.bendler-net.de/ 20535 Hamburg ---ooO-(_)-Ooo--- tel.: 0 177 - 277 37 61 Germany Linux, enjoy the ride ...! From wcooley at nakedape.cc Mon Oct 13 22:03:29 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Mon, 13 Oct 2003 15:03:29 -0700 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <20031013202411.74299.qmail@web80008.mail.yahoo.com> References: <20031013202411.74299.qmail@web80008.mail.yahoo.com> Message-ID: <1066082608.13356.1.camel@denk.nakedape.priv> On Mon, 2003-10-13 at 13:24, Derek P. Moore wrote: > Anyways, I just don't see how the web browsers situation is any different from > the web servers situations (or how the mail clients situation is any different > from the mail servers situation [I definately think Fedora should provide at > least Sendmail, Postfix, and qmail {hotmail.com wouldn't use qmail if it wasn't > good for something}]). Fedora cannot distribute qmail because DJB's license is too restrictive; likewise it also fails to meet either GNU or OSI definitions of "Free" or "Open Source". Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- 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 Oct 13 22:07:15 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 13 Oct 2003 19:07:15 -0300 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20031013200946.GB4874@ds9.private.bendler-net.de> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <20030924201232.GB2764@pua.nirvana> <20030924163450.A7212@devserv.devel.redhat.com> <20030924223908.GG2764@pua.nirvana> <20030924185857.A12115@devserv.devel.redhat.com> <20031013200946.GB4874@ds9.private.bendler-net.de> Message-ID: On Oct 13, 2003, Thomas Bendler wrote: > why not /etc/release?? One reason I can think of is that some random package for another distro might fail to install because it happens to require a -release package, that would then conflict with the original -release should both of them try to install different /etc/release files. I admit this is a convoluted scenario that I don't think I've ever seen in practice. Besides, Requiring a specific -release is probably bad practice anyway, so the packager deserves the incompatibility (too bad it's the installer that gets punished :-( That said, I do like /etc/release, at least as a soft-link, maybe not owned by RPM (to avoid the conflict described above) -- 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 wcooley at nakedape.cc Mon Oct 13 22:41:58 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Mon, 13 Oct 2003 15:41:58 -0700 Subject: rhgb-0.10.2-1 In-Reply-To: <20031013160710.B2400@devserv.devel.redhat.com> References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <20031013160710.B2400@devserv.devel.redhat.com> Message-ID: <1066084918.13389.2.camel@denk.nakedape.priv> On Mon, 2003-10-13 at 13:07, Bill Nottingham wrote: > > Another one (unrelated this time): Times to times applications > > crash and leave sockets in /tmp that prevents them from starting > > next time (I had the problem with xmms-1.2.7 atleast), is there > > any problem with cleaning /tmp completely during boot time? > > Not at a system level, I believe, just at level of annoying people who put > stuff there. :) I like to mount /tmp using tmpfs because I'm a BOFH :) 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 Oct 14 01:18:10 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 13 Oct 2003 21:18:10 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <20031013160401.A2400@devserv.devel.redhat.com> References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> Message-ID: On Mon, 13 Oct 2003, Bill Nottingham wrote: > Tom Diehl (tdiehl at rogueind.com) said: > > > Yup, just disable the keytable script. It probably needs to be > > > removed anyway (it's superfluous). > > > > why is it superfluous?? I actually remap the del and backspace keys. Is there a > > better way to do this?? > > keymaps are loaded in rc.sysinit already. Now that you are talking about rc.sysinit, I recall that on my laptop, I have just a few services to start, say less than five, and most of the boot time is by rc.sysinit, I can hack /etc/rc.d/rc to load services in parallel o some other thing, but rc.sysinit is much harder to hack to load faster, so what's the point in moving stuff there? > Bill behdad, From behdad at cs.toronto.edu Tue Oct 14 01:38:39 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 13 Oct 2003 21:38:39 -0400 Subject: rhgb-0.10.2-1 In-Reply-To: <3F8AED54.8040602@cypress.com> References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <1065861744.3616.5.camel@localhost.localdomain> <3F8AED54.8040602@cypress.com> Message-ID: On Mon, 13 Oct 2003, Thomas Dodd wrote: > Behdad Esfahbod wrote: > > On Sat, 11 Oct 2003, Julien Olivier wrote: > >>Hmmm... I think the best way to handle that would be to put a flag when > >>the computer has started cleanly and remove it when it has be shut down > >>cleanly. This, way, if it kernel-panics or crashes, the flag is still > >>there. > > > > > > I guess you misunderstood what I meant. I cannot see how you can > > handle the panics when you have no write access anywhere. The > > Looks like you missed it. This flag is set on boot, and cleared on > shutdown. If a panic happens, it's not cleared, and stiull set next > boot. During boot if the flag is set, you know you had a problem in the > shudown. I'm talking about when the kernel is still loading, and you have no writeable mounted filesystem to set the flag. > Don't we already have similar flags in / now? > Like .autofsck, which is cleared on shutdown/unmount. > Other flags I see in a quick glance at rc.sysinit include > forcefsck, fsckoptions, fastboot. > > -Thomas > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > behdad, who is going to study after finishing this mail. From notting at redhat.com Tue Oct 14 04:11:59 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 14 Oct 2003 00:11:59 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: ; from behdad@cs.toronto.edu on Mon, Oct 13, 2003 at 09:18:10PM -0400 References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> Message-ID: <20031014001159.B30496@devserv.devel.redhat.com> Behdad Esfahbod (behdad at cs.toronto.edu) said: > > keymaps are loaded in rc.sysinit already. > > Now that you are talking about rc.sysinit, I recall that on my > laptop, I have just a few services to start, say less than five, > and most of the boot time is by rc.sysinit, I can hack > /etc/rc.d/rc to load services in parallel o some other thing, but > rc.sysinit is much harder to hack to load faster, so what's the > point in moving stuff there? It makes more sense to have things associated with system boot there, as opposed to presenting them as a 'service'. There's nothing to prevent breaking up rc.sysinit into rcS.d (or similar) and parallelizing it, though. It's a simple matter of code. :) Bill From behdad at cs.toronto.edu Tue Oct 14 05:21:12 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 14 Oct 2003 01:21:12 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <20031014001159.B30496@devserv.devel.redhat.com> References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> <20031014001159.B30496@devserv.devel.redhat.com> Message-ID: On Tue, 14 Oct 2003, Bill Nottingham wrote: > Behdad Esfahbod (behdad at cs.toronto.edu) said: > > > keymaps are loaded in rc.sysinit already. > > > > Now that you are talking about rc.sysinit, I recall that on my > > laptop, I have just a few services to start, say less than five, > > and most of the boot time is by rc.sysinit, I can hack > > /etc/rc.d/rc to load services in parallel o some other thing, but > > rc.sysinit is much harder to hack to load faster, so what's the > > point in moving stuff there? > > It makes more sense to have things associated with system > boot there, as opposed to presenting them as a 'service'. Makes sense. > There's nothing to prevent breaking up rc.sysinit into rcS.d > (or similar) and parallelizing it, though. It's a simple matter > of code. :) Thanks for the idea. It makes it manageable too. When's the current initscripts schema going change? From the traffic here about MessageBus and other things, seems that it would be a major switch in some step. If it's not for FC2, hacking the current rc stuff seems reasonable. > Bill behdad, who is going to study after finishing this mail. From yinyang at eburg.com Tue Oct 14 06:11:42 2003 From: yinyang at eburg.com (Gordon Messmer) Date: Mon, 13 Oct 2003 23:11:42 -0700 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <20031013202411.74299.qmail@web80008.mail.yahoo.com> References: <20031013202411.74299.qmail@web80008.mail.yahoo.com> Message-ID: <3F8B939E.8090708@eburg.com> Derek P. Moore wrote: > > [I definately think Fedora should provide at > least Sendmail, Postfix, and qmail {hotmail.com wouldn't use qmail if it wasn't > good for something}]). Qmail's license precludes its being distributed as part of Fedora. As an alternative, I would suggest Courier-MTA: http://www.courier-mta.org/ Courier is configured very much like qmail (and resembles qmail in a number of other ways), but is actively maintained and supports all of the features you'd expect in a modern mailer. You can't really say that of qmail. From Nicolas.Mailhot at laPoste.net Tue Oct 14 07:03:18 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 14 Oct 2003 09:03:18 +0200 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> Message-ID: <1066114998.13820.1.camel@rousalka.dyndns.org> Le mar 14/10/2003 ? 03:18, Behdad Esfahbod a ?crit : > On Mon, 13 Oct 2003, Bill Nottingham wrote: > > > Tom Diehl (tdiehl at rogueind.com) said: > > > > Yup, just disable the keytable script. It probably needs to be > > > > removed anyway (it's superfluous). > > > > > > why is it superfluous?? I actually remap the del and backspace keys. Is there a > > > better way to do this?? > > > > keymaps are loaded in rc.sysinit already. Then would changing the default keyboard now translate in "please reboot now ?" I hope not. -- 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 Tue Oct 14 07:12:09 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 14 Oct 2003 09:12:09 +0200 Subject: rhgb-0.10.2-1 In-Reply-To: <20031013160710.B2400@devserv.devel.redhat.com> References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <20031013160710.B2400@devserv.devel.redhat.com> Message-ID: <1066115529.13820.4.camel@rousalka.dyndns.org> Le lun 13/10/2003 ? 22:07, Bill Nottingham a ?crit : > Behdad Esfahbod (behdad at cs.toronto.edu) said: > > A related question: Can't one ask kudzu to scan just a few > > buses? Say, USB and firewire only? > > Setting SAFE=yes in /etc/sysconfig/kudzu turns off the PS/2 and > serial probes, which are the big time sinks. And USB has no business being in a startup probe system like kudzu - usb belongs in hotplug scripts 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 Tue Oct 14 07:15:50 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 14 Oct 2003 09:15:50 +0200 Subject: rhgb-0.10.2-1 In-Reply-To: <1066084918.13389.2.camel@denk.nakedape.priv> References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <20031013160710.B2400@devserv.devel.redhat.com> <1066084918.13389.2.camel@denk.nakedape.priv> Message-ID: <1066115750.13820.8.camel@rousalka.dyndns.org> Le mar 14/10/2003 ? 00:41, Wil Cooley a ?crit : > On Mon, 2003-10-13 at 13:07, Bill Nottingham wrote: > > > > Another one (unrelated this time): Times to times applications > > > crash and leave sockets in /tmp that prevents them from starting > > > next time (I had the problem with xmms-1.2.7 atleast), is there > > > any problem with cleaning /tmp completely during boot time? > > > > Not at a system level, I believe, just at level of annoying people who put > > stuff there. :) > > I like to mount /tmp using tmpfs because I'm a BOFH :) And people usually like it better than being reminded to clean up their stuff -- Nicolas Mailhot Zealot -------------- 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 behdad at cs.toronto.edu Tue Oct 14 07:38:15 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 14 Oct 2003 03:38:15 -0400 Subject: rhgb-0.10.2-1 In-Reply-To: <1066115529.13820.4.camel@rousalka.dyndns.org> References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <20031013160710.B2400@devserv.devel.redhat.com> <1066115529.13820.4.camel@rousalka.dyndns.org> Message-ID: On Tue, 14 Oct 2003, Nicolas Mailhot wrote: > Le lun 13/10/2003 ? 22:07, Bill Nottingham a ?crit : > > Behdad Esfahbod (behdad at cs.toronto.edu) said: > > > A related question: Can't one ask kudzu to scan just a few > > > buses? Say, USB and firewire only? > > > > Setting SAFE=yes in /etc/sysconfig/kudzu turns off the PS/2 and > > serial probes, which are the big time sinks. > > And USB has no business being in a startup probe system like kudzu - usb > belongs in hotplug scripts Last time I remember needed to run kudzu to install a USB printer. Same for the scanner... > Cheers, behdad, From Nicolas.Mailhot at laPoste.net Tue Oct 14 07:58:07 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 14 Oct 2003 09:58:07 +0200 Subject: rhgb-0.10.2-1 In-Reply-To: References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <20031013160710.B2400@devserv.devel.redhat.com> <1066115529.13820.4.camel@rousalka.dyndns.org> Message-ID: <1066118287.28683.8.camel@ulysse.olympe.o2t> Le mar 14/10/2003 ? 09:38, Behdad Esfahbod a ?crit : > On Tue, 14 Oct 2003, Nicolas Mailhot wrote: > > > Le lun 13/10/2003 22:07, Bill Nottingham a crit : > > > Behdad Esfahbod (behdad at cs.toronto.edu) said: > > > > A related question: Can't one ask kudzu to scan just a few > > > > buses? Say, USB and firewire only? > > > > > > Setting SAFE=yes in /etc/sysconfig/kudzu turns off the PS/2 and > > > serial probes, which are the big time sinks. > > > > And USB has no business being in a startup probe system like kudzu - usb > > belongs in hotplug scripts > > Last time I remember needed to run kudzu to install a USB > printer. Same for the scanner... Sure - right now you need kudzu for this. But this does not mean you should do it here - kudzu for usb devices is an horror. They are typically never always-on (or always plugged in) which means if the user doesn't learn to plug and power-on everything before the boot sequence he'll be deluged with helpful kudzu messages asking him to remove printer, scanner... configuration. Kudzu is only good for build-in devices. And even for them the kernel people are moving to an hotplug-only setup. 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 behdad at cs.toronto.edu Tue Oct 14 08:02:54 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 14 Oct 2003 04:02:54 -0400 Subject: rhgb-0.10.2-1 In-Reply-To: <1066118287.28683.8.camel@ulysse.olympe.o2t> References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <20031013160710.B2400@devserv.devel.redhat.com> <1066115529.13820.4.camel@rousalka.dyndns.org> <1066118287.28683.8.camel@ulysse.olympe.o2t> Message-ID: On Tue, 14 Oct 2003, Nicolas Mailhot wrote: > Le mar 14/10/2003 ? 09:38, Behdad Esfahbod a ?crit : > > On Tue, 14 Oct 2003, Nicolas Mailhot wrote: > > > > > Le lun 13/10/2003 22:07, Bill Nottingham a crit : > > > > Behdad Esfahbod (behdad at cs.toronto.edu) said: > > > > > A related question: Can't one ask kudzu to scan just a few > > > > > buses? Say, USB and firewire only? > > > > > > > > Setting SAFE=yes in /etc/sysconfig/kudzu turns off the PS/2 and > > > > serial probes, which are the big time sinks. > > > > > > And USB has no business being in a startup probe system like kudzu - usb > > > belongs in hotplug scripts > > > > Last time I remember needed to run kudzu to install a USB > > printer. Same for the scanner... > > Sure - right now you need kudzu for this. > But this does not mean you should do it here - kudzu for usb devices is > an horror. They are typically never always-on (or always plugged in) > which means if the user doesn't learn to plug and power-on everything > before the boot sequence he'll be deluged with helpful kudzu messages > asking him to remove printer, scanner... configuration. This is another reason that one should chkconfig --level 2345 kudzu off ;) > Kudzu is only good for build-in devices. And even for them the kernel > people are moving to an hotplug-only setup. > > Regards, behdad From sct at redhat.com Tue Oct 14 09:53:00 2003 From: sct at redhat.com (Stephen C. Tweedie) Date: 14 Oct 2003 10:53:00 +0100 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <20031013202411.74299.qmail@web80008.mail.yahoo.com> References: <20031013202411.74299.qmail@web80008.mail.yahoo.com> Message-ID: <1066125180.3270.303.camel@sisko.scot.redhat.com> Hi, On Mon, 2003-10-13 at 21:24, Derek P. Moore wrote: > > But you can only run one web server or mail server at once (at least on > > the standard ports), and it makes sense to limit the number of this type > > of packages. > > I would say that the web servers (and mail servers) are largely personal (or > religious) choices. There are numerous quality web servers in existence: > Apache, Cadium, thttpd, AOLserver, Boa, etc. While I'm an Apache man myself, > I'd have to say I don't have any particularly solid reasons for using Apache > over any of the other servers (other than I learned Apache first). Have a look at http://fedora.redhat.com/participate/terminology.html Fedora Core is the core distribution, the one that the Severn test releases are examples of, the core of the O/S that Red Hat is assembling and over which Red Hat maintains editorial control. But Fedora Alternatives is defined on the same page --- that is intended to become exactly the place where all those alternative web servers can be developed and maintained by the community in a way that drops in cleanly into a Fedora Core system. Fedora *Core* is not going to support a dozen different web servers itself, but if there are developers willing to maintain the packages, we've got a place planned for them within the overall Fedora project and they are welcome there. There is no intention to limit the number of each type of package in Fedora Alternatives. It just needs developers willing to maintain the packages to an appropriate standard. > Anyways, I just don't see how the web browsers situation is any > different from the web servers situations (or how the mail clients > situation is any different from the mail servers situation [I > definately think Fedora should provide at least Sendmail, Postfix, and > qmail {hotmail.com wouldn't use qmail if it wasn't good for > something}]). Right, it's the same situation, same answer --- Fedora Core won't provide all the choices, but Fedora Alternatives will be able to if they fit the guidelines and if people contribute and maintain the packages. Cheers, Stephen From buildsys at porkchop.devel.redhat.com Tue Oct 14 10:01:03 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Tue, 14 Oct 2003 06:01:03 -0400 Subject: rawhide report: 20031014 changes Message-ID: <200310141001.h9EA13W14475@porkchop.devel.redhat.com> Updated Packages: curl-7.10.6-6 ------------- * Mon Oct 13 2003 Adrian Havill 7.10.6-6 - add OpenLDAP copyright notice for usage of code, add OpenLDAP license for this code dia-0.91-3 ---------- * Mon Oct 13 2003 Alexander Larsson 1:0.91-2 - Fix font size (backport from cvs). Fixes bug #106045 - Fix libxslt issue (bug #106863) * Wed Jun 04 2003 Elliot Lee - rebuilt * Wed May 28 2003 Alexander Larsson 1:0.91-1 - Update to 0.91 - Remove printing patch, it doesn't nearly apply yet, and might not be needed since dia is all utf8:y now. * Wed Jan 22 2003 Tim Powers - rebuilt * Fri Jan 10 2003 Alexander Larsson 0.90-9 - Remove duplicate desktop files * Fri Dec 06 2002 Havoc Pennington - rebuild * Tue Sep 03 2002 Akira TAGOH 0.90-8 - dia-0.90-printing.patch: applied to support CJK printing. (#67733) * Thu Aug 29 2002 Owen Taylor - Fix problems with the manual DTD * Wed Aug 28 2002 Owen Taylor - Pass --enable-db2html to configure so we get docs * Fri Aug 23 2002 Alexander Larsson 0.90-6 - Made desktopfile symlink absolute, fixes #71991 * Tue Aug 13 2002 Havoc Pennington - remove libpng10 patches, now using libpng12, #71416 * Mon Jul 29 2002 Havoc Pennington - put pristine upstream tarball back - fix up desktop files * Tue Jul 23 2002 Karsten Hopp - fix menu entry (#69564) * Fri Jun 21 2002 Tim Powers - automated rebuild * Tue Jun 11 2002 root 0.90-1 - Updated to 0.90 from upstream. Removed outdated patches, updated png10 patch. * Thu May 23 2002 Tim Powers - automated rebuild * Wed Jan 30 2002 Bill Nottingham - rebuild against png10 * Thu Jan 24 2002 Havoc Pennington - rebuild in rawhide * Thu Jul 19 2001 Havoc Penningtoon - Add some more build requires, #44732 * Tue Jul 10 2001 Alexander Larsson - Disable doc generation, since it breaks. * Mon Jul 09 2001 Alexander Larsson - Updated from upstream (0.88.1) - Removed source1 (ja.po) since it was in upstream - Disabled patch1 since it breaks 8bit non-multibyte locales. - Updated patch 3 * Fri Jun 15 2001 Havoc Penningtoon - add some BuildRequires * Fri Feb 23 2001 Trond Eivind Glomsr?d - langify - use %{_tmppath} * Fri Feb 09 2001 Akira TAGOH - -2 - Fixed install po. - Updated Japanese translation. Note: Please remove Source1: when release the next upstream version. - Added Japanese patch. - -3 - Fixed text render bug. * Mon Jan 29 2001 Preston Brown - upgraded to fix i18n issues (#24875) * Fri Aug 11 2000 Jonathan Blandford - Up Epoch and release * Fri Aug 04 2000 Havoc Pennington - Whatever, 15321 was already fixed (it's under plain Applications), change the group back * Fri Aug 04 2000 Havoc Pennington - Put it in Applications/Graphics bug 15321 * Wed Jul 12 2000 Prospector - automatic rebuild * Tue Jun 06 2000 Tim Powers - fixed manpage location - use %makinstall * Mon May 01 2000 Matt Wilson - updates to 0.84, added alpha back in * Mon Nov 08 1999 Tim Powers - updated to 0.81 * Mon Aug 30 1999 Tim Powers - changed group * Tue Aug 17 1999 Tim Powers - exludearch alpha dumps core when you do anything * Mon Jul 12 1999 Tim Powers - rebuilt for 6.1 * Wed Apr 28 1999 Preston Brown - initial build for Powertools 6.0 gkrellm-2.1.21-1 ---------------- * Mon Oct 13 2003 Karsten Hopp 2.1.21-1 - update: - fix temperature reads from /proc/acpi - Use username instead of userid in session management userid property. Fixes no session restarts in KDE 3.1.4. - de.po update hwbrowser-0.12-1 ---------------- * Mon Oct 13 2003 Brent Fox 0.12-1 - update language list (bug #106607) kdebase-3.1.4-4 --------------- * Tue Oct 14 2003 Than Ngo 6:3.1.4-4 - add patch to allow different icon size in kicker menu - don't reset icon size to 20x20 if it's greater than 20 * Fri Oct 10 2003 Than Ngo 6:3.1.4-3 - add patch files from Hans de Goede, (bug #63473, #80650, #80651) kdegames-3.1.4-2 ---------------- * Mon Oct 13 2003 Than Ngo 6:3.1.4-2 - backport from CVS to fix atlantikdesigner crashed on startup - fix miscompiled code, (bug #106198, #106888) man-1.5k-12 ----------- * Thu Oct 09 2003 Adrian Havill 1.5k-12 - restore russian locale (#81929) - force utf locale with jnroff (#105764) - don't let awk in makewhatis scan files that aren't man pages (#105594) mozilla-1.0.2-2.7.3 ------------------- * Fri Aug 09 2002 Christopher Blizzard 1.0.1-14 - Update to newer snapshot. - Require htmlview since the redhat-web.desktop is going to use it. * Thu Aug 08 2002 Christopher Blizzard - Update to a newer snapshot - Native themes patch (really, merge theme changes back from the trunk) * Sun Aug 04 2002 Christopher Blizzard - Update to a newer snapshot. * Thu Aug 01 2002 Christopher Blizzard - Update to a newer snapshot. * Wed Jul 24 2002 Christopher Blizzard - Use redhat-menus files. - Use over-the-spot by default. * Fri Jul 12 2002 Christopher Blizzard - Fix Comment section in desktop file. * Thu Jul 11 2002 Christopher Blizzard - Rebuild with newer snapshot. * Wed Jul 10 2002 Christopher Blizzard - Rebuild using gcc 2.96. * Mon Jul 08 2002 Chris Blizzard - Include patch to try to get flash working - Update to newer 1.0.1 snapshot * Mon Jul 01 2002 Chris Blizzard - Update to newer 1.0.1 snapshot - Move libs into the system that need to be there * Tue Jun 25 2002 Christopher Blizzard - Change mozilla-rebuild-databases.pl to remove compreg.dat as well as component.reg. * Sun Jun 23 2002 Chris Blizzard - Move nspr + nss back into /usr/lib * Thu Jun 20 2002 Christopher Blizzard - Time for a new changelog. mozilla-1.4.1-8 --------------- net-snmp-5.0.9-2 ---------------- * Mon Oct 13 2003 Phil Knirsch 5.0.9-2 - Due to rpm-devel we need elfutils-devel, too (#103982). php-4.3.3-4 ----------- * Mon Oct 13 2003 Joe Orton 4.3.3-4 - drop recode support, symbols collide with MySQL * Sun Oct 12 2003 Joe Orton 4.3.3-3 - split domxml extension into php-domxml subpackage - enable xslt and xml support in domxml extension (#106042) - fix httpd-devel build requirement (#104341) - enable recode extension (#106755) - add workaround for #103982 prelink-0.3.0-9 --------------- * Mon Oct 13 2003 Jakub Jelinek 0.3.0-9 - avoid prelink crash if first dependency is to be prelinked because of address space overlaps rawhide-release-20031014-1 -------------------------- redhat-config-keyboard-1.1.5-2 ------------------------------ * Mon Oct 13 2003 Brent Fox 1.1.5-2 - pull in Croatian translation (bug #106617) * Thu Aug 14 2003 Brent Fox 1.1.5-1 - tag on every build * Wed Jul 02 2003 Brent Fox 1.1.3-2 - bump release and rebuild redhat-config-language-1.0.16-1 ------------------------------- * Mon Oct 13 2003 Brent Fox 1.0.16-1 - rebuild for latest translations (bug #106618) redhat-config-mouse-1.1.2-1 --------------------------- * Tue Oct 14 2003 Brent Fox 1.1.2-1 - rebuild with latest translations redhat-config-xfree86-0.9.10-1 ------------------------------ * Mon Oct 13 2003 Brent Fox 0.9.10-1 - make sure current is initialized (bug #106884) * Mon Oct 06 2003 Brent Fox 0.9.9-3 - add a Requires for XFree86 (bug #105992) s390utils-1.2.1-1.1 ------------------- * Mon Oct 13 2003 Florian La Roche - rebuild for development stream * Thu Oct 09 2003 Harald Hoyer 2:1.2.1-1 - secound round at updating to 1.2.1 * Thu Oct 09 2003 Florian La Roche - first round at updating to 1.2.1 xcdroast-0.98a14-2 ------------------ * Mon Oct 13 2003 Harald Hoyer 0.98a14-2 - added patches from xcdroast.org to work again with the cdrtools-2.01a17 or newer. xmms-1.2.8-2.p -------------- * Mon Oct 13 2003 Than Ngo 1:1.2.8-2.p - workaround to fix arts crash xpdf-2.03-1 ----------- * Mon Oct 13 2003 Than Ngo 1:2.03-1 - 2.03 - remove xpdf-2.02pl1.patch, which is included in 2.03 - fix warning issue (bug #106313) - fix huge memory leak, (bug #89552) From paul at gear.dyndns.org Tue Oct 14 10:32:20 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Tue, 14 Oct 2003 20:32:20 +1000 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <1066082608.13356.1.camel@denk.nakedape.priv> References: <20031013202411.74299.qmail@web80008.mail.yahoo.com> <1066082608.13356.1.camel@denk.nakedape.priv> Message-ID: <3F8BD0B4.8000406@gear.dyndns.org> Wil Cooley wrote: > On Mon, 2003-10-13 at 13:24, Derek P. Moore wrote: > > >>Anyways, I just don't see how the web browsers situation is any different from >>the web servers situations (or how the mail clients situation is any different >>from the mail servers situation [I definately think Fedora should provide at >>least Sendmail, Postfix, and qmail {hotmail.com wouldn't use qmail if it wasn't >>good for something}]). > > > Fedora cannot distribute qmail because DJB's license is too restrictive; > likewise it also fails to meet either GNU or OSI definitions of "Free" > or "Open Source". Not to mention that they insist that filesystems must look like whatever-BSD if the software is going to work... -- Paul http://paulgear.webhop.net A: Because we read from top to bottom, left to right. Q: Why should i start my 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 julo at altern.org Tue Oct 14 10:38:16 2003 From: julo at altern.org (Julien Olivier) Date: Tue, 14 Oct 2003 11:38:16 +0100 Subject: rhgb-0.10.2-1 In-Reply-To: References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <1065861744.3616.5.camel@localhost.localdomain> <3F8AED54.8040602@cypress.com> Message-ID: <1066127896.3623.8.camel@localhost.localdomain> > I'm talking about when the kernel is still loading, and you have > no writeable mounted filesystem to set the flag. > OK, now I see your point. Sorry for forcing you to re-phrase it :) From paul at gear.dyndns.org Tue Oct 14 10:40:11 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Tue, 14 Oct 2003 20:40:11 +1000 Subject: Updated Fedora Core test release: Severn In-Reply-To: <20031013142502.A18694@devserv.devel.redhat.com> References: <20031013142502.A18694@devserv.devel.redhat.com> Message-ID: <3F8BD28B.3070808@gear.dyndns.org> Bill Nottingham wrote: > WONDER ... at the bugs that have been fixed! > > GROAN ... at the bugs that haven't been fixed! > > MARVEL ... at Bill actually getting the download location and torrent > names right! > > Yes, it's another update of the Fedora Core test release, SEVERN. > > Problems with SEVERN should be reported via bugzilla, at: > > http://bugzilla.redhat.com/bugzilla/ > > Please report bugs against 'Fedora Core', release 'test3'. Can we have up2date channels soon? -- Paul http://paulgear.webhop.net A: Because we read from top to bottom, left to right. Q: Why should i start my 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 bryan at arcamax.com Tue Oct 14 11:13:34 2003 From: bryan at arcamax.com (Bryan White) Date: Tue, 14 Oct 2003 07:13:34 -0400 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <1066063929.24321.6.camel@mirkwood.devel.redhat.com> References: <1065949938.1417.15.camel@homer.home> <1066012457.1916.84.camel@edoras.local.net> <20031013115334.GM17160@server4.8080.it> <1066063929.24321.6.camel@mirkwood.devel.redhat.com> Message-ID: <3F8BDA5E.6080201@arcamax.com> Jeremy Katz wrote: > Unfortunately, this release is probably the last where floppies have any > relevance. From 2.6 kernels so far, I really don't see how we're going > to be able to continue to have boot disks after moving to a 2.6 kernel. This will be painful. I have been setting up boxes with no CD and doing net installs from a floppy for a long time now. I like the idea of a USB boot into a network install but I suspect some of the older boxes (4-500Mhz Era) will not boot from USB. I picked up a USB keychain drive to do testing but never got it to the point where I could boot off of it. Does anybody know of a recipe or howto for doing such a thing, particularly for booting into a RedHat/Fedora network install. Alternatively, is there some way to create a floppy that would pull a boot image over the network? It would have to have a selection of network drivers. I have never looked into boot ROMs for NICs. That sounds like overkill just to launch an install. Bryan White From Nicolas.Mailhot at laPoste.net Tue Oct 14 11:47:50 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 14 Oct 2003 13:47:50 +0200 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <3F8BDA5E.6080201@arcamax.com> References: <1065949938.1417.15.camel@homer.home> <1066012457.1916.84.camel@edoras.local.net> <20031013115334.GM17160@server4.8080.it> <1066063929.24321.6.camel@mirkwood.devel.redhat.com> <3F8BDA5E.6080201@arcamax.com> Message-ID: <1066132069.3084.1.camel@ulysse.olympe.o2t> Le mar 14/10/2003 ? 13:13, Bryan White a ?crit : > Jeremy Katz wrote: > > Unfortunately, this release is probably the last where floppies have any > > relevance. From 2.6 kernels so far, I really don't see how we're going > > to be able to continue to have boot disks after moving to a 2.6 kernel. I do hope floppy kickstarting will still 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 xose at wanadoo.es Tue Oct 14 12:41:05 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Tue, 14 Oct 2003 14:41:05 +0200 Subject: Fedora and RedHat's autism toward personal users References: <20031013202411.74299.qmail@web80008.mail.yahoo.com> <3F8B939E.8090708@eburg.com> Message-ID: <3F8BEEE1.2020906@wanadoo.es> Gordon Messmer wrote: > Derek P. Moore wrote: > >> >> [I definately think Fedora should provide at >> least Sendmail, Postfix, and qmail {hotmail.com wouldn't use qmail if >> it wasn't >> good for something}]). > Qmail's license precludes its being distributed as part of Fedora. As > an alternative, I would suggest Courier-MTA: http://www.courier-mta.org/ http://cr.yp.to/distributors.html http://cr.yp.to/qmail/dist.html > Courier is configured very much like qmail (and resembles qmail in a > number of other ways), but is actively maintained and supports all of > the features you'd expect in a modern mailer. You can't really say that > of qmail. I think that postfix is enough, but zmailer is much better ;-) http://www.zmailer.org -- Software is like sex, it's better when it's bug free. From jkt at redhat.com Tue Oct 14 13:32:01 2003 From: jkt at redhat.com (Jay Turner) Date: Tue, 14 Oct 2003 09:32:01 -0400 Subject: Updated Fedora Core test release: Severn In-Reply-To: <3F8BD28B.3070808@gear.dyndns.org> References: <20031013142502.A18694@devserv.devel.redhat.com> <3F8BD28B.3070808@gear.dyndns.org> Message-ID: <20031014133201.GC30474@redhat.com> On Tue, Oct 14, 2003 at 08:40:11PM +1000, Paul Gear wrote: > Can we have up2date channels soon? You're best bet is to grab the latest up2date and up2date-gnome, as well as fedora-release from the FTP site and run that. We've switched to Yum repositories being the default, so RHN channels are no longer a necessity for registration and use of up2date. - jkt -- --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--* Jay Turner, QA Technical Lead jkt at redhat.com Red Hat, Inc. Reality is merely an illusion, albeit a very persistent one. - Albert Einstein From notting at redhat.com Tue Oct 14 13:52:27 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 14 Oct 2003 09:52:27 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <1066114998.13820.1.camel@rousalka.dyndns.org>; from Nicolas.Mailhot@laPoste.net on Tue, Oct 14, 2003 at 09:03:18AM +0200 References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> <1066114998.13820.1.camel@rousalka.dyndns.org> Message-ID: <20031014095227.A18136@devserv.devel.redhat.com> Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > > keymaps are loaded in rc.sysinit already. > > Then would changing the default keyboard now translate in "please reboot > now ?" I hope not. I'm not sure I understand your question - could you rephrase? Bill From ted at cypress.com Tue Oct 14 13:57:05 2003 From: ted at cypress.com (Thomas Dodd) Date: Tue, 14 Oct 2003 08:57:05 -0500 Subject: rhgb-0.10.2-1 In-Reply-To: <1066118287.28683.8.camel@ulysse.olympe.o2t> References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <20031013160710.B2400@devserv.devel.redhat.com> <1066115529.13820.4.camel@rousalka.dyndns.org> <1066118287.28683.8.camel@ulysse.olympe.o2t> Message-ID: <3F8C00B1.9070307@cypress.com> Nicolas Mailhot wrote: > Sure - right now you need kudzu for this. > But this does not mean you should do it here - kudzu for usb devices is > an horror. They are typically never always-on (or always plugged in) > which means if the user doesn't learn to plug and power-on everything > before the boot sequence he'll be deluged with helpful kudzu messages > asking him to remove printer, scanner... configuration. Only once. You tell kudzu not to ask about it again. Still not sure i want the hot plug scripts handling more than they do now. They do bad enough there. -Thomas From kaboom at gatech.edu Tue Oct 14 13:59:04 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Tue, 14 Oct 2003 09:59:04 -0400 (EDT) Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <3F8B939E.8090708@eburg.com> Message-ID: On Mon, 13 Oct 2003, Gordon Messmer wrote: > Derek P. Moore wrote: > > > > [I definately think Fedora should provide at > > least Sendmail, Postfix, and qmail {hotmail.com wouldn't use qmail if it wasn't > > good for something}]). > > Qmail's license precludes its being distributed as part of Fedora. As > an alternative, I would suggest Courier-MTA: http://www.courier-mta.org/ > > Courier is configured very much like qmail (and resembles qmail in a > number of other ways), but is actively maintained and supports all of > the features you'd expect in a modern mailer. You can't really say that > of qmail. The last thing that's needed is still more MTAs in Fedora. That stuff belongs in the add-on repositories, like Fedora Alternatives. later, chris From ted at cypress.com Tue Oct 14 14:01:40 2003 From: ted at cypress.com (Thomas Dodd) Date: Tue, 14 Oct 2003 09:01:40 -0500 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <20031014095227.A18136@devserv.devel.redhat.com> References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> <1066114998.13820.1.camel@rousalka.dyndns.org> <20031014095227.A18136@devserv.devel.redhat.com> Message-ID: <3F8C01C4.8010701@cypress.com> Bill Nottingham wrote: > Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > >>>>keymaps are loaded in rc.sysinit already. >> >>Then would changing the default keyboard now translate in "please reboot >>now ?" I hope not. > > > I'm not sure I understand your question - could you rephrase? Instead of "service keytable reload" you now need to re-run rc.sysinit. Is it safe to run rc.sysinit at runlevel 3 or 5? -Thomas From mharris at redhat.com Tue Oct 14 14:04:36 2003 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 14 Oct 2003 10:04:36 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: <3F86CBD0.5090209@cypress.com> References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <1065696476.3713.3.camel@ulysse.olympe.o2t> <3F86CBD0.5090209@cypress.com> Message-ID: On Fri, 10 Oct 2003, Thomas Dodd wrote: >> So am I, but any time something changes, I can't contact n random >> developers and tell them what chagnes to incorporate into their >> packages very easily, and if I make a document and put it >> somewhere, I have no guarantee anyone will read it. I've direct > >You did what you could. It's up to the otheres to do their part. >Post the doc, add it to the XF86 rpms with a link to the current >version. After that it's up to others to follow. >Just like when any other developer changes a system used by others. >I cna tell you it's changed, but cannot force you to change. >(I still miss the XF86 setup tools. I usually build them myself though. >If someone wrote secondary config tool that required the XF86 versions, >it's not your job to fix it. They were told to change, it's up to them >to do so.) The XFree86 supplied config tools are gone for 2 main reasons: 1) They really do suck. 2) In many cases, people use them simply because they don't know what our tool is called, or can't find Xconfigurator, or some similar issue. They just want to configure X, and so they end up using those tools, and end up with tonnes of problems trying to get X to work, and often file bug reports, or have to hit the lists. 3) The more people using xf86config or xf86cfg, or X -configure, the less people using and testing our tool, so the less bugs we're aware of, and the less bugs we will be likely to fix in our tool. The biggest issue for me, is people using the broken XFree86 supplied tools and expecting them to work. They truely are not very reliable, and they open up a _lot_ of doors for people to shoot themselves square in the foot. Technically inclined users who really do want to use those tools for whatever reason, such as yourself, tend to be able to figure out how to compile them themselves fairly easily, and those people also are responsible enough usually to figure out any problems they encounter, etc. >> There is also a problem where all fonts could theoretically be >> used by both xfs and also fontconfig/Xft, however we only want >> the given fonts to be in one or the other of those 2 systems for >> whatever preferential reasons we have. One example is the Luxi >> TTF font. Last I checked, we only enable this in core fonts and >> not in fontconfig, because the Luxi Type1 font is nicer looking >> in fontconfig than Luxi TTF. > >Sounds like the fonts need fixed. The Type1 and TTF version should look >the same (within the limits of the format). In the above, the Luxi TTF >should be fixed, possibly removed untill it is fixed. The Luxi TTF font isn't broken, so it can't be fixed. The Type1 font looks nicer because the Type1 font rendering technology isn't hindered by alleged patents like truetype rendering is. Also, I'm not sure if Luxi even has hints in it, and wether or not they're decent. I can disable the Luxi TTF font if Owen and others think that's a good idea. I think keeping it out of fontconfig should be adequate though more or less. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From notting at redhat.com Tue Oct 14 14:11:33 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 14 Oct 2003 10:11:33 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <3F8C01C4.8010701@cypress.com>; from ted@cypress.com on Tue, Oct 14, 2003 at 09:01:40AM -0500 References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> <1066114998.13820.1.camel@rousalka.dyndns.org> <20031014095227.A18136@devserv.devel.redhat.com> <3F8C01C4.8010701@cypress.com> Message-ID: <20031014101133.A1270@devserv.devel.redhat.com> Thomas Dodd (ted at cypress.com) said: > > I'm not sure I understand your question - could you rephrase? > > Instead of "service keytable reload" you now need to re-run rc.sysinit. > Is it safe to run rc.sysinit at runlevel 3 or 5? No. How often do you need to reload the keytable? Note that to do it by hand is just: loadkeys $KEYTABLE.map Bill From notting at redhat.com Tue Oct 14 14:13:01 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 14 Oct 2003 10:13:01 -0400 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: ; from kaboom@gatech.edu on Tue, Oct 14, 2003 at 09:59:04AM -0400 References: <3F8B939E.8090708@eburg.com> Message-ID: <20031014101301.B1270@devserv.devel.redhat.com> Chris Ricker (kaboom at gatech.edu) said: > The last thing that's needed is still more MTAs in Fedora. That stuff > belongs in the add-on repositories, like Fedora Alternatives. Alternatives is for different versions of things *in* Fedora Core. Extras would be for exim/zmailer/courier/chuckmail. Bill From Nicolas.Mailhot at laPoste.net Tue Oct 14 14:14:12 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 14 Oct 2003 16:14:12 +0200 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <20031014095227.A18136@devserv.devel.redhat.com> References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> <1066114998.13820.1.camel@rousalka.dyndns.org> <20031014095227.A18136@devserv.devel.redhat.com> Message-ID: <1066140852.5201.2.camel@ulysse.olympe.o2t> Le mar 14/10/2003 ? 15:52, Bill Nottingham a ?crit : > Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > > > keymaps are loaded in rc.sysinit already. > > > > Then would changing the default keyboard now translate in "please reboot > > now ?" I hope not. > > I'm not sure I understand your question - could you rephrase? Last time I had to tweak my keyboard I validated the changes with /etc/init.d/key* restart. And now you remove this script. So I'm a bit worried - what will happen next time I need to fiddle with 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 mharris at redhat.com Tue Oct 14 14:16:12 2003 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 14 Oct 2003 10:16:12 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: <3F86CE6C.9030601@cypress.com> References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <3F86CE6C.9030601@cypress.com> Message-ID: On Fri, 10 Oct 2003, Thomas Dodd wrote: >> xfs is "deprecated" in the sense that all new applications will >> be using the new Xft/fontconfig infrastructure, and I had this > >I'm curious about that. With out xfs, how do I share fonts between >machines? Use xfs if you need it. Or, use NFS or SMB. >I currently have fon't from 3 systems (Linux, Solaris, and >HP-UX) shared using xfs so I don't have to keep multiple copies. >There are also potential legal issues in coping the files form >one OS to another. NFS/SMB/xfs all exist currently, so I don't see any issue. >> useable. In a case like that for example, my XFree86 4.3.0 >> packages couldn't easily be recompiled for Red Hat Linux 8.0 and >> expected to work. Another option is a font installation script, >> but that suffers from the last problem I described also. > >External package is needed. Be it a script or a C program. >When you make the decision to create it, make version fro the systems >you plan to continue supporting. So there's the RHL8, RHL9, and FC-x >versions, that understand the differences in each setup. Using >nonstandard X,GNOME, and such on those systems are unsupportable any >way, so If I update my RHL8 system to act like FC1, it's up to me to fix >the font installation program. Since the support of older systems is >based on your kindness, you set the rules of such support. We simply don't drop new development of that type into older distribution releases. Security fixes and major bugfixes only. Anything "new" goes into rawhide. I wont waste my time creating any kind of font installation script until there is public discussion of all issues that can arise with font installation, which ones we can/should solve, and discuss proposed solutions, debate them, and come up with a proposal and perhaps a sample implementation that does what is needed - or multiple implementations and review and pick one. At that point, it has to be made a mandatory font package requirement in _all_ packages that provide fonts, and have a properly and well documented policy that is religiously followed. I'd prefer if this happens that buildsystem tests are also created to enforce it, and packages failed at build time if they do not follow proper font installation policy. That's about the only way we'll ever have consistent policy IMHO, is via machine automation and checking. Humans (all of us, including me), are susceptible to programmer error, goofing up, not realizing some new method must be used, or not remembering it 6 months later, etc. Policy is needed, and must be agreed upon first. Then implementation, and testing. >> I admit that fonts and font related problems in general are a >> huge mess, however it isn't limited to our distribution, but is a >> result more of XFree86 having archaic font technology for so many >> years. It'll take a few more years to shake the uglies out of >> the font infrastructure. > >How exactly did X get such a screwed up system? It was a good system at the time it was created. It did the job and did it fairly well. Over time, computing usage changed in different ways, and X never really followed. >Why was it never corrected? 2 answers: 1) It was never corrected, because the existing method did the job good enough for a very long time. It is only recently in the last 3 years or so where there has been any significant interest of Linux/X on the desktop, and font issues have surfaced as important. 2) It has been corrected - at least somewhat, by fontconfig and Xft now. >How do other systems, especially OS-X handle it? You'll have to ask Apple I guess. Keep in mind, Apple MacOS was a desktop OS from day 1, as was Windows. X was not really, and hasn't been considered such until very recently. Asking why fonts don't work as good in X as they do in OS/X for example is like asking why Windows ME doesn't support 16 processor NUMA hardware.... It wasn't designed to do so. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From Nicolas.Mailhot at laPoste.net Tue Oct 14 14:18:05 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 14 Oct 2003 16:18:05 +0200 Subject: rhgb-0.10.2-1 In-Reply-To: <3F8C00B1.9070307@cypress.com> References: <20031010182538.26975.qmail@linuxmail.org> <20031010150421.C16771@devserv.devel.redhat.com> <20031013160710.B2400@devserv.devel.redhat.com> <1066115529.13820.4.camel@rousalka.dyndns.org> <1066118287.28683.8.camel@ulysse.olympe.o2t> <3F8C00B1.9070307@cypress.com> Message-ID: <1066141084.5201.7.camel@ulysse.olympe.o2t> Le mar 14/10/2003 ? 15:57, Thomas Dodd a ?crit : > Nicolas Mailhot wrote: > > Sure - right now you need kudzu for this. > > But this does not mean you should do it here - kudzu for usb devices is > > an horror. They are typically never always-on (or always plugged in) > > which means if the user doesn't learn to plug and power-on everything > > before the boot sequence he'll be deluged with helpful kudzu messages > > asking him to remove printer, scanner... configuration. > > Only once. You tell kudzu not to ask about it again. > > Still not sure i want the hot plug scripts handling more than they do > now. They do bad enough there. I will readily admit it was a /sbin/chkconfig --level 0123456 kudzu off for me. And I'm sure I'm far from the only one. As for the hotplug scripts - they are perhaps as bad as kudzu right now but they have a chance to improve, while kudzu's on-boot scanning is conceptually flawed as soon as you get hotplug devices into the picture. 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 Nicolas.Mailhot at laPoste.net Tue Oct 14 14:22:49 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 14 Oct 2003 16:22:49 +0200 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <20031014101133.A1270@devserv.devel.redhat.com> References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> <1066114998.13820.1.camel@rousalka.dyndns.org> <20031014095227.A18136@devserv.devel.redhat.com> <3F8C01C4.8010701@cypress.com> <20031014101133.A1270@devserv.devel.redhat.com> Message-ID: <1066141368.5201.10.camel@ulysse.olympe.o2t> Le mar 14/10/2003 ? 16:11, Bill Nottingham a ?crit : > Thomas Dodd (ted at cypress.com) said: > > > I'm not sure I understand your question - could you rephrase? > > > > Instead of "service keytable reload" you now need to re-run rc.sysinit. > > Is it safe to run rc.sysinit at runlevel 3 or 5? > > No. > > How often do you need to reload the keytable? Note that to do it > by hand is just: > > loadkeys $KEYTABLE.map Last I looked the script did more than this. And yes when you change this you rarely get it working at once, so having a foolproof script did help a lot. 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 Tue Oct 14 14:27:33 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 14 Oct 2003 16:27:33 +0200 Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <3F86CE6C.9030601@cypress.com> Message-ID: <1066141653.5201.16.camel@ulysse.olympe.o2t> Le mar 14/10/2003 ? 16:16, Mike A. Harris a ?crit : > On Fri, 10 Oct 2003, Thomas Dodd wrote: > >I currently have fon't from 3 systems (Linux, Solaris, and > >HP-UX) shared using xfs so I don't have to keep multiple copies. > >There are also potential legal issues in coping the files form > >one OS to another. > > NFS/SMB/xfs all exist currently, so I don't see any issue. nfs sucks wrt port filtering, smb sucks at the protocol level, and will xfs work with fontconfig ? A network filesystem that actually just works would be so nice (dreaming...) -- 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 Tue Oct 14 14:36:43 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 14 Oct 2003 10:36:43 -0400 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <1066141368.5201.10.camel@ulysse.olympe.o2t>; from Nicolas.Mailhot@laPoste.net on Tue, Oct 14, 2003 at 04:22:49PM +0200 References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> <1066114998.13820.1.camel@rousalka.dyndns.org> <20031014095227.A18136@devserv.devel.redhat.com> <3F8C01C4.8010701@cypress.com> <20031014101133.A1270@devserv.devel.redhat.com> <1066141368.5201.10.camel@ulysse.olympe.o2t> Message-ID: <20031014103643.A16662@devserv.devel.redhat.com> Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > How often do you need to reload the keytable? Note that to do it > > by hand is just: > > > > loadkeys $KEYTABLE.map > > Last I looked the script did more than this. Actually, yes, but the only other thing is calling setsysfont (with no arguments). Bill From behdad at cs.toronto.edu Tue Oct 14 14:47:43 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 14 Oct 2003 10:47:43 -0400 Subject: FriBidi needed? Message-ID: Hi all, AFAIK fribidi is included in FC as AbiWord requires it, but just now I found that abiword SRPM contains a copy of the fribidi it needs. So is there any other reason for it to be in? I'm asking it because fribidi is going to have a major release which is not ABI compatible, so if there's no reason for the inclusion, I (as the maintainer) prefer it not to be. behdad, From behdad at cs.toronto.edu Tue Oct 14 14:53:54 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 14 Oct 2003 10:53:54 -0400 Subject: FriBidi needed? In-Reply-To: References: Message-ID: Answering myself: in abiword-2.0.0/abi/ac-helpers/abi-fribidi.m4 it says: echo "Note: Don't use the fribidi source which is sometimes" echo " included with AbiWord since that version is for" echo " Windows only." behdad On Tue, 14 Oct 2003, it was written: > Hi all, > > AFAIK fribidi is included in FC as AbiWord requires it, but just > now I found that abiword SRPM contains a copy of the fribidi it > needs. So is there any other reason for it to be in? I'm asking > it because fribidi is going to have a major release which is not > ABI compatible, so if there's no reason for the inclusion, I (as > the maintainer) prefer it not to be. > > > behdad, > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > behdad, who is going to study after finishing this mail. From Nicolas.Mailhot at laPoste.net Tue Oct 14 14:55:04 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 14 Oct 2003 16:55:04 +0200 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <20031014103643.A16662@devserv.devel.redhat.com> References: <20031009154130.A29659@devserv.devel.redhat.com> <20031013160401.A2400@devserv.devel.redhat.com> <1066114998.13820.1.camel@rousalka.dyndns.org> <20031014095227.A18136@devserv.devel.redhat.com> <3F8C01C4.8010701@cypress.com> <20031014101133.A1270@devserv.devel.redhat.com> <1066141368.5201.10.camel@ulysse.olympe.o2t> <20031014103643.A16662@devserv.devel.redhat.com> Message-ID: <1066143303.5201.19.camel@ulysse.olympe.o2t> Le mar 14/10/2003 ? 16:36, Bill Nottingham a ?crit : > Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > > How often do you need to reload the keytable? Note that to do it > > > by hand is just: > > > > > > loadkeys $KEYTABLE.map > > > > Last I looked the script did more than this. > > Actually, yes, but the only other thing is calling setsysfont > (with no arguments). Which I'd have probably never thought about myself at the time... keytable was just damn convenient, a big monolithic script isn't. 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 dcbw at redhat.com Tue Oct 14 15:22:11 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 14 Oct 2003 11:22:11 -0400 Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <3F86CE6C.9030601@cypress.com> Message-ID: <1066144931.4302.11.camel@dhcp64-188.boston.redhat.com> > >How do other systems, especially OS-X handle it? > > You'll have to ask Apple I guess. http://developer.apple.com/documentation/Carbon/Conceptual/ATS_Concepts/atsfonts_intro/index.html OS X handles it quite well and quite transparently. However, it's also not built to do the network operations X11 is, so that's one thing X11 has over OS X if you're into things like that. But you can share fonts using ASIP, SMB, NFS, etc. In any case, here's a quick breakdown: ATS Server: The ATS client communicates directly to the ATS server, which is a separate process. The ATS server maintains the font database and performs such tasks as activating and deactivating fonts, supplying glyph outline data, and obtaining information from font tables. -- worth noting that clients (applications or higher-level frameworks like Cocoa/Carbon) never really access font tables directly, nor do they ever really _need_ to have access to the font file itself. Font locations: ~/Library/Fonts - fonts specific for a user /Library/Fonts - fonts for all users on the local machine /System/Library/Fonts - core system fonts and never altered /Network/Library/Fonts - network shared fonts Applications can also receive notifications of font activation/deactivation so they know to update their font menus or font lists. Its a fairly clean system, deals with almost all types of fonts transparently, and of course it can use the TrueType hinting since Apple has these "patents". Dan From yinyang at eburg.com Tue Oct 14 15:30:03 2003 From: yinyang at eburg.com (Gordon Messmer) Date: Tue, 14 Oct 2003 08:30:03 -0700 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <3F8BEEE1.2020906@wanadoo.es> References: <20031013202411.74299.qmail@web80008.mail.yahoo.com> <3F8B939E.8090708@eburg.com> <3F8BEEE1.2020906@wanadoo.es> Message-ID: <3F8C167B.4000909@eburg.com> Xose Vazquez Perez wrote: > Gordon Messmer wrote: > >>Qmail's license precludes its being distributed as part of Fedora. As >>an alternative, I would suggest Courier-MTA: http://www.courier-mta.org/ > > > http://cr.yp.to/distributors.html I'm well aware of qmail's license. It's been discussed here on a number of occasions past. Specifically, that page notes: You may distribute a precompiled package if installing your package produces exactly the same files, in exactly the same locations, that a user would obtain by installing one of my packages listed That alone is enough to prevent distribution. A distributor can not ship bug fixes in a binary form. You can debate it all you want, but I suggest that you look at the previous debates instead. I know of a number of people who still use qmail, and are very fond of it. That's very well and good, but the license is going to keep qmail in the hands of the people who want to build it for themselves, and out of distributions that care about Free Software. >>Courier is configured very much like qmail (and resembles qmail in a >>number of other ways), but is actively maintained and supports all of >>the features you'd expect in a modern mailer. You can't really say that >>of qmail. > > > I think that postfix is enough, but zmailer is much better ;-) http://www.zmailer.org Courier can't be compared directly to postfix or zmailer, since it provides much more than they do. Courier is a complete mail system, providing the MTA, POP/IMAP/SMAP servers, webmail, the MDA, the fax server, and the mail list manager. All of those components are optional, and pretty much all of them can be replaced with common components (it'll interoperate with what you're currently using, if that's what you want). From ted at cypress.com Tue Oct 14 15:38:14 2003 From: ted at cypress.com (Thomas Dodd) Date: Tue, 14 Oct 2003 10:38:14 -0500 Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <1065696476.3713.3.camel@ulysse.olympe.o2t> <3F86CBD0.5090209@cypress.com> Message-ID: <3F8C1866.4040503@cypress.com> Mike A. Harris wrote: > On Fri, 10 Oct 2003, Thomas Dodd wrote: > > >>>So am I, but any time something changes, I can't contact n random >>>developers and tell them what chagnes to incorporate into their >>>packages very easily, and if I make a document and put it >>>somewhere, I have no guarantee anyone will read it. I've direct >> >>You did what you could. It's up to the otheres to do their part. >>Post the doc, add it to the XF86 rpms with a link to the current >>version. After that it's up to others to follow. >>Just like when any other developer changes a system used by others. >>I cna tell you it's changed, but cannot force you to change. >>(I still miss the XF86 setup tools. I usually build them myself though. >>If someone wrote secondary config tool that required the XF86 versions, >>it's not your job to fix it. They were told to change, it's up to them >>to do so.) > > > The XFree86 supplied config tools are gone for 2 main reasons: Not that I was arguing (again) for their inclusion :) The point being, somone could use the XF86 tools as part of YAXCT (yet another X config tool). No that RHL/RHEL/FC don't include them their app would break. It's not your responsibility, as Red Hat X maintainer, to fix their tool is it? You wouldn't keep the XF86 stuff around for it, would you? No, you said it was going away, then it went away. It's up to them to fix their app, either integrate the XF86 parts, or modify the too to use the new Red Hat parts. > 2) In many cases, people use them simply because they don't know Those are the tools mentioned in the documentation for XF86 though. >>Sounds like the fonts need fixed. The Type1 and TTF version should look >>the same (within the limits of the format). In the above, the Luxi TTF >>should be fixed, possibly removed untill it is fixed. > > > The Luxi TTF font isn't broken, so it can't be fixed. The Type1 > font looks nicer because the Type1 font rendering technology > isn't hindered by alleged patents like truetype rendering is. > Also, I'm not sure if Luxi even has hints in it, and wether or > not they're decent. Since I don't use either of them, I wouldn't know. Sounds like another example of "the evils of software patents". > I can disable the Luxi TTF font if Owen and others think that's a > good idea. I think keeping it out of fontconfig should be > adequate though more or less. I'd never know it was missing. I never use more than Helvetica, Times, Courier, and occasionaly Zapf Chancery:) The new Bitstream Vera fonts looked OK in OO.org, but I stuck with what I like... -Thomas From tdiehl at rogueind.com Tue Oct 14 15:41:37 2003 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 14 Oct 2003 11:41:37 -0400 (EDT) Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: <1066140852.5201.2.camel@ulysse.olympe.o2t> Message-ID: On Tue, 14 Oct 2003, Nicolas Mailhot wrote: > Le mar 14/10/2003 ? 15:52, Bill Nottingham a ?crit : > > Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > > > > keymaps are loaded in rc.sysinit already. > > > > > > Then would changing the default keyboard now translate in "please reboot > > > now ?" I hope not. > > > > I'm not sure I understand your question - could you rephrase? > > Last time I had to tweak my keyboard I validated the changes with > /etc/init.d/key* restart. And now you remove this script. So I'm a bit > worried - what will happen next time I need to fiddle with it ? As Bill said in a previous post "loadkeys $KEYTABLE.map" That is for all practical purposes the same thing. Remember TIMTOWTDI!! :-) -- ......Tom Registered Linux User #14522 http://counter.li.org tdiehl at rogueind.com My current SpamTrap -------> mtd123 at rogueind.com From ted at cypress.com Tue Oct 14 15:42:33 2003 From: ted at cypress.com (Thomas Dodd) Date: Tue, 14 Oct 2003 10:42:33 -0500 Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <3F86CE6C.9030601@cypress.com> Message-ID: <3F8C1969.9060107@cypress.com> Mike A. Harris wrote: > On Fri, 10 Oct 2003, Thomas Dodd wrote: > > >>>xfs is "deprecated" in the sense that all new applications will >>>be using the new Xft/fontconfig infrastructure, and I had this >> >>I'm curious about that. With out xfs, how do I share fonts between >>machines? > > > Use xfs if you need it. Or, use NFS or SMB. As a user I can 'xset +fp ; xset fp rehash'. I cannot export/mount filesystems. >>External package is needed. Be it a script or a C program. >>When you make the decision to create it, make version fro the systems >>you plan to continue supporting. So there's the RHL8, RHL9, and FC-x >>versions, that understand the differences in each setup. Using >>nonstandard X,GNOME, and such on those systems are unsupportable any >>way, so If I update my RHL8 system to act like FC1, it's up to me to fix >>the font installation program. Since the support of older systems is >>based on your kindness, you set the rules of such support. > > > We simply don't drop new development of that type into older > distribution releases. Security fixes and major bugfixes only. > Anything "new" goes into rawhide. I said you set the rules:) -Thomas From behdad at cs.toronto.edu Tue Oct 14 15:44:02 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 14 Oct 2003 11:44:02 -0400 Subject: OO.o from rawhide build Message-ID: Hi I'm trying to build OO.o from rawhide SRPM. The configure is called as: ./configure --enable-libart --enable-libsn --with-lang="%{languages}" --disable-java --with-mozilla But I still get: checking whether to build with Java support... no checking for javac... no checking for java... /usr/java/jre/bin/java checking the installed JDK... configure: error: JDK is too old, you need at least 1.3 Weird, behdad, From dcbw at redhat.com Tue Oct 14 15:50:37 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 14 Oct 2003 11:50:37 -0400 Subject: OO.o from rawhide build In-Reply-To: References: Message-ID: <1066146637.4605.0.camel@dhcp64-188.boston.redhat.com> Hmm, looks like the Java whacking patches check for java location even if you disable it, and that means you must have an old JDK installed too. Will fix. Dan On Tue, 2003-10-14 at 11:44, Behdad Esfahbod wrote: > Hi > > I'm trying to build OO.o from rawhide SRPM. The configure is > called as: > > ./configure --enable-libart --enable-libsn > --with-lang="%{languages}" --disable-java --with-mozilla > > But I still get: > > checking whether to build with Java support... no > checking for javac... no > checking for java... /usr/java/jre/bin/java > checking the installed JDK... configure: error: JDK is too old, > you need at least 1.3 > > Weird, > > behdad, > > > -- > 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 Tue Oct 14 15:54:32 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 14 Oct 2003 11:54:32 -0400 Subject: OO.o from rawhide build In-Reply-To: <1066146637.4605.0.camel@dhcp64-188.boston.redhat.com> References: <1066146637.4605.0.camel@dhcp64-188.boston.redhat.com> Message-ID: On Tue, 14 Oct 2003, Dan Williams wrote: > Hmm, looks like the Java whacking patches check for java location even > if you disable it, and that means you must have an old JDK installed > too. Will fix. That't it. I've got an old kaffe. Made it by adding an if to config_office/configure.in... behdad > Dan > > On Tue, 2003-10-14 at 11:44, Behdad Esfahbod wrote: > > Hi > > > > I'm trying to build OO.o from rawhide SRPM. The configure is > > called as: > > > > ./configure --enable-libart --enable-libsn > > --with-lang="%{languages}" --disable-java --with-mozilla > > > > But I still get: > > > > checking whether to build with Java support... no > > checking for javac... no > > checking for java... /usr/java/jre/bin/java > > checking the installed JDK... configure: error: JDK is too old, > > you need at least 1.3 > > > > Weird, > > > > behdad, > > > > > > -- > > 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 > > behdad, who is going to study after finishing this mail. From dcbw at redhat.com Tue Oct 14 16:01:37 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 14 Oct 2003 12:01:37 -0400 Subject: OO.o from rawhide build In-Reply-To: References: <1066146637.4605.0.camel@dhcp64-188.boston.redhat.com> Message-ID: <1066147297.4605.2.camel@dhcp64-188.boston.redhat.com> Yep, I've got a patch made and stuffed into the 1.1.0-3 specfile for this. Thanks for the heads-up. Dan On Tue, 2003-10-14 at 11:54, Behdad Esfahbod wrote: > On Tue, 14 Oct 2003, Dan Williams wrote: > > > Hmm, looks like the Java whacking patches check for java location even > > if you disable it, and that means you must have an old JDK installed > > too. Will fix. > > That't it. I've got an old kaffe. Made it by adding an if to > config_office/configure.in... > > behdad > > > Dan > > > > On Tue, 2003-10-14 at 11:44, Behdad Esfahbod wrote: > > > Hi > > > > > > I'm trying to build OO.o from rawhide SRPM. The configure is > > > called as: > > > > > > ./configure --enable-libart --enable-libsn > > > --with-lang="%{languages}" --disable-java --with-mozilla > > > > > > But I still get: > > > > > > checking whether to build with Java support... no > > > checking for javac... no > > > checking for java... /usr/java/jre/bin/java > > > checking the installed JDK... configure: error: JDK is too old, > > > you need at least 1.3 > > > > > > Weird, > > > > > > behdad, > > > > > > > > > -- > > > 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 > > > > > > behdad, > who is going to study after finishing this mail. > > > -- > 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 Tue Oct 14 16:07:04 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 14 Oct 2003 12:07:04 -0400 Subject: OO.o from rawhide build In-Reply-To: <1066147297.4605.2.camel@dhcp64-188.boston.redhat.com> References: <1066146637.4605.0.camel@dhcp64-188.boston.redhat.com> <1066147297.4605.2.camel@dhcp64-188.boston.redhat.com> Message-ID: Oh, but more important thing there, why the failing configure does not fail the build? A wrong exit somewhere perhaps. On Tue, 14 Oct 2003, Dan Williams wrote: > Yep, I've got a patch made and stuffed into the 1.1.0-3 specfile for > this. > > Thanks for the heads-up. > > Dan > > On Tue, 2003-10-14 at 11:54, Behdad Esfahbod wrote: > > On Tue, 14 Oct 2003, Dan Williams wrote: > > > > > Hmm, looks like the Java whacking patches check for java location even > > > if you disable it, and that means you must have an old JDK installed > > > too. Will fix. > > > > That't it. I've got an old kaffe. Made it by adding an if to > > config_office/configure.in... > > > > behdad > > > > > Dan > > > > > > On Tue, 2003-10-14 at 11:44, Behdad Esfahbod wrote: > > > > Hi > > > > > > > > I'm trying to build OO.o from rawhide SRPM. The configure is > > > > called as: > > > > > > > > ./configure --enable-libart --enable-libsn > > > > --with-lang="%{languages}" --disable-java --with-mozilla > > > > > > > > But I still get: > > > > > > > > checking whether to build with Java support... no > > > > checking for javac... no > > > > checking for java... /usr/java/jre/bin/java > > > > checking the installed JDK... configure: error: JDK is too old, > > > > you need at least 1.3 > > > > > > > > Weird, > > > > > > > > behdad, > > > > > > > > > > > > -- > > > > 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 > > > > > > > > > > behdad, > > who is going to study after finishing this mail. > > > > > > -- > > 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 > > behdad, who is going to study after finishing this mail. From jkeating at j2solutions.net Tue Oct 14 16:15:39 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Oct 2003 09:15:39 -0700 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <3F8BDA5E.6080201@arcamax.com> References: <1065949938.1417.15.camel@homer.home> <1066063929.24321.6.camel@mirkwood.devel.redhat.com> <3F8BDA5E.6080201@arcamax.com> Message-ID: <200310140915.39762.jkeating@j2solutions.net> On Tuesday 14 October 2003 04:13, Bryan White wrote: > I have never looked into boot ROMs for NICs. That > sounds like overkill just to launch an install. Actually it's not at all. Network booting provides a very fast and efficient method of starting an installation. Just a simple DHCP request, followed by a tftp connection to pull down a kenrel/initrd image provided on the first installation CD, and you're set. We use syslinux as the boot loader, so we can have a nice kickstart menu where the installation techs just pick the type of system that they're installing and the kickstart will automagically start. -- 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 Dan_Ulinski at hotmail.com Tue Oct 14 16:28:39 2003 From: Dan_Ulinski at hotmail.com (Dan Ulinski) Date: Tue, 14 Oct 2003 12:28:39 -0400 Subject: Distribution Size Message-ID: <000501c39270$393c9550$8002a8c0@RFID.local> I have tried to install the servern release now for a couple of times. I have allocated about 6.6 GBytes to distribution And still while the installation is going on it fails because of not enough disk space for temp files created while the installation is processing rpm-s. In this case shouldn't the size of the distribution that Anaconda uses for checking available disk space include the size of the temp files needed to complete the installation? Not just the end size of the distribution. Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdiehl at rogueind.com Tue Oct 14 16:27:28 2003 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 14 Oct 2003 12:27:28 -0400 (EDT) Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <200310140915.39762.jkeating@j2solutions.net> Message-ID: On Tue, 14 Oct 2003, Jesse Keating wrote: > On Tuesday 14 October 2003 04:13, Bryan White wrote: > > I have never looked into boot ROMs for NICs. That > > sounds like overkill just to launch an install. > > Actually it's not at all. Network booting provides a very fast and > efficient method of starting an installation. Just a simple DHCP > request, followed by a tftp connection to pull down a kenrel/initrd > image provided on the first installation CD, and you're set. We use > syslinux as the boot loader, so we can have a nice kickstart menu where > the installation techs just pick the type of system that they're > installing and the kickstart will automagically start. I love my pxe boot machines for the same reasons Jesse listed above. I do not know how I lived without PXE. Expecially now that things do not fit on a floppy. :-) Besides PXE is so much faster than a floppy ever could be. On a slightly different note I have a few older machines that I would like to setup for PXE booting but I need ROMs for them. Does anyone have a good source for them? I have heard that there might be a floppy image available for testing that you can later burn to a Eprom once you know it works. So far I have not had much luck finding it though. -- ......Tom Registered Linux User #14522 http://counter.li.org tdiehl at rogueind.com My current SpamTrap -------> mtd123 at rogueind.com From jsmith at drgutah.com Tue Oct 14 16:33:54 2003 From: jsmith at drgutah.com (Jared Smith) Date: Tue, 14 Oct 2003 10:33:54 -0600 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: References: Message-ID: <1066149234.4489.9.camel@banff.drgutah.com> On Tue, 2003-10-14 at 10:27, Tom Diehl wrote: > I love my pxe boot machines for the same reasons Jesse listed above. I do > not know how I lived without PXE. Expecially now that things do not fit on > a floppy. :-) Besides PXE is so much faster than a floppy ever could be. OK, I've been wanting to do PXE installations for a long time. I can get the machines to boot off off PXE, but I'm not sure where to go from there. (I've played around with it a little, and actually got the kernel to boot, but not far enough to start the installer.) Anybody got some pointers and/or any documentation on how to do a PXE boot installation? Jared Smith From czar at czarc.net Tue Oct 14 16:34:35 2003 From: czar at czarc.net (Gene C.) Date: Tue, 14 Oct 2003 12:34:35 -0400 Subject: Updated Fedora Core test release: Severn In-Reply-To: <20031014133201.GC30474@redhat.com> References: <20031013142502.A18694@devserv.devel.redhat.com> <3F8BD28B.3070808@gear.dyndns.org> <20031014133201.GC30474@redhat.com> Message-ID: <200310141234.35933.czar@czarc.net> On Tuesday 14 October 2003 09:32, Jay Turner wrote: > You're best bet is to grab the latest up2date and up2date-gnome, as well as > fedora-release from the FTP site and run that. We've switched to Yum > repositories being the default, so RHN channels are no longer a necessity > for registration and use of up2date. YES! I believe this is a much better approach for the testing of fedora versions and should reduce the work needed by Red Hat folks. Good idea guys! I "assume" that the up2date that will be shipped with the final will point to rhn again ... or will it? Should something be added to up2date-config so that this stuff can be set in /etc/sysconfig/rhn/sources rather than editing the file directly? -- Gene From czar at czarc.net Tue Oct 14 16:40:49 2003 From: czar at czarc.net (Gene C.) Date: Tue, 14 Oct 2003 12:40:49 -0400 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <20031014101301.B1270@devserv.devel.redhat.com> References: <3F8B939E.8090708@eburg.com> <20031014101301.B1270@devserv.devel.redhat.com> Message-ID: <200310141240.49240.czar@czarc.net> On Tuesday 14 October 2003 10:13, Bill Nottingham wrote: > Alternatives is for different versions of things *in* Fedora Core. > Extras would be for exim/zmailer/courier/chuckmail. That makes sense. So, Alternatives is the place to put such things as a 2.6 kernel or a "beta" version of some package ... correct? -- Gene From czar at czarc.net Tue Oct 14 16:47:44 2003 From: czar at czarc.net (Gene C.) Date: Tue, 14 Oct 2003 12:47:44 -0400 Subject: Distribution Size In-Reply-To: <000501c39270$393c9550$8002a8c0@RFID.local> References: <000501c39270$393c9550$8002a8c0@RFID.local> Message-ID: <200310141247.44168.czar@czarc.net> On Tuesday 14 October 2003 12:28, Dan Ulinski wrote: > I have tried to install the servern release now for a couple of times. I > have allocated about 6.6 GBytes to distribution > > And still while the installation is going on it fails because of not > enough disk space for temp files created while the installation I successfully did an everything install into a 6.4GB partition (everything except /home and swap into that partition). After installation, the partition was about 5.6GB full. -- Gene From crandall at redhat.com Tue Oct 14 17:51:49 2003 From: crandall at redhat.com (Ken Crandall) Date: 14 Oct 2003 10:51:49 -0700 Subject: OO.o from rawhide build In-Reply-To: <1066147297.4605.2.camel@dhcp64-188.boston.redhat.com> References: <1066146637.4605.0.camel@dhcp64-188.boston.redhat.com> <1066147297.4605.2.camel@dhcp64-188.boston.redhat.com> Message-ID: <1066153909.1380.10.camel@magellan.laptop> What if you do have a JVM on the machine, and want to enable the java support? [Is there|Will there be] support for building OO.o both ways? Caveat: I haven't looked at the SRPM yet, so sorry if it's there already and I don't know... Ken On Tue, 2003-10-14 at 09:01, Dan Williams wrote: > Yep, I've got a patch made and stuffed into the 1.1.0-3 specfile for > this. > > Thanks for the heads-up. > > Dan > > On Tue, 2003-10-14 at 11:54, Behdad Esfahbod wrote: > > On Tue, 14 Oct 2003, Dan Williams wrote: > > > > > Hmm, looks like the Java whacking patches check for java location even > > > if you disable it, and that means you must have an old JDK installed > > > too. Will fix. > > > > That't it. I've got an old kaffe. Made it by adding an if to > > config_office/configure.in... > > > > behdad > > > > > Dan > > > > > > On Tue, 2003-10-14 at 11:44, Behdad Esfahbod wrote: > > > > Hi > > > > > > > > I'm trying to build OO.o from rawhide SRPM. The configure is > > > > called as: > > > > > > > > ./configure --enable-libart --enable-libsn > > > > --with-lang="%{languages}" --disable-java --with-mozilla > > > > > > > > But I still get: > > > > > > > > checking whether to build with Java support... no > > > > checking for javac... no > > > > checking for java... /usr/java/jre/bin/java > > > > checking the installed JDK... configure: error: JDK is too old, > > > > you need at least 1.3 > > > > > > > > Weird, > > > > > > > > behdad, > > > > > > > > > > > > -- > > > > 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 > > > > > > > > > > behdad, > > who is going to study after finishing this mail. > > > > > > -- > > 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 -- Ken Crandall Red Hat, Inc. From jeremyp at pobox.com Tue Oct 14 17:54:53 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: Tue, 14 Oct 2003 13:54:53 -0400 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: References: Message-ID: <1066154093.2990.7.camel@jeremy.dtcc.cc.nc.us> On Tue, 2003-10-14 at 12:27, Tom Diehl wrote: > > On a slightly different note I have a few older machines that I would like > to setup for PXE booting but I need ROMs for them. Does anyone have a good > source for them? I have heard that there might be a floppy image available > for testing that you can later burn to a Eprom once you know it works. So > far I have not had much luck finding it though. Have you checked out Etherboot at http://etherboot.sourceforge.net/ ? They include images for floppies that can be used in place of boot ROMs, and they also provide boot ROM images. Good stuff. --Jeremy -------------- 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 Oct 14 18:01:38 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 14 Oct 2003 14:01:38 -0400 Subject: OO.o from rawhide build In-Reply-To: <1066153909.1380.10.camel@magellan.laptop> References: <1066146637.4605.0.camel@dhcp64-188.boston.redhat.com> <1066147297.4605.2.camel@dhcp64-188.boston.redhat.com> <1066153909.1380.10.camel@magellan.laptop> Message-ID: <1066154498.9046.8.camel@dhcp64-188.boston.redhat.com> We were discussing this in the thread "GCC-3.3 and OO.org", and came to the conclusion that yes, you should be able to soon. It won't work now and it won't work for the next release either unless you hack the specfile (though the hacks are fairly easy). dan On Tue, 2003-10-14 at 13:51, Ken Crandall wrote: > What if you do have a JVM on the machine, and want to enable the java > support? [Is there|Will there be] support for building OO.o both ways? > > Caveat: I haven't looked at the SRPM yet, so sorry if it's there already > and I don't know... > > Ken > > On Tue, 2003-10-14 at 09:01, Dan Williams wrote: > > Yep, I've got a patch made and stuffed into the 1.1.0-3 specfile for > > this. > > > > Thanks for the heads-up. > > > > Dan > > > > On Tue, 2003-10-14 at 11:54, Behdad Esfahbod wrote: > > > On Tue, 14 Oct 2003, Dan Williams wrote: > > > > > > > Hmm, looks like the Java whacking patches check for java location even > > > > if you disable it, and that means you must have an old JDK installed > > > > too. Will fix. > > > > > > That't it. I've got an old kaffe. Made it by adding an if to > > > config_office/configure.in... > > > > > > behdad > > > > > > > Dan > > > > > > > > On Tue, 2003-10-14 at 11:44, Behdad Esfahbod wrote: > > > > > Hi > > > > > > > > > > I'm trying to build OO.o from rawhide SRPM. The configure is > > > > > called as: > > > > > > > > > > ./configure --enable-libart --enable-libsn > > > > > --with-lang="%{languages}" --disable-java --with-mozilla > > > > > > > > > > But I still get: > > > > > > > > > > checking whether to build with Java support... no > > > > > checking for javac... no > > > > > checking for java... /usr/java/jre/bin/java > > > > > checking the installed JDK... configure: error: JDK is too old, > > > > > you need at least 1.3 > > > > > > > > > > Weird, > > > > > > > > > > behdad, > > > > > > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > behdad, > > > who is going to study after finishing this mail. > > > > > > > > > -- > > > 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 behdad at cs.toronto.edu Tue Oct 14 18:02:37 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 14 Oct 2003 14:02:37 -0400 Subject: OO.o from rawhide build In-Reply-To: <1066153909.1380.10.camel@magellan.laptop> References: <1066146637.4605.0.camel@dhcp64-188.boston.redhat.com> <1066147297.4605.2.camel@dhcp64-188.boston.redhat.com> <1066153909.1380.10.camel@magellan.laptop> Message-ID: >From discussion on this list, it is supposed to be a matter of a variable passed to rpmbuild. Right now its to remove --disable-java and add --with-jdk-path in the spec file. On Tue, 14 Oct 2003, Ken Crandall wrote: > What if you do have a JVM on the machine, and want to enable the java > support? [Is there|Will there be] support for building OO.o both ways? > > Caveat: I haven't looked at the SRPM yet, so sorry if it's there already > and I don't know... > > Ken > > On Tue, 2003-10-14 at 09:01, Dan Williams wrote: > > Yep, I've got a patch made and stuffed into the 1.1.0-3 specfile for > > this. > > > > Thanks for the heads-up. > > > > Dan > > > > On Tue, 2003-10-14 at 11:54, Behdad Esfahbod wrote: > > > On Tue, 14 Oct 2003, Dan Williams wrote: > > > > > > > Hmm, looks like the Java whacking patches check for java location even > > > > if you disable it, and that means you must have an old JDK installed > > > > too. Will fix. > > > > > > That't it. I've got an old kaffe. Made it by adding an if to > > > config_office/configure.in... > > > > > > behdad > > > > > > > Dan > > > > > > > > On Tue, 2003-10-14 at 11:44, Behdad Esfahbod wrote: > > > > > Hi > > > > > > > > > > I'm trying to build OO.o from rawhide SRPM. The configure is > > > > > called as: > > > > > > > > > > ./configure --enable-libart --enable-libsn > > > > > --with-lang="%{languages}" --disable-java --with-mozilla > > > > > > > > > > But I still get: > > > > > > > > > > checking whether to build with Java support... no > > > > > checking for javac... no > > > > > checking for java... /usr/java/jre/bin/java > > > > > checking the installed JDK... configure: error: JDK is too old, > > > > > you need at least 1.3 > > > > > > > > > > Weird, > > > > > > > > > > behdad, > > > > > > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > behdad, > > > who is going to study after finishing this mail. > > > > > > > > > -- > > > 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 > behdad, who is going to study after finishing this mail. From dcbw at redhat.com Tue Oct 14 18:09:20 2003 From: dcbw at redhat.com (Dan Williams) Date: Tue, 14 Oct 2003 14:09:20 -0400 Subject: OO.o from rawhide build In-Reply-To: References: <1066146637.4605.0.camel@dhcp64-188.boston.redhat.com> <1066147297.4605.2.camel@dhcp64-188.boston.redhat.com> <1066153909.1380.10.camel@magellan.laptop> Message-ID: <1066154959.9046.12.camel@dhcp64-188.boston.redhat.com> And don't forget to comment out all of the no-java patches in the specfile, though in a perfect world it shouldn't be necessary. Dan On Tue, 2003-10-14 at 14:02, Behdad Esfahbod wrote: > >From discussion on this list, it is supposed to be a matter of a > variable passed to rpmbuild. Right now its to remove > --disable-java and add --with-jdk-path in the spec file. > > On Tue, 14 Oct 2003, Ken Crandall wrote: > > > What if you do have a JVM on the machine, and want to enable the java > > support? [Is there|Will there be] support for building OO.o both ways? > > > > Caveat: I haven't looked at the SRPM yet, so sorry if it's there already > > and I don't know... > > > > Ken > > > > On Tue, 2003-10-14 at 09:01, Dan Williams wrote: > > > Yep, I've got a patch made and stuffed into the 1.1.0-3 specfile for > > > this. > > > > > > Thanks for the heads-up. > > > > > > Dan > > > > > > On Tue, 2003-10-14 at 11:54, Behdad Esfahbod wrote: > > > > On Tue, 14 Oct 2003, Dan Williams wrote: > > > > > > > > > Hmm, looks like the Java whacking patches check for java location even > > > > > if you disable it, and that means you must have an old JDK installed > > > > > too. Will fix. > > > > > > > > That't it. I've got an old kaffe. Made it by adding an if to > > > > config_office/configure.in... > > > > > > > > behdad > > > > > > > > > Dan > > > > > > > > > > On Tue, 2003-10-14 at 11:44, Behdad Esfahbod wrote: > > > > > > Hi > > > > > > > > > > > > I'm trying to build OO.o from rawhide SRPM. The configure is > > > > > > called as: > > > > > > > > > > > > ./configure --enable-libart --enable-libsn > > > > > > --with-lang="%{languages}" --disable-java --with-mozilla > > > > > > > > > > > > But I still get: > > > > > > > > > > > > checking whether to build with Java support... no > > > > > > checking for javac... no > > > > > > checking for java... /usr/java/jre/bin/java > > > > > > checking the installed JDK... configure: error: JDK is too old, > > > > > > you need at least 1.3 > > > > > > > > > > > > Weird, > > > > > > > > > > > > behdad, > > > > > > > > > > > > > > > > > > -- > > > > > > 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 > > > > > > > > > > > > > > > > > > behdad, > > > > who is going to study after finishing this mail. > > > > > > > > > > > > -- > > > > 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 > > > > behdad, > who is going to study after finishing this mail. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From notting at redhat.com Tue Oct 14 18:34:57 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 14 Oct 2003 14:34:57 -0400 Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <200310141240.49240.czar@czarc.net>; from czar@czarc.net on Tue, Oct 14, 2003 at 12:40:49PM -0400 References: <3F8B939E.8090708@eburg.com> <20031014101301.B1270@devserv.devel.redhat.com> <200310141240.49240.czar@czarc.net> Message-ID: <20031014143457.A30825@devserv.devel.redhat.com> Gene C. (czar at czarc.net) said: > > Alternatives is for different versions of things *in* Fedora Core. > > Extras would be for exim/zmailer/courier/chuckmail. > > That makes sense. > > So, Alternatives is the place to put such things as a 2.6 kernel or a "beta" > version of some package ... correct? Correct. Bill From alan at redhat.com Tue Oct 14 18:38:49 2003 From: alan at redhat.com (Alan Cox) Date: Tue, 14 Oct 2003 14:38:49 -0400 (EDT) Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <1066149234.4489.9.camel@banff.drgutah.com> from "Jared Smith" at Hyd 14, 2003 10:33:54 Message-ID: <200310141838.h9EIcn203063@devserv.devel.redhat.com> > OK, I've been wanting to do PXE installations for a long time. I can > get the machines to boot off off PXE, but I'm not sure where to go from > there. (I've played around with it a little, and actually got the > kernel to boot, but not far enough to start the installer.) Anybody got > some pointers and/or any documentation on how to do a PXE boot > installation? If you are using pxelinux (throw the old intel pxe crap in the bitbucket its just pain 8)) Edit /etc/dhcpd.conf. Set it up for dhcp as normal but also add next-server the-pxe-tftp-box-i-have; filename "/pxelinux.0" for the host range, and make sure allow booting; is included in the top section. Edit /etc/xinetd.d/tftp. Enable tftp and make sure the server_args is "-s /tftpboot" - this limits where the tftp can access. Stick pxelinux.0 from syslinux into /tftpboot Boot the pxe box and it should boot to a boot prompt but will fail to load a kernel. cp the initrd and kernel image from the first CD pxe directory into /tftpboot. Now either set up a pxelinux.cfg (see docs) or at the prompt type the kernelname initrd=initrdname Its a godsend for saving time From briandee at mail.weber.edu Tue Oct 14 18:43:55 2003 From: briandee at mail.weber.edu (Brian Dee) Date: Tue, 14 Oct 2003 12:43:55 -0600 Subject: How can I get more involved??? Message-ID: <1066157034.20006.46.camel@Anubis> Don't laugh!! ; ) I'm a CS major at my local university and have been using Linux, specifically RedHat, for the past four years or so. I have benefited greatly from using it, tweaking it, breaking it, fixing it, etc. I greatly enjoy the friendly and helpful Linux and open source communities. I want to give back and at the same time "beef up" my skills in programming, administration, or whatever. Can any of you share how you get started in this big wide world of Linux hacking? I mean, I've read many things about it such as "Find a bug and fix it.", "Help with documentation.", etc. But, I still am not sure what I can do, or where to start. I have some programming experience with several languages, but unless you use them really in depth, you just don't learn them very well. You know? I can take all the requirements for my BS, but unless I can actually find ways to use the things I'm learning, I'll forget them. Just like any kind of talent. So, how do you get started? I enjoy Python a TON, and have built a few personal utilities with it for my job, including a pyGTK based thingamajig that helps me with an administration task I face frequently. Mostly just fun self tutorials and stuff. I would love to just do *something* that would be useful for others and fun for me to do. Anyway, I would appreciate any advice or guidance anyone has. Thanks for contributing *your* time and talents that has made this such a great ride!!! -- Brian Dee -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Tue Oct 14 18:57:57 2003 From: alan at redhat.com (Alan Cox) Date: Tue, 14 Oct 2003 14:57:57 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs In-Reply-To: from "Mike A. Harris" at Hyd 14, 2003 10:04:36 Message-ID: <200310141857.h9EIvvD15176@devserv.devel.redhat.com> > I can disable the Luxi TTF font if Owen and others think that's a > good idea. I think keeping it out of fontconfig should be > adequate though more or less. Does Luxi have the same character range in both ttf and type 1 ? From notting at redhat.com Tue Oct 14 18:59:00 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 14 Oct 2003 14:59:00 -0400 Subject: i18n freeze for Fedora Core 1: Monday, Oct. 20 Message-ID: <20031014145859.C30825@devserv.devel.redhat.com> Given the schedule at: http://fedora.redhat.com/participate/schedule/ To make sure that all translations are merged OK, we'd like to make the cutoff on Monday, Oct. 20, at noon EDT (1600 UTC). Anything committed after that point may not be included. Bill From peter.backlund at home.se Tue Oct 14 16:52:24 2003 From: peter.backlund at home.se (Peter Backlund) Date: 14 Oct 2003 18:52:24 +0200 Subject: Distribution Size In-Reply-To: <000501c39270$393c9550$8002a8c0@RFID.local> References: <000501c39270$393c9550$8002a8c0@RFID.local> Message-ID: <1066150344.27013.0.camel@mozer.nailed.org> > And still = while the installation is going on it fails because of not > enough disk space for = temp files created while the installation > > is = processing rpm-s. Did you create a swap partition, and if you did, how large was it? /Peter From oden.eriksson at kvikkjokk.net Tue Oct 14 19:19:07 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Tue, 14 Oct 2003 21:19:07 +0200 Subject: Yo. Message-ID: <200310142119.07763.oden.eriksson@kvikkjokk.net> Hi Folks, I've been involved in many aspects of the Mandrake Linux evolution and done many great things there. Lately I feel the focus has changed to the worse, and I'm not happy about it. What can you say to convince me to join this community? From jsmith at drgutah.com Tue Oct 14 19:25:07 2003 From: jsmith at drgutah.com (Jared Smith) Date: Tue, 14 Oct 2003 13:25:07 -0600 Subject: Yo. In-Reply-To: <200310142119.07763.oden.eriksson@kvikkjokk.net> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> Message-ID: <1066159507.4489.13.camel@banff.drgutah.com> On Tue, 2003-10-14 at 13:19, Oden Eriksson wrote: > I've been involved in many aspects of the Mandrake Linux evolution and done > many great things there. Lately I feel the focus has changed to the worse, > and I'm not happy about it. What can you say to convince me to join this > community? Nothing! I don't mean to sound rude, but nothing I could possibly say would "convince" you to join the community. But I strongly encourage you to jump in and give it a shot. If you like it, great! If you don't, that's fine too. Jared Smith From otaylor at redhat.com Tue Oct 14 19:48:28 2003 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 14 Oct 2003 15:48:28 -0400 Subject: [RFC] Better font filetype and metadata file detection for xfs In-Reply-To: <200310141857.h9EIvvD15176@devserv.devel.redhat.com> References: <200310141857.h9EIvvD15176@devserv.devel.redhat.com> Message-ID: <1066160907.14898.217.camel@poincare.devel.redhat.com> On Tue, 2003-10-14 at 14:57, Alan Cox wrote: > > I can disable the Luxi TTF font if Owen and others think that's a > > good idea. I think keeping it out of fontconfig should be > > adequate though more or less. > > Does Luxi have the same character range in both ttf and type 1 ? Not exactly. The TTF version has ~60 more characters, though they are fairly peripheral. The more important reason to keep the TTF version in the distribution is that we still have some FreeType1-based code (magicpoint, in particular) and that code can't handle Type1 fonts. There shouldn't be any harm as long as we keep them out of the fontconifg path. Regards, Owen From alan at redhat.com Tue Oct 14 19:51:11 2003 From: alan at redhat.com (Alan Cox) Date: Tue, 14 Oct 2003 15:51:11 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs In-Reply-To: <1066160907.14898.217.camel@poincare.devel.redhat.com> from "Owen Taylor" at Hyd 14, 2003 03:48:28 Message-ID: <200310141951.h9EJpBk20851@devserv.devel.redhat.com> > Not exactly. The TTF version has ~60 more characters, though > they are fairly peripheral. I thought so - with the TTF one I got w^ without I didnt seem to From florin at sgi.com Tue Oct 14 20:28:27 2003 From: florin at sgi.com (Florin Andrei) Date: 14 Oct 2003 13:28:27 -0700 Subject: TV and radio apps Message-ID: <1066163306.24423.9.camel@stantz.corp.sgi.com> Probably too late to include them in the upcoming release, but perhaps nice to consider for other future releases: Currently, the functions of radio and TV/analog video player are covered by xawtv. There are quite a few shortcomings of this package. Perhaps better replacements would be: - tvtime http://tvtime.sourceforge.net/ Has filtering abilities. Can deinterlace the image, hence the image quality is so much higher (no more interlacing artifacts). Has a nicer and more clever interface. Even searching for new channels is far easier and it's a full-GUI task (well, not exactly a classic GUI, but everything happens right on the display, like many TVs and standalone DVD players do). Generally, a lot more flexible, powerful and feature rich. Main quality: the image is far better than with xawtv. Main drawback: can't find any. - gqradio http://gqmpeg.sourceforge.net/radio.html Has an interface that makes sense. Can do autoseek. You can label the stations. Everything is GUI-able. On the eye-candy side, it has skins. Main quality: at least has a GUI. :-) Main drawback: it's a GUI app. :-) -- Florin Andrei http://florin.myip.org/ From oden.eriksson at kvikkjokk.net Tue Oct 14 20:32:24 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Tue, 14 Oct 2003 22:32:24 +0200 Subject: Yo. In-Reply-To: <1066159507.4489.13.camel@banff.drgutah.com> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <1066159507.4489.13.camel@banff.drgutah.com> Message-ID: <200310142232.24649.oden.eriksson@kvikkjokk.net> tisdagen den 14 oktober 2003 21.25 skrev Jared Smith: > On Tue, 2003-10-14 at 13:19, Oden Eriksson wrote: > > I've been involved in many aspects of the Mandrake Linux evolution and > > done many great things there. Lately I feel the focus has changed to the > > worse, and I'm not happy about it. What can you say to convince me to > > join this community? > > Nothing! > > I don't mean to sound rude, but nothing I could possibly say would > "convince" you to join the community. But I strongly encourage you to > jump in and give it a shot. If you like it, great! If you don't, > that's fine too. > Ok I get it Jared the "welcome and mince words fellow" dude. If no one else with something to say (without fucking mincing words) comes forward I will take it as this forum is a hostile place and nothing for me. Am I wrong? Is this a hostile place? Are we picking on "new comers" here? From skvidal at phy.duke.edu Tue Oct 14 20:38:03 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 14 Oct 2003 16:38:03 -0400 Subject: Yo. In-Reply-To: <200310142232.24649.oden.eriksson@kvikkjokk.net> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <1066159507.4489.13.camel@banff.drgutah.com> <200310142232.24649.oden.eriksson@kvikkjokk.net> Message-ID: <1066163883.31347.70.camel@opus> > Ok I get it Jared the "welcome and mince words fellow" dude. I'm not sure who jared is - I think it's the first time I've seen him post. So I'd take his post with a grain of salt. > If no one else with something to say (without fucking mincing words) comes > forward I will take it as this forum is a hostile place and nothing for me. oh cmon - one person does not make a good sample size. :) but more to the point: where are your interests? You said you were working with mandrake some and didn't like where things were going - where were things going? what is it that you didn't like? What is it that you do like? What things can you do? In order to answer your question persuasively I'll need to know a bit more about you. -sv From sopwith at redhat.com Tue Oct 14 20:38:32 2003 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 14 Oct 2003 16:38:32 -0400 (EDT) Subject: Yo. In-Reply-To: <200310142232.24649.oden.eriksson@kvikkjokk.net> Message-ID: On Tue, 14 Oct 2003, Oden Eriksson wrote: > Ok I get it Jared the "welcome and mince words fellow" dude. > > If no one else with something to say (without fucking mincing words) comes > forward I will take it as this forum is a hostile place and nothing for me. > > Am I wrong? > > Is this a hostile place? > > Are we picking on "new comers" here? I don't think Jared meant to be rude or discourage you. You're welcome to contribute if you like! -- Elliot Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. From peter.backlund at home.se Tue Oct 14 20:47:52 2003 From: peter.backlund at home.se (Peter Backlund) Date: 14 Oct 2003 22:47:52 +0200 Subject: TV and radio apps In-Reply-To: <1066163306.24423.9.camel@stantz.corp.sgi.com> References: <1066163306.24423.9.camel@stantz.corp.sgi.com> Message-ID: <1066164471.27006.15.camel@mozer.nailed.org> > - gqradio http://gqmpeg.sourceforge.net/radio.html > Has an interface that makes sense. Can do autoseek. You can label the > stations. Everything is GUI-able. On the eye-candy side, it has skins. Heh...skinned multimedia applications and eye-candy...that's usually not a good combination. In my experience, most skin looks like this: http://www.mplayerhq.hu/homepage/images/skin-krystal-shot01.jpg (Disclaimer: I haven't seen any gqmpeg skins, so they might not be as bad.) Overall, this could probably go into Fedora Extras pretty much right away. I noticed there are already (tvview) rpms for RHL 7.3/8/9, built by Dag Wieers. /Peter From paul at gear.dyndns.org Tue Oct 14 20:51:15 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Wed, 15 Oct 2003 06:51:15 +1000 Subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!! In-Reply-To: References: Message-ID: <3F8C61C3.2090807@gear.dyndns.org> Tom Diehl wrote: > ... >>Last time I had to tweak my keyboard I validated the changes with >>/etc/init.d/key* restart. And now you remove this script. So I'm a bit >>worried - what will happen next time I need to fiddle with it ? > > > As Bill said in a previous post "loadkeys $KEYTABLE.map" That is for > all practical purposes the same thing. Remember TIMTOWTDI!! :-) That might be a good motto for Perl, but it's a very *bad* motto for starting services on a box... -- Paul http://paulgear.webhop.net A: Because we read from top to bottom, left to right. Q: Why should i start my 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 jamie at oulman.org Tue Oct 14 20:55:31 2003 From: jamie at oulman.org (Jamie Oulman) Date: Tue, 14 Oct 2003 13:55:31 -0700 Subject: Suggestions for the Installer (regarding network installs) In-Reply-To: <200310141838.h9EIcn203063@devserv.devel.redhat.com> References: <1066149234.4489.9.camel@banff.drgutah.com> <200310141838.h9EIcn203063@devserv.devel.redhat.com> Message-ID: <20031014205531.GA19755@oulman.org> hpa has additional info on his syslinux site, http://syslinux.zytor.com/pxe.php pxe is really great for installs. i've been doing redhat installations with pxe/nfs for a couple of months now and it's extremely nice not to need media. just drop the isos in an nfs export somewhere and your all set. -jamie On Tue, Oct 14, 2003 at 02:38:49PM -0400, Alan Cox wrote: > > OK, I've been wanting to do PXE installations for a long time. I can > > get the machines to boot off off PXE, but I'm not sure where to go from > > there. (I've played around with it a little, and actually got the > > kernel to boot, but not far enough to start the installer.) Anybody got > > some pointers and/or any documentation on how to do a PXE boot > > installation? > > If you are using pxelinux (throw the old intel pxe crap in the bitbucket its > just pain 8)) > > Edit /etc/dhcpd.conf. Set it up for dhcp as normal but also add > > next-server the-pxe-tftp-box-i-have; > filename "/pxelinux.0" > > for the host range, and make sure allow booting; is included in the top > section. > > Edit /etc/xinetd.d/tftp. Enable tftp and make sure the server_args is > "-s /tftpboot" - this limits where the tftp can access. > > Stick pxelinux.0 from syslinux into /tftpboot > > Boot the pxe box and it should boot to a boot prompt but will fail to > load a kernel. > > cp the initrd and kernel image from the first CD pxe directory into > /tftpboot. Now either set up a pxelinux.cfg (see docs) or at the prompt > type the kernelname initrd=initrdname > > Its a godsend for saving time > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From peter.backlund at home.se Tue Oct 14 20:57:27 2003 From: peter.backlund at home.se (Peter Backlund) Date: 14 Oct 2003 22:57:27 +0200 Subject: Yo. In-Reply-To: <200310142232.24649.oden.eriksson@kvikkjokk.net> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <1066159507.4489.13.camel@banff.drgutah.com> <200310142232.24649.oden.eriksson@kvikkjokk.net> Message-ID: <1066165047.27005.20.camel@mozer.nailed.org> > > I don't mean to sound rude, but nothing I could possibly say would > > "convince" you to join the community. But I strongly encourage you to > > jump in and give it a shot. If you like it, great! If you don't, > > that's fine too. > > > > Ok I get it Jared the "welcome and mince words fellow" dude. > > If no one else with something to say (without fucking mincing words) comes > forward I will take it as this forum is a hostile place and nothing for me. /me looks up "mince", just to be sure... Really, I think this is just a misunderstanding. I absolutely cannot interpret Jared's post as hostile in any way. Quite the opposite actually. He'll probably come forward himself and explain...just read the last two sentences again. /Peter From ms-nospam-0306 at arcor.de Tue Oct 14 21:03:06 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 14 Oct 2003 23:03:06 +0200 Subject: Yo. In-Reply-To: <200310142232.24649.oden.eriksson@kvikkjokk.net> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <1066159507.4489.13.camel@banff.drgutah.com> <200310142232.24649.oden.eriksson@kvikkjokk.net> Message-ID: <20031014230306.11777f4f.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 14 Oct 2003 22:32:24 +0200, Oden Eriksson wrote: > If no one else with something to say (without fucking mincing words) comes > forward I will take it as this forum is a hostile place and nothing for me. Not sure what kind of reply you did expect. Your posting was three lines short and the only question was strange. You could have expanded a bit on what you don't like about Mandrake Linux's focus or what visions you have. Or you could have commented on specific portions of http://fedora.redhat.com to give food for a discussion. > Am I wrong? Yes. > Is this a hostile place? No. > Are we picking on "new comers" here? No. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/jGSK0iMVcrivHFQRAn0PAJoCOVyi/+CgYNK4x5FQDk90vxCcOQCfbGCj apqlA1qcZ0X2hEIUYbcpMGc= =m5sL -----END PGP SIGNATURE----- From czar at czarc.net Tue Oct 14 21:06:50 2003 From: czar at czarc.net (Gene C.) Date: Tue, 14 Oct 2003 17:06:50 -0400 Subject: Yo. In-Reply-To: <200310142232.24649.oden.eriksson@kvikkjokk.net> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <1066159507.4489.13.camel@banff.drgutah.com> <200310142232.24649.oden.eriksson@kvikkjokk.net> Message-ID: <200310141706.50147.czar@czarc.net> On Tuesday 14 October 2003 16:32, Oden Eriksson wrote: > Am I wrong? > > Is this a hostile place? Not really hostile. Some folks don't always engage brain before speaking/typing (I have done this a time or two) but on the whole this is a friendly group trying to get the best product we can. Admittedly, this effort is Red Hat oriented and I am all for their succeeding (I do own a few shares of stock). The Red Hat folks I have had dealings with were all very professional. Yes, sometimes things can get a bit testy but everyone is trying to do it "right". When Red Hat found that their process of producing a "Retail Linux" was not producing sufficient $$ (and this is important because all companies are in the business of making money or they will not exist in the long run), they are trying to come up with a new model of doing business (The Fedora Project) which will benefit both Red Hat and the Open Source (Linux) community. I suggest you might want to "lurk" for a while on both this (the devel) and the test mailing lists before jumping in. You might also want to look at the archives of these lists to see what has gone before. The whole fedora thing is still in a state of flux and Red Hat (and others) are trying to figure out how to do things ... how to handling packages in Alternatives, in Extras, in Legacy, etc ... just what is Legacy and how will it fit/work with the Fedora Core ... does Lagacy include old (unsupported) releases of Red Hat Linux ... etc., etc. -- Gene C. From jkeating at j2solutions.net Tue Oct 14 21:09:53 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Oct 2003 14:09:53 -0700 Subject: Yo. In-Reply-To: <200310141706.50147.czar@czarc.net> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <200310142232.24649.oden.eriksson@kvikkjokk.net> <200310141706.50147.czar@czarc.net> Message-ID: <200310141409.53746.jkeating@j2solutions.net> On Tuesday 14 October 2003 14:06, Gene C. wrote: > in Legacy, etc ... just what is Legacy and how will > it fit/work with the Fedora Core ... does Lagacy include old > (unsupported) releases of Red Hat Linux ... etc., etc. I can speak to some of the Legacy issues. We're aiming for supporting 7.3 this December, 9 in April, FC 1 when it goes EOL, etc.. There may be some interest in older than 7.3 support, not sure how much will make it in though. Thats up to the community, those actually doing the backports. -- 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 czar at czarc.net Tue Oct 14 21:44:36 2003 From: czar at czarc.net (Gene C.) Date: Tue, 14 Oct 2003 17:44:36 -0400 Subject: Yo. In-Reply-To: <200310142232.24649.oden.eriksson@kvikkjokk.net> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <1066159507.4489.13.camel@banff.drgutah.com> <200310142232.24649.oden.eriksson@kvikkjokk.net> Message-ID: <200310141744.36789.czar@czarc.net> Another point, I believe that Mike has summarized the Fedora situation quite well in this message: https://www.redhat.com/archives/fedora-list/2003-October/msg00358.html on the fedora-list at redhat.com -- Gene From mark at mark.mielke.cc Tue Oct 14 21:51:33 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Tue, 14 Oct 2003 17:51:33 -0400 Subject: Yo. In-Reply-To: <200310142119.07763.oden.eriksson@kvikkjokk.net> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> Message-ID: <20031014215132.GA2513@mark.mielke.cc> On Tue, Oct 14, 2003 at 09:19:07PM +0200, Oden Eriksson wrote: > I've been involved in many aspects of the Mandrake Linux evolution and done > many great things there. Lately I feel the focus has changed to the worse, > and I'm not happy about it. What can you say to convince me to join this > community? Perhaps a question I would find more valuable to see answered - why do you believe that you deserve to be scouted? What skills or experience do you have that we should honour? So far, you have come across as a little pompous... :-) If you don't like this being said outright... so sad... Cheers, mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From florin at sgi.com Tue Oct 14 22:29:23 2003 From: florin at sgi.com (Florin Andrei) Date: 14 Oct 2003 15:29:23 -0700 Subject: TV and radio apps In-Reply-To: <1066163306.24423.9.camel@stantz.corp.sgi.com> References: <1066163306.24423.9.camel@stantz.corp.sgi.com> Message-ID: <1066170563.24423.14.camel@stantz.corp.sgi.com> On Tue, 2003-10-14 at 13:28, Florin Andrei wrote: > - tvtime http://tvtime.sourceforge.net/ Actually, Joe Barr has an article on NewsForge in which he describes the software far better than i could: http://newsforge.com/article.pl?sid=03/09/22/0120255 -- Florin Andrei http://florin.myip.org/ From ellson at research.att.com Tue Oct 14 22:36:23 2003 From: ellson at research.att.com (John Ellson) Date: Tue, 14 Oct 2003 18:36:23 -0400 Subject: Fedora Extras??? In-Reply-To: <1066164471.27006.15.camel@mozer.nailed.org> References: <1066163306.24423.9.camel@stantz.corp.sgi.com> <1066164471.27006.15.camel@mozer.nailed.org> Message-ID: <3F8C7A67.6000508@research.att.com> Peter Backlund wrote: > Overall, this could probably go into Fedora Extras pretty much right > away. ... Where can we find these "Fedora Extras" ? And where are the instructions on how we might contribute to them? John From bfox at redhat.com Tue Oct 14 22:43:15 2003 From: bfox at redhat.com (Brent Fox) Date: Tue, 14 Oct 2003 18:43:15 -0400 Subject: Redhat-Config-XFree86 In-Reply-To: <1065662476.3226.19.camel@localhost.localdomain> References: <1065662476.3226.19.camel@localhost.localdomain> Message-ID: <20031014224315.GB21750@redhat.com> On Wed, Oct 08, 2003 at 06:21:18PM -0700, Matt Jones wrote: > Hi - The dual head support doesn't seem to work for me (i'm on a toshiba > satellite 1405-s151 laptop) via redhat-config-xfree86. Whenever I > restart my X server, it merely clones my X screen onto my external > monitor. Looking at my logs, it shows TRIDENT(0) as picking up both > monitors. Should this be happening? I'm assuming that TRIDENT(0) should > only be detecting the lcd, and that TRIDENT(1) should pick up the > monitor. I don't think that the external video port on most laptops can do dual-head in the way that true dual-head video cards can (or machines that have more than one video card). Even if you configured the file by hand, I don't think it would be possible to do Xinerama on your laptop for the LCD and an external monitor. Cheers, Brent From mandreiana at rdslink.ro Tue Oct 14 23:21:26 2003 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Wed, 15 Oct 2003 02:21:26 +0300 Subject: How can I get more involved??? In-Reply-To: <1066157034.20006.46.camel@Anubis> References: <1066157034.20006.46.camel@Anubis> Message-ID: <1066173686.5051.20.camel@marte.biciclete.ro> Hi Brian and thank you for your help! You may find this useful: http://developer.gnome.org/helping/ If you like GTK in C too, you can find gnome requests here: http://bugzilla.gnome.org/ You might want to search for bugs with keywords easy-fix (attach patches for them) or path (verify the patches, make improvements if necesary and notify the maintainer that it works and should be checked in cvs). You can get involved in projects using Python and pyGTK by finding them by programming language on freshmeat.net and sf.net , e.g. http://freshmeat.net/browse/178/ Getting involved means subscribing to devel mailing lists, using that application (from CVS usually) and start improving it (coordinating with other developers as you do it). You can add features you'd like too have, and therefore "scratch your own itch". Here's a summary of ideas and link to The Cathedral and the Bazaar: http://www.openresources.com/documents/halloween-1/node4.html#SECTION00042300000000000000 Happy hacking! -- Marius Andreiana LOAD - Linux Open Alternative Days Specialist Linux, Co-organizator http://www.load.ro From mattharrison at sbcglobal.net Wed Oct 15 01:00:16 2003 From: mattharrison at sbcglobal.net (Matt Jones) Date: Tue, 14 Oct 2003 18:00:16 -0700 Subject: Japanese Font Antialiasing - Where did it go? Message-ID: <1066179616.1335.6.camel@localhost.localdomain> Hi - I just noticed that the font antialiasing seems to have stopped working for Japanese fonts. Admittedly, I haven't been using japanese on rawhide for about 3 weeks, but I have no clue what's going wrong. When i run LANG=ja_JP gedit i get nasty non-antialiased text, which used to not happen. Glancing at /etc/fonts/fonts.conf, I see some comment about disabling antialiasing for korean, japanese and chinese fonts, yet when I re-enable (change a false to a true) it via that xml file, nothing changes. I've recently installed some new fonts, but none should affect japanese language support (all dealing with Mathematica 5). Does any one else get this problem (if thats what it is) - you can run 'LANG=ja_JP gedit' if you have ja fonts installed to check - and has anyone figured out what's going on? Matt Jones -------------- 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 warren at togami.com Wed Oct 15 03:44:54 2003 From: warren at togami.com (Warren Togami) Date: Tue, 14 Oct 2003 17:44:54 -1000 Subject: Japanese Font Antialiasing - Where did it go? In-Reply-To: <1066179616.1335.6.camel@localhost.localdomain> References: <1066179616.1335.6.camel@localhost.localdomain> Message-ID: <3F8CC2B6.60601@togami.com> Matt Jones wrote: > Hi - I just noticed that the font antialiasing seems to have stopped > working for Japanese fonts. Admittedly, I haven't been using japanese on > rawhide for about 3 weeks, but I have no clue what's going wrong. > > When i run LANG=ja_JP gedit i get nasty non-antialiased text, which used > to not happen. Glancing at /etc/fonts/fonts.conf, I see some comment > about disabling antialiasing for korean, japanese and chinese fonts, yet > when I re-enable (change a false to a true) it via that xml file, > nothing changes. > > I've recently installed some new fonts, but none should affect japanese > language support (all dealing with Mathematica 5). > > Does any one else get this problem (if thats what it is) - you can run > 'LANG=ja_JP gedit' if you have ja fonts installed to check - and has > anyone figured out what's going on? > > Matt Jones I have noticed this in gaim too. Earlier all fonts were looking good, but at some point in rawhide AA of fonts stopped working. Warren From jspaleta at princeton.edu Wed Oct 15 04:21:30 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 15 Oct 2003 00:21:30 -0400 Subject: First Unofficial Fedora Bug Day: Tomorrow err I mean Today!!!!!!!!! Message-ID: <1066191690.11893.68.camel@localhost.localdomain> What: Fedora Bug Day!!!!! When: Oct 15 09:00 EDT about 21:00 EDT Where: #fedora-bugs on the freenode irc network Why: to clean up bugzilla bug reports that need more info Who: Anyone who wants to help make the fedora developers more efficient In an effort to get the ball rolling on a fedora community based bugzilla triage effort, I am hereby decreeing that tomorrow Wednesday October 15, 2003 the first unofficial Fedora Bug day, and every Weds there after to be Fedora Bug Days until the end of time, or someone more competent wants to be in charge and wants to change the date. In an effort to control the chaos, during tomorrow's first attempt at this..I want to try to focus effort on bugs that need more information to be useful. I'd like to also like to encourage anyone interested in translation work to possibly take this bug day opportunity to take a crack at going back and sweeping up outstanding translation bugtickets in bugzilla. The goal here isn't to create a whole new set of bugs, the goal is to get as many existing bugs as possible closed..or at the very least in shape to be closed by developers. "But Jef...what exactly is the point of a Bug Day?" Good question. The basic idea of a Fedora Bug Day, is a chance for us...the Fedora community to spend some quality time cleaning up Fedora bugzilla so the developers can spend less time sifting through lots of duplicate or incomplete bug reports and spend more time fixing bugs that can be fixed right away. The basic concept of bugzilla triage is that community members go through bugzilla fixing up bug reports that need information or confirmation so developers don't have to do this sort of routine day-to-day maintenance, and hopefully as a result developers spend more time fixing bugs than they do asking for clarifying information in bugreports. The Gnome bugsquad project is a good starting point in the process of building guidelines and policies for people interested in helping out in the fedora bugzilla triage effort: http://developer.gnome.org/projects/bugsquad And specifically for those people interested in participating in Fedora Bug Days, reading about how Gnome handles bug days would be quite useful: http://developer.gnome.org/projects/bugsquad/triage/faq.html#II Gnome's bugsquad project idea relies heavily on having trusted community members being able to modify existing bugreports. And eventually I hope to have a core group of fedora community members with the same sort of access to edit bugsreports (without stepping on the toes of the existing Red Hat QA team of course)...but in the beginning we can do a lot just by focusing on the bugs that need more information and working to fill those in, so the bugs can be closed by developers. So tomorrow...if you have some time, try to read over how Gnome handles triage, and then try to find open bugs in redhat's/fedora's bugzilla that are in need of more information (log files or certain command output for example). And please drop into the #fedora-bugs channel to ask questions about the triage efforts or to wax eloquent on how to make this community based triage idea more useful for everbody. -jef"www.homestarrunner.com is not a good reference for learning about bugzilla triage"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 michael at koziarski.com Wed Oct 15 06:09:06 2003 From: michael at koziarski.com (Michael A. Koziarski) Date: Wed, 15 Oct 2003 19:09:06 +1300 Subject: DVD Isos Message-ID: <3F8CE482.3030700@koziarski.com> Hey guys, I see in the FAQ (http://fedora.redhat.com/about/faq/) that fedora intends to provide DVD ISOs. Are these available? I have a lovely new DVD-Writer and I'm more than happy to help test. Cheers Koz From nos at utel.no Wed Oct 15 06:54:01 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Wed, 15 Oct 2003 08:54:01 +0200 Subject: Yo. In-Reply-To: <6cc35a6f02089e07d3@[192.168.170.10]> References: <6cc35a6f02089e07d3@[192.168.170.10]> Message-ID: <6f3c125a0308de07d3@[192.168.170.10]> On Tue, 2003-10-14 at 21:19, Oden Eriksson wrote: > Hi Folks, > > I've been involved in many aspects of the Mandrake Linux evolution and done > many great things there. Lately I feel the focus has changed to the worse, > and I'm not happy about it. What can you say to convince me to join this > community? What do you feel have gone worse with Mandrake ? Anyway, http://fedora.redhat.com/ describes what Fedora is and is not. Take your time to read that, and decide wether you want to be part of it. -- 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 pekkas at netcore.fi Wed Oct 15 07:01:06 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 15 Oct 2003 10:01:06 +0300 (EEST) Subject: RPM problem: prereq: not honored in upgrade ordering? Message-ID: Hi, This is semi-offtopic here, but is relevant to see whether this issue has since then been fixed. When I was upgrading a RHL72 box to RHL73, I noticed that /usr/sbin/sendmail symlink was not added by the alternatives (done at %post of sendmail). RHL72 didn't have alternatives, but sendmail.spec does have: Prereq: /usr/sbin/alternatives .. I upgraded between RHL72 and RHL73 using autoupdate, and the updating of RPM's is done basically by 'rpm -Uvh '. >From the logs I note that sendmail was installed before a newer version of chkconfig which would have provided /usr/sbin/alternatives. Thus, no /usr/sbin/alternatives existed when sendmail was upgraded, and the link failed. I think this smells like a problem in the ordering RPM uses to upgrade the packages? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nphilipp at redhat.com Wed Oct 15 07:26:43 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 15 Oct 2003 09:26:43 +0200 Subject: Gimp 1.3 packages, was: New extra packages and yum repository In-Reply-To: <20031014213758.29a31d6f.ms-nospam-0306@arcor.de> References: <1066147414.4511.36.camel@gibraltar.stuttgart.redhat.com> <1066148362.6205.1.camel@mozer.nailed.org> <20031014213758.29a31d6f.ms-nospam-0306@arcor.de> Message-ID: <1066202803.6024.56.camel@wombat.tiptoe.de> [ Followup to fedora-devel-list at redhat.com ] On Tue, 2003-10-14 at 21:37, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 14 Oct 2003 18:19:22 +0200, Peter Backlund wrote: > > > > - gimp-beta-1.3.21 > > > > The 1.3 series of gimp is already in Fedora, and is called gimp2. > > It's not a very good idea to supply the same software with a different > > name. > > To Nils' defense, he has been offering a small selection of own > packages for some time and already when the fedora.us package was > still called gimp13. > > Whether it makes sense to duplicate the packaging efforts, when > gimp2-1.3.21-0.fdr.1 is in the fedora.us publish queue, is a different > question. IMO both packagers should team up. With pleasure ;-). A few points I'd like to discuss and/or noticed (after comparing the gimp2 and gimp-beta packages): - whether it should be called gimp2 or gimp-beta -- gimp2 makes sense if the final package also will be called gimp2, gimp-beta could be easily obsoleted in any later final package ("gimp-beta <= 2.0") - whether or not to explicitly list directories - I guess this makes sense for /etc/gimp, but e.g. /usr/share/locale/zh_CN/LC_MESSAGES or /usr/include don't belong in gimp packages - whether or not gimptool-1.3 belongs into the -devel package - I moved the devel docs from /usr/share/gtk-doc to /usr/share/doc/gimp-beta-devel-.../ - the gimp2 package requires libaa, libexif, the gimp-beta package has a few more explicit requirements (which min versions of glib2, gtk2, pango, ...) - I think the desktop file should reflect that this is still a beta version, even though it's close it's not yet "GIMP 2" Comments? 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 nphilipp at redhat.com Wed Oct 15 07:34:57 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 15 Oct 2003 09:34:57 +0200 Subject: RPM problem: prereq: not honored in upgrade ordering? In-Reply-To: References: Message-ID: <1066203296.6024.59.camel@wombat.tiptoe.de> On Wed, 2003-10-15 at 09:01, Pekka Savola wrote: > Hi, > > This is semi-offtopic here, but is relevant to see whether this issue has > since then been fixed. > > When I was upgrading a RHL72 box to RHL73, I noticed that > /usr/sbin/sendmail symlink was not added by the alternatives (done at > %post of sendmail). RHL72 didn't have alternatives, but sendmail.spec > does have: > > Prereq: /usr/sbin/alternatives > > .. I upgraded between RHL72 and RHL73 using autoupdate, and the updating > of RPM's is done basically by 'rpm -Uvh '. > > >From the logs I note that sendmail was installed before a newer > version of chkconfig which would have provided /usr/sbin/alternatives. > Thus, no /usr/sbin/alternatives existed when sendmail was upgraded, and > the link failed. > > I think this smells like a problem in the ordering RPM uses to upgrade the > packages? Hmm, what was "Prereq" once is "Requires(pre)" now ("Prereq" works like a normal "Requires"). But that doesn't solve your problem, does it? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pekkas at netcore.fi Wed Oct 15 09:18:30 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 15 Oct 2003 12:18:30 +0300 (EEST) Subject: RPM problem: prereq: not honored in upgrade ordering? In-Reply-To: <1066203296.6024.59.camel@wombat.tiptoe.de> Message-ID: On Wed, 15 Oct 2003, Nils Philippsen wrote: > On Wed, 2003-10-15 at 09:01, Pekka Savola wrote: > > This is semi-offtopic here, but is relevant to see whether this issue has > > since then been fixed. > > > > When I was upgrading a RHL72 box to RHL73, I noticed that > > /usr/sbin/sendmail symlink was not added by the alternatives (done at > > %post of sendmail). RHL72 didn't have alternatives, but sendmail.spec > > does have: > > > > Prereq: /usr/sbin/alternatives > > > > .. I upgraded between RHL72 and RHL73 using autoupdate, and the updating > > of RPM's is done basically by 'rpm -Uvh '. > > > > From the logs I note that sendmail was installed before a newer > > version of chkconfig which would have provided /usr/sbin/alternatives. > > Thus, no /usr/sbin/alternatives existed when sendmail was upgraded, and > > the link failed. > > > > I think this smells like a problem in the ordering RPM uses to upgrade the > > packages? > > Hmm, what was "Prereq" once is "Requires(pre)" now ("Prereq" works like > a normal "Requires"). That would seem to me as a totally broken choice. If someone has put in a "prereq", you can be pretty sure he means that it should be _at least_ "Requires(pre)" and probably also "Requires" (depending on what Requires(xxx) means semantically), right? > But that doesn't solve your problem, does it? Doesn't seem to be doing that. With a small number of packages (just chkconfig, sendmail* and ntsysv, which were all required), the ordering _apparently_ went right but the result still was that alternatives was not run: # rpm -Fvh sendmail-* chkconfig-1.3.5-3.i386.rpm ntsysv-1.3.5-3.i386.rpm Preparing... ########################################### [100%] 1:chkconfig ########################################### [ 25%] 2:sendmail warning: /etc/sendmail.cf created as /etc/sendmail.cf.rpmnew ########################################### [ 50%] 3:sendmail-cf ########################################### [ 75%] 4:ntsysv ########################################### [100%] I've also tested it with -vvvv debugging, and the sendmail does (try to?) run the /usr/sbin/alternatives command, but for some reason it does not work. I've filed this as, including a log file of rpm run with -vvvvv option: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107132 -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From matthias at rpmforge.net Wed Oct 15 09:55:35 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Wed, 15 Oct 2003 11:55:35 +0200 Subject: Gimp 1.3 packages, was: New extra packages and yum repository In-Reply-To: <1066202803.6024.56.camel@wombat.tiptoe.de> References: <1066147414.4511.36.camel@gibraltar.stuttgart.redhat.com> <1066148362.6205.1.camel@mozer.nailed.org> <20031014213758.29a31d6f.ms-nospam-0306@arcor.de> <1066202803.6024.56.camel@wombat.tiptoe.de> Message-ID: <20031015115535.0423f6dd.matthias@rpmforge.net> Nils Philippsen wrote : > > Whether it makes sense to duplicate the packaging efforts, when > > gimp2-1.3.21-0.fdr.1 is in the fedora.us publish queue, is a different > > question. IMO both packagers should team up. > > With pleasure ;-). > > A few points I'd like to discuss and/or noticed (after comparing the > gimp2 and gimp-beta packages): > > - whether it should be called gimp2 or gimp-beta -- gimp2 makes sense if > the final package also will be called gimp2, gimp-beta could be easily > obsoleted in any later final package ("gimp-beta <= 2.0") > - whether or not to explicitly list directories - I guess this makes > sense for /etc/gimp, but e.g. /usr/share/locale/zh_CN/LC_MESSAGES or > /usr/include don't belong in gimp packages > - whether or not gimptool-1.3 belongs into the -devel package > - I moved the devel docs from /usr/share/gtk-doc to > /usr/share/doc/gimp-beta-devel-.../ > - the gimp2 package requires libaa, libexif, the gimp-beta package has a > few more explicit requirements (which min versions of glib2, gtk2, > pango, ...) > - I think the desktop file should reflect that this is still a beta > version, even though it's close it's not yet "GIMP 2" > > Comments? You can also check my spec file. Mine is actually called plain "gimp", so you can either upgrade to it, or "rpm -ivh" it as no files conflict with the stable gimp, although having "duplicate" packages other than kernels doesn't make most dependency tools happy. Why double efforts when they can be tripled? Uh, doesn't make sense? Indeed, none whatsoever... I just started packaging it for myself a while back. http://freshrpms.net/packages/builds/index.html?build=gimp http://ftp.freshrpms.net/pub/freshrpms/redhat/testing/9/gimp/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 0.95 (Severn) - Linux kernel 2.4.22-20.1.2024.2.36.nptl Load : 1.20 1.89 1.64 From buildsys at porkchop.devel.redhat.com Wed Oct 15 10:00:32 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Wed, 15 Oct 2003 06:00:32 -0400 Subject: rawhide report: 20031015 changes Message-ID: <200310151000.h9FA0Wk17135@porkchop.devel.redhat.com> Updated Packages: abiword-2.0.0-4 --------------- * Tue Oct 14 2003 Jeremy Katz 1:2.0.0-4 - remove duplicate desktop file (#107023) anaconda-9.0.96-0.20031014202343 -------------------------------- * Tue Oct 14 2003 Anaconda team - built new version from CVS * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 * Mon Sep 09 2002 Jeremy Katz - can't buildrequire dietlibc and kernel-pcmcia-cs since they don't always exist * Wed Aug 21 2002 Jeremy Katz - added URL * Thu May 23 2002 Jeremy Katz - add require and buildrequire on rhpl * Tue Apr 02 2002 Michael Fulbright - added some more docs * Fri Feb 22 2002 Jeremy Katz - buildrequire kernel-pcmcia-cs as we've sucked the libs the loader needs to there now * Thu Feb 07 2002 Michael Fulbright - goodbye reconfig * Thu Jan 31 2002 Jeremy Katz - update the BuildRequires a bit * Fri Jan 04 2002 Jeremy Katz - ddcprobe is now done from kudzu * Wed Jul 18 2001 Jeremy Katz - own /usr/lib/anaconda and /usr/share/anaconda * Fri Jan 12 2001 Matt Wilson - sync text with specspo * Thu Aug 10 2000 Matt Wilson - build on alpha again now that I've fixed the stubs * Wed Aug 09 2000 Michael Fulbright - new build * Fri Aug 04 2000 Florian La Roche - allow also subvendorid and subdeviceid in trimpcitable * Fri Jul 14 2000 Matt Wilson - moved init script for reconfig mode to /etc/init.d/reconfig - move the initscript back to /etc/rc.d/init.d - Prereq: /etc/init.d * Thu Feb 03 2000 Michael Fulbright - strip files - add lang-table to file list * Wed Jan 05 2000 Michael Fulbright - added requirement for rpm-python * Mon Dec 06 1999 Michael Fulbright - rename to 'anaconda' instead of 'anaconda-reconfig' * Fri Dec 03 1999 Michael Fulbright - remove ddcprobe since we don't do X configuration in reconfig now * Tue Nov 30 1999 Michael Fulbright - first try at packaging reconfiguration tool anaconda-help-9.0.95-1.200310141713 ----------------------------------- evolution-1.4.5-3 ----------------- * Tue Oct 14 2003 Jeremy Katz 1.4.5-3 - Pull in some patches from upstream CVS * Avoid division by zero with POP (X#41610) * Don't mangle headers (X#33545) * Prefix IPV6 numeric hosts properly (X#46006, #105028) * Use proper function for IPV6 reverse lookups (X#46006) * Allow timezone offset to be up to 14 hours (X#49357) * Mon Oct 13 2003 Jeremy Katz - add patch from upstream CVS to fix SMTP syntax problems (#106630) - really remove duplicate menu entry (#103826) * Mon Oct 06 2003 Jeremy Katz - make redhat-email.desktop symlink relative (#104391) * Wed Sep 24 2003 Jeremy Katz - add ipv6 support per dwmw2's request gdm-2.4.4.3-7 ------------- * Thu Oct 09 2003 Jonathan Blandford 1:2.4.4.3-6.sel - new patch from George to fix #106189 - change bg color in rhdefaults patch - turn off SELinux * Wed Oct 08 2003 Dan Walsh 1:2.4.4.3-6.sel - turn on SELinux gnumeric-1.2.1-1 ---------------- * Tue Oct 14 2003 Havoc Pennington 1:1.2.1-1 - add %post to install schemas - 1.2.1 grub-0.93-7 ----------- * Tue Oct 14 2003 Jeremy Katz 0.93-7 - rebuild * Wed Jul 02 2003 Jeremy Katz - Requires: /usr/bin/cmp (#98325) kernel-2.4.22-1.2093.nptl ------------------------- * Mon Oct 13 2003 Dave Jones - Back out previous unnecessary commit. - More changes from 2.4.23pre - Fix ACPI hang with sysrq & o - Reenable laptopmode (but not AAM). - Fix pci_generic_prep_mwi export breakage - Small ACPI tweaks - attach_mnt fix - fix 2.4.x incorrect argv[0] for init - kupdated: correctly dequeue SIGSTOP signals - Assorted VM fixes. - PageReserved memory counting fix - page->flags corruption fix - Remove racy optimization from exec_mmap() - Fix quota counter overflow - Fix do_proc_readlink failpath - cciss update: support new controller - Numerous networking updates. - Fix potential PPPoE oops - Clear all flags in exec_usermodehelper - Clear IRQ_INPROGRESS in setup_irq() - Numerous NetFilter fixes/improvements. mozilla-1.4.1-10 ---------------- * Tue Oct 14 2003 Christopher Blizzard 37:1.4.1-9 - Add langpacks rawhide-release-20031015-1 -------------------------- redhat-artwork-0.85-1 --------------------- * Wed Oct 15 2003 Alexander Larsson 0.85-1 - fix icons in gtk theme redhat-config-boot-0.1.4-1 -------------------------- * Tue Oct 14 2003 Harald Hoyer 0.1.4-1 - autofooed and intltoolized r-c-boot redhat-config-kickstart-2.4.2-1 ------------------------------- * Tue Oct 14 2003 Brent Fox 2.4.2-1 - call language_backend correctly (bug #103625) unixODBC-2.2.5-8 ---------------- * Tue Oct 14 2003 Fernando Nasser 2.2.5-8 - Move libodbcmyS.so to the main package as well. It is used the same way as libodbcpsqlS.so. * Tue Oct 14 2003 Fernando Nasser 2.2.5-7 - Bumped the version so it rebuilds. * Tue Oct 14 2003 Fernando Nasser 2.2.5-4 - Revert previous change and special case libodbcpsql.so and libodbcpsqlS.so instead. Here is the explanation (from Elliot Lee): ".so files are only used at link time for normal dynamic libraries. The libraries referred to here are being used as dynamically loaded modules, so I guess moving those particular .so files back to the main package would make sense, but the other .so files should stay in the devel subpackage." * Fri Oct 10 2003 Fernando Nasser 2.2.5-3 - Moved all the shared library symlinks to the main package. They were deliberatedly being added to the devel package for unknown reasons but this was forcing users to install the devel package always. - No need to special-case libodbc.so anymore up2date-4.1.7-1 --------------- * Wed Oct 15 2003 Adrian Likins - only download headers approriate to the current machine vim-6.2.121-1 ------------- * Tue Oct 14 2003 Karsten Hopp 1:6.2.121-1 - patchlevel 121 - fix buildrequires (#106824, #105832) wordtrans-1.1pre13-2 -------------------- * Tue Oct 14 2003 Than Ngo 1.1pre13-2 - enable fribidi - fixes utf8 issue From oden.eriksson at kvikkjokk.net Wed Oct 15 10:04:37 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Wed, 15 Oct 2003 12:04:37 +0200 Subject: Yo. In-Reply-To: <1066163883.31347.70.camel@opus> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <200310142232.24649.oden.eriksson@kvikkjokk.net> <1066163883.31347.70.camel@opus> Message-ID: <200310151204.37871.oden.eriksson@kvikkjokk.net> tisdagen den 14 oktober 2003 22.38 skrev seth vidal: > where are your interests? You said you were working with mandrake some > and didn't like where things were going - where were things going? what > is it that you didn't like? What is it that you do like? What things can > you do? > > In order to answer your question persuasively I'll need to know a bit > more about you. Mandrake=mdk My interests are non gui applications, server and security applications mainly. The mdk focus seems to be rather ship a game than a nice server application, I simply hate games. I'm maintaining hundreds of mdk packages in contribs and maybe up to 10 in main. I'm the one responsible for mdk to have a total of 113 apache2 modules, this has taken me about 1,5 years. I do not write code at all nor am I a unix guru, but I usually find a way to solve problems anyhow, if I can't fix it I ask for help, I give credit, I fix it, simple. I'm nearing 40yo. I'm a doer. Visit my status page regarding apache2 here: http://www.deserve-it.com/modules_for_apache2.html I recently started to look into IDN (International domain names) for mdk and patched glibc with libidn support and also patched bind with idnkit support (I got no responce from mdk, but everyone could be on vacation...). This basically means this is a start towards IDN, not the solution as all applications using gethostby* needs to be patched (for example ping) to support IDN. Bind on the other hand, well actually host, nslookup and dig can do IDN. I believe any name server can do IDN. KDE 3.2.x will have support for IDN using libidn, or possibly a patched glibc. Mozilla 1.4 supports IDN. Sweden (where I live, well to be specific I live in a small town named "Jokkmokk" way up in the north.) is the first country in Europe to implement IDN on the top level TLD dot SE. Read about it here: http://www.nic-se.se/english/ I have been doing (OpenSource) research for a long time and have fiddled a lot with rpm packages, maybe for five years now. I like this. Cheers. From oden.eriksson at kvikkjokk.net Wed Oct 15 10:11:36 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Wed, 15 Oct 2003 12:11:36 +0200 Subject: Yo. In-Reply-To: <20031014230306.11777f4f.ms-nospam-0306@arcor.de> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <200310142232.24649.oden.eriksson@kvikkjokk.net> <20031014230306.11777f4f.ms-nospam-0306@arcor.de> Message-ID: <200310151211.36056.oden.eriksson@kvikkjokk.net> tisdagen den 14 oktober 2003 23.03 skrev Michael Schwendt: [...] > > Is this a hostile place? > > No. > > > Are we picking on "new comers" here? > > No. Thank you. From oden.eriksson at kvikkjokk.net Wed Oct 15 10:19:38 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Wed, 15 Oct 2003 12:19:38 +0200 Subject: Yo. In-Reply-To: <200310141706.50147.czar@czarc.net> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <200310142232.24649.oden.eriksson@kvikkjokk.net> <200310141706.50147.czar@czarc.net> Message-ID: <200310151219.38828.oden.eriksson@kvikkjokk.net> tisdagen den 14 oktober 2003 23.06 skrev Gene C.: > On Tuesday 14 October 2003 16:32, Oden Eriksson wrote: > > Am I wrong? > > > > Is this a hostile place? > > Not really hostile. Some folks don't always engage brain before > speaking/typing (I have done this a time or two) but on the whole this is a > friendly group trying to get the best product we can. > > Admittedly, this effort is Red Hat oriented and I am all for their > succeeding (I do own a few shares of stock). The Red Hat folks I have had > dealings with were all very professional. Yes, sometimes things can get a > bit testy but everyone is trying to do it "right". > > When Red Hat found that their process of producing a "Retail Linux" was not > producing sufficient $$ (and this is important because all companies are in > the business of making money or they will not exist in the long run), they > are trying to come up with a new model of doing business (The Fedora > Project) which will benefit both Red Hat and the Open Source (Linux) > community. > > I suggest you might want to "lurk" for a while on both this (the devel) and > the test mailing lists before jumping in. You might also want to look at > the archives of these lists to see what has gone before. > > The whole fedora thing is still in a state of flux and Red Hat (and others) > are trying to figure out how to do things ... how to handling packages in > Alternatives, in Extras, in Legacy, etc ... just what is Legacy and how > will it fit/work with the Fedora Core ... does Lagacy include old > (unsupported) releases of Red Hat Linux ... etc., etc. Thank you very much for this explanation, looks good, sounds sound. I will lurk awhile and see what's up. No one at mandrake or at the community wiki has thought about supporting EOL products this way. I like that idea. From oden.eriksson at kvikkjokk.net Wed Oct 15 10:30:22 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Wed, 15 Oct 2003 12:30:22 +0200 Subject: Yo. In-Reply-To: <200310141744.36789.czar@czarc.net> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <200310142232.24649.oden.eriksson@kvikkjokk.net> <200310141744.36789.czar@czarc.net> Message-ID: <200310151230.22857.oden.eriksson@kvikkjokk.net> tisdagen den 14 oktober 2003 23.44 skrev Gene C.: > Another point, I believe that Mike has summarized the Fedora situation > quite well in this message: > https://www.redhat.com/archives/fedora-list/2003-October/msg00358.html > on the fedora-list at redhat.com Aha, I see. Seems cool. I'm used to how this works in Mandrake as I'm involved with maintaining some core packages and many contribs packages. I hope the infrastructure will be worked out soon and guide lines will be written, etc. Thanks for the pointer. From mharris at redhat.com Wed Oct 15 12:00:32 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 15 Oct 2003 08:00:32 -0400 (EDT) Subject: Fedora and RedHat's autism toward personal users In-Reply-To: <3F8C167B.4000909@eburg.com> References: <20031013202411.74299.qmail@web80008.mail.yahoo.com> <3F8B939E.8090708@eburg.com> <3F8BEEE1.2020906@wanadoo.es> <3F8C167B.4000909@eburg.com> Message-ID: On Tue, 14 Oct 2003, Gordon Messmer wrote: >>>Qmail's license precludes its being distributed as part of Fedora. As >>>an alternative, I would suggest Courier-MTA: http://www.courier-mta.org/ >> >> http://cr.yp.to/distributors.html > >I'm well aware of qmail's license. It's been discussed here on a number >of occasions past. Specifically, that page notes: > >You may distribute a precompiled package if installing your package >produces exactly the same files, in exactly the same locations, that a >user would obtain by installing one of my packages listed > >That alone is enough to prevent distribution. A distributor can not >ship bug fixes in a binary form. You can debate it all you want, but I >suggest that you look at the previous debates instead. > >I know of a number of people who still use qmail, and are very fond of >it. That's very well and good, but the license is going to keep qmail >in the hands of the people who want to build it for themselves, and out >of distributions that care about Free Software. While I personally believe it is unlikely that we'd be adding a new MTA to the Fedora Core itself anytime soon, alternative MTAs without legal or licensing issues sound perfect for 'Fedora Alternatives' in the long term, and maintained outside Red Hat. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From jspaleta at princeton.edu Wed Oct 15 12:05:42 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 15 Oct 2003 08:05:42 -0400 Subject: RPM problem: prereq: not honored in upgrade ordering? Message-ID: <1066219542.13075.7.camel@localhost.localdomain> Pekka Savola wrote: > .. I upgraded between RHL72 and RHL73 using autoupdate, and the > updating of RPM's is done basically by 'rpm -Uvh '. done basically. by ...or done exactly by. I'm a bit suspicious that the problem lies with the perl script autoupdate and not necessarily rpm...but you could certainly test whether its a problem with rpm. If you can rollback the changes you made then place the updates you did in a local directory then do rpm -Uvh or -Fvh on that local directory..without using autoUpdate...you should be able to determine if it is in fact a problem with rpm. But even if you do determine it is a bug in rpm....the version of rpm might not be so relevant to the current version in the fedora test releases :->. -jef -------------- 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 mharris at redhat.com Wed Oct 15 12:07:56 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 15 Oct 2003 08:07:56 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: <3F8C1866.4040503@cypress.com> References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <1065696476.3713.3.camel@ulysse.olympe.o2t> <3F86CBD0.5090209@cypress.com> <3F8C1866.4040503@cypress.com> Message-ID: On Tue, 14 Oct 2003, Thomas Dodd wrote: >> The XFree86 supplied config tools are gone for 2 main reasons: > >Not that I was arguing (again) for their inclusion :) Ok.. >The point being, somone could use the XF86 tools as part of YAXCT >(yet another X config tool). No that RHL/RHEL/FC don't include them >their app would break. It's extremely unlikely an external config tool would use xf86config or xf86cfg directly for configuration. If there is anything out there it would more likely than not be something that is a core part of an OS distribution rather than an addon, such as a distro supplied control panel type of thing in some other distribution. Other X config tools out there no doubt either: 1) Implement their own detection, config file parsing/writing routines, etc. or 2) Use libxf86config.a - which is what our own config tool does. libxf86config.a is included with XFree86, and is the library which the XFree86 supplied config tools themselves use. This is included in the distribution. >It's not your responsibility, as Red Hat X maintainer, to fix their tool >is it? 'course not. >You wouldn't keep the XF86 stuff around for it, would you? Nope. >No, you said it was going away, then it went away. It's up to >them to fix their app, either integrate the XF86 parts, or >modify the too to use the new Red Hat parts. Indeed. Or better, use libxf86config like most sane tools do/should. It's not like there are a plethora of 3rd party X configuration tools however, so this is very theoretical. >> 2) In many cases, people use them simply because they don't know >Those are the tools mentioned in the documentation for XF86 though. People who report bugs in specific XFree86 documentation referencing the tools which we have disabled, I'd be glad to fix with future documentation updates. It'd even be a useful idea for someone to file a "container" bug which says something like "Update XFree86 documentation to refer to redhat-config-xfree86 everywhere instead of the XFree86 supplied tools." Then when people file individual cases where the docs refer to these tools, they can be marked as dependancies. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Wed Oct 15 12:20:34 2003 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 15 Oct 2003 08:20:34 -0400 (EDT) Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: <3F8C1969.9060107@cypress.com> References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <3F86CE6C.9030601@cypress.com> <3F8C1969.9060107@cypress.com> Message-ID: On Tue, 14 Oct 2003, Thomas Dodd wrote: >>>I'm curious about that. With out xfs, how do I share fonts between >>>machines? >> >> Use xfs if you need it. Or, use NFS or SMB. > >As a user I can 'xset +fp ; xset fp rehash'. >I cannot export/mount filesystems. By default, the X server's font modules are not loaded (unless that changed without my knowledge). So xset +fp will fail unless you've reconfigured the X server to specify the font modules get loaded. xset +fp does not talk to the font server - it talks to the X server. Anyway, as I said.. X core fonts are a legacy technology. Users will be able to use them as long as the core protocol permits them. However, desktops are moving more and more to client side fonts, and as this happens, over time, core fonts are going to become more and more irrelevant. If you're using our GNOME or KDE desktop, you're using client side fonts and you're not using the font server for those applications. xset fp options wont do anything for these applications. At some point core fonts will be for the most part irrelevant. That doesn't mean nothing will use them anymore of course. But we will cross that bridge when the time comes. I'm not saying "Fedora Core 2 will not come with xfs" or anything like that, so nobody really needs to convince me that they use xfs or need it. It's not going anywhere anytime soon. The core font technology is deprecated, or in other words "announced to be out of style" more or less, and new applications shouldn't use it. The X server will have some fonts compiled right into the X server in the future, to ensure core fonts are supported at least minimally even if xfs is not running and no fontpaths are configured. As for xfs, it will likely be included and enabled by default as long as it is needed, and doesn't present any major technical problems I would think. Even if we were to disable it by default in Fedora Core 6 or somesuch, it doesn't mean it wouldn't be included. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From veillard at redhat.com Wed Oct 15 12:35:50 2003 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 15 Oct 2003 08:35:50 -0400 Subject: Yum'ification of the rhn_applet Message-ID: <20031015083550.D16905@redhat.com> I have just released an updated version of rhn_applet which should work better for the Fedora framework: - handle Yum repositories - handle multiple repositories - does not require RHN registration You can find it at: http://people.redhat.com/~veillard/testing/yum/rhn-applet/2.1.0/ the Yum/Fedora repository for it is: http://people.redhat.com/~veillard/testing/yum/rhn-applet/ It uses the same configuration file as up2date, i.e. /etc/sysconfig/rhn/sources Features: - do some caching on the client see ~/.rhn-applet/*.yum - tries to limit the load on servers to a minimal amount - the applet does not need to be restarted if sources are added or removed from /etc/sysconfig/rhn/sources - should be able to handle HTTPS connections TODO: - HTTP(S) proxy support (easy) - FTP support - better error reporting when source are unavailable Feedback welcome, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From pekkas at netcore.fi Wed Oct 15 12:49:54 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 15 Oct 2003 15:49:54 +0300 (EEST) Subject: RPM problem: prereq: not honored in upgrade ordering? In-Reply-To: <1066219542.13075.7.camel@localhost.localdomain> Message-ID: On Wed, 15 Oct 2003, Jef Spaleta wrote: > Pekka Savola wrote: > > .. I upgraded between RHL72 and RHL73 using autoupdate, and the > > updating of RPM's is done basically by 'rpm -Uvh '. > > done basically. by ...or done exactly by. I'm a bit suspicious that the > problem lies with the perl script autoupdate and not necessarily > rpm... Basically, yes. Precisely, it calls 'rpm -Uvh --nodeps' on all packages if 'rpm --test -U' on those packages was successful (I don't know why nodeps in that case), otherwise it calls just 'rpm -U'. I don't recall which was done in this particular case. > but you could certainly test whether its a problem with rpm. I did not see wrong reordering (but in all fairness, the autoupdate was 250+ packets, I just tested the bare minimum of 4 here), at least outright, but the fundamental problem still persisted. (The next message in the thread.) > If you can rollback the changes you made then place the updates you did > in a local directory then do rpm -Uvh or -Fvh on that local > directory..without using autoUpdate...you should be able to determine if > it is in fact a problem with rpm. Well, yes, I can easily see the main problem, alternatives not being able to run in sendmail's %post, with plain rpm as well. > But even if you do determine it is a bug in rpm....the version of rpm > might not be so relevant to the current version in the fedora test > releases :->. I haven't tried to simulate this. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jeremyp at pobox.com Wed Oct 15 13:04:50 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: Wed, 15 Oct 2003 09:04:50 -0400 Subject: Fedora Extras??? In-Reply-To: <3F8C7A67.6000508@research.att.com> References: <1066163306.24423.9.camel@stantz.corp.sgi.com> <1066164471.27006.15.camel@mozer.nailed.org> <3F8C7A67.6000508@research.att.com> Message-ID: <1066223090.4372.1.camel@jeremy.dtcc.cc.nc.us> On Tue, 2003-10-14 at 18:36, John Ellson wrote: > Peter Backlund wrote: > > > Overall, this could probably go into Fedora Extras pretty much right > > away. ... > > > Where can we find these "Fedora Extras" ? > > And where are the instructions on how we might contribute to them? > The official "Fedora Extras" has not been set up yet. But in the interim, visit http://www.fedora.us/ to use these packages. You can follow the QA procedure outlined there to contribute if you wish. --Jeremy -------------- 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 gemi at bluewin.ch Wed Oct 15 13:06:05 2003 From: gemi at bluewin.ch (gemi at bluewin.ch) Date: Wed, 15 Oct 2003 15:06:05 +0200 Subject: Contributing packages Message-ID: <3F710DB5000A829E@mssazhb-int.msg.bluewin.ch> Hi, I would like to contribute RPM packages to the Fedora project. I am especially interested in development tools like programming languages etc... I think these packages would go into fedora-extras. However there doesn't seem to be any information about repositories. There is also no information about non-free packages, i.e. software only available as binaries. How should I proceed? Other questions: What if developers of software already built RPM packages? Is it alright to repackage them? Sometimes it is quite difficult to create pure source packages, for example Haskell compilers that need a Haskell compiler to bootstrap. Is it possible in this case to package binaries within a source package? What is the policy regarding Java software? Will there be an RPM for Sun's JVM in Fedora? Regards, G?rard From g.magnini at tiscali.it Wed Oct 15 13:33:42 2003 From: g.magnini at tiscali.it (Giacomo Magnini) Date: Wed, 15 Oct 2003 15:33:42 +0200 Subject: Translations Message-ID: <3F8D4CB6.20406@tiscali.it> Hi all, I'm new to the list, and I wish to work on translating Fedora packages in my own language (Italian). Is someone already working on this? Should I look anywhere else to gather more informations? Is someone already coordinating the effort? Sorry for the slew of questions! :) Cheers, Giacomo Magnini. PS. I'm already working on the Mozilla translation team, if this is of any use... From pauln at truemesh.com Wed Oct 15 13:43:51 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 15 Oct 2003 14:43:51 +0100 Subject: Contributing packages In-Reply-To: <3F710DB5000A829E@mssazhb-int.msg.bluewin.ch> References: <3F710DB5000A829E@mssazhb-int.msg.bluewin.ch> Message-ID: <20031015134350.GZ24349@shitake.truemesh.com> On Wed, Oct 15, 2003 at 03:06:05PM +0200, gemi at bluewin.ch wrote: > Hi, > > I would like to contribute RPM packages to the Fedora project. At the moment you can contribute via the fedora.us project: http://www.fedora.us/wiki/PackageSubmissionQAPolicy > What is the policy regarding Java software? Will there > be an RPM for Sun's JVM in Fedora? Not in Fedora Core but JPackage currently and will make RPMS for the jdk (http://www.jpackage.org). Also you can see how we deal with distribution (nosource packages). Paul From jspaleta at princeton.edu Wed Oct 15 14:13:17 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 15 Oct 2003 10:13:17 -0400 Subject: RPM problem: prereq: not honored in upgrade ordering? Message-ID: <1066227197.25026.18.camel@spatula> Pekka Savola wrote: > Basically, yes. Precisely, it calls 'rpm -Uvh --nodeps' --nodeps !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! should you expect correct package ordering...if --nodeps is used? if you aren't checking dependancies when doing the package upgrade/install....HOW does rpm know to order a packagelist a certain way...using --nodeps argument you tell rpm to ignore dependancy issues...im actually shocked autoupdate doesn't break all the time. if autoupdate is using --nodeps to install packages...that is pretty much going to shortcircuit whatever care rpm takes with resolving dependancies...including installation ordering. if autoupdate is using --nodeps, then i say its pretty much a problem with autoupdate and not rpm...and therefore very very much off topic to any fedora discussion or red hat linux discussion since autoupdate is a 3rd party tool outside of the distro. Using --nodeps is not wise, unless you know what you are doing. And I certaintly don't think an automatic tool should be using --nodeps. --jef"Smokey the Bear says: Prevent dependancy breakage, don't use --nodeps"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 Dan_Ulinski at hotmail.com Wed Oct 15 14:27:26 2003 From: Dan_Ulinski at hotmail.com (Dan Ulinski) Date: Wed, 15 Oct 2003 10:27:26 -0400 Subject: Distribution Size In-Reply-To: <1066150344.27013.0.camel@mozer.nailed.org> Message-ID: <000201c39328$74dd9740$8002a8c0@RFID.local> >> And still = while the installation is going on it fails because of not >> enough disk space for = temp files created while the installation >> >> is = processing rpm-s. > Did you create a swap partition, and if you did, how large was it? Yes the Partition Size was 512 mB. Twice the size of my RAM. I have also tried to install the servern core three times since and Increase the size of the partition to 8 GB and still no luck. I think I might be having a hadware problem. It seems to fail in the OpenOffice rpm install. Saying that there is a fatal error and must exit the install process. The possible causes that the dialog box lists are: 1. Media error 2. Disk Space Cannot figure out what is going on with the install at this point. Dan From peter.backlund at home.se Wed Oct 15 14:37:21 2003 From: peter.backlund at home.se (Peter Backlund) Date: 15 Oct 2003 16:37:21 +0200 Subject: Distribution Size In-Reply-To: <000201c39328$74dd9740$8002a8c0@RFID.local> References: <000201c39328$74dd9740$8002a8c0@RFID.local> Message-ID: <1066228641.27011.22.camel@mozer.nailed.org> > Saying that there is a fatal error and must exit the install process. > The possible causes that the dialog box lists are: > 1. Media error > 2. Disk Space Did you run mediacheck? The CD's might be bad if you burned them at high speed. /Peter From Dan_Ulinski at hotmail.com Wed Oct 15 14:59:13 2003 From: Dan_Ulinski at hotmail.com (Dan Ulinski) Date: Wed, 15 Oct 2003 10:59:13 -0400 Subject: Distribution Size In-Reply-To: <1066228641.27011.22.camel@mozer.nailed.org> Message-ID: <000001c3932c$e546c390$8002a8c0@RFID.local> >> Saying that there is a fatal error and must exit the install process. >> The possible causes that the dialog box lists are: >> 1. Media error >> 2. Disk Space > Did you run mediacheck? The CD's might be bad if you burned them at high > speed. After the second attempt I ran media check. All three disks passed. -- 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 Wed Oct 15 15:29:58 2003 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 15 Oct 2003 11:29:58 -0400 Subject: Japanese Font Antialiasing - Where did it go? In-Reply-To: <1066179616.1335.6.camel@localhost.localdomain> References: <1066179616.1335.6.camel@localhost.localdomain> Message-ID: <1066231798.24675.15.camel@poincare.devel.redhat.com> On Tue, 2003-10-14 at 21:00, Matt Jones wrote: > Hi - I just noticed that the font antialiasing seems to have stopped > working for Japanese fonts. Admittedly, I haven't been using japanese on > rawhide for about 3 weeks, but I have no clue what's going wrong. > > When i run LANG=ja_JP gedit i get nasty non-antialiased text, which used > to not happen. Glancing at /etc/fonts/fonts.conf, I see some comment > about disabling antialiasing for korean, japanese and chinese fonts, yet > when I re-enable (change a false to a true) it via that xml file, > nothing changes. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97337 It's a fontconfig bug, but hard to fix without updating to devel code, so I've worked around it for the fonts we ship. The package with the fix had been sitting around for a month because of some problems I encountered before with Perl include paths and the documentation; I've thrown it into the build system again and hopefully it will build this time. Regards, Owen From P at draigBrady.com Wed Oct 15 15:33:02 2003 From: P at draigBrady.com (P at draigBrady.com) Date: Wed, 15 Oct 2003 16:33:02 +0100 Subject: Yum'ification of the rhn_applet In-Reply-To: <20031015083550.D16905@redhat.com> References: <20031015083550.D16905@redhat.com> Message-ID: <3F8D68AE.3010206@draigBrady.com> Daniel Veillard wrote: > I have just released an updated version of rhn_applet which > should work better for the Fedora framework: > - handle Yum repositories > - handle multiple repositories > - does not require RHN registration > > You can find it at: > http://people.redhat.com/~veillard/testing/yum/rhn-applet/2.1.0/ But does up2date work with yum? I updated rh9 with the latest up2date from rawhide and rhn-applet from above, but up2date seems to hang on the first RPM header with the following as my only source? yum fedora-i386-os http://download.fedora.us/fedora/redhat/0.95/i386/yum/os/ cheers, P?draig. From ms-nospam-0306 at arcor.de Wed Oct 15 16:25:17 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 15 Oct 2003 18:25:17 +0200 Subject: Gimp 1.3 packages, was: New extra packages and yum repository In-Reply-To: <1066202803.6024.56.camel@wombat.tiptoe.de> References: <1066147414.4511.36.camel@gibraltar.stuttgart.redhat.com> <1066148362.6205.1.camel@mozer.nailed.org> <20031014213758.29a31d6f.ms-nospam-0306@arcor.de> <1066202803.6024.56.camel@wombat.tiptoe.de> Message-ID: <20031015182517.7250d596.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 15 Oct 2003 09:26:43 +0200, Nils Philippsen wrote: > A few points I'd like to discuss and/or noticed (after comparing the > gimp2 and gimp-beta packages): > > - whether it should be called gimp2 or gimp-beta -- gimp2 makes sense if > the final package also will be called gimp2, gimp-beta could be easily > obsoleted in any later final package ("gimp-beta <= 2.0") Not a big issue. What about "Obsoletes: gimp2 < 2.0-0.fdr.1"? And with "gimp-beta <= 2.0", what would you do with any release candidates? Also, the different base package name is good to distinguish the extra gimp2 packages from the gimp packages in Fedora Core: $ rpm -qa 'gimp*' gimp-1.2.3-20.2 gimp-print-4.2.5-2 gimp-data-extras-1.2.0-8 gimp-print-plugin-4.2.5-2 gimp-print-devel-4.2.5-2 gimp-print-utils-4.2.5-2 > - whether or not to explicitly list directories - I guess this makes > sense for /etc/gimp, but e.g. /usr/share/locale/zh_CN/LC_MESSAGES or Some of the locale directories are not owned by glibc-common. One of the goals of owning directories is, that - when the package is installed with a restrictive umask, the directories which are created get good permissions, - when the package is uninstalled, empty directories are not left behind. Redundancy with regard to owning directories below /usr/share/locale doesn't hurt, does it? You have missed /etc/gimp, /usr/lib/gimp, /usr/lib/gimp/1.3/environ, and /usr/share/gimp. > /usr/include don't belong in gimp packages Correct. Minor glitch. One of the previous gimp2 packages was relocated to a different root directory. > - whether or not gimptool-1.3 belongs into the -devel package Looks like a devel tool. But since it also provides options for installation of .scm scripts into user's directories, it makes sense to keep it in the main package. > - I moved the devel docs from /usr/share/gtk-doc to > /usr/share/doc/gimp-beta-devel-.../ /usr/share/gtk-doc/html/ is a place where "devhelp" looks for manuals. > - I think the desktop file should reflect that this is still a beta > version, even though it's close it's not yet "GIMP 2" Not an issue for a package in an "unstable" extras repository. The splash screen, "About" and other parts contain the 1.3.21 version number. Apart from that, gimp2 doesn't put an entry in the top-level desktop menu where the "stable" 1.2.3 version can be found. But package description/summary could mention somewhere that it's a beta version. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/jXTt0iMVcrivHFQRAjBlAJ9ryFlhLCfXtzWbQsu971mGYEd0mQCdEAX0 rcfqr7S5W2GxhdTs1MRhG5M= =UGEe -----END PGP SIGNATURE----- From pekkas at netcore.fi Wed Oct 15 16:26:55 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 15 Oct 2003 19:26:55 +0300 (EEST) Subject: RPM problem: prereq: not honored in upgrade ordering? In-Reply-To: <1066227197.25026.18.camel@spatula> Message-ID: On 15 Oct 2003, Jef Spaleta wrote: > Pekka Savola wrote: > > > Basically, yes. Precisely, it calls 'rpm -Uvh --nodeps' > > --nodeps !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [...] Thanks for the rant. Unfortunately, it is not relevant to this discussion, if you read the mail in detail. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From katzj at redhat.com Wed Oct 15 16:45:27 2003 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 15 Oct 2003 12:45:27 -0400 Subject: Gimp 1.3 packages, was: New extra packages and yum repository In-Reply-To: <1066202803.6024.56.camel@wombat.tiptoe.de> References: <1066147414.4511.36.camel@gibraltar.stuttgart.redhat.com> <1066148362.6205.1.camel@mozer.nailed.org> <20031014213758.29a31d6f.ms-nospam-0306@arcor.de> <1066202803.6024.56.camel@wombat.tiptoe.de> Message-ID: <1066236327.10429.3.camel@mirkwood.devel.redhat.com> On Wed, 2003-10-15 at 03:26, Nils Philippsen wrote: > - whether it should be called gimp2 or gimp-beta -- gimp2 makes sense if > the final package also will be called gimp2, gimp-beta could be easily > obsoleted in any later final package ("gimp-beta <= 2.0") You can obsolete gimp2 just as well (not that I'm arguing one way or another) > - I moved the devel docs from /usr/share/gtk-doc to > /usr/share/doc/gimp-beta-devel-.../ Please don't do this. With the docs in /usr/share/gtk-doc, they'll get picked up by devhelp. With them in /usr/share/doc/gimp-beta-devel, they are just there for reading by going there directly. Cheers, Jeremy From jspaleta at princeton.edu Wed Oct 15 17:01:56 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: 15 Oct 2003 13:01:56 -0400 Subject: RPM problem: prereq: not honored in upgrade ordering? Message-ID: <1066237316.25026.67.camel@spatula> Pekka Savola wrote: > Thanks for the rant. Unfortunately, it is not relevant to this > discussion, if you read the mail in detail. Its relevant...to the bug summary you posted to bugzilla..which speaks about a 'reordering issue' where you didn't specify that you orginally saw the reordering issue with using autoupdate. Your bugzilla reports is quite misleading about the circumstances where you saw the 'reordering' issue...and makes it hard to actually try to verify...since you do not make mention of autoupdate in the bugzilla entry....full disclosure is important. You initial bugreport comment about a 'reordering' problem is misleading since you didn't specify the exact commandline you used when doing the 300 RPMs install...i'd hate for a developer to waste time trying to confirm a general 'reordering' problem wider in scope than a specific packaging problem with sendmail when 'reordering' bug was actually because autoupdate used --nodeps. This could easily a problem specific to the sendmail package...a packaging error with sendmail, and not a general problem with rpm itself. Have you checked to see if the other programs that use the alternatives system installs correctly..like the printing subsystems? If other alternatives based systems get installed correctly...maybe its not a general rpm bug at all..and your bugreport is misfiled under rpm. Wouldn't you hate to waste the rpm developers time hunting down a general 'reordering' bug that doesn't actually exist...because you failed to tell them you were using autoupdate to do the large 300+ package install. Now...that we are all pretty much convinced that a 'reordering' bug would be specific to autoupdate and not rpm...we can handle the specific 'core problem' of why the postinstall scriptlet is not running alternatives like you expect. Have you tried running the alternatives command that is in the postinstall scriptlet by hand? /usr/sbin/alternatives --install /usr/sbin/sendmail mta /usr/sbin/sendmail.sendmail 90 --slave /usr/bin/mailq mta-mailq /usr/bin/mailq.sendmail --slave /usr/bin/newaliases mta-newaliases /usr/bin/newaliases.sendmail --slave /usr/bin/rmail mta-rmail /usr/bin/rmail.sendmail --slave /usr/share/man/man1/mailq.1.gz mta-mailqman /usr/share/man/man1/mailq.sendmail.1.gz --slave /usr/share/man/man1/newaliases.1.gz mta-newaliasesman /usr/share/man/man1/newaliases.sendmail.1.gz --slave /usr/share/man/man5/aliases.5.gz mta-aliasesman /usr/share/man/man5/aliases.sendmail.5.gz --initscript sendmail thats one very long commandline...it could be a simple syntax error in the command or something and nothing to do with the order rpm is trying to install things (if used without --nodeps). Can you get that alternatives --install ..... command to work right after the rpms are installed? -jef"make sure you test LPRng and cups since they use alternatives as 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 jaap_haitsma at zonnet.nl Wed Oct 15 20:23:14 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Wed, 15 Oct 2003 22:23:14 +0200 Subject: Yum'ification of the rhn_applet In-Reply-To: <20031015083550.D16905@redhat.com> References: <20031015083550.D16905@redhat.com> Message-ID: <3F8DACB2.9040803@zonnet.nl> Daniel Veillard wrote: > I have just released an updated version of rhn_applet which > should work better for the Fedora framework: > - handle Yum repositories > - handle multiple repositories > - does not require RHN registration > > You can find it at: > http://people.redhat.com/~veillard/testing/yum/rhn-applet/2.1.0/ > the Yum/Fedora repository for it is: > http://people.redhat.com/~veillard/testing/yum/rhn-applet/ > It uses the same configuration file as up2date, i.e. > /etc/sysconfig/rhn/sources > > Features: > - do some caching on the client see ~/.rhn-applet/*.yum > - tries to limit the load on servers to a minimal amount > - the applet does not need to be restarted if sources are > added or removed from /etc/sysconfig/rhn/sources > - should be able to handle HTTPS connections > > TODO: > - HTTP(S) proxy support (easy) > - FTP support > - better error reporting when source are unavailable > > Feedback welcome, > > Daniel > Hi Daniel, It works for me. Nice that the update applet now finally tells you when there are updates :-) One minor remark up2date tells me that all the files of the update are 0kB. Is this due to yum or is there a bug?? Jaap From Christer.Hemgren at axfood.se Wed Oct 15 21:04:48 2003 From: Christer.Hemgren at axfood.se (Hemgren, Christer) Date: Wed, 15 Oct 2003 23:04:48 +0200 Subject: Wlan problem and enterprise wlan needs Message-ID: Hello I 'm using the "Severn Beta 2 (i386)" updated 13 Oct on a Compaq laptop and are very pleased with it, but i have problem with the PCMCIA wlan cards. It's got broken after a up2date. I can use the Cisco aironet 350 as i hade one the install moment but when i shift to "PRISMA2" chipset card Netgear MA401, it don't work. Kudzu finds it. The "Netgear MA401" work to associate with the CISCO AP1200 before it got broken using iwconfig eth2 essid "secret" But the Cisco aironet 350 card don't associate using iwconfig, only if it is a broadcasted ssid (by a sheep 3Com AP at home)!!!! strange!!! I think the aironet driver works strange in enterprise wlan using EAP. Are the driver not up to date? I regally shift wlan card between aironet and the "PRISMA2" card but after one up2date it stop working for the "PRISMA2" card but i don't now if it was a kernel or other .rpm package broke it or even when for the matter. I thing it is a problem with the module. Both cards works in M$ XP. Should i go for the new beta to see if there is updates or update this one? I have try Arjan's "2.6 test7.1.56.rpm" kernel and in that no wlan card or USB mouse works. I'm still missing some wlan stuff like Xsupplicant from http://www.open1x.org/ for secure wlan login using 802.1x (most have in enterprise network) and a wlan profile manager like Kwifimanager from http://kwifimanager.sourceforge.net/ so i can have two ore more profiles and change fast from one to another. Great work guys. tanks Christer Hemgren Network Admin/Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Wed Oct 15 21:21:05 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 15 Oct 2003 17:21:05 -0400 (EDT) Subject: Yo. In-Reply-To: <200310151204.37871.oden.eriksson@kvikkjokk.net> from "Oden Eriksson" at Hyd 15, 2003 12:04:37 Message-ID: <200310152121.h9FLL5a05127@devserv.devel.redhat.com> > I recently started to look into IDN (International domain names) for mdk and > patched glibc with libidn support and also patched bind with idnkit support Does libidn manage to avoid all the US patent issues ? From nphilipp at redhat.com Wed Oct 15 21:59:14 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 15 Oct 2003 23:59:14 +0200 Subject: Gimp 1.3 packages, was: New extra packages and yum repository In-Reply-To: <20031015182517.7250d596.ms-nospam-0306@arcor.de> References: <1066147414.4511.36.camel@gibraltar.stuttgart.redhat.com> <1066148362.6205.1.camel@mozer.nailed.org> <20031014213758.29a31d6f.ms-nospam-0306@arcor.de> <1066202803.6024.56.camel@wombat.tiptoe.de> <20031015182517.7250d596.ms-nospam-0306@arcor.de> Message-ID: <1066255153.6805.9.camel@wombat.tiptoe.de> On Wed, 2003-10-15 at 18:25, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 15 Oct 2003 09:26:43 +0200, Nils Philippsen wrote: > > > A few points I'd like to discuss and/or noticed (after comparing the > > gimp2 and gimp-beta packages): > > > > - whether it should be called gimp2 or gimp-beta -- gimp2 makes sense if > > the final package also will be called gimp2, gimp-beta could be easily > > obsoleted in any later final package ("gimp-beta <= 2.0") > > Not a big issue. > > What about "Obsoletes: gimp2 < 2.0-0.fdr.1"? Uhm, I didn't make my (small) point very clear here. What I meant is that gimp-beta can be a catch-all so that you can do "Obsoletes: gimp-beta < $currentversion" -- this works whether it's the 1.3 beta, the 1.1 beta, ... You don't have to individually mark all older versions as obsolete. > And with "gimp-beta <= 2.0", what would you do with any release > candidates? If you have the final, I venture you don't care anymore about the RCs being installed ;-). > Also, the different base package name is good to distinguish the extra > gimp2 packages from the gimp packages in Fedora Core: > > $ rpm -qa 'gimp*' > gimp-1.2.3-20.2 > gimp-print-4.2.5-2 > gimp-data-extras-1.2.0-8 > gimp-print-plugin-4.2.5-2 > gimp-print-devel-4.2.5-2 > gimp-print-utils-4.2.5-2 same thing with gimp-beta IMO. > > - whether or not to explicitly list directories - I guess this makes > > sense for /etc/gimp, but e.g. /usr/share/locale/zh_CN/LC_MESSAGES or > > Some of the locale directories are not owned by glibc-common. This is a bug in glibc-common which should not be tried to fix/circumvent in other packages. > One of the goals of owning directories is, that > > - when the package is installed with a restrictive umask, the > directories which are created get good permissions, > - when the package is uninstalled, empty directories are not > left behind. > > Redundancy with regard to owning directories below /usr/share/locale > doesn't hurt, does it? > > You have missed /etc/gimp, /usr/lib/gimp, /usr/lib/gimp/1.3/environ, > and /usr/share/gimp. I didn't try to give a complete list. > > /usr/include don't belong in gimp packages > > Correct. Minor glitch. One of the previous gimp2 packages was > relocated to a different root directory. > > > - whether or not gimptool-1.3 belongs into the -devel package > > Looks like a devel tool. But since it also provides options for > installation of .scm scripts into user's directories, it makes sense > to keep it in the main package. Agreed. > > - I moved the devel docs from /usr/share/gtk-doc to > > /usr/share/doc/gimp-beta-devel-.../ > > /usr/share/gtk-doc/html/ is a place where "devhelp" looks > for manuals. I thought I was missing something here. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ms-nospam-0306 at arcor.de Wed Oct 15 23:31:06 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 16 Oct 2003 01:31:06 +0200 Subject: Gimp 1.3 packages, was: New extra packages and yum repository In-Reply-To: <1066255153.6805.9.camel@wombat.tiptoe.de> References: <1066147414.4511.36.camel@gibraltar.stuttgart.redhat.com> <1066148362.6205.1.camel@mozer.nailed.org> <20031014213758.29a31d6f.ms-nospam-0306@arcor.de> <1066202803.6024.56.camel@wombat.tiptoe.de> <20031015182517.7250d596.ms-nospam-0306@arcor.de> <1066255153.6805.9.camel@wombat.tiptoe.de> Message-ID: <20031016013106.1c76543e.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 15 Oct 2003 23:59:14 +0200, Nils Philippsen wrote: > > > - whether or not to explicitly list directories - I guess this makes > > > sense for /etc/gimp, but e.g. /usr/share/locale/zh_CN/LC_MESSAGES or > > > > Some of the locale directories are not owned by glibc-common. > > This is a bug in glibc-common which should not be tried to > fix/circumvent in other packages. What do you suggest as alternative? Now owning such directories would a) leave them behind upon package removal and b) create them with wrong permissions in case of a restrictive umask. As a similar example, Red Hat's "perl" package should own several directories, e.g. vendor install dirs. There's an old bug report about it somewhere in bugzilla. But it doesn't get fixed. > > You have missed /etc/gimp, /usr/lib/gimp, /usr/lib/gimp/1.3/environ, > > and /usr/share/gimp. > > I didn't try to give a complete list. Sorry, your package should own those directories. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/jdi60iMVcrivHFQRAjptAJ9Zvz8dC/HOPYcIrCwxQzBC4d/aQACaA1rd Rscebuc2uACOchen5Ia8dck= =SAAI -----END PGP SIGNATURE----- From oden.eriksson at kvikkjokk.net Wed Oct 15 23:33:54 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Thu, 16 Oct 2003 01:33:54 +0200 Subject: Yo. In-Reply-To: <200310152121.h9FLL5a05127@devserv.devel.redhat.com> References: <200310152121.h9FLL5a05127@devserv.devel.redhat.com> Message-ID: <200310160133.54539.oden.eriksson@kvikkjokk.net> onsdagen den 15 oktober 2003 23.21 skrev Alan Cox: > > I recently started to look into IDN (International domain names) for mdk > > and patched glibc with libidn support and also patched bind with idnkit > > support > > Does libidn manage to avoid all the US patent issues ? I don't know, I wasn't aware of any patents regarding this. The software itself is LGPL. http://www.gnu.org/software/libidn/ From veillard at redhat.com Thu Oct 16 00:30:16 2003 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 15 Oct 2003 20:30:16 -0400 Subject: Yum'ification of the rhn_applet In-Reply-To: ; from linuxnow@newtral.org on Wed, Oct 15, 2003 at 04:22:17PM +0200 References: <20031015083550.D16905@redhat.com> Message-ID: <20031015203016.V16905@redhat.com> On Wed, Oct 15, 2003 at 04:22:17PM +0200, Pau Aliagas wrote: > On Wed, 15 Oct 2003, Daniel Veillard wrote: > > > I have just released an updated version of rhn_applet which > > should work better for the Fedora framework: > > - handle Yum repositories > > - handle multiple repositories > > - does not require RHN registration > > I'd love it to be apt'fied :) Should I file a RFE? Far more complex to do. You can file it but it will be low priority (and I'm really busy with libxml2 maintainance right now). Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Thu Oct 16 00:31:38 2003 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 15 Oct 2003 20:31:38 -0400 Subject: Yum'ification of the rhn_applet In-Reply-To: <3F8D68AE.3010206@draigBrady.com>; from P@draigBrady.com on Wed, Oct 15, 2003 at 04:33:02PM +0100 References: <20031015083550.D16905@redhat.com> <3F8D68AE.3010206@draigBrady.com> Message-ID: <20031015203138.W16905@redhat.com> On Wed, Oct 15, 2003 at 04:33:02PM +0100, P at draigBrady.com wrote: > Daniel Veillard wrote: > > I have just released an updated version of rhn_applet which > > should work better for the Fedora framework: > > - handle Yum repositories > > - handle multiple repositories > > - does not require RHN registration > > > > You can find it at: > > http://people.redhat.com/~veillard/testing/yum/rhn-applet/2.1.0/ > > But does up2date work with yum? yes for recent versions. > I updated rh9 with the latest up2date from rawhide and rhn-applet from > above, but up2date seems to hang on the first RPM header with the > following as my only source? > > yum fedora-i386-os > http://download.fedora.us/fedora/redhat/0.95/i386/yum/os/ Hum, I upgraded my fedora core0.95 to rawhide with up2date this morning without troubles. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Thu Oct 16 00:32:56 2003 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 15 Oct 2003 20:32:56 -0400 Subject: Yum'ification of the rhn_applet In-Reply-To: <3F8DACB2.9040803@zonnet.nl>; from jaap_haitsma@zonnet.nl on Wed, Oct 15, 2003 at 10:23:14PM +0200 References: <20031015083550.D16905@redhat.com> <3F8DACB2.9040803@zonnet.nl> Message-ID: <20031015203256.X16905@redhat.com> On Wed, Oct 15, 2003 at 10:23:14PM +0200, Jaap A. Haitsma wrote: > It works for me. Nice that the update applet now finally tells you when > there are updates :-) One minor remark up2date tells me that all the okay good :-) > files of the update are 0kB. Is this due to yum or is there a bug?? hum, it's likely to be an up2date bug, I saw it too, there is still a bit of debug needed ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From notting at redhat.com Thu Oct 16 02:33:55 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 15 Oct 2003 22:33:55 -0400 Subject: Translations In-Reply-To: <3F8D4CB6.20406@tiscali.it>; from g.magnini@tiscali.it on Wed, Oct 15, 2003 at 03:33:42PM +0200 References: <3F8D4CB6.20406@tiscali.it> Message-ID: <20031015223355.D20266@devserv.devel.redhat.com> Giacomo Magnini (g.magnini at tiscali.it) said: > I'm new to the list, and I wish to work on translating Fedora packages > in my own language (Italian). > Is someone already working on this? There are currently 4 registered Italian translators. > Should I look anywhere else to gather more informations? http://i18n.redhat.com/ Bill From pjones at redhat.com Wed Oct 1 14:15:31 2003 From: pjones at redhat.com (Peter Jones) Date: Wed, 1 Oct 2003 10:15:31 -0400 (EDT) Subject: PowerPC support In-Reply-To: <3F79F6AA.6050103@digitalme.com> Message-ID: On Tue, 30 Sep 2003, Nicholas Wourms wrote: > Some of us actually remember when Red Hat had a sparc product :-(. > Perhaps it is time for Aurora to merge back into the fold? It seems > that Fedora would be a perfect means to do this... In principle, as a Red Hat person and an Aurora person, I think you're right. In practice, not much is going to happen here until we get a real policy for how to merge changes "upstream" to Fedora, and external access to some build system for it. I suspect this will still take quite some time. -- Peter "Java is the most distressing thing to happen to computing since MS-DOS." -- Alan Kay From buildsys at porkchop.devel.redhat.com Sat Oct 11 09:58:36 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sat, 11 Oct 2003 05:58:36 -0400 Subject: rawhide report: 20031011 changes Message-ID: <200310110958.h9B9waP06851@porkchop.devel.redhat.com> Updated Packages: Canna-3.6-24 ------------ * Fri Oct 10 2003 Akira TAGOH 3.6-24 - Canna-3.6-fix-ia64-unaligned-access.patch: fixed unaligned access on ia64. (#101762) bind-9.2.2.P3-7 --------------- coreutils-5.0-23 ---------------- * Fri Oct 10 2003 Tim Waugh 5.0-23 - Make split(1) handle large files (bug #106700). * Thu Oct 09 2003 Dan Walsh 5.0-22 - Turn off SELinux * Wed Oct 08 2003 Dan Walsh 5.0-21.sel - Cleanup SELinux patch epiphany-1.0.1-2 ---------------- * Fri Oct 10 2003 Christopher Blizzard 1.0.1-2 - Add patch to set the home page to the release notes gaim-0.71-0 ----------- gnome-panel-2.4.0-3 ------------------- * Thu Oct 09 2003 Owen Taylor 2.4.0-2 - Look up the largest size available when picking default images for panel stock icons (#106673) gnome-pilot-2.0.10-3 -------------------- * Thu Oct 09 2003 Jeremy Katz 2.0.10-3 - add patch from Dax Kelson for Treo600 support (#106731) initscripts-7.37-1 ------------------ * Fri Oct 10 2003 Bill Nottingham 7.37-1 - bridging updates (#104421, ) * Wed Oct 08 2003 Bill Nottingham 7.36-1 - mount /dev/pts before starting rhgb * Wed Oct 01 2003 Bill Nottingham 7.35-1 - load acpi modules on startup if necessary - fix typo in ipsec comments & sysconfig.txt * Mon Sep 15 2003 Than Ngo 7.34-1 - use upsdrvctl to start the shutdown process * Mon Sep 15 2003 Bill Nottingham 7.33-1 - ipsec fixes (#104227, ) - ppp fixes (#104128, #97845, #85447) * Thu Sep 11 2003 Bill Nottingham 7.32-1 - fix ip calls for some device names (#104187) - ipsec fixes * Fri Sep 05 2003 Bill Nottingham 7.31-1 - fix bonding + dhcp (#91399) - fix typo (#103781) - sysconfig/network-scripts/ifup: fix use of local - fix shutdown with NFS root (#100556, ) - remove /var/run/confirm when done with /etc/rc (#100898) - ipcalc: fix some memory handling (#85478, ) - handle sorting > 10 network devices (#98209) - unset ONPARENT after use (#101384) - random other fixes - bridging support () * Fri Aug 15 2003 Bill Nottingham 7.30-1 - IPv6 updates (#86210, #91375, ) * Fri Aug 08 2003 Bill Nottingham 7.29-1 - setsysfont: don't echo to /dev/console (#102004) - fix ethernet device renaming deadlock (#101566) - consoletype: don't return 'vt' on vioconsole (#90465) - ifup: fix short-circuit (#101445) * Fri Jul 18 2003 Nalin Dahyabhai - ifup-routes: pass the interface name to handle_file() so that we don't try to use the routes file's name as an interface name * Wed Jul 09 2003 Bill Nottingham 7.28-1 - switch from $CONFIG.keys to keys-$CONFIG * Tue Jul 08 2003 Bill Nottingham 7.27-1 - add a check to consoletype for the current foreground console - use it when running unicode_start (#98753) * Wed Jul 02 2003 Bill Nottingham 7.26-1 - ipsec support (see sysconfig.txt, ifup-ipsec) - read $CONFIG.keys, for non-world-readable keys - allow default window size for routes to be set with WINDOW= (#98112) - support setting device options with ethtool opts - fix s390 bootup spew (#98078) - support renaming interfaces with nameif based on hwaddr * Mon Jun 23 2003 Bill Nottingham 7.25-1 - fix DNS punching in the case of other rules for the DNS server (#97686, ) - initlog, ppp-watch, and usernetctl tweaks () - fix grep for mingetty (#97188) - fix rhgb-client bad syntax - change network device searching, use correct naming, fix route issues () - other random tweaks * Fri May 23 2003 Bill Nottingham 7.24-1 - now even still yet more tweaks for graphical boot * Thu May 22 2003 Bill Nottingham 7.23-1 - even still yet more tweaks for graphical boot * Tue May 20 2003 Bill Nottingham 7.22-1 - still yet more tweaks for graphical boot * Tue May 20 2003 Bill Nottingham 7.21-1 - yet more tweaks for graphical boot * Fri May 02 2003 Bill Nottingham 7.20-1 - more tweaks for graphical boot * Wed Apr 30 2003 Bill Nottingham 7.18-1 - some tweaks for graphical boot * Mon Apr 21 2003 Florian La Roche - initscripts-s390.patch: remove not needed parts about PNP= - inittab.390: sync with normal version - rc.sysinit: remove two further calls to /sbin/consoletype with $CONSOLETYPE * Fri Apr 18 2003 Florian La Roche - sysconfig/init.s390: set LOGLEVEL=3 as for other archs - rc.d/init.d/network, rc.d/rc: change confirmation mode to not use an environment variable - rc.d/init.d/functions: make strstr() even shorter, remove old "case" version that has been already commented out - rc.d/rc.sysinit: - no need to set NETWORKING=no, it is not used/exported - do not export BOOTUP - delete two "sleep 1" calls that wants to add time to go into confirmation mode. There is enough time to press a key anyway or use "confirm" in /proc/cmdline. - read /proc/cmdline into a variable - use strstr() to search in /proc/cmdline - add "forcefsck" as possible option in /proc/cmdline - while removing lock files, no need to call `basename` - add unamer=`uname -r` and reduce number of forks - do not fork new bash to create /var/log/ksyms.0 * Thu Apr 03 2003 Karsten Hopp 7.15-1 - Mainframe has no /dev/ttyX devices and no mingetty, don't initialize them. This gave error messages during startup * Mon Mar 17 2003 Nalin Dahyabhai - init.d/network: don't advertise "probe: true" in the header if we don't recognize "probe" as an argument * Wed Mar 12 2003 Bill Nottingham 7.14-1 * - do not handle changed chain name; change was reverted * Tue Feb 25 2003 Bill Nottingham 7.13-1 - handle 7.x SYSFONTACM settings in setsysfont (#84183) * Mon Feb 24 2003 Bill Nottingham 7.12-1 - handle changed chain name - init vts used in all cases * Fri Feb 21 2003 Bill Nottingham 7.10-1 - handle LANGUAGE specially for zh_CN.GB18030 and gdm (#84773) * Thu Feb 20 2003 Bill Nottingham 7.09-1 - initialize two ttys past # of mingettys (for GDM) - fix zeroconf route - redhat-config-network writes $NAME.route for some static routes (e.g., ppp); handle that (#84193) * Tue Feb 18 2003 Bill Nottingham 7.08-1 - load keybdev & mousedev even if hid is already loaded/static - run fewer scripts through action (#49670, #75279, #81531) * Mon Feb 10 2003 Bill Nottingham 7.07-1 - fix nicknames & profiles (#82246) - fix check_device_down (#83780, ) - vlan fixes () - fix groff macros (#83531, ) - various updated translations - fix checkpid for multiple pids (#83401) * Fri Jan 31 2003 Bill Nottingham 7.06-1 - 802.1Q VLAN support (, #82593) - update translations * Thu Jan 30 2003 Bill Nottingham 7.05-1 - fix syntax error in rc.sysinit when there are fsck errors - fix zh_TW display on console (#82235) * Wed Jan 15 2003 Bill Nottingham 7.04-1 - tweak some translatable strings - fix for rc.sysinit on machines that pass arguments to mingetty () * Tue Jan 14 2003 Bill Nottingham 7.03-1 - move system font setting sooner () - fix link checking for dhcp, use both ethtool and mii-tool - fix CJK text on the console, and locale-archive held open on shutdown - IPv6 updates , - speedup tweaks () - use glib2 for ppp-watch (#78690, ) - add zeroconf route (#81738) - fix ifup-ppp for dial-on-demand, and onboot () - tweak raidtab parsing, don't worry about not-in-fstab RAID devices (#71087, #78467, ) - don't automatically bring up aliases if 'ONPARENT=no' is set (#78992) - getkey cleanups/tweaks (#76071, ) - rework halt_get_remaining (#76831, ) - ipcalc: fix calculation of /32 addresses (#76646) - various other tweaks and fixes * Fri Dec 20 2002 Bill Nottingham 7.01-1 - %config(noreplace) inittab * Tue Dec 17 2002 Nalin Dahyabhai - add a "nofirewire" option to /etc/rc.sysinit, analogous to "nousb" * Tue Dec 17 2002 Bill Nottingham 7.00-1 - tweaks for potential GUI bootup - loop checking for network link state, don't unilterally wait five seconds * Sat Dec 14 2002 Karsten Hopp 6.99-1 - remove call to /sbin/update for S/390, too * Wed Dec 11 2002 Bill Nottingham 6.98-1 - remove call to /sbin/update - fix netprofile * Mon Dec 02 2002 Bill Nottingham 6.97-1 - IPv6 update (, ) - devlabel support () - do lazy NFS umounts * Tue Nov 19 2002 Florian La Roche - correctly remove non-packaged files for mainframe * Tue Nov 12 2002 Bill Nottingham 6.96-1 - fix various static-routes brokeness (#74317, #74318, #74320, #76619, - fix handling of SYSFONTACM in setsysfont (#75662) - fix lang.csh for CJK (#76908, ) - IPv6 update (, ) - other minor tweaks * Mon Sep 16 2002 Than Ngo - owns directory /etc/ppp/peers (bug #74037) * Wed Sep 04 2002 Bill Nottingham 6.95-1 - fix syntax error in duplicate route removal section of ifup * Wed Sep 04 2002 Nalin Dahyabhai 6.94-1 - fix syntax error calling unicode_start when SYSFONTACM isn't set * Mon Sep 02 2002 Bill Nottingham - fix calling of unicode_start in lang.{sh,csh} - ipv6 tweak * Wed Aug 28 2002 Bill Nottingham - don't infinite loop on ifdown - remove disabling of DMA; this can cause problems - move swap startup to after LVM (#66588) * Tue Aug 20 2002 Bill Nottingham - don't cycle through eth0-eth9 on dhcp link check (#68127) - don't retry indefinitely on ppp startup - activate network profile passed on kernel commandline via netprofile= - fix iptables invocations again - translation refresh * Wed Aug 14 2002 Bill Nottingham - fix silly typo in rc.sysinit - increase timeout for link to 5 seconds (#70545) * Tue Aug 13 2002 Bill Nottingham - require /etc/redhat-release (#68903) - fix tty2-tty6 (sort of) - fix iptables invocations (#70807, #71201, #68368) - other minor tweaks * Wed Jul 24 2002 Bill Nottingham - fix unicode checks in rc.sysinit, lang.{sh,csh} to handle UTF-8 at euro * Tue Jul 16 2002 Bill Nottingham - use iptables, not ipchains * Tue Jul 16 2002 Florian La Roche - /sbin/service: set PATH before calling startup scripts HOME and TERM are also set during bootup, but they should not make a difference for well-written daemons. * Mon Jul 15 2002 Bill Nottingham - fix boot-time cleanup of /var - update po files * Thu Jul 11 2002 Florian La Roche - /etc/init.d/functions: daemon(): avoid starting another bash killproc(): avoid starting another bash for the default case - do not call "insmod -p" before loading the "st" module * Tue Jul 09 2002 Florian La Roche - allow an option for ups poweroff #68123 - change grep for ONBOOT= #63903 - allow building with a cross-compiler #64362,#64255 - faster check in network-functions:check_default_route() - better checks for backup files - drastically reduce the number of consoletype invocations - do not export "GATEWAY" in network-functions - code cleanups in rc.sysinit * Fri Jul 05 2002 Florian La Roche - rc.sysinit: do not load raid modules unless /etc/raidtab exists - many cleanups for more consistent shell programming and also many smaller speedups within network scripts, no un-necessary sourcing of files etc - nearly re-code /etc/rc.d/rc * Thu Jun 27 2002 Bill Nottingham - a couple minor unicode tweaks in rc.sysinit * Wed Jun 26 2002 Bill Nottingham - move /proc/bus/usb mount, in case USB is in the initrd * Wed Jun 26 2002 Preston Brown - don't try to set wireless freq/channel when in Managed mode * Wed Jun 26 2002 Florian La Roche - start some sh coding cleanups - change to /etc/init.d/functions - eliminate some un-necessary PATH settings - eliminate some TEXTDOMAIN settings * Wed Jun 12 2002 Bill Nottingham 6.78-1 - fix UTF-8 checks * Wed Jun 05 2002 Than Ngo 6.77-1 - fixed a bug in setting defaultgateway * Thu May 30 2002 Bill Nottingham 6.76-1 - call unicode_start in lang.{sh,csh}, setsysfont when necessary * Tue May 28 2002 Bill Nottingham 6.75-1 - add check for link for dhcp back in * Fri Apr 19 2002 Bill Nottingham 6.67-1 - fix silly cut&paste bug in hdparm settings in initscripts * Mon Apr 15 2002 Trond Eivind Glomsr?d 6.65-1 - Update translations * Sun Apr 14 2002 Bill Nottingham 6.64-1 - make sure chatdbg is set before using it (#63448, ) - allow tweaking of more devices with hdparm (#53511), and tweak non-disk devices iff they explicitly have a config file for that device (#56575, #63415) - some translation updates * Fri Apr 12 2002 Bill Nottingham 6.63-1 - ipcalc cleanups (#58410) - quit stripping binaries - do LVM init after RAID init too (#63238) - export all locale variables (#56142) - run sysctl -p after network init as well * Tue Apr 09 2002 Bill Nottingham 6.62-1 - delete X/VNC locks on startup (#63035) - shut up DMA disabling, move it to after ide-scsi (#62873, #62956) - use full path to /sbin/ifconfig (#59457) - /sbin/service: change to root directory before staring/stopping; also sanitize environment * Tue Apr 02 2002 Bill Nottingham 6.61-1 - when disabling DMA, don't use things in /usr * Thu Mar 28 2002 Bill Nottingham 6.60-1 - disable DMA on CD-ROMs at bootup * Wed Mar 27 2002 Bill Nottingham 6.59-1 - add local hook to halt * Fri Mar 15 2002 Than Ngo 6.58-1 - fix usernetctl for working with neat * Thu Mar 14 2002 Bill Nottingham 6.57-1 - update translations * Tue Mar 12 2002 Bill Nottingham 6.56-1 - use nameif for interfaces where we don't agree on HWADDR with the config file () - LSB support tweaks * Tue Mar 12 2002 Mike A. Harris 6.55-1 - Removed process accounting stuff from rc.sysinit and halt scripts as it is now handled by the psacct initscript in the psacct package * Thu Feb 28 2002 Bill Nottingham - conflict with older psacct * Fri Feb 22 2002 Bill Nottingham - fix invocation of need_hostname (#58946), a couple other minor tweaks * Tue Feb 12 2002 Mike A. Harris - rc.sysinit: changed /var/log/pacct to /var/account/pacct for FHS 2.2 compliance * Wed Jan 30 2002 Bill Nottingham - run /bin/setfont, not /usr/bin/setfont (kbd) - lots-o-random bugfixes/tweaks (see ChangeLog) * Thu Jan 17 2002 Michael K. Johnson - Added support for libredhat-kernel.so.* symlink handling * Wed Nov 07 2001 Than Ngo - fix bug in setting netmask on s390/s390x (bug #55421) nmbd daemon works now ;-) * Fri Nov 02 2001 Than Ngo - fixed typo bug ifup-ippp * Mon Oct 29 2001 Than Ngo - fix bug in channel bundling if MSN is missed - support DEBUG option * Wed Sep 19 2001 Than Ngo - don't show user name by DSL connection * Sat Sep 08 2001 Bill Nottingham - don't run hwclock --adjust on a read-only filesystem * Thu Sep 06 2001 Than Ngo * update initscripts-s390.patch for s390/s390x * Wed Sep 05 2001 Bill Nottingham - translation updates - quota and hwclock tweaks () * Mon Sep 03 2001 Bill Nottingham - fix severe alias problems (#52882) * Mon Sep 03 2001 Than Ngo - don't start pppbind if encapsulation is rawip (bug #52491) * Sun Sep 02 2001 Than Ngo - add ISDN patches from pekkas at netcore.fi and pb at bieringer.de (bug #52491) - fix handling of ISDN LSZ Compresssion * Thu Aug 30 2001 Than Ngo - po/de.po: fix typo bug, lo instead 1o * Wed Aug 29 2001 David Sainty - fix ifdown for multiple dhcpcd interfaces * Wed Aug 29 2001 Than Ngo - fix ISDN dial on demand bug - fix typo bug in network-functions * Tue Aug 28 2001 Nalin Dahyabhai - document /etc/sysconfig/authconfig * Tue Aug 28 2001 Bill Nottingham 6.31-1 - message un-tweaks () - make getkey more useful, fix some of the autofsck stuff () * Mon Aug 27 2001 Bill Nottingham - autofsck support, archive modules/symbol info () * Mon Aug 27 2001 Than Ngo - fix some typo bugs in ifup-ippp * Fri Aug 24 2001 Bill Nottingham - sort output of halt_get_remaining (#52180) - fix bad translation (#52503) * Wed Aug 22 2001 Bill Nottingham - fix ifup-wireless (#52135) * Wed Aug 22 2001 Than Ngo - fix return code of isdnctrl (bug #52225) * Tue Aug 21 2001 Than Ngo - fix Bringing up isdn device again. It works now correct. * Tue Aug 21 2001 Than Ngo - fix shutdown/Bringing up isdn device * Mon Aug 20 2001 Nalin Dahyabhai - fix syntax error in lang.csh - set codeset by echoing to /dev/tty instead of /proc/self/fd/15 * Sun Aug 19 2001 Bill Nottingham - fix a broken call to check_device_down - make all loopback addresses have host scope, not global scope. Fixes #49374, possibly others * Wed Aug 15 2001 Bill Nottingham - add is_available() network function, use it; cleans up ugly modprobe error messages - update translation info - fix #51787 * Wed Aug 15 2001 Bernhard Rosenkraenzer - adjust s390 patch - fix up ifup-ctc and mkkerneldoth.s390 (both are s390 specific) * Mon Aug 13 2001 Yukihiro Nakai - don't display Chinese Korean if we aren't on a pty * Sat Aug 11 2001 Florian La Roche - adjust s390 patches to current sources * Fri Aug 10 2001 Bill Nottingham - use GDM_LANG if it's set in lang.sh/lang.csh (#51432, ) * Fri Aug 10 2001 Than Ngo - don't set MSN if it' empty (it's now optional) - don't give login name as a cmdline-option (Bug #23066) - remove peer device file if ppp connection is down - fix channel bundling * Thu Aug 09 2001 Bill Nottingham - require SysVinit (#51335) * Wed Aug 08 2001 Bill Nottingham - tweak raittab grep slightly (#51231) - allow resetting of default route for DHCP addresses (#48994) - save resolv.conf in ifup-ppp for restoration by ifdown-post (#50759) - when munging firewall rules for dns, only allow dest ports 1025-65535 (#44038, #40833) - allow shell characters in ppp names (#43719) - allow setting DHCP arguments, just kill dhcpcd instead of using -k (#46492) - behave sanely if ifup called when dhcpcd is running (#49392, #51038) * Mon Aug 06 2001 Bill Nottingham - honor HOTPLUG=no if running under hotplug (#47483) - use awk, not grep, for modprobe -c checks (#49616) - don't print ugly messages for the case where the device doesn't exist, and there is no alias (i.e., PCMCIA ONBOOT=yes (#various)) - run kbdconfig in /.unconfigured mode (#43941) - use a bigger buffer size argument to dmesg (#44024) - detach loopback devices on shutdown (#43919, #45826) * Thu Aug 02 2001 Bill Nottingham - fix halt_get_remaining() (#50720) * Tue Jul 31 2001 Bill Nottingham - mount all FS types r/o at halt (#50461) - don't use mii-tool at all (#various) * Thu Jul 26 2001 Bill Nottingham - don't use kbd commands in setsysfont now that we've switched back to console-tools (#50075) - sleep in check_link_down; some devices require it - only bring link down if check_link_down fails * Wed Jul 25 2001 Bill Nottingham - set link up before checking with mii-tool (#49949) * Tue Jul 24 2001 Bill Nottingham - update netdev stuff to use _netdev - IPv6 updates () - fix downing of devices with static IPs (#49777, #49783) - put ifcfg-lo back in the package * Fri Jul 20 2001 Preston Brown 6.06 - updates for quota * Tue Jul 17 2001 Bill Nottingham - own some more directories - use -O nonetdev, require mount package that understands this - fix do_netreport when called as non-root - remove ip addresses from interfaces on ifdown - oops, fix ifup/ifdown * Mon Jul 16 2001 Than Ngo - fix country_code for ISDN * Mon Jul 09 2001 Bill Nottingham - fix '--check' - prereq sh-utils (#43065) - fix some invocations of reboot/halt (#45966) - fix typo in ifup-wireless - don't muck with /etc/issue each boot - big IPv6 update () * Fri Jul 06 2001 Trond Eivind Glomsr?d - Add new directories required by new network tool * Thu Jul 05 2001 Karsten Hopp - disable hwclock on S390 (no such executable) - Fix up kernel versioning on binary-only modules (S390) - don't use newt scripts on S390 console * Sun Jul 01 2001 Trond Eivind Glomsr?d - reenable pump, but make sure dhcpcd is the default. This way, upgrades of systems without dhcpcd has a better chance at working. * Thu Jun 28 2001 Trond Eivind Glomsr?d - Disable pump completely * Wed Jun 27 2001 Than Ngo - fix pap/chap authentication for syncppp - support ippp options * Mon Jun 25 2001 Bill Nottingham - add ifup-wireless * Fri Jun 22 2001 Than Ngo - add support xDSL * Thu Jun 21 2001 Bill Nottingham - more networking script fixes (#45364) - add stuff for unmounting /initrd * Thu Jun 21 2001 Than Ngo - add support ISDN * Wed Jun 20 2001 Bill Nottingham - fix extremely broken new network scripts * Wed Jun 20 2001 Bill Nottingham - bump version to 5.89 - make it build * Thu May 17 2001 Bill Nottingham - don't run ifup ppp0 if ppp-watch gets SIGINT (#40585, ak at cave.hop.stu.neva.ru) - fix do_netreport (#37716, #39603 ) * Wed May 16 2001 Nalin Dahyabhai - copyright: GPL -> license: GPL - fix a syntax error in lang.csh - skip commented-out i18n configuration lines in lang.csh * Fri May 11 2001 Preston Brown - new network-scripts infrastructure; ifcfg-lo moved to /etc/sysconfig/networking * Wed May 02 2001 Bernhard Rosenkraenzer 5.86-1 - support kbd in setsysfont - bzip2 source * Wed Apr 25 2001 Florian La Roche - add further s390 changes: - ifup-iucv - mkkerneldoth.s390 * Tue Apr 24 2001 Than Ngo - add shutdown UPS into halt (bug #34312) * Sat Apr 07 2001 Preston Brown - broke out kernel.h updater from rc.sysinit into /sbin/mkkerneldoth * Fri Apr 06 2001 Bill Nottingham - be a little more careful in do_netreport (#34933) * Tue Apr 03 2001 Bill Nottingham - set umask explicitly to 022 in /etc/init.d/functions * Mon Apr 02 2001 Bill Nottingham - fix segfault in usernetctl (#34353) * Mon Mar 26 2001 Bill Nottingham - don't print errors in /etc/init.d/network if kernel.hotplug doesn't exist * Thu Mar 22 2001 Erik Troan - take advantage of new swapon behaviors * Wed Mar 14 2001 Bill Nottingham - add cipe interfaces last (#31597) * Tue Mar 13 2001 Bill Nottingham - fix typo in ifup (#31627) - update translation source * Tue Mar 13 2001 Nalin Dahyabhai - fix typo in rc.sysinit - fix ifup-routes not setting DEVICE properly * Mon Mar 12 2001 Preston Brown - Work properly with new quota utilities * Mon Mar 05 2001 Bill Nottingham - IPv6 fixes (#30506) - make static-routes handling more sane and consistent (#29500, #29549) - handle multiple USB controllers *correctly* * Wed Feb 28 2001 Nalin Dahyabhai - usernetctl, ppp-watch: cleanups - netreport: use O_NOFOLLOW - ifup-ppp: let ppp-watch watch over demand-dialed connections (#28927) * Tue Feb 27 2001 Bill Nottingham - don't run isapnp on isapnp-enabled 2.4 kernels (part of #29450) - disable hotplug during network initscript - don't munge wireless keys in ifup; that will be done with the PCMCIA wireless stuff - run sndconfig --mungepnp for non-native-isapnp soundcards - don't explicitly kill things in init.d/single, init will do it - don't explicitly load usb-storage; mount the usbdevfs before initializing host controller modules * Wed Feb 21 2001 Bill Nottingham - initialize multiple USB controllers if necessary * Wed Feb 21 2001 Nalin Dahyabhai - close extra file descriptors before exec()ing commands in initlog * Mon Feb 19 2001 Bill Nottingham - fix some substitions in init.d/functions (fixes various killproc issues) - make sure ipv6 module alias is available if configured - fix initlog segfaults in popt when called with bogus stuff (#28140) * Thu Feb 15 2001 Nalin Dahyabhai - make pidofproc() and killproc() try to use the PID associated with the full pathname first before killing the daemon by its basename (for daemons that share the same basename, i.e. "master" in postfix and cyrus-imapd) (#19016) - fix status() as well * Wed Feb 14 2001 Bill Nottingham - fix init.d/single to work around possible kernel problem * Tue Feb 13 2001 Bill Nottingham - fix unmounting of loopback stuff (#26439, #14672) * Mon Feb 12 2001 Bill Nottingham - fix ifup-post so that it will work right when not called from ifup * Sat Feb 10 2001 Florian La Roche - add all save changes for s390 s390x that won't break anything patches are from Oliver Paukstadt @ millenux.com * Fri Feb 09 2001 Bill Nottingham - muck with the font in lang.csh/lang.sh, but don't spit out errors (#26903) * Wed Feb 07 2001 Bill Nottingham - ipv6 sync ups (#26502, #25775) - fix hangs at shutdown (#25744) - fix ifup-ppp (#26323) * Tue Feb 06 2001 Bill Nottingham - modify firewall on ifup to allow any new DNS servers through (#25951) - don't muck with the font in lang.csh/lang.sh (#26349) - don't display Japanese if we aren't on a pty (#25041) - load ide-scsi if passed on /proc/cmdline * Mon Feb 05 2001 Trond Eivind Glomsr?d - i18n updates * Fri Feb 02 2001 Bill Nottingham - actually *ship* the ipv6 (and plusb) files * Thu Feb 01 2001 Trond Eivind Glomsr?d - i18n updates * Tue Jan 30 2001 Bill Nottingham - various init.d/functions cleanups (#10761, from ) - in daemon(), only look at pidfile to determine if process is running (#17244, others) - ifup-ppp enhancements (#17388, from ) - ipv6 support (#23576, originally by Peter Bieringer ) - lots of other minor fixes (see ChangeLog) * Mon Jan 29 2001 Bill Nottingham - add plusb support (#18892, patch from ) - don't ignore RETRYTIMEOUT when we never connect (#14071, patch from ) * Wed Jan 24 2001 Bill Nottingham - quiet LVM setup (#24841) - fix inability to shutdown cleanly (#24889) * Tue Jan 23 2001 Bill Nottingham - new i18n mechanism * Tue Jan 23 2001 Matt Wilson - fixed typo in init.d/network - missing | in pipeline * Mon Jan 22 2001 Bill Nottingham - do LVM setup through normal initscripts mechanisms - ignore backup files in /etc/sysconfig/network-scripts - lots of .po file updates * Tue Jan 02 2001 Bill Nottingham - initial i18n support - originally from Conectiva * Mon Dec 11 2000 Bill Nottingham - only load sound if persistent DMA buffers are necessary - fix lots of bugs: #18619, #21187, #21283, #12097 - integrate MAXFAIL option for ppp-watch - don't load keymaps/fonts on a serial console * Tue Nov 21 2000 Karsten Hopp - changed hdparm section in rc.sysinit to allow different parameters for each disk (if needed) by copying /etc/sysconfig/harddisks to /etc/sysconfig/harddiskhda (hdb,hdc..) - fix RFE #20967 * Tue Oct 31 2000 Than Ngo - fix the adding default route if GATEWAY=0.0.0.0 * Tue Oct 10 2000 Nalin Dahyabhai - handle "gw x.x.x.x" as the last pair of flags in ifup-routes (#18804) - fix top-level makefile install target - make usernetctl just fall-through if getuid() == 0 * Sun Sep 03 2000 Florian La Roche - /etc/init.d is already provided by chkconfig * Wed Aug 23 2000 Nalin Dahyabhai - set "holdoff ${RETRYTIMEOUT} ktune" for demand-dialed PPP links * Tue Aug 22 2000 Bill Nottingham - update documentation (#15475) * Tue Aug 22 2000 Than Ngo - add KDE2 support to prefdm * Mon Aug 21 2000 Bill Nottingham - add usleep after kill -KILL in pidofproc, works around lockd issues (#14847) - add some fallback logic to prefdm (#16464) * Fri Aug 18 2000 Bill Nottingham - don't load usb drivers if they're compiled statically - don't call ifdown-post twice for ppp (#15285) * Wed Aug 16 2000 Bill Nottingham - fix /boot/kernel.h generation (#16236, #16250) * Tue Aug 15 2000 Nalin Dahyabhai - be more careful about creating files in netreport (#16164) * Fri Aug 11 2000 Nalin Dahyabhai - move documentation for the DEMAND and IDLETIMEOUT values to the right section of sysconfig.txt * Wed Aug 09 2000 Bill Nottingham - load agpgart if necessary (hack) - fix /boot/kernel.h stuff (jakub) * Mon Aug 07 2000 Bill Nottingham - remove console-tools requirement - in netfs, start portmap if needed - cosmetic cleanups, minor tweaks - don't probe USB controllers * Mon Aug 07 2000 Nalin Dahyabhai - fix demand-dialing support for PPP devices - change updetach back to nodetach * Sun Aug 06 2000 Bill Nottingham - add RETRYCONNECT option for ifcfg-pppX files (kenn at linux.ie) * Wed Jul 26 2000 Bill Nottingham - fix unclean shutdown * Tue Jul 25 2000 Nalin Dahyabhai - s/nill/null/g * Tue Jul 25 2000 Bill Nottingham - unmount usb filesystem on halt - run /sbin/ifup-pre-local if it exists * Tue Jul 18 2000 Trond Eivind Glomsr?d - add "nousb" command line parameter - fix some warnings when mounting /proc/bus/usb * Sat Jul 15 2000 Matt Wilson - kill all the PreTransaction stuff - directory ownership cleanups, add more LSB symlinks - move all the stuff back in to /etc/rc.d/ * Thu Jul 13 2000 Bill Nottingham - fix == tests in rc.sysinit - more %pretrans tweaks * Thu Jul 13 2000 Jeff Johnson - test if /etc/rc.d is a symlink already in pre-transaction syscalls. * Tue Jul 11 2000 Bill Nottingham - implement the %pre with RPM Magic(tm) * Sat Jul 08 2000 Bill Nottingham - fix it to not follow /etc/rc.d * Fri Jul 07 2000 Bill Nottingham - fix %pre, again * Thu Jul 06 2000 Bill Nottingham - tweak %pre back to a mv (rpm is fun!) - do USB initialization before fsck, so keyboard works if it fails * Mon Jul 03 2000 Bill Nottingham - rebuild; allow 'fastboot' kernel command line option to skip fsck * Mon Jul 03 2000 Nalin Dahyabhai - fix demand-dialing with PPP * Sun Jul 02 2000 Trond Eivind Glomsr?d - don't use tail * Wed Jun 28 2000 Trond Eivind Glomsr?d - add support for USB controllers and HID devices (mice, keyboards) * Tue Jun 27 2000 Trond Eivind Glomsr?d - add support for EIDE optimization * Mon Jun 26 2000 Bill Nottingham - tweak %pre * Wed Jun 21 2000 Preston Brown - noreplace for adjtime file * Fri Jun 16 2000 Nalin Dahyabhai - ifup-ppp: add hooks for demand-dialing PPP - functions: use basename of process when looking for its PID file * Thu Jun 15 2000 Bill Nottingham - move from /etc/rc.d/init.d -> /etc/init.d * Tue Jun 13 2000 Bill Nottingham - set soft limit, not hard, in daemon function - /var/shm -> /dev/shm * Thu Jun 08 2000 Preston Brown - use dhcpcd if pump fails. - use depmod -A (faster) * Sun Jun 04 2000 Bernhard Rosenkraenzer - add autologin support to prefdm * Thu Jun 01 2000 Bill Nottingham - random networking fixes (alias routes, others) - conf.modules -> modules.conf * Thu May 11 2000 Nalin Dahyabhai - fix incorrect grep invocation in rc.sysinit (bug #11267) * Wed Apr 19 2000 Bill Nottingham - fix lang.csh, again (oops) - use /poweroff, /halt to determine whether to poweroff * Fri Apr 14 2000 Bill Nottingham - fix testing of RESOLV_MODS (which shouldn't be used anyways) * Tue Apr 04 2000 Ngo Than - fix overwrite problem of resolv.conf on ippp/ppp/slip connections * Mon Apr 03 2000 Bill Nottingham - fix typo in functions file - explicitly set --localtime when calling hwclock if necessary * Fri Mar 31 2000 Bill Nottingham - fix typo in /etc/rc.d/init.d/network that broke linuxconf (#10472) * Mon Mar 27 2000 Bill Nottingham - remove compatiblity chkconfig links - run 'netfs stop' on 'network stop' if necessary * Tue Mar 21 2000 Bernhard Rosenkraenzer - Mount /var/shm if required (2.3.99, 2.4) * Mon Mar 20 2000 Bill Nottingham - don't create resolv.conf 0600 - don't run ps as much (speed issues) - allow setting of MTU - other minor fixes * Sun Mar 19 2000 Bernhard Rosenkraenzer - Start devfsd if installed and needed (Kernel 2.4...) * Wed Mar 08 2000 Bill Nottingham - check that network devices are up before bringing them down * Wed Mar 08 2000 Jakub Jelinek - update sysconfig.txt * Tue Mar 07 2000 Bill Nottingham - rerun sysctl on network start (for restarts) * Mon Feb 28 2000 Bill Nottingham - don't read commented raid devices * Mon Feb 21 2000 Bill Nottingham - fix typo in resolv.conf munging * Thu Feb 17 2000 Bill Nottingham - sanitize repair prompt - initial support for isdn-config stuff * Mon Feb 14 2000 Nalin Dahyabhai - add which as a package dependency (bug #9416) * Tue Feb 08 2000 Bill Nottingham - fixes for sound module loading * Mon Feb 07 2000 Nalin Dahyabhai - check that LC_ALL/LINGUAS and LANG are set before referencing them in lang.csh - fix check for /var/*/news, work around for bug #9140 * Fri Feb 04 2000 Nalin Dahyabhai - fix bug #9102 * Fri Feb 04 2000 Bill Nottingham - if LC_ALL/LINGUAS == LANG, don't set them * Wed Feb 02 2000 Bill Nottingham - fix problems with linuxconf static routes * Tue Feb 01 2000 Nalin Dahyabhai - shvar cleaning - fix wrong default route ip in network-functions * Mon Jan 31 2000 Nalin Dahyabhai - attempt to restore default route if PPP takes it over - man page fix for ipcalc - shvar cleaning - automate maintaining /boot/System.map symlinks * Mon Jan 31 2000 Bill Nottingham - fix hanging ppp-watch - fix issues with cleaning of /var/{run,lock} * Fri Jan 21 2000 Bill Nottingham - fix pidof calls in pidofproc * Wed Jan 19 2000 Bill Nottingham - fix ifup-ipx, don't munge resolv.conf if $DNS1 is already in it * Thu Jan 13 2000 Bill Nottingham - link popt statically * Mon Jan 10 2000 Bill Nottingham - don't try to umount /loopfs * Mon Dec 27 1999 Bill Nottingham - switch to using sysctl * Mon Dec 13 1999 Bill Nottingham - umount /proc *after* trying to turn off raid * Mon Dec 06 1999 Michael K. Johnson - improvements in clone device handling - better signal handling in ppp-watch - yet another attempt to fix those rare PAP/CHAP problems * Sun Nov 28 1999 Bill Nottingham - impressive. Three new features, three new bugs. * Mon Nov 22 1999 Michael K. Johnson - fix more possible failed CHAP authentication (with chat scripts) - fix ppp default route problem - added ppp-watch man page, fixed usernetctl man page - make ifup-ppp work again when called from netcfg and linuxconf - try to keep ppp-watch from filling up logs by respawning pppd too fast - handle all linuxconf-style alias files with linuxconf * Mon Nov 22 1999 Bill Nottingham - load mixer settings for monolithic sound - man page for ppp-watch - add ARP variable for ifup - some i18n fixes * Wed Nov 10 1999 Bill Nottingham - control stop-a separately from sysrq * Mon Nov 08 1999 Michael K. Johnson - fix some failed CHAP authentication - fix extremely unlikely, but slightly possible kill-random-process bug in ppp-watch - allow DNS{1,2} in any ifcfg-* file, not just PPP, and add nameserver entries, don't just replace them - don't use /tmp/confirm, use /var/run/confirm instead * Tue Nov 02 1999 Bill Nottingham - fix lang.csh /tmp race oops * Wed Oct 27 1999 Bill Nottingham - we now ship hwclock on alpha. * Mon Oct 25 1999 Jakub Jelinek - fix check for serial console, don't use -C argument to fsck on serial console. * Mon Oct 18 1999 Bill Nottingham - do something useful with linuxconf 'any' static routes. * Tue Oct 12 1999 Matt Wilson - added patch from Owen to source i18n configuration before starting prefdm * Mon Oct 11 1999 Bill Nottingham - support for linuxconf alias files - add support for Jensen clocks. * Tue Oct 05 1999 Bill Nottingham - assorted brown paper bag fixes - check for programs/files before executing/sourcing them - control stop-a like magic sysrq * Thu Sep 30 1999 Bill Nottingham - req. e2fsprogs >= 1.15 * Fri Sep 24 1999 Bill Nottingham - munge C locale definitions to en_US - use fsck's completion bar * Thu Sep 23 1999 Michael K. Johnson - ppp-watch now always kills pppd pgrp to make sure dialers are dead, and tries to hang up the modem * Tue Sep 21 1999 Bill Nottingham - add a DEFRAG_IPV4 option * Mon Sep 20 1999 Michael K. Johnson - changed to more modern defaults for PPP connections * Mon Sep 20 1999 Bill Nottingham - kill processes for umount in halt, too. - fixes to remove /usr dependencies * Fri Sep 17 1999 Bill Nottingham - load/save mixer settings in rc.sysinit, halt * Mon Sep 13 1999 Michael K. Johnson - add --remotename option to wvdial code - make sure we do not have an earlier version of wvdial that doesn't know how handle --remotename - make ppp-watch background itself after 30 seconds even if connection does not come up, at boot time only, so that a non-functional PPP connection cannot hang boot. * Sun Sep 12 1999 Bill Nottingham - a couple of /bin/sh -> /bin/bash fixes - fix swapoff silliness * Fri Sep 10 1999 Bill Nottingham - chkconfig --del in %preun, not %postun - use killall5 in halt - swapoff non-/etc/fstab swap * Wed Sep 08 1999 Michael K. Johnson - ifdown now synchronous (modulo timeouts) - several unrelated cleanups, primarily in ifdown * Tue Sep 07 1999 Bill Nottingham - add an 'unconfigure' sort of thing * Mon Sep 06 1999 Michael K. Johnson - added ppp-watch to make "ifup ppp*" synchronous * Fri Sep 03 1999 Bill Nottingham - require lsof * Wed Sep 01 1999 Bill Nottingham - add interactive prompt * Tue Aug 31 1999 Bill Nottingham - disable magic sysrq by default * Mon Aug 30 1999 Bill Nottingham - new NFS unmounting from Bill Rugolsky - fix ifup-sl/dip confusion - more raid startup cleanup - make utmp group 22 * Fri Aug 20 1999 Bill Nottingham - pass hostname to pump - add lang.csh * Thu Aug 19 1999 Bill Nottingham - more wvdial updates - fix a *stupid* bug in process reading * Fri Aug 13 1999 Bill Nottingham - add new /boot/kernel.h boot kernel version file - new RAID startup * Fri Aug 13 1999 Michael K. Johnson - use new linkname argument to pppd to make if{up,down}-ppp reliable -- requires ppp-2.3.9 or higher * Mon Aug 02 1999 Bill Nottingham - fix typo. - add 'make check' * Wed Jul 28 1999 Michael K. Johnson - simple wvdial support for ppp connections * Mon Jul 26 1999 Bill Nottingham - stability fixes for initlog - initlog now has a config file - add alias speedup from dharris at drh.net - move netfs links - usleep updates * Thu Jul 08 1999 Bill Nottingham - remove timeconfig dependency - i18n fixes from nkbj at image.dk - move inputrc to setup package * Tue Jul 06 1999 Bill Nottingham - fix killall links, some syntax errors * Fri Jun 25 1999 Bill Nottingham - don't make module-info, System.map links - handle utmpx/wtmpx - fix lots of bugs in 4.21 release :) * Thu Jun 17 1999 Bill Nottingham - set clock as soon as possible - use INITLOG_ARGS everywhere - other random fixes in networking * Mon Jun 14 1999 Bill Nottingham - oops, don't create /var/run/utmp and then remove it. - stomp RAID bugs flat. Sort of. * Mon May 24 1999 Bill Nottingham - clean out /var better - let everyone read /var/run/ppp*.dev - fix network startup so it doesn't depend on /usr * Tue May 11 1999 Bill Nottingham - various fixes to rc.sysinit - fix raid startup - allow for multi-processor /etc/issues * Sun Apr 18 1999 Matt Wilson - fixed typo - "Determing" to "Determining" * Fri Apr 16 1999 Preston Brown - updated inputrc so that home/end/del work on console, not just X * Thu Apr 08 1999 Bill Nottingham - fix more logic in initlog - fix for kernel versions in ifup-aliases - log to /var/log/boot.log * Wed Apr 07 1999 Bill Nottingham - fix daemon() function so you can specify pid to look for * Wed Apr 07 1999 Erik Troan - changed utmp,wtmp to be group writeable and owned by group utmp * Tue Apr 06 1999 Bill Nottingham - fix loading of consolefonts/keymaps - three changelogs. three developers. one day. Woohoo! * Tue Apr 06 1999 Michael K. Johnson - fixed ifup-ipx mix-up over . and _ * Tue Apr 06 1999 Erik Troan - run /sbin/ifup-local after bringing up an interface (if that file exists) * Mon Apr 05 1999 Bill Nottingham - load keymaps & console font early - fixes for channel bonding, strange messages with non-boot network interfaces * Sat Mar 27 1999 Cristian Gafton - added sysvinitfiles as a documenattaion file * Fri Mar 26 1999 Bill Nottingham - nfsfs -> netfs * Mon Mar 22 1999 Bill Nottingham - don't source /etc/sysconfig/init if $BOOTUP is already set * Fri Mar 19 1999 Bill Nottingham - don't run linuxconf if /usr isn't mounted - set macaddr before bootp - zero in the /var/run/utmpx file (gafton) - don't set hostname on ppp/slip (kills X) * Wed Mar 17 1999 Bill Nottingham - exit ifup if pump fails - fix stupid errors in reading commands from subprocess * Tue Mar 16 1999 Bill Nottingham - fix ROFS logging - make fsck produce more happy output - fix killproc logic * Mon Mar 15 1999 Bill Nottingham - doc updates - support for SYSFONTACM, other console-tools stuff - add net route for interface if it isn't there. - fix for a bash/bash2 issue * Mon Mar 15 1999 Michael K. Johnson - pam_console lockfile cleanup added to rc.sysinit * Sun Mar 14 1999 Bill Nottingham - fixes in functions for 'action' - fixes for pump * Wed Mar 10 1999 Bill Nottingham - Mmm. Must always remove debugging code. before release. *thwap* - pump support - mount -a after mount -a -t nfs * Thu Feb 25 1999 Bill Nottingham - put preferred support back in * Thu Feb 18 1999 Bill Nottingham - fix single-user mode (source functions, close if) * Wed Feb 10 1999 Bill Nottingham - turn off xdm in runlevel 5 (now a separate service) * Thu Feb 04 1999 Bill Nottingham - bugfixes (ifup-ppp, kill -TERM, force fsck, hwclock --adjust, setsysfont) - add initlog support. Now everything is logged (and bootup looks different) * Thu Nov 12 1998 Preston Brown - halt now passed the '-i' flag so that network interfaces disabled * Tue Nov 10 1998 Michael K. Johnson - handle new linuxconf output for ipaliases * Thu Oct 15 1998 Erik Troan - fixed raid start stuff - added raidstop to halt * Mon Oct 12 1998 Cristian Gafton - handle LC_ALL * Mon Oct 12 1998 Preston Brown - adjusted setsysfont to always run setfont, even if only w/default font * Tue Oct 06 1998 Cristian Gafton - rc.sysvinit should be working with all kernel versions now - requires e2fsprogs (for fsck) - set INPUTRC and LESSCHARSET on linux-lat * Wed Sep 16 1998 Jeff Johnson - /etc/rc.d/rc: don't run /etc/rc.d/rcN.d/[KS]??foo.{rpmsave,rpmorig} scripts. - /etc/rc.d/rc.sysinit: raid startup (Nigel.Metheringham at theplanet.net). - /sbin/setsysfont: permit unicode fonts. * Mon Aug 17 1998 Erik Troan - don't add 'Red Hat Linux' to /etc/issue; use /etc/redhat-release as is * Sun Aug 16 1998 Jeff Johnson - paranoia improvements to .rhkmvtag - if psacct with /sbin/accton, than turn off accounting * Tue Jul 07 1998 Jeff Johnson - start/stop run levels changed. - ipx_configure/ipx_internal_net moved to /sbin. * Wed Jul 01 1998 Erik Troan - usernetctl didn't understand "" around USERCTL attribute * Wed Jul 01 1998 Jeff Johnson - Use /proc/version to find preferred modules. - Numerous buglets fixed. * Sun Jun 07 1998 Erik Troan - rc.sysinit looks for bootfile= as well as BOOT_IMAGE to set /lib/modules/preferred symlink * Mon Jun 01 1998 Erik Troan - ipcalc should *never* have been setgid anything - depmod isn't run properly for non-serial numbered kernels * Wed May 06 1998 Donnie Barnes - added system font and language setting * Mon May 04 1998 Michael K. Johnson - Added missing files to packagelist. * Sat May 02 1998 Michael K. Johnson - Added lots of linuxconf support. Should still work on systems that do not have linuxconf installed, but linuxconf gives enhanced support. - In concert with linuxconf, added IPX support. Updated docs to reflect it. * Fri May 01 1998 Erik Troan - rc.sysinit uses preferred directory * Sun Apr 05 1998 Erik Troan - updated rc.sysinit to deal with kernel versions with release numbers * Sun Mar 22 1998 Erik Troan - use ipcalc to calculate the netmask if one isn't specified * Tue Mar 10 1998 Erik Troan - added and made use of ipcalc * Tue Mar 10 1998 Erik Troan - removed unnecessary dhcp log from /tmp * Mon Mar 09 1998 Erik Troan - if bootpc fails, take down the device * Mon Mar 09 1998 Erik Troan - added check for mktemp failure * Thu Feb 05 1998 Erik Troan - fixed support for user manageable cloned devices * Mon Jan 12 1998 Michael K. Johnson - /sbin/ isn't always in $PATH, so call /sbin/route in ifup-routes * Wed Dec 31 1997 Erik Troan - touch /var/lock/subsys/kerneld after cleaning out /var/lock/subsys - the logic for when /var/lock/subsys/kerneld is touched was backwards * Tue Dec 30 1997 Erik Troan - tried to get /proc stuff right one more time (uses -t nonfs,proc now) - added support for /fsckoptions - changed 'yse' to 'yes' in KERNELD= line * Tue Dec 09 1997 Erik Troan - set domainname to "" if none is specified in /etc/sysconfig/network - fix /proc mounting to get it in /etc/mtab * Mon Dec 08 1997 Michael K. Johnson - fixed inheritance for clone devices * Fri Nov 07 1997 Erik Troan - added sound support to rc.sysinit * Fri Nov 07 1997 Michael K. Johnson - Added missing "then" clause * Thu Nov 06 1997 Michael K. Johnson - Fixed DEBUG option in ifup-ppp - Fixed PPP persistance - Only change IP forwarding if necessary * Tue Oct 28 1997 Donnie Barnes - removed the skeleton init script - added the ability to 'nice' daemons * Tue Oct 28 1997 Erik Troan - touch /var/lock/subsys/kerneld if it's running, and after mounting /var - applied dhcp fix * Thu Oct 23 1997 Donnie Barnes - added status|restart to init scripts * Thu Oct 23 1997 Michael K. Johnson - touch random seed file before chmod'ing it. * Wed Oct 15 1997 Erik Troan - run domainname if NISDOMAIN is set * Wed Oct 15 1997 Michael K. Johnson - Make the random seed file mode 600. * Tue Oct 14 1997 Michael K. Johnson - bring down ppp devices if ifdown-ppp is called while ifup-ppp is sleeping. * Mon Oct 13 1997 Erik Troan - moved to new chkconfig conventions * Sat Oct 11 1997 Erik Troan - fixed rc.sysinit for hwclock compatibility * Thu Oct 09 1997 Erik Troan - run 'ulimit -c 0' before running scripts in daemon function * Wed Oct 08 1997 Donnie Barnes - added chkconfig support - made all rc*.d symlinks have missingok flag * Mon Oct 06 1997 Erik Troan - fixed network-scripts to allow full pathnames as config files - removed some old 3.0.3 pcmcia device handling * Wed Oct 01 1997 Michael K. Johnson - /var/run/netreport needs to be group-writable now that /sbin/netreport is setguid instead of setuid. * Tue Sep 30 1997 Michael K. Johnson - Added network-functions to spec file. - Added report functionality to usernetctl. - Fixed bugs I introduced into usernetctl while adding clone device support. - Clean up entire RPM_BUILD_ROOT directory in %clean. * Mon Sep 29 1997 Michael K. Johnson - Clone device support in network scripts, rc scripts, and usernetctl. - Disassociate from controlling tty in PPP and SLIP startup scripts, since they act as daemons. - Spec file now provides start/stop symlinks, since they don't fit in the CVS archive. * Tue Sep 23 1997 Donnie Barnes - added mktemp support to ifup * Thu Sep 18 1997 Donnie Barnes - fixed some init.d/functions bugs for stopping httpd * Tue Sep 16 1997 Donnie Barnes - reworked status() to adjust for processes that change their argv[0] in the process table. The process must still have it's "name" in the argv[0] string (ala sendmail: blah blah). * Mon Sep 15 1997 Erik Troan - fixed bug in FORWARD_IPV4 support * Sun Sep 14 1997 Erik Troan - added support for FORWARD_IPV4 variable * Thu Sep 11 1997 Donald Barnes - added status function to functions along with better killproc handling. - added /sbin/usleep binary (written by me) and man page - changed BuildRoot to /var/tmp instead of /tmp * Tue Jun 10 1997 Michael K. Johnson - /sbin/netreport sgid rather than suid. - /var/run/netreport writable by group root. - /etc/ppp/ip-{up|down} no longer exec their local versions, so now ifup-post and ifdown-post will be called even if ip-up.local and ip-down.local exist. * Tue Jun 03 1997 Michael K. Johnson - Added missing -f to [ invocation in ksyms check. * Fri May 23 1997 Michael K. Johnson - Support for net event notification: Call /sbin/netreport to request that SIGIO be sent to you whenever a network interface changes status (won't work for brining up SLIP devices). Call /sbin/netreport -r to remove the notification request. - Added ifdown-post, and made all the ifdown scrips call it, and added /etc/ppp/ip-down script that calls /etc/ppp/ip-down.local if it exists, then calls ifdown-post. - Moved ifup and ifdown to /sbin * Tue Apr 15 1997 Michael K. Johnson - usernetctl put back in ifdown - support for slaved interfaces * Wed Apr 02 1997 Erik Troan - Created ifup-post from old ifup - PPP, PLIP, and generic ifup use ifup-post * Fri Mar 28 1997 Erik Troan - Added DHCP support - Set hostname via reverse name lookup after configuring a networking device if the current hostname is (none) or localhost * Tue Mar 18 1997 Erik Troan - Got rid of xargs dependency in halt script - Don't mount /proc twice (unmount it in between) - sulogin and filesystem unmounting only happened for a corrupt root filesystem -- it now happens when other filesystems are corrupt as well * Tue Mar 04 1997 Michael K. Johnson - PPP fixes and additions * Mon Mar 03 1997 Erik Troan - Mount proc before trying to start kerneld so we can test for /proc/ksyms properly. * Wed Feb 26 1997 Michael K. Johnson - Added MTU for PPP. - Put PPPOPTIONS at the end of the options string instead of at the beginning so that they override other options. Gives users more rope... - Don't do module-based stuff on non-module systems. Ignore errors if st module isn't there and we try to load it. * Tue Feb 25 1997 Michael K. Johnson - Changed ifup-ppp and ifdown-ppp not to use doexec, because the argv[0] provided by doexec goes away when pppd gets swapped out. - ifup-ppp now sets remotename to the logical name of the device. This will BREAK current PAP setups on netcfg-managed interfaces, but we needed to do this to add a reasonable interface-specific PAP editor to netcfg. * Fri Feb 07 1997 Erik Troan - Added usernetctl wrapper for user mode ifup and ifdown's and man page - Rewrote ppp and slip kill and retry code - Added doexec and man page isdn4k-utils-3.2-3.p1 --------------------- * Fri Oct 10 2003 Than Ngo 3.2-3.p1 - fixed wrong version of xisdnload (bug #106616) kbd-1.08-11 ----------- * Fri Oct 10 2003 Bill Nottingham 1.08-11 - remove keytable init script (#106783) * Tue Aug 12 2003 Adrian Havill 1.08-10.1 - bump for RHEL kdelibs-3.1.4-3 --------------- * Fri Oct 10 2003 Than Ngo 6:3.1.4-3 - better icon scale patch kernel-2.4.22-1.2088.nptl ------------------------- * Fri Oct 10 2003 Dave Jones - Only enable DMA on hard disks in the BOOT kernel. kudzu-1.1.33-1 -------------- * Fri Oct 10 2003 Bill Nottingham 1.1.33-1 - add a diskonkey device (#105939, ) libwvstreams-3.70-12 -------------------- * Fri Oct 10 2003 Nalin Dahyabhai 3.70-12 - link libwvstreams shared libs against libcrypt, upon which they depend man-1.5k-11 ----------- * Wed Oct 01 2003 Adrian Havill 1.5k-11 - Use UTF-8 in makewhatis when searching for non-English versions of the phrase "NAME" in man pages - add "-o" option to makeis to specify an alternate whatis db location - move makewhatis from /sbin to /usr/bin, chmod o+x it as the whatis db is writable only by root anyway * Wed Aug 20 2003 Adrian Havill 1.5k-10 - added auto-detect for utf8 and conversion to allow gripes() and others to correctly output to some charsets (#88605) * Fri Aug 08 2003 Adrian Havill 1.5k-9 - cleaned up apropos script bugs (#97006) - merged all apropos changes into one cleaner patch - fix the search/replace for man.conf * Wed Jun 04 2003 Elliot Lee - rebuilt * Thu May 22 2003 Jeremy Katz 1.5k-7 - fix build with gcc 3.3 * Mon Feb 10 2003 Adrian Havill 1.5k-6 - added patch for korean (#83934) * Thu Feb 06 2003 Adrian Havill 1.5k-5 - marked man.config as noreplace %config (#82088) - moved man.config from /usr/share to /etc even though +fhs (#81964) - removed bad argcat patch which made bogus grep queries (#82684) * Wed Jan 22 2003 Tim Powers - rebuilt * Mon Jan 13 2003 Adrian Havill 1.5k-2 - bump version from j to k - adjust patches to reflect upstream integration * Wed Jan 08 2003 Adrian Havill 1.5j-16 - require groff 1.18 because prev vers don't have -c getopt (#77847) - added /usr/local/share/man to MANPATH (#65467) * Mon Jan 06 2003 Adrian Havill 1.5j-14 - don't run trojan sh cmd that have unsafe chars munged (#79289) - made apropos command more robust (#62606) * Tue Dec 10 2002 Joe Orton 1.5j-13 - include makewhatis.8 (#65511) * Fri Nov 22 2002 Tim Powers - remove unpackaged files from the buildroot * Tue Sep 03 2002 Karsten Hopp 1.5j-11 - fix segfault when running 'man --' (#73212) * Mon Sep 02 2002 Bill Nottingham 1.5j-10 - use nroff -c * Fri Jul 12 2002 Phil Knirsch 1.5j-9 - Changed output of groff to latin1 instead of utf8 as utf8 seems to be broken ATM. * Fri Jun 21 2002 Tim Powers 1.5j-8 - automated rebuild * Thu May 23 2002 Tim Powers 1.5j-7 - automated rebuild * Mon Mar 25 2002 Bernhard Rosenkraenzer 1.5j-6 - Fix bugs #60676 and #61105 - Add /usr/local/man and /usr/X11R6/man to makewhatis default paths * Tue Feb 26 2002 Bernhard Rosenkraenzer 1.5j-5 - Fix up filename quoting in makewhatis (#60289) * Mon Feb 25 2002 Bernhard Rosenkraenzer 1.5j-3 - Fix bugs #60131, #60088 - Don't send makewhatis output to /dev/tty (#60285) * Wed Jan 09 2002 Tim Powers - automated rebuild * Thu Nov 22 2001 Bernhard Rosenkraenzer 1.5j-1 - Update to 1.5j * Fri Aug 31 2001 Trond Eivind Glomsr?d 1.5i2-6 - set LC_CTYPE, not just LC_MESSAGES. That way, the messages requested can also be displayed (#52978) * Mon Aug 20 2001 Bernhard Rosenkraenzer 1.5i2-5 - Make sure the trigger exits cleanly (#51940) * Wed Jul 18 2001 Bernhard Rosenkraenzer 1.5i2-4 - Don't create warnings on fresh installs * Tue Jul 17 2001 Bernhard Rosenkraenzer 1.5i2-3 - Restore /var/cache/man directories even if we've built without usecache. This allows users to enable catman caching manually (#48762) and shuts up tmpwatch (#47784 and its 1000 duplicates) * Tue Jul 03 2001 Bernhard Rosenkraenzer 1.5i2-2 - Fix makewhatis interoperability with gawk 3.1.x (#46405) - Fix initial creation of whatis database if makewhatis is run with "-u" even then (e.g. by cron) (#45646) - Fix #45827 - Require current mktemp (#43134) - Fix #42915 - Fix paths on old distributions (#42031) * Sun Jun 24 2001 Bernhard Rosenkraenzer 1.5i2-1 - 1.5i2 * Thu Jun 07 2001 Harald Hoyer 1.5i-9 - Some fixes for secure pathnames - remove cache directories - remove sgid - fixed man.1 to refer to man.config(5) - fixed makewhatis * Thu May 31 2001 Bernhard Rosenkraenzer 1.5i-8 - Some fixes to legacy path support * Mon May 28 2001 Bernhard Rosenkraenzer 1.5i-7 - Fix up another buffer overrun (#42450) - Add "`" and "$(" to the list of illegal filename parts in makewhatis (#42450) - Add a define toggle to build 5.x and 6.x errata correctly (#42031, #42192) - * Thu May 17 2001 Bernhard Rosenkraenzer 1.5i-6 - Fix up potential GID man -> root exploit (#41805) * Thu May 17 2001 Bernhard Rosenkraenzer 1.5i-5 - Fix up support for UTF-8 locales (#39139) * Sun May 13 2001 Bernhard Rosenkraenzer 1.5i-4 - More workarounds for "detecting" stuff that isn't in the build roots * Sun May 06 2001 Bernhard Rosenkraenzer 1.5i-3 - Fix up makewhatis (#39217) * Mon Apr 30 2001 Bernhard Rosenkraenzer 1.5i-2 - break the configure script. We want man to use less even though it can't be found at build time. * Tue Apr 24 2001 Bernhard Rosenkraenzer 1.5i-1 - 1.5i (Fixes #23258, #31805, #33276) - Fix apropos and whatis for pages that contain non-ascii characters (#21619) - Look for legacy whatis databases in $manpath (#33897) * Sun Feb 04 2001 Bernhard Rosenkraenzer - Require findutils for makewhatis (Bug #25615) * Fri Jan 19 2001 Jeff Johnson - Use PreReq: not Requires(post,preun). * Mon Jan 08 2001 Bernhard Rosenkraenzer - s/Prereq/Requires(post,preun)/ (this should fix #22775) * Fri Dec 29 2000 Bill Nottngham - tweak prereqs * Mon Dec 18 2000 Yukihiro Nakai - Add Japanese patches. * Mon Dec 11 2000 Bernhard Rosenkraenzer - Requires(preun,post) fileutils * Thu Oct 19 2000 Bernhard Rosenkraenzer - Fix yet another security problem (MANSECT overrun), Bug #19351 * Thu Oct 12 2000 Bernhard Rosenkraenzer - Fix trailing garbage when a man page doesn't end with a newline (Bug #9026) - Look for files in other man directories if the first match isn't accessible (Bug #10254) * Mon Oct 09 2000 Bernhard Rosenkraenzer - Move whatis database to /var/cache/man/whatis to allow read-only /usr filesystems (Bug #18383) - Don't use predictable filenames in makewhatis (not reported, spotted while fixing 18383) * Wed Oct 04 2000 Bernhard Rosenkraenzer - Add internationalization support, based on patch from noa at noa.tm (Bug #7680) * Wed Aug 23 2000 Tim Powers - fix bad man path for makewhatis in bug #16754 * Tue Aug 15 2000 Bernhard Rosenkraenzer - Fix up .so handling in some odd cases (Bug #16171) * Fri Aug 04 2000 Bernhard Rosenkraenzer - Fix up the fix for #14278, this fixes #11621 as well. * Thu Jul 27 2000 Bernhard Rosenkraenzer - Get rid of random s (Bug #14278, thanks, Tim) * Wed Jul 12 2000 Prospector - automatic rebuild * Fri Jun 30 2000 Bill Nottingham - makewhatis makes predicatable filenames in /tmp. Bad. * Mon Jun 12 2000 Bernhard Rosenkraenzer - gzip the man pages manually - since file doesn't recognize them as man pages, the build root policy doesn't do it (Bug #12015) * Tue May 16 2000 Preston Brown - default man path is now /usr/share/man. /usr/man maintained for compat. - remove +sgid option to allow builds as a normal user. SPEC file maintains proper permissions. * Fri Mar 03 2000 Bernhard Rosenkraenzer - Add kerberos man paths to man.config (Bug #11168 + extra fixes) * Tue Feb 29 2000 Bernhard Rosenkraenzer - 1.5h1 - this has a better fix for the security problems. - remove manpath patch (now in base) - remove loop patch (now in base) * Mon Feb 28 2000 Bernhard Rosenkraenzer - Fix security problems related to buffer overruns caused by oversized enviroment variables * Thu Feb 03 2000 Bernhard Rosenkraenzer - deal with rpm gziping man pages - fix file locking (Bug #8947) * Mon Sep 13 1999 Bill Nottingham - strip man2html * Fri Sep 10 1999 Cristian Gafton - revert to latin1 instead of ascii * Wed Jun 16 1999 Cristian Gafton - fixed man2html loop on terminfo.5 (patrch from the author; #3316) * Mon May 10 1999 Michael K. Johnson - fixed #2532 by adding /usr/local/sbin as a MANPATH_MAP * Fri Apr 09 1999 Michael K. Johnson - cron.weekly rebuilds, cron.daily updates in minimal time * Fri Apr 09 1999 Preston Brown - man 1.5g bugfix release * Sun Mar 21 1999 Cristian Gafton - auto rebuild in the new build environment (release 5) * Thu Feb 18 1999 Jeff Johnson - add manpath symlinks (#1138). * Fri Feb 12 1999 Michael Maher - fixed bug #792 - added man2html files * Tue Dec 29 1998 Cristian Gafton - build for 6.0 - upgraded to 1.5e - properly buildrooted * Thu Aug 13 1998 Jeff Johnson - enable fsstnd organization - change /var/catman/X11 to X11R6 - %post/%preun to clean up cat litter * Tue Jun 02 1998 Prospector System - translations modified for de * Tue Jun 02 1998 Erik Troan - you can't do free(malloc(10) + 4) * Wed May 06 1998 Cristian Gafton - upgraded to 1.5d * Fri Apr 24 1998 Prospector System - translations modified for de, fr, tr * Fri Apr 10 1998 Cristian Gafton - updated to 1.5a * Sun Oct 19 1997 Erik Troan - uses a build root * Mon Sep 22 1997 Erik Troan - updated to man-1.4j, which fixes some security problems; release 1 is for RH 4.2, release 2 is for glibc * Mon Jun 02 1997 Erik Troan - built against glibc * Tue Mar 25 1997 Erik Troan - Added /usr/lib/perl5/man to default manpath pam_krb5-2.0.4-1 ---------------- * Fri Oct 10 2003 Nalin Dahyabhai 2.0.3-1 - update to 2.0.4 prelink-0.3.0-8 --------------- * Thu Oct 09 2003 Jakub Jelinek 0.3.0-8 - use /var/lib/misc/prelink.full instead of /var/run/prelink.full for last full prelink timestamp (#106721) - warn about UPX compressed binaries or libraries/binaries without section headers (neither can be prelinked obviously) rawhide-release-20031011-1 -------------------------- From pekkas at netcore.fi Thu Oct 16 05:50:17 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 16 Oct 2003 08:50:17 +0300 (EEST) Subject: RPM problem: prereq: not honored in upgrade ordering? In-Reply-To: <1066237316.25026.67.camel@spatula> Message-ID: On 15 Oct 2003, Jef Spaleta wrote: > Pekka Savola wrote: > > Thanks for the rant. Unfortunately, it is not relevant to this > > discussion, if you read the mail in detail. > > Its relevant...to the bug summary you posted to bugzilla..which speaks > about a 'reordering issue' where you didn't specify that you orginally > saw the reordering issue with using autoupdate. Your bugzilla reports is > quite misleading about the circumstances where you saw the 'reordering' > issue...and makes it hard to actually try to verify...since you do not > make mention of autoupdate in the bugzilla entry....full disclosure is > important. You initial bugreport comment about a 'reordering' problem is > misleading since you didn't specify the exact commandline you used when > doing the 300 RPMs install...i'd hate for a developer to waste time > trying to confirm a general 'reordering' problem wider in scope Right. There seem to be two problems here, one with reordering using hundreds of packages (not sure whether nodeps was used here), and the second one which is easy to reproduce (without nodeps). The end effects seem to be the same. I should have been clearer about separating these two issues. Btw. I looked at rpm source and it looks like nodeps does not change the package ordering. You have to use a separate toggle, --noorder, to do that. So, if you are certain all of your deps are included. nodeps should not do harm (I would still not use it though). Package upgrade with the 4 RPMs with --nodeps *seems to* confirm this theory. If jbj is listening, it would be nice to get an ACK/NACK on this.. > than a > specific packaging problem with sendmail when 'reordering' bug was > actually because autoupdate used --nodeps. This could easily a problem > specific to the sendmail package...a packaging error with sendmail, and > not a general problem with rpm itself. Have you checked to see if the > other programs that use the alternatives system installs correctly..like > the printing subsystems? If other alternatives based systems get > installed correctly... No, I haven't tested w/ CUPS + LPRng. Maybe I will try at some point soon. > maybe its not a general rpm bug at all..and your > bugreport is misfiled under rpm. Wouldn't you hate to waste the rpm > developers time hunting down a general 'reordering' bug that doesn't > actually exist...because you failed to tell them you were using > autoupdate to do the large 300+ package install. > > Now...that we are all pretty much convinced that a 'reordering' bug > would be specific to autoupdate and not rpm... I'm not sure we can ascertain that. I doubt it very much. But the recent autoupdate versions have eliminated all use of nodeps, and thus waste some CPU cycles in dependency resolution (when they've already been checked with rpm -U --test), so when/if I upgrade another box to RHL73, I might watch out how the reordering goes. I certainly think this has nothing to do with nodeps, as nodeps is used only if all the external dependencies are met. > we can handle the specific > 'core problem' of why the postinstall scriptlet is not running > alternatives like you expect. Right. > Have you tried running the alternatives command that is in the > postinstall scriptlet by hand? > /usr/sbin/alternatives --install /usr/sbin/sendmail mta /usr/sbin/sendmail.sendmail 90 --slave /usr/bin/mailq mta-mailq /usr/bin/mailq.sendmail --slave /usr/bin/newaliases mta-newaliases /usr/bin/newaliases.sendmail --slave /usr/bin/rmail mta-rmail /usr/bin/rmail.sendmail --slave /usr/share/man/man1/mailq.1.gz mta-mailqman /usr/share/man/man1/mailq.sendmail.1.gz --slave /usr/share/man/man1/newaliases.1.gz mta-newaliasesman /usr/share/man/man1/newaliases.sendmail.1.gz --slave /usr/share/man/man5/aliases.5.gz mta-aliasesman /usr/share/man/man5/aliases.sendmail.5.gz --initscript sendmail > > thats one very long commandline...it could be a simple syntax error in > the command or something Right.. works from command-line, and works run non-interactively from a cronjob (as noted in the report). The about only thing I can think of is that the command does not exist when it's being run... :-/ > and nothing to do with the order rpm is trying > to install things (if used without --nodeps). Doubtful. This happens also without nodeps. > Can you get that > alternatives --install ..... > command to work right after the rpms are installed? Yep. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nphilipp at redhat.com Thu Oct 16 06:48:00 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 16 Oct 2003 08:48:00 +0200 Subject: Gimp 1.3 packages, was: New extra packages and yum repository In-Reply-To: <20031016013106.1c76543e.ms-nospam-0306@arcor.de> References: <1066147414.4511.36.camel@gibraltar.stuttgart.redhat.com> <1066148362.6205.1.camel@mozer.nailed.org> <20031014213758.29a31d6f.ms-nospam-0306@arcor.de> <1066202803.6024.56.camel@wombat.tiptoe.de> <20031015182517.7250d596.ms-nospam-0306@arcor.de> <1066255153.6805.9.camel@wombat.tiptoe.de> <20031016013106.1c76543e.ms-nospam-0306@arcor.de> Message-ID: <1066286879.6355.13.camel@wombat.tiptoe.de> On Thu, 2003-10-16 at 01:31, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 15 Oct 2003 23:59:14 +0200, Nils Philippsen wrote: > > > > > - whether or not to explicitly list directories - I guess this makes > > > > sense for /etc/gimp, but e.g. /usr/share/locale/zh_CN/LC_MESSAGES or > > > > > > Some of the locale directories are not owned by glibc-common. > > > > This is a bug in glibc-common which should not be tried to > > fix/circumvent in other packages. > > What do you suggest as alternative? Now owning such directories would > a) leave them behind upon package removal and b) create them with > wrong permissions in case of a restrictive umask. > > As a similar example, Red Hat's "perl" package should own several > directories, e.g. vendor install dirs. There's an old bug report about > it somewhere in bugzilla. But it doesn't get fixed. If it's not in Bugzilla, put it in there. If it's in Bugzilla, step on people's toes until they react ;-). Putting this fix in an unrelated package is not the right thing to do. > > > You have missed /etc/gimp, /usr/lib/gimp, /usr/lib/gimp/1.3/environ, > > > and /usr/share/gimp. > > > > I didn't try to give a complete list. > > Sorry, your package should own those directories. Thanks, I'll fix this. 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 nos at utel.no Thu Oct 16 07:00:17 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Thu, 16 Oct 2003 09:00:17 +0200 Subject: Translations In-Reply-To: <70b1e7e403097107d3@[192.168.170.10]> References: <70b1e7e403097107d3@[192.168.170.10]> Message-ID: <746836250409ea07d3@[192.168.170.10]> On Wed, 2003-10-15 at 15:33, Giacomo Magnini wrote: > Hi all, > I'm new to the list, and I wish to work on translating Fedora packages > in my own language (Italian). > Is someone already working on this? Should I look anywhere else to > gather more informations? > Is someone already coordinating the effort? > Sorry for the slew of questions! :) > Cheers, Giacomo Magnini. You should probably join the translation team for your country/language Seems http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=it and perhaps http://www.it.gnome.org/ are good places to start. -- 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 fs111 at web.de Thu Oct 16 08:03:51 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Thu, 16 Oct 2003 10:03:51 +0200 Subject: rawhide report: 20031015 changes In-Reply-To: <200310151000.h9FA0Wk17135@porkchop.devel.redhat.com> References: <200310151000.h9FA0Wk17135@porkchop.devel.redhat.com> Message-ID: <1066291430.1934.2.camel@localhost> Am Mit, 2003-10-15 um 12.00 schrieb Build System: > vim-6.2.121-1 > -- > * Tue Oct 14 2003 Karsten Hopp 1:6.2.121-1 > > - patchlevel 121 > - fix buildrequires (#106824, #105832) I think there is a missing dependence. I installed the newest vim packages on my shrike box, and it works fine, but I can remove libattr without any dependencies. This should be fixed: [FS111 at Hermes FS111]$ gvim [FS111 at Hermes FS111]$ su Password: [root at Hermes FS111]# rpm -e libattr [root at Hermes FS111]# exit exit [FS111 at Hermes FS111]$ gvim gvim: error while loading shared libraries: libattr.so.1: cannot open shared object file: No such file or directory [FS111 at Hermes FS111]$ vim vim: error while loading shared libraries: libattr.so.1: cannot open shared object file: No such file or directory [FS111 at Hermes FS111]$ best regards 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 ms-nospam-0306 at arcor.de Thu Oct 16 09:36:11 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 16 Oct 2003 11:36:11 +0200 Subject: Gimp 1.3 packages, was: New extra packages and yum repository In-Reply-To: <1066286879.6355.13.camel@wombat.tiptoe.de> References: <1066147414.4511.36.camel@gibraltar.stuttgart.redhat.com> <1066148362.6205.1.camel@mozer.nailed.org> <20031014213758.29a31d6f.ms-nospam-0306@arcor.de> <1066202803.6024.56.camel@wombat.tiptoe.de> <20031015182517.7250d596.ms-nospam-0306@arcor.de> <1066255153.6805.9.camel@wombat.tiptoe.de> <20031016013106.1c76543e.ms-nospam-0306@arcor.de> <1066286879.6355.13.camel@wombat.tiptoe.de> Message-ID: <20031016113611.0b896376.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 16 Oct 2003 08:48:00 +0200, Nils Philippsen wrote: > > > > Some of the locale directories are not owned by glibc-common. > > > > > > This is a bug in glibc-common which should not be tried to > > > fix/circumvent in other packages. > > > > What do you suggest as alternative? No_t_ owning such directories would > > a) leave them behind upon package removal and b) create them with > > wrong permissions in case of a restrictive umask. > > > > As a similar example, Red Hat's "perl" package should own several > > directories, e.g. vendor install dirs. There's an old bug report about > > it somewhere in bugzilla. But it doesn't get fixed. > > If it's not in Bugzilla, put it in there. If it's in Bugzilla, step on > people's toes until they react ;-). You do know, that would make the reporter look like a nerd. In the case of Perl, it's even a report from someone at Red Hat. One year old by now, without any comment from the person it's assigned to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73970 > Putting this fix in an unrelated > package is not the right thing to do. The only alternative is to publish packages without a work-around, which makes them look broken due core packages are broken. I can live with that. But it is a poor decision nevertheless. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/jmaL0iMVcrivHFQRAhvWAJ0QVUUJ2MVIt/dMch+OcItFskq4FwCdG/Ti DeCdR56M76N33u4HyUUUooU= =PlhO -----END PGP SIGNATURE----- From buildsys at porkchop.devel.redhat.com Thu Oct 16 09:48:05 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Thu, 16 Oct 2003 05:48:05 -0400 Subject: rawhide report: 20031016 changes Message-ID: <200310160948.h9G9m5s08991@porkchop.devel.redhat.com> Updated Packages: XFree86-4.3.0-40 ---------------- * Mon Oct 13 2003 Mike A. Harris 4.3.0-40 - More xfs initscript cleanups - Added XFree86-4.3.0-ia64-drm-locking.patch from John Dennis, to fix DRI locking deadlock on ia64 architecture (#104338,103936) * Fri Oct 10 2003 Mike A. Harris 4.3.0-39 - Fixed brown paper bag bug - missing "; then" in if clause of xfs initscript * Thu Oct 09 2003 Mike A. Harris 4.3.0-38.1 - Added conditional option with_bail_on_undef_syms which currently sets SharedLibraryLoadFlags to "-shared -Wl,-z,defs" in order to cause linking to fail completely when undefined symbols are found. Mesa compilation blows up, so I've disabled this option for now until I have proper time to spend on an investigation sometime in the future. * Wed Oct 08 2003 Mike A. Harris 4.3.0-38 - Updated xfs initscript to improve startup performance by not triggering the creation of fonts.dir due to new fonts.cache* files being found (#97240). - Updated xfs initscript to handle Opentype (otf, otc) fonts by calling mkfontscale + mkfontdir on them. - Updated xfs initscript to ignore all known font metadata file types when determining wether or not to trigger mkfontdir on non-truetype/non-opentype font file types. - Updated xfs initscript to run fc-cache if fonts.dir files get updated in any way. This is disabled for fc-cache version 1.0.2 which shipped on Red Hat Linux 8.0, as it SEGV's for some reason on that release, and 4.3.0 isn't officially supported for that release. - Updated xfs initscript to use "grep -qs" instead of output redirection in all grep invocations, as it is a bit cleaner code, possibly even faster. - Call mkfontscale in Syriac-fonts rpm post and postun scripts to properly generate fonts.scale and fonts.dir for these Opentype fonts. - Added XFree86-4.3.0-missing-lib-sharedreqs.patch to make sure libDPS, libXmuu, libXfont, libXp, libXpm, libXrandr, and libXv get linked to their dependant libraries when building XFree86, so that undefined symbols do not prevent prelinking from working. This solves other problems too, and now obsoletes the previous XFree86-4.3.0-missing-SharedXfooReqs.patch, and XFree86-4.3.0-libXrandr-missing-sharedreqs.patch patches as well (#106661) curl-7.10.6-7 ------------- * Wed Oct 15 2003 Adrian Havill 7.10.6-7 - aclocal before libtoolize - move OpenLDAP license so it's present as a doc file, present in both the source and binary as per conditions db4-4.1.25-11 ------------- * Wed Oct 15 2003 Nalin Dahyabhai 4.1.25-11 - fix multiple-inclusion problem of startup files when building shlibs without the -nostdlib flag * Tue Oct 14 2003 Nalin Dahyabhai - link shared libraries without -nostdlib, which created an unresolvable dep on a hidden symbol evolution-1.4.5-4 ----------------- * Wed Oct 15 2003 Jeremy Katz 1.4.5-4 - really, really remove duplicate menu entry (#103826) firstboot-1.2.4-1 ----------------- * Wed Oct 15 2003 Brent Fox 1.2.4-1 - pull lightrays.png from a different location fontconfig-2.2.1-6.1 -------------------- * Mon Sep 22 2003 Owen Taylor 2.2.1-6.0 - Should have been passing --with-add-fonts, not --with-add-dirs to configure ... caused wrong version of Luxi to be used. (#100862) * Fri Sep 19 2003 Owen Taylor 2.2.1-5.0 - Tweak fonts.conf to get right hinting for CJK fonts (#97337) gdb-5.3.90-0.20030710.41 ------------------------ * Wed Oct 15 2003 Elena Zannoni 0.20030710.41 - Bump up version number. * Wed Sep 24 2003 Elena Zannoni 0.20030710.40 - Fix problem with gcore and single threaded programs. (bugzilla 103531) * Mon Sep 22 2003 Jeff Johnston 0.20030710.39 - Fix call to quit_target from quit_force. * Sun Sep 21 2003 Andrew Cagney 0.20030710.38 - Fix PPC64 push dummy call. - Re-fix PPC64 return value (had wrong / old patch). * Sat Sep 20 2003 Andrew Cagney 0.20030710.37 - Fix PPC32 return values. * Sat Sep 20 2003 Andrew Cagney 0.20030710.36 - Rewrite ppc64 retun value methods so that they (hopefully) match the SysV spec. - Enable ppc64 testsuite. * Thu Sep 18 2003 Andrew Cagney 0.20030710.35 - Hack around problem "break main" vs "break .main" when there is only a minimal ppc64 symbol table. The former is a function descriptor and not where you want the breakpoint to go. Only convert descriptors to pointers when the address is in the ".opd" section. * Wed Sep 17 2003 Andrew Cagney 0.20030710.34 - Fix ppc32 push_dummy_call. * Tue Sep 16 2003 Andrew Cagney 0.20030710.33 - Pack gdb.sum and gdb.log using uuencode and bzip. * Tue Sep 16 2003 Jeff Johnston 0.20030710.32 - Catch errors when quitting so exit of gdb still occurs. * Mon Sep 15 2003 Andrew Cagney 0.20030710.31 - Fix ppc32 use_struct_convention. * Thu Sep 11 2003 Andrew Cagney 0.20030710.30 - Mods to dwarf2-frame.c to work around a lack of GCC/CFI info. * Thu Sep 11 2003 Elena Zannoni 0.20030710.29 - Bump up version number. * Wed Sep 10 2003 Elena Zannoni 0.20030710.28 - Fix a core dump with MI. - Add new ChangeLog patch for mi changes. * Thu Sep 04 2003 Elena Zannoni 0.20030710.27 - Change the name of the package to gdb64 in ppc64 case. * Tue Aug 26 2003 Elena Zannoni 0.20030710.26 - Add testcase for separate debug info. * Tue Aug 26 2003 Andrew Cagney 0.20030710.25 - fix i386 on x86-64 TLS - add "base-aug2003" suffix to older x86i386 patch * Tue Aug 26 2003 Andrew Cagney 0.20030710.24 - skip the ppc64 and x86-64 frame redzone. * Fri Aug 22 2003 Elena Zannoni 0.20030710.23 - Relax one testcase in selftest.exp a bit. - Accept different output as well in thread bt (platform dependent). - Enable testsuite run for ia64, ppc, s390 and s390x. They are in reasonably good shape. * Thu Aug 21 2003 Jeff Johnston 0.20030710.22 - Multiple ia64 fixes. - Fix ia64 printing of function pointers. - Fix ia64 prologue examination to ignore predicated insns if we haven't found the return address yet. - Skip dump.exp testcase for ia64 gimp-1.2.5-1 ------------ * Wed Oct 15 2003 Matt Wilson 1:1.2.5-1 - 1.2.5 (#101225) gnome-vfs2-2.4.1-1 ------------------ * Wed Oct 15 2003 Alexander Larsson 2.4.1-1 - Update to 2.4.1, fixes bug #107130 gtk2-2.2.4-5.1 -------------- * Wed Oct 15 2003 Owen Taylor 2.2.4-5.1 - Link gdk-pixbuf-xlib against gdk-pixbuf (#106678) * Fri Oct 03 2003 Owen Taylor 2.2.4-4.0 - Fix 64-bit problem in gtkimcontextxim.c (#106124) perl-5.8.1-92 ------------- * Wed Oct 15 2003 Chip Turner 3:5.8.1-92 - add srand on fork patch from upstream, as well as test case python-2.2.3-7 -------------- * Wed Oct 15 2003 Jeremy Katz 2.2.3-7 - use the simpler heuristic for finding the GNU .mo metadata from python 2.3 (#97796) * Mon Aug 18 2003 Mihai Ibanescu 2.2.3-6 - lib-dynload files are not stripped (bug #97264) * Fri Aug 08 2003 Mihai Ibanescu 2.2.3-5 - Added missing BuildRequires (bug #101950) * Thu Jul 03 2003 Mihai Ibanescu 2.2.3-4 - Rebuilt against newer db4 packages (bug #98539) rawhide-release-20031016-1 -------------------------- redhat-config-date-1.5.23-1 --------------------------- * Wed Oct 15 2003 Brent Fox 1.5.23-1 - UTF8-ify po/timezones/de.po (bug #107033) redhat-config-samba-1.1.4-1 --------------------------- * Wed Oct 15 2003 Brent Fox 1.1.4-1 - clarify error message (bug #105045) * Wed Oct 15 2003 Brent Fox 1.1.3-1 - don't allow whitespace in section headers (bug #106880) redhat-config-xfree86-0.9.12-1 ------------------------------ * Wed Oct 15 2003 Brent Fox 0.9.12-1 - fix bug #106884 for real this time * Tue Oct 14 2003 Brent Fox 0.9.11-1 - package lightrays.png inside redhat-config-xfree86 rhn-applet-2.1.0-1 ------------------ * Wed Oct 15 2003 Daniel Veillard 2.1.0-1 - added support needed for Fedora Core: Yum repositories, multiple sources, and possibly no RHN channel - translation strings update rhpl-0.118-1 ------------ * Wed Oct 15 2003 Jeremy Katz 0.118-1 - translate.py: assume UTF-8 if we can't figure out the encoding of a mofile sylpheed-0.9.7-1 ---------------- * Thu Oct 16 2003 Akira TAGOH 0.9.7-1 - New upstream release. tcltk-8.3.5-93 -------------- * Wed Oct 15 2003 Jens Petersen - 8.3.5-93 - update expect to 5.39.0 (fixes #58317) - drop first hunk of 64bit patch and rename to expect-5.39.0-64bit-82547.patch - expect-5.32.2-weather.patch and expect-5.32.2-expectk.patch no longer needed - update tix url (#101721) [reported by support at internetdiscovery.com] * 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) From pekkas at netcore.fi Thu Oct 16 12:40:12 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 16 Oct 2003 15:40:12 +0300 (EEST) Subject: RPM problem: prereq: not honored in upgrade ordering? In-Reply-To: Message-ID: On Thu, 16 Oct 2003, Pekka Savola wrote: [...] > Btw. I looked at rpm source and it looks like nodeps does not change the > package ordering. You have to use a separate toggle, --noorder, to do > that. So, if you are certain all of your deps are included. nodeps should > not do harm (I would still not use it though). Package upgrade with the 4 > RPMs with --nodeps *seems to* confirm this theory. > > If jbj is listening, it would be nice to get an ACK/NACK on this.. FYI, I discussed this with Jeff, and he said that currently --nodeps implies --noorder for performance reasons. This change has been active for around a year at least, but whether it affects RPM 4.0.4 (used here) was a question mark. In any case, the situation with --nodeps is not better, at least, with Fedora :-) So, I'd even more strongly recommend against using --nodeps because its new implication has quite severe implications with a large set of interdependent packages. But the core problem exists regardless of --nodeps, and I believe the original reordering problem also exists without nodeps (but that would have to be confirmed). Jeff's initial guess about the problem was the way Alternatives requirement is used, as a file requirement (doesn't really work in every case) rather than a package. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nphilipp at redhat.com Thu Oct 16 17:14:18 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 16 Oct 2003 19:14:18 +0200 Subject: Gimp 1.3 packages, was: New extra packages and yum repository In-Reply-To: <20031016113611.0b896376.ms-nospam-0306@arcor.de> References: <1066147414.4511.36.camel@gibraltar.stuttgart.redhat.com> <1066148362.6205.1.camel@mozer.nailed.org> <20031014213758.29a31d6f.ms-nospam-0306@arcor.de> <1066202803.6024.56.camel@wombat.tiptoe.de> <20031015182517.7250d596.ms-nospam-0306@arcor.de> <1066255153.6805.9.camel@wombat.tiptoe.de> <20031016013106.1c76543e.ms-nospam-0306@arcor.de> <1066286879.6355.13.camel@wombat.tiptoe.de> <20031016113611.0b896376.ms-nospam-0306@arcor.de> Message-ID: <1066324457.5921.38.camel@wombat.tiptoe.de> On Thu, 2003-10-16 at 11:36, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 16 Oct 2003 08:48:00 +0200, Nils Philippsen wrote: > > > > > > Some of the locale directories are not owned by glibc-common. > > > > > > > > This is a bug in glibc-common which should not be tried to > > > > fix/circumvent in other packages. > > > > > > What do you suggest as alternative? No_t_ owning such directories would > > > a) leave them behind upon package removal and b) create them with > > > wrong permissions in case of a restrictive umask. > > > > > > As a similar example, Red Hat's "perl" package should own several > > > directories, e.g. vendor install dirs. There's an old bug report about > > > it somewhere in bugzilla. But it doesn't get fixed. > > > > If it's not in Bugzilla, put it in there. If it's in Bugzilla, step on > > people's toes until they react ;-). > > You do know, that would make the reporter look like a nerd. In the > case of Perl, it's even a report from someone at Red Hat. One year old > by now, without any comment from the person it's assigned to: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73970 At least every new version gives ample opportunity to remind maintainers that something is still an issue without getting to obtrusive. I've ticked the ticket to FC/test3. > > Putting this fix in an unrelated > > package is not the right thing to do. > > The only alternative is to publish packages without a work-around, > which makes them look broken due core packages are broken. I can live > with that. But it is a poor decision nevertheless. I can live with unrelated packages owning orphaned directories as well ;-) but the best thing is fixing it in the right package. I fear that if we settle with a workaround that it never gets fixed in these. 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 shahms at shahms.com Thu Oct 16 17:17:56 2003 From: shahms at shahms.com (Shahms E. King) Date: Thu, 16 Oct 2003 10:17:56 -0700 Subject: Yum'ification of the rhn_applet In-Reply-To: <20031015203138.W16905@redhat.com> References: <20031015083550.D16905@redhat.com> <3F8D68AE.3010206@draigBrady.com> <20031015203138.W16905@redhat.com> Message-ID: <1066324676.9416.1.camel@localhost.localdomain> On Wed, 2003-10-15 at 17:31, Daniel Veillard wrote: > On Wed, Oct 15, 2003 at 04:33:02PM +0100, P at draigBrady.com wrote: > > Daniel Veillard wrote: > > > I have just released an updated version of rhn_applet which > > > should work better for the Fedora framework: > > > - handle Yum repositories > > > - handle multiple repositories > > > - does not require RHN registration > > > > > > You can find it at: > > > http://people.redhat.com/~veillard/testing/yum/rhn-applet/2.1.0/ > > > > But does up2date work with yum? > > yes for recent versions. > > > I updated rh9 with the latest up2date from rawhide and rhn-applet from > > above, but up2date seems to hang on the first RPM header with the > > following as my only source? > > > > yum fedora-i386-os > > http://download.fedora.us/fedora/redhat/0.95/i386/yum/os/ > > Hum, I upgraded my fedora core0.95 to rawhide with up2date this morning > without troubles. > > Daniel Yeah, up2date pull from the RedHat rawhide channel, yum is pulling from download.fedora.us and the 0.95 repository has a headers.info but *no actual headers* meaning yum won't work. Do'h to say the least. Been waiting for someone else to notice and just using up2date in the meantime, but it's been a few days now with no change . . . -- --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 alan at redhat.com Thu Oct 16 21:30:36 2003 From: alan at redhat.com (Alan Cox) Date: Thu, 16 Oct 2003 17:30:36 -0400 (EDT) Subject: Yo. In-Reply-To: <200310160133.54539.oden.eriksson@kvikkjokk.net> from "Oden Eriksson" at Hyd 16, 2003 01:33:54 Message-ID: <200310162130.h9GLUaX19702@devserv.devel.redhat.com> > I don't know, I wasn't aware of any patents regarding this. http://www.computerworld.com/managementtopics/ebusiness/story/0,10801,59043,00.html http://www.i-d-n.net/#patents All very messy but I've not followed it since early 2002 to know what happened or if it all died From ckloiber at redhat.com Fri Oct 17 07:34:42 2003 From: ckloiber at redhat.com (Chris Kloiber) Date: Fri, 17 Oct 2003 03:34:42 -0400 Subject: DVD Isos In-Reply-To: <3F8CE482.3030700@koziarski.com> References: <3F8CE482.3030700@koziarski.com> Message-ID: <1066376081.24696.4.camel@localhost.localdomain> On Wed, 2003-10-15 at 15:09, Michael A. Koziarski wrote: > Hey guys, > > I see in the FAQ (http://fedora.redhat.com/about/faq/) that fedora > intends to provide DVD ISOs. Are these available? > > I have a lovely new DVD-Writer and I'm more than happy to help test. > > Cheers > > Koz Roll your own DVD isos using my script. Get the latest CD isos into one directory, then run: # mkdvdiso.sh /path/to/the/cd/isos /location/and/name/of/dvd.iso # growisofs -Z /dev/scd0=/location/and/name/of/dvd.iso Where is my script? ftp://people.redhat.com/ckloiber/mkdvdiso.sh -- Chris Kloiber Red Hat, Inc. From paul at gear.dyndns.org Fri Oct 17 07:37:57 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Fri, 17 Oct 2003 17:37:57 +1000 Subject: Yo. In-Reply-To: <20031014230306.11777f4f.ms-nospam-0306@arcor.de> References: <200310142119.07763.oden.eriksson@kvikkjokk.net> <1066159507.4489.13.camel@banff.drgutah.com> <200310142232.24649.oden.eriksson@kvikkjokk.net> <20031014230306.11777f4f.ms-nospam-0306@arcor.de> Message-ID: <3F8F9C55.10704@gear.dyndns.org> Michael Schwendt wrote: > ... > >>Am I wrong? > > Yes. > >>Is this a hostile place? > > No. > >>Are we picking on "new comers" here? > > No. Doesn't Michael just have a way with words? :-) -- Paul http://paulgear.webhop.net A: Because we read from top to bottom, left to right. Q: Why should i start my 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 P at draigBrady.com Fri Oct 17 08:41:00 2003 From: P at draigBrady.com (P at draigBrady.com) Date: Fri, 17 Oct 2003 09:41:00 +0100 Subject: Yum'ification of the rhn_applet In-Reply-To: <1066324676.9416.1.camel@localhost.localdomain> References: <20031015083550.D16905@redhat.com> <3F8D68AE.3010206@draigBrady.com> <20031015203138.W16905@redhat.com> <1066324676.9416.1.camel@localhost.localdomain> Message-ID: <3F8FAB1C.1050909@draigBrady.com> Shahms E. King wrote: > Yeah, up2date pull from the RedHat rawhide channel, yum is pulling from > download.fedora.us and the 0.95 repository has a headers.info but *no > actual headers* meaning yum won't work. Do'h to say the least. Been > waiting for someone else to notice and just using up2date in the > meantime, but it's been a few days now with no change . . . Ah, OK thanks. I looked at the network packets and it does get a 404 error. up2date should do something other than hang there forever though. P?draig. From g.magnini at tiscali.it Fri Oct 17 08:49:58 2003 From: g.magnini at tiscali.it (Giacomo Magnini) Date: Fri, 17 Oct 2003 10:49:58 +0200 Subject: Translations In-Reply-To: <20031015223355.D20266@devserv.devel.redhat.com> References: <3F8D4CB6.20406@tiscali.it> <20031015223355.D20266@devserv.devel.redhat.com> Message-ID: <3F8FAD36.1010701@tiscali.it> Bill Nottingham wrote: >>Is someone already working on this? >> >> >There are currently 4 registered Italian translators. > > > >>Should I look anywhere else to gather more informations? >> >> >http://i18n.redhat.com/ > > Thanks for the answers, now i'm stuck in the other ML as well, but that's an improvement anyway! :) Cheers, Giacomo. From buildsys at porkchop.devel.redhat.com Fri Oct 17 10:15:21 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Fri, 17 Oct 2003 06:15:21 -0400 Subject: rawhide report: 20031017 changes Message-ID: <200310171015.h9HAFLV17067@porkchop.devel.redhat.com> Updated Packages: anaconda-9.0.96-0.20031016192606 -------------------------------- * Thu Oct 16 2003 Anaconda team - built new version from CVS * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 * Mon Sep 09 2002 Jeremy Katz - can't buildrequire dietlibc and kernel-pcmcia-cs since they don't always exist * Wed Aug 21 2002 Jeremy Katz - added URL * Thu May 23 2002 Jeremy Katz - add require and buildrequire on rhpl * Tue Apr 02 2002 Michael Fulbright - added some more docs * Fri Feb 22 2002 Jeremy Katz - buildrequire kernel-pcmcia-cs as we've sucked the libs the loader needs to there now * Thu Feb 07 2002 Michael Fulbright - goodbye reconfig * Thu Jan 31 2002 Jeremy Katz - update the BuildRequires a bit * Fri Jan 04 2002 Jeremy Katz - ddcprobe is now done from kudzu * Wed Jul 18 2001 Jeremy Katz - own /usr/lib/anaconda and /usr/share/anaconda * Fri Jan 12 2001 Matt Wilson - sync text with specspo * Thu Aug 10 2000 Matt Wilson - build on alpha again now that I've fixed the stubs * Wed Aug 09 2000 Michael Fulbright - new build * Fri Aug 04 2000 Florian La Roche - allow also subvendorid and subdeviceid in trimpcitable * Fri Jul 14 2000 Matt Wilson - moved init script for reconfig mode to /etc/init.d/reconfig - move the initscript back to /etc/rc.d/init.d - Prereq: /etc/init.d * Thu Feb 03 2000 Michael Fulbright - strip files - add lang-table to file list * Wed Jan 05 2000 Michael Fulbright - added requirement for rpm-python * Mon Dec 06 1999 Michael Fulbright - rename to 'anaconda' instead of 'anaconda-reconfig' * Fri Dec 03 1999 Michael Fulbright - remove ddcprobe since we don't do X configuration in reconfig now * Tue Nov 30 1999 Michael Fulbright - first try at packaging reconfiguration tool db4-4.1.25-12 ------------- * Wed Oct 15 2003 Nalin Dahyabhai - build both with and without support for shared mutex locks, which require NPTL - make behavior wrt where we put libdb the same for all OSs - revert changes making tcl optional - nesting %if tcl and %ifarch nptl doesn't work - fix dangling HREFs in utility docs (pointed to main docs dir, while they're actually in the -utils docs dir) - run ldconfig when installing/removing the -utils subpackage, as it contains shared libraries dbus-0.13-6 ----------- * Thu Oct 16 2003 Havoc Pennington 0.13-6 - hmm, dbus doesn't support uids in the config file. fix. * Thu Oct 16 2003 Havoc Pennington 0.13-5 - put uid instead of username in the config file, to keep things working with name change * Thu Oct 16 2003 Havoc Pennington 0.13-4 - make subpackages require the specific release, not just version, of base package * Thu Oct 16 2003 Havoc Pennington 0.13-3 - change system user "messagebus" -> "dbus" to be under 8 chars fetchmail-6.2.0-8 ----------------- * Fri Oct 10 2003 Nalin Dahyabhai 6.2.0-8 - add patch to not truncate headers which have been munged to include a hostname where one didn't exist before (CAN-2003-0792), backport from fix for 6.2.4 included in 6.2.5 * Thu Oct 09 2003 Nalin Dahyabhai - add patch from Markus Friedl to fix possible buffer underrun (CAN-2003-0790) gnome-mime-data-2.4.0-2 ----------------------- * Fri Oct 17 2003 Alexander Larsson 2.4.0-2 - Add startup notification support to OpenOffice.org hwdata-0.100-1 -------------- * Thu Oct 16 2003 Brent Fox 0.100-1 - add entry for Sun (made by Samsung) monitor (bug #107128) kernel-2.4.22-1.2096.nptl ------------------------- * Tue Oct 14 2003 Dave Jones - More merges from 2.4.23pre - Update ACPI CA to 20031002 - Various network driver updates. kinput2-v3.1-11 --------------- * Thu Oct 16 2003 Akira TAGOH v3.1-11 - kinput2-v3.1-ia64.patch: updated to fix FreeWnn not working on ia64. openldap-2.1.22-7 ----------------- * Thu Oct 16 2003 Nalin Dahyabhai 2.1.22-7 - force bundled libdb to not use O_DIRECT by making it forget that we have it * Wed Oct 15 2003 Nalin Dahyabhai - build bundled libdb for slapd dynamically to make the package smaller, among other things - on tls-capable arches, build libdb both with and without shared posix mutexes, otherwise just without - disable posix mutexes unconditionally for db 4.0, which shouldn't need them for the migration cases where it's used - update to MigrationTools 45 rawhide-release-20031017-1 -------------------------- redhat-config-securitylevel-1.2.11-1 ------------------------------------ * Thu Oct 16 2003 Brent Fox 1.2.11-1 - require iptables >=1.2.8 (bug #104777) redhat-config-xfree86-0.9.13-1 ------------------------------ * Thu Oct 16 2003 Brent Fox 0.9.13-1 - allow dualhead to be disabled (bug #107261) rhgb-0.10.5-3 ------------- * Thu Oct 16 2003 Jonathan Blandford 0.10.5-2 - Don't build on s390, s390x and ppc64 as they don't have libxf86config. * Thu Oct 16 2003 Jonathan Blandford 0.10.5-1 - add xkb support * Tue Oct 07 2003 Jonathan Blandford 0.10.4.-1s - new splash code * Wed Jul 09 2003 Bill Nottingham 0.9.4-1 - fix checking for command-line arguments, again * Mon Jul 07 2003 Bill Nottingham 0.9.3-1 - fix checking for command-line arguments * Fri Oct 11 2002 Jonathan Blandford - Initial build. rhn-applet-2.1.1-1 ------------------ * Thu Oct 16 2003 Daniel Veillard 2.1.1-1 - added proxy support for yum repositories, tested https too - add repositories error reporting - fixed spec for build requirements #102814 - translation strings update rhpl-0.120-1 ------------ * Thu Oct 16 2003 Brent Fox 0.120-1 - mouse.py - add two entries for optical mice * Thu Oct 16 2003 Jeremy Katz 0.119-1 - keyboard_models.py: fix greek keyboard layout (#100773) symlinks-1.2-20 --------------- * Thu Oct 16 2003 Florian La Roche - add patch from #89655 unixODBC-2.2.5-9 ---------------- * Thu Oct 16 2003 Fernando Nasser 2.2.5-9 - Add comments to the /etc/odbcinst.ini file regarding the proper setup for MySQL and the origin of each library needed. From gemi at bluewin.ch Fri Oct 17 12:05:39 2003 From: gemi at bluewin.ch (gemi at bluewin.ch) Date: Fri, 17 Oct 2003 14:05:39 +0200 Subject: Mime types, icons and .desktop files Message-ID: <3F710DB5000BB18C@mssazhb-int.msg.bluewin.ch> The mime-info database misses a lot of mime types. Also most third-party applications don't come with .desktop files and their corresponding icons (For example I use Mathematica and Maple and had to create .desktop files and mime-types myself). I propose therefore that there be an entry form on Fedora home page where people can submit this information. There could also be a program like appfinder, that looks if there are applications installed that it knows about and then installs the corresponding .desktop files into /usr/share/applications Regards, G?rard From kaboom at gatech.edu Fri Oct 17 14:20:27 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Fri, 17 Oct 2003 10:20:27 -0400 (EDT) Subject: rsync and rawhide Message-ID: Now that the fedora process is opening up development a bit more, I suspect more people are frequently downloading rawhide. Has there been any thought about making it available usably over rsync? The current drawback to using rsync is that what's posted to rawhide are packages, and package names change so rsync can't find the preexisting similar bits. Consider, just to pick one example, unixODBC. Yesterday, unixODBC-2.2.5-8 was pushed to rawhide. Today, unixODBC-2.2.5-9 was pushed. The only difference between the two is that in -9 Fernando tweaked ~4 lines of text in /etc/odbcinst.ini, yet to get that I have to download the whole thing again b/c rsync sees them as different files and therefore doesn't compare them.... One way to make rsync work with rawhide would be to autogenerate isos (not full working isos which can be booted off of and such, just the RPMs) on a daily basis, then to use the hardlinks script that the RH mirrors often use to explode the contents off of loopback-mounted isos. People could then just rsync ftp.redhat.com/pub/redhat/linux/rawhide/iso/daily.iso and save some bandwidth on both sides.... Thoughts? Is this feasible on the RH side? Of interest to anyone else on the client side? later, chris From oden.eriksson at kvikkjokk.net Fri Oct 17 14:29:09 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Fri, 17 Oct 2003 16:29:09 +0200 Subject: rsync and rawhide In-Reply-To: References: Message-ID: <200310171629.09963.oden.eriksson@kvikkjokk.net> fredagen den 17 oktober 2003 16.20 skrev Chris Ricker: [...] > The current drawback to using rsync is that what's posted to rawhide are > packages, and package names change so rsync can't find the preexisting > similar bits. Consider, just to pick one example, unixODBC. Yesterday, [...] http://members.optusnet.com.au/ronst/ Cheers. From elanthis at awesomeplay.com Fri Oct 17 14:30:40 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 17 Oct 2003 10:30:40 -0400 Subject: Mime types, icons and .desktop files In-Reply-To: <3F710DB5000BB18C@mssazhb-int.msg.bluewin.ch> References: <3F710DB5000BB18C@mssazhb-int.msg.bluewin.ch> Message-ID: <1066401040.20347.4.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2003-10-17 at 08:05, gemi at bluewin.ch wrote: > The mime-info database misses a lot of mime types. > Also most third-party applications don't come > with .desktop files and their corresponding > icons (For example I use Mathematica and Maple > and had to create .desktop files and mime-types > myself). > I propose therefore that there be an entry > form on Fedora home page where people can > submit this information. I would hope users first try getting upstream to fix these problems. .desktop files are now standard across all desktop environments, so upstream authors only ever need to write one. MIME types are also standard (or int he process of being standardized, anyways) and are easy to "auto-plug" in. Yes, *if* the upstream folks are dinks and won't fix it, distro hacks would be necessary, but 'twould be nice to fix the problem at the 'source' if possible. ;-) > There could also be a program like appfinder, > that looks if there are applications installed > that it knows about and then installs the > corresponding .desktop files into > /usr/share/applications > > Regards, > G??rard > > > -- > 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 notting at redhat.com Fri Oct 17 14:54:50 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Oct 2003 10:54:50 -0400 Subject: rsync and rawhide In-Reply-To: ; from kaboom@gatech.edu on Fri, Oct 17, 2003 at 10:20:27AM -0400 References: Message-ID: <20031017105450.E4974@devserv.devel.redhat.com> Chris Ricker (kaboom at gatech.edu) said: > Now that the fedora process is opening up development a bit more, I suspect > more people are frequently downloading rawhide. Has there been any thought > about making it available usably over rsync? Some of the mirrors that mirror it may make it available over rsync. Bill From jeremyp at pobox.com Fri Oct 17 15:38:28 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: Fri, 17 Oct 2003 11:38:28 -0400 Subject: rsync and rawhide In-Reply-To: <20031017105450.E4974@devserv.devel.redhat.com> References: <20031017105450.E4974@devserv.devel.redhat.com> Message-ID: <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> On Fri, 2003-10-17 at 10:54, Bill Nottingham wrote: > Chris Ricker (kaboom at gatech.edu) said: > > Now that the fedora process is opening up development a bit more, I suspect > > more people are frequently downloading rawhide. Has there been any thought > > about making it available usably over rsync? > > Some of the mirrors that mirror it may make it available over rsync. > Bill, I think you snipped the most important part of Chris's message. While the current repository is indeed available over rsync at various mirrors, it is not very useable. This is because the filenames change for each new RPM posted, so rsync downloads a completely new file. If the rsync tree was built into ISOs, or some other larger archive files that could be loopback-mounted, it would be a better situation for rsync. It can then check for differences in the old and new versions and only download the differences. --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 ted at cypress.com Fri Oct 17 15:55:41 2003 From: ted at cypress.com (Thomas Dodd) Date: Fri, 17 Oct 2003 10:55:41 -0500 Subject: [RFC] Better font filetype and metadata file detection for xfs initscript In-Reply-To: References: <20031009041129.69736.qmail@web80004.mail.yahoo.com> <1065685496.1665.7.camel@ulysse.olympe.o2t> <1065696476.3713.3.camel@ulysse.olympe.o2t> <3F86CBD0.5090209@cypress.com> <3F8C1866.4040503@cypress.com> Message-ID: <3F9010FD.3020507@cypress.com> Mike A. Harris wrote: > configuration tools however, so this is very theoretical. Yes, ment to be. But you as maintainer of the packages have the right to remove cruft. Announce it's going away, and that "this" is the new way. If somone doesn't fix their stuff, it's _their_ fault, not yours. Put you foot down. :) I'd rather you fix this stuff, and piss people off, than be nice, and continue with the legacy crap. >>>2) In many cases, people use them simply because they don't know >> >>Those are the tools mentioned in the documentation for XF86 though. > > People who report bugs in specific XFree86 documentation > referencing the tools which we have disabled, I'd be glad to fix > with future documentation updates. It'd even be a useful idea Next time I see one, I'll file a bug then. > for someone to file a "container" bug which says something like > "Update XFree86 documentation to refer to redhat-config-xfree86 > everywhere instead of the XFree86 supplied tools." Then when That sounds like a job for the documentation people. -Thomas From notting at redhat.com Fri Oct 17 15:56:05 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Oct 2003 11:56:05 -0400 Subject: rsync and rawhide In-Reply-To: <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us>; from jeremyp@pobox.com on Fri, Oct 17, 2003 at 11:38:28AM -0400 References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> Message-ID: <20031017115605.B18024@devserv.devel.redhat.com> Jeremy Portzer (jeremyp at pobox.com) said: > If the rsync tree was built into ISOs, or some other larger archive > files that could be loopback-mounted, it would be a better situation for > rsync. It can then check for differences in the old and new versions > and only download the differences. Building rawhide as ISOs would a) complicate the build process b) make it more of a hassle to grab a single fix. Adding ISOs in *addition* to the files would lead to a rather dramatic increase in disk space required. Bill From oden.eriksson at kvikkjokk.net Fri Oct 17 15:57:54 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Fri, 17 Oct 2003 17:57:54 +0200 Subject: rsync and rawhide In-Reply-To: <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> Message-ID: <200310171757.54705.oden.eriksson@kvikkjokk.net> fredagen den 17 oktober 2003 17.38 skrev Jeremy Portzer: > On Fri, 2003-10-17 at 10:54, Bill Nottingham wrote: > > Chris Ricker (kaboom at gatech.edu) said: > > > Now that the fedora process is opening up development a bit more, I > > > suspect more people are frequently downloading rawhide. Has there been > > > any thought about making it available usably over rsync? > > > > Some of the mirrors that mirror it may make it available over rsync. > > Bill, > I think you snipped the most important part of Chris's message. While > the current repository is indeed available over rsync at various > mirrors, it is not very useable. This is because the filenames change > for each new RPM posted, so rsync downloads a completely new file. That is why I posted this link: http://members.optusnet.com.au/ronst/ Read about it, adopt it. From kevin-redhat-devel at scrye.com Fri Oct 17 15:59:32 2003 From: kevin-redhat-devel at scrye.com (Kevin Fenzi) Date: Fri, 17 Oct 2003 09:59:32 -0600 Subject: rsync and rawhide References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> Message-ID: <20031017155935.BB27EF7D61@voldemort.scrye.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jeremy" == Jeremy Portzer writes: Jeremy> On Fri, 2003-10-17 at 10:54, Bill Nottingham wrote: >> Chris Ricker (kaboom at gatech.edu) said: > Now that the fedora >> process is opening up development a bit more, I suspect > more >> people are frequently downloading rawhide. Has there been any >> thought > about making it available usably over rsync? >> >> Some of the mirrors that mirror it may make it available over >> rsync. >> Jeremy> Bill, I think you snipped the most important part of Chris's Jeremy> message. While the current repository is indeed available Jeremy> over rsync at various mirrors, it is not very useable. This Jeremy> is because the filenames change for each new RPM posted, so Jeremy> rsync downloads a completely new file. Jeremy> If the rsync tree was built into ISOs, or some other larger Jeremy> archive files that could be loopback-mounted, it would be a Jeremy> better situation for rsync. It can then check for differences Jeremy> in the old and new versions and only download the differences. Someone the other day was telling me that with updates for SuSe you could pull down all the new rpms, or just pull down changes between the updated rpm and your current version... Ah, there they are... called 'patch rpms'. From: http://www.suse.com/us/private/download/updates/90_i386.html "New: Patch RPMs As of now we are offering so called Patch RPM packages. A Patch RPM updates an already installed RPM. It only contains files which have changed - therefore it is (much) smaller than the complete RPM package. Prerequisite for installation is an already installed basic RPM. The packages included on the SUSE LINUX 9.0-CDs/DVD are considered as basic RPMs. If you want to update an already installed package, please download the smaller Patch RPM package." Something like this would be very handy for keeping up with rawhide, saving redhat bandwith, and making more people use it as it became smaller/faster/easer to do. Anyone know how they do those? Would that be hard to implement? kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQE/kBHn3imCezTjY0ERAtcXAJ9snjqQHS48BTUiZY8qkfB9tFebFQCgiK6m 5h4LenaqeC96VblKWclmebk= =9u7f -----END PGP SIGNATURE----- From edwardam at interlix.com Fri Oct 17 16:31:56 2003 From: edwardam at interlix.com (Edward Muller) Date: Fri, 17 Oct 2003 11:31:56 -0500 Subject: rsync and rawhide In-Reply-To: References: Message-ID: <1066408316.8443.1.camel@palin> Perhaps a script could be created that would get a listing of the existing contents of rawhide via ftp, then if any newer packages are found the old ones are renamed to the new versions and then rsynced. Dunno if this would work, just speculating. On Fri, 2003-10-17 at 09:20, Chris Ricker wrote: > Now that the fedora process is opening up development a bit more, I suspect > more people are frequently downloading rawhide. Has there been any thought > about making it available usably over rsync? > > The current drawback to using rsync is that what's posted to rawhide are > packages, and package names change so rsync can't find the preexisting > similar bits. Consider, just to pick one example, unixODBC. Yesterday, > unixODBC-2.2.5-8 was pushed to rawhide. Today, unixODBC-2.2.5-9 was pushed. > The only difference between the two is that in -9 Fernando tweaked ~4 lines > of text in /etc/odbcinst.ini, yet to get that I have to download the whole > thing again b/c rsync sees them as different files and therefore doesn't > compare them.... > > One way to make rsync work with rawhide would be to autogenerate isos (not > full working isos which can be booted off of and such, just the RPMs) on a > daily basis, then to use the hardlinks script that the RH mirrors often use > to explode the contents off of loopback-mounted isos. People could then just > rsync ftp.redhat.com/pub/redhat/linux/rawhide/iso/daily.iso and save some > bandwidth on both sides.... > > Thoughts? Is this feasible on the RH side? Of interest to anyone else on the > client side? > > later, > chris > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Edward Muller - http://www.interlix.com - "Open Source Specialists" Dedicated Zope Hosting - Web Hosting - Open Source Consulting Network & PC Service & Support - Custom Programming Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572 Jabber: edwardam at jabber.interlix.com - AIM: edwardam453 - ICQ: 287033 From Nicolas.Mailhot at laPoste.net Fri Oct 17 16:35:47 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 17 Oct 2003 18:35:47 +0200 Subject: rsync and rawhide In-Reply-To: <20031017155935.BB27EF7D61@voldemort.scrye.com> References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017155935.BB27EF7D61@voldemort.scrye.com> Message-ID: <1066408546.11165.4.camel@ulysse.olympe.o2t> Le ven 17/10/2003 ? 17:59, Kevin Fenzi a ?crit : > Ah, there they are... called 'patch rpms'. > From: > > http://www.suse.com/us/private/download/updates/90_i386.html > > "New: Patch RPMs [...] > Something like this would be very handy for keeping up with rawhide, > saving redhat bandwith, and making more people use it as it became > smaller/faster/easer to do. As someone who's been using rawhide for years I'd hate it if I had to track all those small package bits. The joy of an rpm system is that package units are self-contained (not some sort of patch layer sedimentation impossible to process by a human being). Whatever delta comparison goes on should be done at the download protocol layer (rsync...) not at the package level. 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 mark at mark.mielke.cc Fri Oct 17 16:42:05 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Fri, 17 Oct 2003 12:42:05 -0400 Subject: rsync and rawhide In-Reply-To: References: Message-ID: <20031017164205.GA7303@mark.mielke.cc> On Fri, Oct 17, 2003 at 10:20:27AM -0400, Chris Ricker wrote: > Now that the fedora process is opening up development a bit more, I suspect > more people are frequently downloading rawhide. Has there been any thought > about making it available usably over rsync? I would prefer to use rsync to update my rpm set with rawhide simply because it communicates the information more efficiently. Lately using 'lftp mirror' I've noticed that packages sometimes download on top of themselves, perhaps just because the timestamp of the file has changed? Even if the RPM had changed (signed after the fact?), rsync would do a better job than ftp. > The current drawback to using rsync is that what's posted to rawhide are > packages, and package names change so rsync can't find the preexisting > similar bits. Consider, just to pick one example, unixODBC. Yesterday, > unixODBC-2.2.5-8 was pushed to rawhide. Today, unixODBC-2.2.5-9 was pushed. > The only difference between the two is that in -9 Fernando tweaked ~4 lines > of text in /etc/odbcinst.ini, yet to get that I have to download the whole > thing again b/c rsync sees them as different files and therefore doesn't > compare them.... Note, though, that just because the change was only 4 lines of text, does not mean that the whole RPM won't need to be downloaded. I was under the impression that rsync communicates block checksums back and forth. How would it handle the entire file from offset 4096 being shifted 512 bytes longer or shorter? Would it not re-transfer the whole file? Also, I think one could argue that rsync should have an option to deal with this situation - file content not significantly changing, but file name changing. At *least* for files in the same directory. > One way to make rsync work with rawhide would be to autogenerate isos (not > full working isos which can be booted off of and such, just the RPMs) on a > daily basis, then to use the hardlinks script that the RH mirrors often use > to explode the contents off of loopback-mounted isos. People could then just > rsync ftp.redhat.com/pub/redhat/linux/rawhide/iso/daily.iso and save some > bandwidth on both sides.... Again, I suspect this has the same issues as I describe in my previous paragraph, although the effect may be reduced -- which isn't to say it would be useless, but, I wonder why rsync shouldn't be able to do a better job with the raw data, than in a pre-packed iso form. mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From gemi at bluewin.ch Fri Oct 17 18:22:22 2003 From: gemi at bluewin.ch (gemi at bluewin.ch) Date: Fri, 17 Oct 2003 20:22:22 +0200 Subject: Mime types, icons and .desktop files Message-ID: <3F710DB5000BE709@mssazhb-int.msg.bluewin.ch> Yes, of course the developers should include the information, but especially commercial providers don't do this. I want my distribution to provide .desktop files and icons for most common commercial applications. I created the desktop files myself and I would like to submit them somewhere. Mime-types for Mathematica notebooks should also be included in gnome-vfs.* or whatever. From elanthis at awesomeplay.com Fri Oct 17 18:44:11 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 17 Oct 2003 14:44:11 -0400 Subject: Mime types, icons and .desktop files In-Reply-To: <3F710DB5000BE709@mssazhb-int.msg.bluewin.ch> References: <3F710DB5000BE709@mssazhb-int.msg.bluewin.ch> Message-ID: <1066416251.20347.27.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2003-10-17 at 14:22, gemi at bluewin.ch wrote: > Yes, of course the developers should include the information, but especially > commercial providers don't do this. I want my distribution to provide .desktop > files and icons for most common commercial applications. I created the desktop > files myself and I would like to submit them somewhere. Mime-types for Mathematica > notebooks should also be included in gnome-vfs.* or whatever. Point understood. But again, have you actually told the commercial vendor about not having a .desktop file? Perhaps if a user or two asked them for it, they'd provide it. Certainly, better desktop integration can only help sales. Attack the problem at the source, and only after that fails should the distros try hacking around it. (In hopes of avoiding the brain-dead yammering that seems common from certain people because they only read one sentence of a list post and carry on a 10 page rant based on that alone, I'll again clarify that I'm *not* saying to never provide pre-made desktop entries and such, I'm only saying to try to get it done upstream first. Which is, by the way, one of the stated goals of the Fedora project.) There's also a couple possible issues with Fedora doing this at all. For one, Fedora being all Free Software, it could be taken the wrong way if commercial software is "hacked in." Look at how the FSF won't even link to Debian because they contain an official non-free archive, despite the fact their main OS is all Free Software. A kind of, "if we're all about Free Software, why go out of our way to support non-Free stuff made by vendors who can't just write their own .desktop file?" Also, there could be legal repercussions in using a commercial application's name and logo/icon without installing the software. IANAL tho. If the above problems are indeed a blocker, and there are a good number of vendors who refuse to "fix" their app to include proper desktop integration, it could certainly be possible to make a "broken-commercial-app-desktop-stuff" package in some non-US repository or another to provide the desktop entries and MIME data. > > > -- > 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 jaap_haitsma at zonnet.nl Fri Oct 17 19:29:37 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Fri, 17 Oct 2003 21:29:37 +0200 Subject: Question about kernel updates In-Reply-To: <200310171015.h9HAFLV17067@porkchop.devel.redhat.com> References: <200310171015.h9HAFLV17067@porkchop.devel.redhat.com> Message-ID: <3F904321.5000503@zonnet.nl> I saw this changelog in the rawhide build file of today. > > kernel-2.4.22-1.2096.nptl > ------------------------- > * Tue Oct 14 2003 Dave Jones > > - More merges from 2.4.23pre > Maybe a stupid question, but I'm just curious: why does RedHat (and also other distro providers) do this? Why don't they just ship the official 2.4.22 kernel and just wait until the 2.4.23 kernel gets released? It's probably due to the fact that the RedHat Linux kernel is a modified version (a fork) of the official kernel. But is this forking/merging worth the effort? It takes quite some time to do all this and also there is a possibility to introduce extra bugs. Wouldn't it be better for RedHat if RedHat just sends the patches to Linus and company, and just accept the fact that they maybe don't accepted? Thanks Jaap From elanthis at awesomeplay.com Fri Oct 17 19:38:15 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 17 Oct 2003 15:38:15 -0400 Subject: Question about kernel updates In-Reply-To: <3F904321.5000503@zonnet.nl> References: <200310171015.h9HAFLV17067@porkchop.devel.redhat.com> <3F904321.5000503@zonnet.nl> Message-ID: <1066419494.20347.60.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2003-10-17 at 15:29, Jaap A. Haitsma wrote: > I saw this changelog in the rawhide build file of today. > > > > > kernel-2.4.22-1.2096.nptl > > ------------------------- > > * Tue Oct 14 2003 Dave Jones > > > > - More merges from 2.4.23pre > > > > Maybe a stupid question, but I'm just curious: why does RedHat (and also > other distro providers) do this? Why don't they just ship the official > 2.4.22 kernel and just wait until the 2.4.23 kernel gets released? > It's probably due to the fact that the RedHat Linux kernel is a modified > version (a fork) of the official kernel. But is this forking/merging > worth the effort? It takes quite some time to do all this and also there > is a possibility to introduce extra bugs. > > Wouldn't it be better for RedHat if RedHat just sends the patches to > Linus and company, and just accept the fact that they maybe don't accepted? They're using accepted patches - that what merges from 2.4.23pre *are*. Red Hat also has some talented kernel hackers on board that develop their own patches to fill specific needs. Red hat and other distros provides patched kernels because, simply, stock kernels aren't good enough. They aren't released quick enough for the feature addition/bug-fixes a distro needs, they don't often have the features the distro wants to provide, etc. If you read the kernel list, you'll even notice Linus and others rather encourage distro customization versus trying to get everything in the main line kernel. ;-) > > Thanks > > Jaap > > > -- > 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 notting at redhat.com Fri Oct 17 20:06:21 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Oct 2003 16:06:21 -0400 Subject: rsync and rawhide In-Reply-To: <1066408316.8443.1.camel@palin>; from edwardam@interlix.com on Fri, Oct 17, 2003 at 11:31:56AM -0500 References: <1066408316.8443.1.camel@palin> Message-ID: <20031017160621.A27469@devserv.devel.redhat.com> Edward Muller (edwardam at interlix.com) said: > Perhaps a script could be created that would get a listing of the > existing contents of rawhide via ftp, then if any newer packages are > found the old ones are renamed to the new versions and then rsynced. > > Dunno if this would work, just speculating. It 'works', but it actually does not help that much, due to compressed payloads and other fun. Bill From mvd at mylinux.com.ua Fri Oct 17 20:12:26 2003 From: mvd at mylinux.com.ua (Maxim Dzumanenko) Date: Fri, 17 Oct 2003 23:12:26 +0300 Subject: Translations In-Reply-To: <20031015223355.D20266@devserv.devel.redhat.com> References: <3F8D4CB6.20406@tiscali.it> <20031015223355.D20266@devserv.devel.redhat.com> Message-ID: <1066421546.2851.11.camel@wind> ???, 2003-10-16 ? 05:33, Bill Nottingham ???????: > Giacomo Magnini (g.magnini at tiscali.it) said: > > I'm new to the list, and I wish to work on translating Fedora packages > > in my own language (Italian). > > Is someone already working on this? > > There are currently 4 registered Italian translators. > > > Should I look anywhere else to gather more informations? > > http://i18n.redhat.com/ > > Bill How about Ukrainian? As far as I know there are no Ukrainan translators. At least there are no Ukrainian translations in CVS. I have Ukrainian translations for most redhat-config-* packages but I need CVS access to commit it. I have already sent account request at http://i18n.redhat.com/cgi-bin/i18n-signup on 11 Sep 2003, but I've got only AutoReply message since then. What do I need to do to bring translations in CVS? -- Maxim Dzumanenko myLinux -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: ?? ??????? ??????????????????????? ????????? ???????? ???????? URL: From davej at redhat.com Fri Oct 17 20:16:44 2003 From: davej at redhat.com (Dave Jones) Date: Fri, 17 Oct 2003 21:16:44 +0100 Subject: Question about kernel updates In-Reply-To: <3F904321.5000503@zonnet.nl> References: <200310171015.h9HAFLV17067@porkchop.devel.redhat.com> <3F904321.5000503@zonnet.nl> Message-ID: <20031017201644.GA29602@redhat.com> On Fri, Oct 17, 2003 at 09:29:37PM +0200, Jaap A. Haitsma wrote: > Maybe a stupid question, but I'm just curious: why does RedHat (and also > other distro providers) do this? Why don't they just ship the official > 2.4.22 kernel and just wait until the 2.4.23 kernel gets released? Because theres no guarantee 2.4.23 will be out any time soon. It could be six months off for all we know. There are patches going into the pre's that fix known problems, so merging the 'obvious fixes' is something that's always happened. The riskier bits have been held off. For example, the VM updates that are currently going into 2.4.23pre which some early-adopters are noting problems with. > It's probably due to the fact that the RedHat Linux kernel is a modified > version (a fork) of the official kernel. But is this forking/merging > worth the effort? It takes quite some time to do all this and also there > is a possibility to introduce extra bugs. When there are known fixes in the pre's, just ignoring them and shipping a product without because the next stable kernel hadn't been released doesn't sound too useful. I wish it was this easy. You're right that its a lot of effort. It's a full time job tracking 2.4, judging whether something is needed or not in the RH kernel, merging, adapting (due to NPTL and other largescale changes), and testing. > Wouldn't it be better for RedHat if RedHat just sends the patches to > Linus and company, and just accept the fact that they maybe don't accepted? A majority of whats been merged in the last few weeks are patches that already have been accepted upstream. Dave -- Dave Jones http://www.codemonkey.org.uk From notting at redhat.com Fri Oct 17 20:52:05 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Oct 2003 16:52:05 -0400 Subject: Translations In-Reply-To: <1066421546.2851.11.camel@wind>; from mvd@mylinux.com.ua on Fri, Oct 17, 2003 at 11:12:26PM +0300 References: <3F8D4CB6.20406@tiscali.it> <20031015223355.D20266@devserv.devel.redhat.com> <1066421546.2851.11.camel@wind> Message-ID: <20031017165205.A19903@devserv.devel.redhat.com> Maxim Dzumanenko (mvd at mylinux.com.ua) said: > How about Ukrainian? > As far as I know there are no Ukrainan translators. > At least there are no Ukrainian translations in CVS. > I have Ukrainian translations for most redhat-config-* packages but I > need CVS access to commit it. > I have already sent account request at > http://i18n.redhat.com/cgi-bin/i18n-signup on 11 Sep 2003, but I've got > only AutoReply message since then. There were a few accounts that were created without a reply sent (local screwup). Yours appears to be one of them. Fire away. :) Bill From jaap_haitsma at zonnet.nl Fri Oct 17 20:52:12 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Fri, 17 Oct 2003 22:52:12 +0200 Subject: Question about kernel updates In-Reply-To: <20031017201644.GA29602@redhat.com> References: <200310171015.h9HAFLV17067@porkchop.devel.redhat.com> <3F904321.5000503@zonnet.nl> <20031017201644.GA29602@redhat.com> Message-ID: <3F90567C.8020006@zonnet.nl> Thanks Sean and Dave Learned something again today Jaap Dave Jones wrote: > On Fri, Oct 17, 2003 at 09:29:37PM +0200, Jaap A. Haitsma wrote: > > > Maybe a stupid question, but I'm just curious: why does RedHat (and also > > other distro providers) do this? Why don't they just ship the official > > 2.4.22 kernel and just wait until the 2.4.23 kernel gets released? > > Because theres no guarantee 2.4.23 will be out any time soon. > It could be six months off for all we know. There are patches going > into the pre's that fix known problems, so merging the 'obvious fixes' > is something that's always happened. The riskier bits have been held > off. For example, the VM updates that are currently going into 2.4.23pre > which some early-adopters are noting problems with. > > > It's probably due to the fact that the RedHat Linux kernel is a modified > > version (a fork) of the official kernel. But is this forking/merging > > worth the effort? It takes quite some time to do all this and also there > > is a possibility to introduce extra bugs. > > When there are known fixes in the pre's, just ignoring them and shipping > a product without because the next stable kernel hadn't been released > doesn't sound too useful. I wish it was this easy. You're right that > its a lot of effort. It's a full time job tracking 2.4, judging whether > something is needed or not in the RH kernel, merging, adapting > (due to NPTL and other largescale changes), and testing. > > > Wouldn't it be better for RedHat if RedHat just sends the patches to > > Linus and company, and just accept the fact that they maybe don't accepted? > > A majority of whats been merged in the last few weeks are patches that > already have been accepted upstream. > > Dave > From florin at sgi.com Fri Oct 17 23:28:45 2003 From: florin at sgi.com (Florin Andrei) Date: 17 Oct 2003 16:28:45 -0700 Subject: ink Message-ID: <1066433325.9185.44.camel@stantz.corp.sgi.com> Another too-late-for-this-time-but-maybe-next-round application: http://home.arcor.de/markusheinz/ink.html Essentially, it's a tool for checking the ink level of inkjet printers under Linux. It allows you to figure out what's wrong with the printer, even if your printserver is not running Windows so you can't run the proprietary printer tools. I missed this functionality badly since i bought my Epson Stylus Photo 780, but now i can do it, thanks to ink. It works pretty well, it can access the printer even if CUPS is running, there's no device access conflict or anything. So perhaps it's worth including it in the distribution. Since the RPM packages offered on the website do not compile on Red Hat, i made some packages on RH9 and uploaded them here: ftp://andrei.myip.org/ink/ -- Florin Andrei http://florin.myip.org/ From ra at ra.is Sat Oct 18 01:11:57 2003 From: ra at ra.is (Richard Allen) Date: Sat, 18 Oct 2003 01:11:57 +0000 Subject: Laptop power management In-Reply-To: <1066433325.9185.44.camel@stantz.corp.sgi.com> References: <1066433325.9185.44.camel@stantz.corp.sgi.com> Message-ID: <20031018011157.GA16185@ra.is> I just got a HP NX7000 laptop. Beta3 installs nicely (failed to propperly detect the monitor) and runs very well also. It's even 3D enabled right out of the box. It has no idea on power management tho. "AC on-line, no system battery" All other hardware except the modem and wireless lan is working. The machine is Centrino based. 00:1f.6 Modem: Intel Corp. 82801DB AC'97 Modem Controller (rev 01) 02:02.0 Network controller: Intel Corp. PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04) Should I bugzilla any of these ? -- Rikki. -- RHCE, RHCX, HP-UX Certified Administrator. -- Solaris 7 Certified Systems and Network Administrator. Bell Labs Unix -- Reach out and grep someone. Those who do not understand Unix are condemned to reinvent it, poorly. From m.fioretti at inwind.it Sat Oct 18 06:29:44 2003 From: m.fioretti at inwind.it (M. Fioretti) Date: Sat, 18 Oct 2003 08:29:44 +0200 Subject: Better packaging for older hardware? Message-ID: <20031018062944.GB32004@inwind.it> Greetings, As some of you may already know, the RULE project (see my signature) works to make the latest stable release of Red Hat useable on very low end hardware (i386+ 16 MB+ RAM, 3/400 MB hard disks). This is not an academic exercise: students and schools in developing (and "developed") countries often have only 5/6 years old computers from donations, without money to buy more parts for them, when those parts still exist. To have an idea of what we do in RULE, please have a look at our website, maybe starting from these very short pages: http://www.rule-project.org/en/faq.php (please start here!) http://www.rule-project.org/en/what_can_rule_do.php http://www.rule-project.org/en/sw/kdrive.php http://www.rule-project.org/en/news/vumbox.php http://www.rule-project.org/en/news/state_of_the_rule_200310.php Now to the actual issue. RULE will now switch to Fedora. Since this is a community based project, we hope that the issues addressed by RULE can receive more attention than a corporation could afford (this is not a critic to Red Hat: a company must make ends meet and produce money, no question about that). We are not going to ask that the whole project is turned upside down. There are a few things, however, that would make the life of RULE school and private users a whole lot easier, and be almost transparent to other users. I refer to building: 1) kdrive RPMs whenever the XFree86 ones are updated. 2) i386 kernel RPMs, possibly tweaked for low RAM. 3) (this is maybe the most important) single RPMs of several user friendly desktop applications. Practical example: a lot of RULE end users will be non programmers without any prior PC experience, and they will only need email, web browsing and to do simple homework. They would have real problems to use mutt, no possibility to run a compiler, no skills to do it. Their ideal solutions would be to have fedora RPMs to install (just as an example!!!) ONLY Kmail (or sylpheed), Gnumeric or KOffice, Konqueror... without any other applications and/or the most advanced/cool features of Gnome and KDE. On plain X or Kdrive with only Qt / Gtk and a basic WM like Ice or blackbox. With respect to the KDE case, if there were (with the same builds, from the same source RPMs already available) kmail.rpm konqueror.rpm and the current kde packages, which are actually monolithic bundles of much more stuff, became "meta-packages" which just require the single things, situation would be: much much better for RULE users, no more forced to trash a computer because it won't fit "hidden" apps never needed. almost transparent to power end users: they would continue to install/update as usual "kde desktop", "gnome desktop", and so on, without ever noticing what happened below. What do you think? Ciao, Marco Fioretti RULE project coordinator -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ Human beings act intelligently only after they have exhausted the alternatives -- Abba Eban From tdiehl at rogueind.com Sat Oct 18 07:14:07 2003 From: tdiehl at rogueind.com (Tom Diehl) Date: Sat, 18 Oct 2003 03:14:07 -0400 (EDT) Subject: Better packaging for older hardware? In-Reply-To: <20031018062944.GB32004@inwind.it> Message-ID: On Sat, 18 Oct 2003, M. Fioretti wrote: > Greetings, > > As some of you may already know, the RULE project (see my signature) > works to make the latest stable release of Red Hat useable on very > low end hardware (i386+ 16 MB+ RAM, 3/400 MB hard disks). > > This is not an academic exercise: students and schools in developing > (and "developed") countries often have only 5/6 years old computers > from donations, without money to buy more parts for them, when those > parts still exist. > > To have an idea of what we do in RULE, please have a look at our > website, maybe starting from these very short pages: > > http://www.rule-project.org/en/faq.php (please start here!) > http://www.rule-project.org/en/what_can_rule_do.php > http://www.rule-project.org/en/sw/kdrive.php > http://www.rule-project.org/en/news/vumbox.php > http://www.rule-project.org/en/news/state_of_the_rule_200310.php > > > Now to the actual issue. RULE will now switch to Fedora. Since this is > a community based project, we hope that the issues addressed by RULE > can receive more attention than a corporation could afford (this is not > a critic to Red Hat: a company must make ends meet and produce money, > no question about that). > > We are not going to ask that the whole project is turned upside > down. There are a few things, however, that would make the life of > RULE school and private users a whole lot easier, and be almost > transparent to other users. > > I refer to building: > > 1) kdrive RPMs whenever the XFree86 ones are updated. > > 2) i386 kernel RPMs, possibly tweaked for low RAM. > > 3) (this is maybe the most important) single RPMs of several user > friendly desktop applications. > > Practical example: a lot of RULE end users will be non programmers > without any prior PC experience, and they will only need email, web > browsing and to do simple homework. > > They would have real problems to use mutt, no possibility to run a > compiler, no skills to do it. Their ideal solutions would be to have > fedora RPMs to install (just as an example!!!) ONLY Kmail (or > sylpheed), Gnumeric or KOffice, Konqueror... without any other > applications and/or the most advanced/cool features of Gnome and > KDE. On plain X or Kdrive with only Qt / Gtk and a basic WM like Ice > or blackbox. > > With respect to the KDE case, if there were (with the same builds, > from the same source RPMs already available) > > kmail.rpm > konqueror.rpm > > and the current kde packages, which are actually monolithic bundles of > much more stuff, became "meta-packages" which just require the single > things, situation would be: > > much much better for RULE users, no more forced to trash a computer > because it won't fit "hidden" apps never needed. > > almost transparent to power end users: they would continue to > install/update as usual "kde desktop", "gnome desktop", and so on, > without ever noticing what happened below. IMHO it is bloat. I thought the idea was to reduce the size of FC. See below. > What do you think? Sounds like something for fedora extras once that is setup. Since Red Hat is still controlling the devel on FC I do not think it would get in there and as long as someone wants to maintain the packages I do not see a problem with that. If the RULE project is already maintaining these packages they could simply be moved to FE, IMHO putting an i386 kernel etc in the main FC distro would be a waste, but that is just me. -- ......Tom Registered Linux User #14522 http://counter.li.org tdiehl at rogueind.com My current SpamTrap -------> mtd123 at rogueind.com From m.fioretti at inwind.it Sat Oct 18 08:43:46 2003 From: m.fioretti at inwind.it (M. Fioretti) Date: Sat, 18 Oct 2003 10:43:46 +0200 Subject: Better packaging for older hardware? In-Reply-To: References: <20031018062944.GB32004@inwind.it> Message-ID: <20031018084346.GC32004@inwind.it> On Sat, Oct 18, 2003 03:14:07 at 03:14:07AM -0400, Tom Diehl (tdiehl at rogueind.com) wrote: > > > > almost transparent to power end users: they would continue to > > install/update as usual "kde desktop", "gnome desktop", and so on, > > without ever noticing what happened below. > > IMHO it is bloat. I thought the idea was to reduce the size of FC. See below. The kernel is a special case, I agree, and it is not really the most important things. Proper packages are. Why do you think the repackaging I suggest would be against reducing the size of FC (Fedora Core, right? Sorry, I just came in...)? Which size do you refer to? byte size would increase little or nothing: I'm proposing to make 10 packages of 1 MB instead of 1 of 10 MB (very rough approximation, I agree) Pure *Number* of binary packages: that would increase a lot, yes, but not the complexity or maintenance effort. If you keep the same source kdebase RPM you have today (one only) and modify the spec file so that it creates kde_app1.rpm, kde_app2.rpm, etc... you still have *one* code base: you apply patches to that one, and packages are rebuilt automatically. Please let me know if and why this is not possible. Ciao, Marco Fioretti -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ Furious activity is no substitute for understanding. -- H.H. Williams From mharris at redhat.com Sat Oct 18 09:02:37 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 18 Oct 2003 05:02:37 -0400 (EDT) Subject: Better packaging for older hardware? In-Reply-To: <20031018084346.GC32004@inwind.it> References: <20031018062944.GB32004@inwind.it> <20031018084346.GC32004@inwind.it> Message-ID: On Sat, 18 Oct 2003, M. Fioretti wrote: >> > almost transparent to power end users: they would continue to >> > install/update as usual "kde desktop", "gnome desktop", and so on, >> > without ever noticing what happened below. >> >> IMHO it is bloat. I thought the idea was to reduce the size of FC. See below. > >The kernel is a special case, I agree, and it is not really the most >important things. Proper packages are. Why do you think the >repackaging I suggest would be against reducing the size of FC (Fedora >Core, right? Sorry, I just came in...)? Which size do you refer to? > >byte size would increase little or nothing: I'm proposing to make 10 >packages of 1 MB instead of 1 of 10 MB (very rough approximation, I >agree) > >Pure *Number* of binary packages: that would increase a lot, yes, but >not the complexity or maintenance effort. If you keep the same source >kdebase RPM you have today (one only) and modify the spec file so that >it creates kde_app1.rpm, kde_app2.rpm, etc... you still have *one* >code base: you apply patches to that one, and packages are rebuilt >automatically. Please let me know if and why this is not possible. It _is_ possible, and in fact our KDE used to be split up into more packages. There are _always_ tradeoffs in this world however, and more packages and subpackages _DO_ increase package maintenance efforts. That doesn't mean subpackages should be avoided, but it does very much mean that a balance is needed, and that there are many other factors which determine things. Should I put every single binary application which comes with XFree86 in it's own separate rpm for example? Do you use xcalc? Someone might put forth that including xcalc, xditview, etc. are bloat, and that they only want to install the apps they will actually use. They might even make the bogus disk space claim. What's funny though, is that for XFree86 packaging at least, every single sub package consumes at least a minimum of 150-200Kb each on your hard disk, even if the package were to contain zero files. This is because the rpm spec file changelog is stored in the rpm database once per installed package (instead of merging and refcounting, unless this has changed and I'm wrong now), so any subpackage that isn't at least 400-500Kb or more in size argueably is *wasting* space and should be merged into a different subpackage. ;o) Someone out there is now no doubt multiplying the size of the changelog by the number of subpackages and calculating the total wasted disk space in the rpm database when XFree86 is installed. If not, it'll likely be something to the effect of: $ rpm -q --changelog $(rpm -qa |grep ^XFree86) |wc -c 4433085 Or roughly 4.5Mb of your RPM database files is XFree86 changelogs. Wowsers. ;o) Before someone asks/complains/flames/whatever about this wasteage, I'm considering trimming the changelog down so that it only includes changes since 4.1.0, and moving the older changes into /usr/share/doc/XFree86-* somewhere with a pointer to them at the end of the rpm changelog. I just checked and removing all changelog entries from 4.2.1 and older would cut wasteage only in half, so not that huge of a gain anyway. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From paul at gear.dyndns.org Sat Oct 18 09:18:18 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Sat, 18 Oct 2003 19:18:18 +1000 Subject: Better packaging for older hardware? In-Reply-To: References: <20031018062944.GB32004@inwind.it> <20031018084346.GC32004@inwind.it> Message-ID: <3F91055A.90603@gear.dyndns.org> Mike A. Harris wrote: > ... > What's funny though, is that for XFree86 packaging at least, > every single sub package consumes at least a minimum of 150-200Kb > each on your hard disk, even if the package were to contain zero > files. This is because the rpm spec file changelog is stored in > the rpm database once per installed package (instead of merging > and refcounting, unless this has changed and I'm wrong now), so > any subpackage that isn't at least 400-500Kb or more in size > argueably is *wasting* space and should be merged into a > different subpackage. ;o) > > Someone out there is now no doubt multiplying the size of the > changelog by the number of subpackages and calculating the total > wasted disk space in the rpm database when XFree86 is installed. > If not, it'll likely be something to the effect of: > > $ rpm -q --changelog $(rpm -qa |grep ^XFree86) |wc -c > 4433085 > > Or roughly 4.5Mb of your RPM database files is XFree86 > changelogs. Wowsers. ;o) Not a complaint, but why did they/you move changelogs from the doc directory into the RPM database? It doesn't seem like a very necessary thing... -- 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 buildsys at porkchop.devel.redhat.com Sat Oct 18 09:44:39 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sat, 18 Oct 2003 05:44:39 -0400 Subject: rawhide report: 20031018 changes Message-ID: <200310180944.h9I9idt19965@porkchop.devel.redhat.com> Updated Packages: a2ps-4.13b-30 ------------- * Fri Oct 17 2003 Tim Waugh 4.13b-30 - Prevent strsignal segfaulting (bug #104970). bind-9.2.2.P3-9 --------------- * Fri Oct 17 2003 Daniel Walsh 9.2.2.P3-9 - Add /var/named/slaves directory cyrus-sasl-2.1.15-5 ------------------- * Fri Oct 17 2003 Nalin Dahyabhai 2.1.15-5 - install saslauthd's mdoc page instead of the pre-formatted man page, which would get formatted again * Mon Sep 15 2003 Nalin Dahyabhai - include testsaslauthd - note in the README that the saslauthd protocol is different for v1 and v2, so v1's clients can't talk to the v2 server gaim-0.71-1 ----------- * Fri Oct 17 2003 Christopher Blizzard 1:0.71-1 - Include patch that updates the tray icon to a more recent version initscripts-7.38-1 ------------------ * Fri Oct 17 2003 Bill Nottingham 7.38-1 - rhgb updates, now pass 'rhgb' to use it, instead of passing 'nogui' to disable it kdelibs-3.1.4-4 --------------- * Fri Oct 17 2003 Than Ngo 6:3.1.4-4 - fixed icon scale patch, thanks to Thomas W??rner kernel-2.4.22-1.2097.nptl ------------------------- * Wed Oct 15 2003 Dave Jones - Drop kupdated 'fix' that broke things with nptl. - Fix up unresolved symbols. kudzu-1.1.34-1 -------------- * Fri Oct 17 2003 Bill Nottingham 1.1.34-1 - switch to new scsi device id code (#102136, 107350) - fix scsi tape enumeration (#107361) printman-0.0.1-1.20021202.15 ---------------------------- * Fri Oct 17 2003 Tim Waugh 0.0.1-1.20021202.15 - Work-around for bug #107373. quagga-0.96.3-1 --------------- * Wed Oct 15 2003 Jay Fenlason 0.96.3-1 - Patch a remote DoS attack (#107140) - New upstream version - Removed the .libcap patch, which was applied upstream - Renamed the vty group from quaggavty to quaggavt because quaggavty is too long for NIS. - Patch the spec file to fix #106857: /etc/quagga/zebra.conf is created with the wrong owner. - Removed the "med" part of the 0.96.1-warnings patch for . . . - Add a new warnings patch with a fix for #106315. This also updates the "med" part of the previous warnings patch. rawhide-release-20031018-1 -------------------------- rhgb-0.11-1 ----------- * Fri Oct 17 2003 Jonathan Blandford 0.11 - only launch if explicitly listed in grub * Fri Oct 17 2003 Jonathan Blandford 0.10.6-1 - add working xkb support subversion-0.31.0-2 ------------------- * Fri Oct 10 2003 Joe Orton 0.31.0-2 - include The Book - don't add an RPATH for libdir to executables xemacs-21.4.14-2 ---------------- * Fri Oct 17 2003 Jens Petersen - 21.4.14-2 - require Canna-libs not Canna - move CJK X resource files to xemacs-sumo - no longer need to define ispell program to be aspell * Mon Sep 08 2003 Jens Petersen - 21.4.14-1 - update to 21.4.14 - default require-final-newline to t in site-start.el (#102022) * Tue Sep 02 2003 Jens Petersen - 21.4.13-5 - default require-final-newline to ask in site-start.el and remove redundant setting of next-line-add-newlines to nil in default.el (#102022) [reported by Ville Skytt??] * Mon Jul 14 2003 Jens Petersen - 21.4.13-4 - build with --debug=yes by default (suggested by Ville Skytt??) * Sun Jul 13 2003 Ville Skytt?? - add xemacs-21.4.13-utf8-fontsets.patch to eliminate warning about missing charsets in utf-8 locale with Xaw - motif-specific xemacs-21.4.13-EmacsFrame-fontlock.patch no longer needed * Fri Jun 27 2003 Jens Petersen - 21.4.13-3 - add xemacs-21.4.13-dump-paths-lispdir.patch, so that the source lisp files get re-bytecompiled and dumped, not the installed ones - use Athena/Xaw3d instead of motif for dialogs and widgets - buildrequirements fixes - use _localstatedir * Sat May 31 2003 Jens Petersen - 21.4.13-2 - add xemacs-21.4.13-EmacsFrame-fontlock.patch to stop font-lock being very slow (Ville Skytt??) * Fri May 30 2003 Ville Skytt?? - Use upstream icon in desktop entry, add missing semicolon to Categories. - Have backup-by-copying-when-mismatch default to true in site-start.el. - Mark init files as %config. * Thu May 29 2003 Jens Petersen - 21.4.13-1 - update to 21.4.13 - rcs2log-update.patch no longer needed - buildrequire recent xemacs-sumo - set system-uses-terminfo in default.el (#76102) - use defvar in default.el not to override user's settings - default gnus-default-article-saver to mbox format (#90604) - add aspell as ispell program in site-start.el (#88262) - add rpmbuild option "--with gtk" allowing building with gtk - exclude s390x temporarily * Mon May 12 2003 Jens Petersen - 21.4.12-12 - sumo packages moved to separate xemacs-sumo package * Sat May 10 2003 Jens Petersen - 21.4.12-11 - build with system malloc on ppc64 * Tue Apr 22 2003 Jens Petersen - 21.4.12-10 - obsoletes ruby-mode-xemacs (#84673) - move obsoletes xemacs-sumo-el to -el subpackage - fix links in jde html documentation (#89499) * Tue Apr 15 2003 Jens Petersen - 21.4.12-8 - comment out ja and ko menubar translations in X resource files for now, to avoid startup hanging in utf-8 locale (#88860) - use default menubar font in ja and ko locale - in a UTF-8 locale set default coding systems to utf-8 (partly #77130 and #74227) - set Info-directory-list in site-start.el again - move psgml setup into site-start.el - move previous contents of "dotxemacs-init.el" to new "default.el" * Mon Mar 31 2003 Akira TAGOH 21.4.12-7 - Rebuild against the latest Canna. * Thu Feb 20 2003 Jens Petersen - 21.4.12-6 - default browse-url to use htmlview and update psgml-html browser defaults (#84262) * Tue Feb 11 2003 Jens Petersen - 21.4.12-5 - build with system-malloc on alpha and ia64 - skip redundant check-features target * Thu Feb 06 2003 Jens Petersen - 21.4.12-4 - fix "libexec dir" to be under lib64 on multilib archs - set default ftp to be non-kerberos in site-start.el - update sumos to 2003-02-05 - mspec patch and rpm-spec-mode update no longer needed - buildrequire autoconf213 - add ".xemacs/init.el" to /etc/skel - skip redundant check-features target on s390 and s390x * Wed Jan 22 2003 Tim Powers - rebuilt * Tue Jan 21 2003 Jens Petersen - 21.4.12-2 - fix `paths-emacs-root-p' (find-paths.el) to look in share not lib - don't generate backup files when updating autoloads - try startup notification in desktop file - cleanup desktop file to use name XEmacs and add encoding key * Fri Jan 17 2003 Jens Petersen 21.4.12-1 - update to 21.4.12 bugfix release (21.4 series now declared stable branch) - renumbered sumo package patches to be greater than 100 - install sumo packages by copying rather than moving - patch sh-script.el to append m?spec entry to auto-mode-alist - avoid ppc.ldscript and build on ppc - remove games that we shouldn't ship - update to latest rcs2log - update to latest rpm-spec-mode.el - use _smp_mflags for lib-src and src - run batch-update-directory and batch-byte-recompile-directory on sumo lisp dirs - improve datadir/xemacs-version/ ownership * Sat Jan 04 2003 Jens Petersen 21.4.11-1 - update to 21.4.11 - don't configure with union-type, since it causes runtime problems apparently - only do postun info dir deletions when uninstalling * Wed Jan 01 2003 Jens Petersen 21.4.10-6 - move apel to separate package and require it - renamed psgml-init.el-xemacs to xemacs-psgml-init.el - use datadir in site-start.el - really include the movemail mkstemp patch - use mapc to load site-start.d files * Tue Dec 31 2002 Ville Skytt?? - New Sumos (2002-12-30). - Use `construct-emacs-version-name' in `paths-emacs-root-p' (find-paths.el), fixing "Couldn't find obvious default for XEmacs hierarchy" warnings (as in XEmacs 21.5). - Move site-start stuff to site-packages. - Don't set Info-directory-list in site-start.el. - Don't use --pkgdir, it's ignored. Don't pass pkgdir to makeinstall. - Fix source tarball URLs. - Don't override the defcustom in psgml-init.el, set its default value instead. - Add rpmbuild option: "--with debug" for building a debug-enabled XEmacs. * Sun Dec 29 2002 Jens Petersen - updates package sumos to 2002-12-26 release * Mon Dec 23 2002 Jens Petersen 21.4.10-5 - patch find-paths.el to search in datadir - setup lisp packages under datadir not libdir - use buildroot macro instead of RPM_BUILD_ROOT - drop local configure macro - fix buildrequires and requires - list configure options one-per-line - improve psgml-init.el catalog setup - remove and add lisp packages with package-admin - rebyte-compile lisp packages - keep etags as etags.xemacs (#78106) - don't bother removing non-existent udp2tcp nor .cvsignore files - simply filelist generation to a single find search pass - put core .el files in -el package - put package info files into -info package - don't create backup files when patching in lisp packages tree - don't explicitly gzip lisp package info files - don't mark the applications files noreplace - exclude ppc, since __init_array_start undefined * Wed Dec 18 2002 Jens Petersen - patch egg-wnn to default to unix domain socket (#79826) [patch from ynakai at redhat.com] - add ia64 patch from SuSE - use mkstemp in movemail * Tue Nov 19 2002 Jens Petersen - apply jlatex autodetect patch correctly and drop append to tex-site.el - default to pTeX and pLaTeX for Japanese TeX and LaTeX * Mon Nov 18 2002 Jens Petersen 21.4.10-3 - backout uncommenting of deactivate-mark (#77696) - update psgml dtd catalog path in psgml-init.el (#78022) [reported by ville.skytta at iki.fi] - build with --use-union-type (#78024) [suggested by ville.skytta at iki.fi] * Fri Nov 15 2002 Jens Petersen - fix autodetection of jlatex (#69129) * Tue Nov 12 2002 Elliot Lee 21.4.10-2 - build on x86_64 * Mon Nov 11 2002 Jens Petersen 21.4.10-1 - update to 21.4.10 - update sumos to 2002-09-19 - no longer backout mule-ucs package - encode this file in utf-8 - xemacs-21.1.14-xfs.patch no longer needed - use _libdir, _datadir, _bindir, _prefix - exclude x86_64 (requires Canna) - own /usr/lib/xemacs/{,mule-packages} and /usr/X11R6/lib/X11/ (#73982) [reported by enrico.scholz at informatik.tu-chemnitz.de] - fix default italic font size (#75275) [reported with fix by ville.skytta at iki.fi] - update ja menubar translations in ja locale X resource file (#76068) [from ynakai at redhat.com] - update ko locale X resource file (#76072) [from ynakai at redhat.com] - add pkgdir rpm macro for packages dir - uncomment deactivate-mark in simple.el (#77696) * Mon Aug 26 2002 Trond Eivind Glomsr??d 21.4.8-16 - some cleanups - and remove the info tarball, it's now part of the base tarball. Wow, the package gets smaller. (#72480) * Mon Aug 19 2002 Trond Eivind Glomsr??d 21.4.8-15 - Bug in specfile from -14 gave bug on startup (#71743) * Thu Aug 15 2002 Trond Eivind Glomsr??d 21.4.8-14 - Use utf-8 by default for input/output (#71584 ) - Make it not segfault when handling utf-8 (#71589) * Wed Aug 07 2002 Trond Eivind Glomsr??d 21.4.8-13 - Add openmotif-devel to buildrequires, as it will use it for widgets if it finds it * Fri Aug 02 2002 Trond Eivind Glomsr??d 21.4.8-12 - Don't package po-mode separately, it's now in sumo - Compile with drag'n'drop support - Use the bundled rpm-spec-mode, it has some adaptions for XEmacs * Wed Jul 31 2002 Trond Eivind Glomsr??d 21.4.8-11 - Don't use a separate ispell.el file anymore - the included one is newer - Fix html-mode (#64826) * Tue Jul 23 2002 Trond Eivind Glomsr??d 21.4.8-10 - Update lisp tarballs - desktop file fixes (#69542) - Add bdb support (#65640) * Mon Jul 08 2002 Trond Eivind Glomsr??d 21.4.8-9 - Make it provide ruby-mode-xemacs (request from tagoh) * Fri Jun 21 2002 Tim Powers - automated rebuild * Mon Jun 17 2002 Trond Eivind Glomsr??d 21.4.8-7 - #66835 * Wed May 29 2002 Trond Eivind Glomsr??d 21.4.8-6 - Make it build... Evil. - Exclude IA64 - Upgrade sumo tarballs to 2002-05-22 * Fri May 24 2002 Jens Petersen 21.4.8-5 - Build using portable dumper, so that build with glibc-2.3 malloc is ok * Mon May 13 2002 Trond Eivind Glomsr??d 21.4.8-2 - Remove the s390 patches so it builds on s390 :) * Fri May 10 2002 Trond Eivind Glomsr??d 21.4.8-1 - 21.4.8 * Tue May 07 2002 Trond Eivind Glomsr??d 21.4.6-9 - Rebuild... chmod -x pstogif to work around an rpm bug until it's fixed (#64320) * Tue Apr 23 2002 Trond Eivind Glomsr??d 21.4.6-8 - New sumo packages * Thu Feb 21 2002 Trond Eivind Glomsr??d 21.4.6-7 - Rebuild * Tue Jan 29 2002 Jens Petersen 21.4.6-6 - Remove skk package, since it conflicts with ddskk-xemacs (newer) * Thu Jan 24 2002 Trond Eivind Glomsr??d 21.4.6-5 - New sumos * Wed Jan 09 2002 Tim Powers - automated rebuild * Wed Dec 19 2001 Jens Petersen 21.4.6-3 - Fix fontlist pattern in Emacs.ad.Japanese. - CHANGES-beta is now CHANGES-release. - Obsolete xemacs-sumo xemacs-sumo-el * Wed Dec 19 2001 Jens Petersen 21.4.6-2 - Don't obsolete flim. * Mon Dec 17 2001 Trond Eivind Glomsr??d 21.4.6-1 - 21.4.6 - New sumo packages - disable alpha * Wed Nov 14 2001 Jens Petersen 21.4.5-2 - Add -znocombreloc configure option to override new ld default. * Tue Nov 06 2001 Trond Eivind Glomsr??d 21.4.5-1 - 21.4.5. It builds on IA64 and fixes #55578 * Thu Oct 18 2001 Trond Eivind Glomsr??d 21.1.14-26 - Updated the sumo tarballs * Tue Oct 16 2001 Akira TAGOH 21.1.14-25 - Separeted an elisp of mew. * Fri Sep 14 2001 Than Ngo 21.1.14-24 - fix to build on s390/s390x * Fri Sep 14 2001 Jens Petersen 21.1.14-23 - Restored teg's name in changelogs - Added xemacs file variable for encoding at start of file to avoid this happening again - Restored (obsolete) atype.el and file-detect.el into apel-10.3 package, required by semi through rmail dependency * Fri Sep 07 2001 Akira TAGOH 21.1.14-22 - Fixed provide version of apel - Fixed replaced apel. * Thu Sep 06 2001 Jens Petersen 21.1.14-21 - replaced apel-10.2 from sumo with apel-10.3 * Mon Aug 27 2001 Trond Eivind Glomsr??d 21.1.14-20 - Remove buildroot-paths from finder-inf.el - remove various multibyte comments from finder-inf.el if necessary, so it will compile even if XEmacs is installed. (#51985) * Wed Jul 25 2001 Trond Eivind Glomsr??d 21.1.14-19 - Added app-defaults for Korean and simplified Chineese (#49857) * Fri Jul 20 2001 Trond Eivind Glomsr??d - Don't have a special configure define for alpha anymore - they converged, and weren't different anymore. (#49209) * Thu Jul 12 2001 Trond Eivind Glomsr??d - add more libraries to buildprereq - replace individually updated lisppackages with the official collection * Mon Jul 09 2001 Trond Eivind Glomsr??d - Reenable canna and wnn * Tue Jun 26 2001 SATO Satoru - Wanderlust and SEMI are splitted off (wl-xemacs, semi-xemacs) * Fri Jun 22 2001 Trond Eivind Glomsr??d - Use fontset in the resource file, since we use "--with-xfs" (#45499) - Include po-mode, adjusted for XEmacs by enrico.scholz at informatik.tu-chemnitz.de * Wed Jun 20 2001 Trond Eivind Glomsr??d - More dependencies added to buildrequires - disable wl-init.el, as we don't want to load mime-setup - cleanups in site-start.el * Mon Jun 18 2001 Florian La Roche - merge s390x patch from * Mon Jun 04 2001 Trond Eivind Glomsr??d - Make it build (don't run autoconf, disable Japanese) - New rpm-spec-mode which fixes #43323 * Tue Apr 24 2001 Trond Eivind Glomsr??d - New sumo packages * Mon Mar 19 2001 Akira TAGOH - Fixed semi's mailcap issues. * Fri Mar 16 2001 Trond Eivind Glomsr??d - remove the mailcap lisp files from semi-xemacs - they break stuff - don't include our own sh-script files anymore, bash is now bash2 * Thu Mar 08 2001 Akira TAGOH - 21.1.14-8 - Merged semi-xemacs into the main package, as wl (already bundled) needs it. - Fixed the byte-compile for wl. * Fri Mar 02 2001 Nalin Dahyabhai - rebuild in new environment * Thu Feb 22 2001 Trond Eivind Glomsr??d - minor fixes to psgml-init.el * Mon Feb 12 2001 Trond Eivind Glomsr??d - Move eieio.el to the main package (#26753) - Prereq info * Thu Feb 08 2001 Trond Eivind Glomsr??d - add init file for mew * Mon Feb 05 2001 Trond Eivind Glomsr??d - Obsolete xemacs-static * Fri Feb 02 2001 Trond Eivind Glomsr??d - obsolete xemacs-noX and xemacs-mule * Mon Jan 29 2001 Trond Eivind Glomsr??d - 21.1.14 * Wed Jan 24 2001 Yukihiro Nakai - enable Wanderlust * Tue Jan 23 2001 Trond Eivind Glomsr??d - added Japanese support to .desktop file * Mon Jan 22 2001 Trond Eivind Glomsr??d - enable canna, wnn4, wnn6 - improve app-defaults file for Japanese and traditional Chineese * Fri Jan 19 2001 Trond Eivind Glomsr??d - turn on --with-xfs to improve support for Japanese - copy the app-defaults to /usr/X11R6/lib/X11/app-defaults - add app-defaults for traditional Chineese * Mon Jan 08 2001 Trond Eivind Glomsr??d - 21.1.13 - update the rpm spec mode - removed the alpha patch - remove the elc sourcefile, these can be generated during the build process * Tue Jan 02 2001 Trond Eivind Glomsr??d - make sure it doesn't use canna, wnn or wnn6 by default * Thu Dec 28 2000 Bill Nottingham - bzip2 sources * Tue Dec 12 2000 Trond Eivind Glomsr??d - fix psgml mode by adding the psgml-init.el file from the psgml package. Should fix #21827 - add rpm-spec-mode * Sat Dec 09 2000 Than Ngo - added s390 port * Mon Dec 04 2000 Trond Eivind Glomsr??d - make sure that the info pages in /usr/lib/xemacs/mule-packages/info/ are compressed * Fri Dec 01 2000 Trond Eivind Glomsr??d - add "--with-xim=xlib" to configure to avoid linking with Motif * Thu Nov 30 2000 Trond Eivind Glomsr??d - move site-start.el to /usr/lib/xemacs/xemacs-packages/lisp/site-start.el (it shouldn't depend on xemacs version) - add new directory /usr/lib/xemacs/xemacs-packages/lisp/site-start.d - change run .el files here on startup - revert to "normal" xemacs * Tue Nov 28 2000 Trond Eivind Glomsr??d - fix the "restore cursor" problem I submitted myself before I started here(#9853). Sometimes, you're digging your own grave without even knowing. * Tue Nov 14 2000 Trond Eivind Glomsr??d - new sumo tarballs - new xemacs tarball - fixing of the improved .desktop file - include xemacs.png file (from kdebase) to be used with above file * Tue Oct 17 2000 Trond Eivind Glomsr??d - new and better xemacs.desktop file * Tue Oct 10 2000 Trond Eivind Glomsr??d - use xemacs package from 2000-09-25 - move tex-site.el to main package (#18494) * Tue Sep 12 2000 Trond Eivind Glomsr??d - remove README.i386-pc-linux - it's no longer anywhere near accurate - update sumo package to 2000-09-04 - use mule by default, like we do for GNU Emacs - use gtk-xemacs - it's in the XEmacs cvs now - move the xemacs desktop file to "Applications" - specify ldap (it was just detected before) - enable native sound - remove a binary which somehow had made it into the lisp package, compiled with libraries we don't have * Wed Aug 23 2000 Nalin Dahyabhai - change locking mechanism to lockf * Thu Aug 17 2000 Trond Eivind Glomsr??d - use ispell.el from GNU Emacs, which work better than the ones found at the xemacs ftp site or at the author's site. Fixes bug #16071 * Sun Aug 06 2000 Trond Eivind Glomsr??d - 21.1.12 bugfix release - removed security patch as it is now included - gzip info packages in the package directory * Tue Jul 18 2000 Trond Eivind Glomsr??d - 21.1.11 - upgrade(? - it wasn't specified) to sumo tarball from 2000-05-24 - add a sitestart.rl file, for configuration of info and spelling - fixed the ownership of lots of package directories (#14197) - disabled ia64 patch as they know have their own support... - ... which doesn't work. Excludearch coming up. * Thu Jul 13 2000 Prospector - automatic rebuild * Mon Jul 03 2000 Than Ngo - don't use xemac to compile some lisp-source in byte code * Sun Jul 02 2000 Trond Eivind Glomsr??d - include the files in the %{_infodir}, not the directory * Wed Jun 28 2000 Than Ngo - add xemacs-extras xemacs-packages-el xemacs-packages in obsoletes to resolse conflicts (#13120) - add missing stuff (#13176) * Tue Jun 27 2000 Trond Eivind Glomsr??d - don't specify -O0 - do it anyway for IA64 * Tue Jun 20 2000 Bill Nottingham - build on ia64 * Tue Jun 20 2000 Trond Eivind Glomsr??d - override optflags, use -O0 to avoid compiler bugs (last build, actually) - don't include some info files which clash with others * Mon Jun 19 2000 Trond Eivind Glomsr??d - redid most of the spec file * Mon Jun 19 2000 Trond Eivind Glomsr??d - build in the main tree - disabled static package (it was partially disabled...) - don't change ownership while installing - updated some of the documentation (s/21.1.8/21.1.10/) - don't build on IA64 - use %{_mandir} instead of hardcoding /usr/share/man * Mon May 29 2000 Ngo Than - update to 2.1.10 for 7.0 - fix permission - put man pages in correct place - fix xemacs to build with gcc-2.96 (thanks Jakub) * Wed May 24 2000 Ngo Than - fix a security problem in key strokes. - fix a permission problem. XEmacs doesn't set proper permissions for the slave PTY device. - remove xemacs static * Thu Mar 23 2000 Ngo Than - updated to 21.1.9 * Fri Feb 11 2000 Ngo Than - fixed Bug #7694, #9149 * Tue Jan 18 2000 Tim Powers - bzipped sources to conserve space - fixed so that alpha builds properly - removed the --with-xface stuff. * Wed Dec 01 1999 Tim Powers - updated to 21.1.8 - gzip man pages - now builds for alpha :) * Thu Oct 21 1999 Cristian Gafton - include /var/lock/xemacs as the lockdir to make it stop whining * Thu Aug 19 1999 Tim Powers - fixed problem with dirs not being removed during uninstall * Sun Jul 11 1999 Tim Powers - updated to version 21.1.4 - added the elc and info src. - modified spec as needed - had a beer after building * Fri May 14 1999 Cristian Gafton - version 21.1.2 - require ctags * Wed Oct 14 1998 Michael Maher - built pacakge for 5.2, didn't use a pre update. * Sat Apr 11 1998 Cristian Gafton - updated to 20.4 - new package xemacs-mule with mule support - Changed spec file almost completely * Fri Dec 05 1997 Otto Hammersmith - refixed perl problem. - added wmconfig * Tue Dec 02 1997 Otto Hammersmith - added changelog - configure for ncurses - removed sound support on i386 - moved buildroot to /var/tmp xemacs-sumo-20031003-3 ---------------------- * Sat Oct 18 2003 Jens Petersen - 20031003-3 - fix mh-e toolbar error (#100764) [reported by vonbrand at inf.utfsm.cl, fix by Stephen J. Turnbull] * Fri Oct 17 2003 Jens Petersen - 20031003-2 - generate X resource files in utf-8 for de, fr and ro (#107310) [frh at gmx.de] - move our CJK X resource files here from xemacs with one file for native encoding and one for utf-8 - re-enable menubar translations for native CJK encodings (part of #106994) [Yukihiro Nakai] From alan at redhat.com Sat Oct 18 09:51:05 2003 From: alan at redhat.com (Alan Cox) Date: Sat, 18 Oct 2003 05:51:05 -0400 (EDT) Subject: Better packaging for older hardware? In-Reply-To: <20031018062944.GB32004@inwind.it> from "M. Fioretti" at Hyd 18, 2003 08:29:44 Message-ID: <200310180951.h9I9p5Y25510@devserv.devel.redhat.com> > As some of you may already know, the RULE project (see my signature) > works to make the latest stable release of Red Hat useable on very > low end hardware (i386+ 16 MB+ RAM, 3/400 MB hard disks). Some of us know yes. Its what I used to install RH9 on a 486 with 24Mb of RAM 8) > I refer to building: > 1) kdrive RPMs whenever the XFree86 ones are updated. As I understand it keiths current kdrive XFree is very much split from the base XFree project now because XFree86 threw him out. > 2) i386 kernel RPMs, possibly tweaked for low RAM. 386/486 kernel RPMs make sense but you probably also want to think about that as a seperate kernel with less options selected and without the more high end tuning Red Hat has. > fedora RPMs to install (just as an example!!!) ONLY Kmail (or > sylpheed), Gnumeric or KOffice, Konqueror... without any other > applications and/or the most advanced/cool features of Gnome and > KDE. On plain X or Kdrive with only Qt / Gtk and a basic WM like Ice > or blackbox. Stuff like Rox instead of nautilus etc you mnean ? Alan From mharris at redhat.com Sat Oct 18 09:51:58 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 18 Oct 2003 05:51:58 -0400 (EDT) Subject: Better packaging for older hardware? In-Reply-To: <3F91055A.90603@gear.dyndns.org> References: <20031018062944.GB32004@inwind.it> <20031018084346.GC32004@inwind.it> <3F91055A.90603@gear.dyndns.org> Message-ID: On Sat, 18 Oct 2003, Paul Gear wrote: >> Someone out there is now no doubt multiplying the size of the >> changelog by the number of subpackages and calculating the total >> wasted disk space in the rpm database when XFree86 is installed. >> If not, it'll likely be something to the effect of: >> >> $ rpm -q --changelog $(rpm -qa |grep ^XFree86) |wc -c >> 4433085 >> >> Or roughly 4.5Mb of your RPM database files is XFree86 >> changelogs. Wowsers. ;o) > >Not a complaint, but why did they/you move changelogs from the doc >directory into the RPM database? It doesn't seem like a very necessary >thing... I/we did not and have not ever moved changelogs from doc directory to rpm database. You misunderstand what an rpm changelog is. The rpm spec file contains an optional changelog, which is very highly recommended for everyone packaging software in rpm format to use, and it is mandatorily required by Red Hat and most other distributions for all software they ship, as well as most high quality 3rd party repositories. The rpm spec file changelog deals with distribution packager changes to the packaging of the software, not changes to the upstream software itself. The changelog that a given piece of software might include in it's source code, and might install into the doc directory is a totally different concept. That log documents upstream changes to the software itself as it gets checked into CVS and turned into stable releases. To keep with my previous example of XFree86, the XFree86 upstream changelog, is included in my XFree86 packaging and is located at: $ dir /usr/share/doc/XFree86-4.3.0/CHANGELOG -rw-r--r-- 1 root 935244 Jun 11 13:37 /usr/share/doc/XFree86-4.3.0/CHANGELOG That changelog is the one produced by XFree86.org to log the changes they make while developing XFree86. The rpm spec file changelog, which gets stored in the rpm database for each subpackage, is the list of packager/distribution changes that relate to the packaging of the software, including things like spec file changes, addition or removal of new subpackages, addition or removal of patches along with an explanation of what a given patch is fixing, and other packager related changes to the packaging itself. The two changelogs are totally different in concept, and the rpm spec file changelog has always existed in rpm and been stored in the rpm database, and a given upstream program's changelog - if one exists for a given piece of software has never been stored in the rpm database. So your assumption that we have moved changelogs around and stuffed them in rpm's database is incorrect. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From roozbeh at sharif.edu Sat Oct 18 09:49:45 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Sat, 18 Oct 2003 13:19:45 +0330 Subject: Yo. In-Reply-To: <200310162130.h9GLUaX19702@devserv.devel.redhat.com> References: <200310162130.h9GLUaX19702@devserv.devel.redhat.com> Message-ID: <1066470585.4061.12.camel@guava.bamdad.org> On Fri, 2003-10-17 at 01:00, Alan Cox wrote: > > I don't know, I wasn't aware of any patents regarding this. > > http://www.computerworld.com/managementtopics/ebusiness/story/0,10801,59043,00.html > http://www.i-d-n.net/#patents > > All very messy but I've not followed it since early 2002 to know > what happened or if it all died I've done that. There was consensus in the IETF IDN working group that Walid's patents are invalid, especially since there existed published and widely-distributed prior art (Martin Duerst's UTF-5, to name). There is no patent issue, as far as IETF and the lawyers members have contacted agree. And BTW, Mozilla already supports IDN. roozbeh From mharris at redhat.com Sat Oct 18 10:00:35 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 18 Oct 2003 06:00:35 -0400 (EDT) Subject: Better packaging for older hardware? In-Reply-To: <200310180951.h9I9p5Y25510@devserv.devel.redhat.com> References: <200310180951.h9I9p5Y25510@devserv.devel.redhat.com> Message-ID: On Sat, 18 Oct 2003, Alan Cox wrote: >> As some of you may already know, the RULE project (see my signature) >> works to make the latest stable release of Red Hat useable on very >> low end hardware (i386+ 16 MB+ RAM, 3/400 MB hard disks). > >Some of us know yes. Its what I used to install RH9 on a 486 with 24Mb of >RAM 8) > >> I refer to building: >> 1) kdrive RPMs whenever the XFree86 ones are updated. > >As I understand it keiths current kdrive XFree is very much split from >the base XFree project now because XFree86 threw him out. Just so other people who read that and start possibly incorrect rumours however, Keith wrote kdrive himself (the k in kdrive == keith's driver). He maintained kdrive in XFree86.org's CVS repository officially because he had CVS write permission at the time and it seemed logical. However since he's been removed from the XFree86 core team for just under a year now, and doesn't have CVS write permission anymore he is unable to maintain his kdrive X server(s) inside XFree86.org's CVS repository any longer. In order to continue maintaining kdrive, he had to open up a new CVS repository in order to continue to do development on the project. It isn't clear wether XFree86.org will update kdrive in their tree in the future or not, or if they'll strip it from the source code tree. It doesn't much matter IMHO either way, as Keith's repository will always be the official repository for kdrive. ;o) Keith has also of course been the official upstream maintainer of Xrender, Xft, Xcursor, fontconfig, Xrandr, and other stuff, and since he no longer has CVS repository access to further develop those, they are also now maintained outside of XFree86 officially. All of these things are now hosted on freedesktop.org and hopefully XFree86.org will track them and update their sources. It's of no real consequence if XFree86.org doesn't follow the externally maintained libraries, etc. however as all major OS distributions will be shifting to splitting out these libraries anyway for easier maintenance and updating. Similar to freetype/fontconfig/expat and other stuff being included with XFree86 sources, but we don't use the included version, instead we use the official upstream versions of all those. Debian, FreeBSD, Mandrake and others most likely will track the official upstream versions of Keith's various projects also. HTH -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From m.fioretti at inwind.it Sat Oct 18 11:36:48 2003 From: m.fioretti at inwind.it (M. Fioretti) Date: Sat, 18 Oct 2003 13:36:48 +0200 Subject: Better packaging for older hardware? In-Reply-To: <200310180951.h9I9p5Y25510@devserv.devel.redhat.com> References: <20031018062944.GB32004@inwind.it> <200310180951.h9I9p5Y25510@devserv.devel.redhat.com> Message-ID: <20031018113648.GA392@inwind.it> On Sat, Oct 18, 2003 05:51:05 at 05:51:05AM -0400, Alan Cox (alan at redhat.com) wrote: > > As some of you may already know, the RULE project (see my signature) > > works to make the latest stable release of Red Hat useable on very > > low end hardware (i386+ 16 MB+ RAM, 3/400 MB hard disks). > > Some of us know yes. Its what I used to install RH9 on a 486 with 24Mb of > RAM 8) Gee, great. If we were a company, you'd be receiving an offer for an outrageously overpaid ad campaign RSN. Can we quote you on that? On a more serious note, I'd really like to hear any direct feedback from how you found RULE and its installer. Probably offline, no need to fill the list with it. > > 2) i386 kernel RPMs, possibly tweaked for low RAM. > > 386/486 kernel RPMs make sense but you probably also want to think > about that as a seperate kernel with less options selected and > without the more high end tuning Red Hat has. Absolutely. The problem is that we realize this would be a very good thing, but, almost by definition, have not enough expertise, bandwidth, and CPU power to investigate all the possible alternatives. Please have a look to the archives of the Linux Kernel Mailing List: less than a week ago I started a thread there, called "unbloating the kernel". I almost explicitly say there that few things would make me happier (software wise, of course) if some real kernel hacker spends some day explaining to us how to tweak for RULE scenarios the *official* SRPMs of Red Hat, soon Fedora kernels. We can walk (almost) alone after that, just need a very good initial push in the right direction. Right .config, proper /proc settings, whatever. > > fedora RPMs to install (just as an example!!!) ONLY Kmail (or > > sylpheed), Gnumeric or KOffice, Konqueror... without any other > > applications and/or the most advanced/cool features of Gnome and > > KDE. On plain X or Kdrive with only Qt / Gtk and a basic WM like Ice > > or blackbox. > > Stuff like Rox instead of nautilus etc you mnean ? > Exactly. In user space the first problem is that lean and mean applications receive less and less press, especially for those coming to desktop Linux for the first time: they have to given the choice at install time among: "Full featured GNOME desktop, too big for your hard disk and RAM" "Full featured KDE desktop, too big for your hard disk and RAM" "Dive head first for hours in an unknown foggy maze of dependencies trying to get a leaner system" Here we are pretty good, we just lack enough hours in the day... The last (serious) problem in userspace is that even when you find a seemingly light application, often it is built to pretend on disk a tons of other libraries not needed by our users, so in the end it is no light at all. This is what prompted my original request here. Ciao, Marco Fioretti -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ None can love freedom heartily but good men; the rest love not freedom but license. John Milton From peter.backlund at home.se Sat Oct 18 12:26:16 2003 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 18 Oct 2003 14:26:16 +0200 Subject: RPM segfaulting Message-ID: <1066479975.21286.22.camel@localhost.localdomain> Hi. I've caught several segmentation faults and other problems with rpm-4.2.1-0.30 in Fedora 0.95 when installing software that's been compiled on a different platform, and is only distributed in binary form. Examples include Acrobat Reader (AR), Real Player (RP) and Flash Player (FP). AR and RP are custom rpms built by myself (with attached specfiles), FP is from macromedia.mplug.org. Now, rpm -ivvh on acrobat-reader-* in a directory with both a-r-5.08.rpm and a-r-plugin-5.0.8.rpm makes rpm segfault. a-r-plugin depends on a-r, and putting them both on the same commandline results in [root at localhost peter]# rpm -ivv acrobat-reader-* D: ============== acrobat-reader-5.0.8-0.fdr.1.i386.rpm D: Expected size: 9131647 = lead(96)+sigs(180)+pad(4)+data(9131367) D: Actual size: 9131647 D: acrobat-reader-5.0.8-0.fdr.1.i386.rpm: MD5 digest: OK (e83fa62e90330323915bbc6726c0ce89) D: added binary package [0] D: ============== acrobat-reader-plugin-5.0.8-0.fdr.1.i386.rpm D: Expected size: 56726 = lead(96)+sigs(180)+pad(4)+data(56446) D: Actual size: 56726 D: acrobat-reader-plugin-5.0.8-0.fdr.1.i386.rpm: MD5 digest: OK (ccbdbea7814c388c3b51907db669b9cb) D: added binary package [1] D: found 0 source and 2 binary packages D: opening db environment /var/lib/rpm/Packages joinenv D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 D: locked db index /var/lib/rpm/Packages D: ========== +++ acrobat-reader-5.0.8-0.fdr.1 i386-linux 0x1 D: opening db index /var/lib/rpm/Depends create mode=0x0 D: opening db index /var/lib/rpm/Basenames rdonly mode=0x0 D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0 D: read h# 1460 Header sanity check: OK D: ========== DSA pubkey id fd372689897da07a D: read h# 32 Header V3 DSA signature: OK, key ID 897da07a D: Requires: /bin/sh YES (db files) Segmentation fault Same situation with RP and FP. However, installing only the acrobat-reader rpm works most of the time, but sometimes (hard to reproduce, but has happened more than once) is gets stuck a la rpm in rh8/9, last output being GZDIO: 3100 reads, 25389892 total bytes in 2.210 secs Strace output from rpm when segfaulting ends with write(2, "========== DSA pubkey id fd37268"..., 42========== DSA pubkey id fd372689897da07a ) = 42 write(2, "D: ", 3D: ) = 3 write(2, " read h# 32 Header V3 DSA s"..., 62 read h# 32 Header V3 DSA signature: OK, key ID 897da07a ) = 62 write(2, "D: ", 3D: ) = 3 write(2, " Requires: /bin/sh "..., 72 Requires: /bin/sh YES (db files) ) = 72 rt_sigprocmask(SIG_BLOCK, ~[RTMIN], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 pread(5, "\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\10\0\0\0\0 \0\0\0\10\0"..., 8192, 0) = 8192 pread(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192, 8192) = 8192 rt_sigprocmask(SIG_BLOCK, ~[RTMIN], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ From peter.backlund at home.se Sat Oct 18 12:34:15 2003 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 18 Oct 2003 14:34:15 +0200 Subject: RPM segfaults - the attachements Message-ID: <1066480455.21286.25.camel@localhost.localdomain> As ususal, I forgot the attchements...here are the specfiles for AR and RP. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: acroread.spec URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: realplayer.spec URL: From johnsonm at redhat.com Sat Oct 18 12:58:58 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Sat, 18 Oct 2003 08:58:58 -0400 Subject: early userspace and volume management In-Reply-To: <20031010182902.GF31195@ti19>; from brugolsky@telemetry-investments.com on Fri, Oct 10, 2003 at 02:29:02PM -0400 References: <20031010182902.GF31195@ti19> Message-ID: <20031018085858.B12648@devserv.devel.redhat.com> On Fri, Oct 10, 2003 at 02:29:02PM -0400, Bill Rugolsky Jr. wrote: > Back in January I started packaging up Device-Mapper, and LVM2, and > made some changes to initscripts, mkinitrd, etc., to get root-on-lvm2. > Now that device-mapper is stabilizing, I'd like to take up this task > again and contribute the changes to Fedora core. Before doing so, > I'd like to solicit some feedback on how to proceed with changes to > early userspace. > > 1. nash is inadequate to the task. Replacing it with a real shell > and other tools will take us over the size limit for > a floppy. Does it matter any more? A kernel with ACPI won't fit > on a floppy either, and we are going to want to include a lot of > userland discovery code in initramfs as we move into 2.7. > > Once we exceed the size of a floppy, is there another "natural" > size constraint that would prevent just using the usual tools, such > as mdadm, perhaps in a multi-call binary or rebuilt against klibc? For 2.6 kernels, where (with ACPI) it just isn't going to fit on a floppy anyway, I see no problems with this approach. An open question is, I guess, whether we want to fork mkinitrd -- should it stick to nash for 2.4 kernels where the possibility of fitting on a floppy still remains? I'd think that for early work, being able to move back and forth between 2.4 and 2.6 kernels would be valuable, and people would complain about regressions if mkinitrd lost the ability to make floppies on 2.4 kernels that would otherwise support them. However, there are multiple ways to achieve that goal; if keeping full support for the 2.4 way of doing things in the same script with the best new methods for 2.6 makes the script harder to read, it's easy to do a version check early on and exec mkinitrd-2.4 (or whatever) as a separate script. That would make it easy to keep the two separate if it's useful to do so. > 2. People are going to use various combinations of MD, Device-Mapper, > LVM2, and EVMS2. Do we want to support the simultaneous, stacked > use of all of these? Is that too complicated, and should, e.g., > (LVM2+dmsetup) and EVMS2 be mutually exclusive? One of the nicest > features of EVMS2 is the support for legacy partitions. This can > also be done with dmsetup and some scripting, or by generalizing LVM2. Right, there are two conflicting goals: o All reasonable stacking should be supported. o Adding options that don't really increase functionality is just asking for more bugs. :-) I do hear some nice things about EVMS2, and their philosophy of making everything Just Work[tm] with a consistent interface is attractive. However, I'm worried about throwing babies out with bathwater; for instance, mdadm is a really nice way to deal with the md layer (like its hot spare migration and monitoring capabilities). This clearly needs lots of discussion, and I have more questions than answers right now. Probably could use a bit of experimentation, too. > 4. Volume management is just one of many tasks that need attention > in early userspace. Is there a roadmap anywhere? Right, there are lots of things that need re-thinking for early userspace. I'm not aware of a formal roadmap document, if that's what you mean. Basically, I see two things here: we need to preserve the functionality of people's existing installations, but we've really got a good opportunity to make radical changes to the mechanism to make it more sane and easier to maintain, blah blah blah... We haven't written up a detailed proposal within Red Hat for precisely what we want to do here; rather, we've got several people on the kernel team who have done significant work on early user space (e.g. Al and Jeff) because we recognize that it's an important change to make, and will enable all sorts of improvements. 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 Sat Oct 18 13:13:59 2003 From: czar at czarc.net (Gene C.) Date: Sat, 18 Oct 2003 09:13:59 -0400 Subject: RPM segfaulting In-Reply-To: <1066479975.21286.22.camel@localhost.localdomain> References: <1066479975.21286.22.camel@localhost.localdomain> Message-ID: <200310180913.59455.czar@czarc.net> On Saturday 18 October 2003 08:26, Peter Backlund wrote: > I've caught several segmentation faults and other problems with > rpm-4.2.1-0.30 in Fedora 0.95 when installing software that's been > compiled on a different platform, and is only distributed in binary > form. Examples include Acrobat Reader (AR), Real Player (RP) and Flash > Player (FP). AR and RP are custom rpms built by myself (with attached > specfiles), FP is from macromedia.mplug.org. I have also seen segfaults (and at least one rpm hang) when I try installing packages built on RHL8 or RHL9. When these packages are rebuilt on FC1-t3, they install OK. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107127 -- Gene From kaboom at gatech.edu Sat Oct 18 14:01:51 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Sat, 18 Oct 2003 10:01:51 -0400 (EDT) Subject: rsync and rawhide In-Reply-To: <20031017164205.GA7303@mark.mielke.cc> References: <20031017164205.GA7303@mark.mielke.cc> Message-ID: On Fri, 17 Oct 2003, Mark Mielke wrote: > I would prefer to use rsync to update my rpm set with rawhide simply because > it communicates the information more efficiently. Lately using 'lftp mirror' > I've noticed that packages sometimes download on top of themselves, perhaps > just because the timestamp of the file has changed? At one point, the machines in the load balance often timestamped files an hour apart. Depending on which box you hit when you did the DNS query, you'd be an hour ahead or an hour behind, and have to mirror everything again. I don't know if that's still the case, since I just picked one and stick with it now. > Even if the RPM had changed (signed after the fact?), rsync would do a > better job than ftp. That's actually what got me thinking about this. I noticed I was downloading all of XFree86 again b/c it was unsigned two days ago, and signed one day ago, so I got it both times. > Note, though, that just because the change was only 4 lines of text, does not > mean that the whole RPM won't need to be downloaded. I was under the > impression that rsync communicates block checksums back and forth. How would > it handle the entire file from offset 4096 being shifted 512 bytes longer > or shorter? Would it not re-transfer the whole file? Not as I understand it. I think the way rsync works is one side blocks, checksums, then sends the checksums to the other side. The other side then does sliding checksums across all possible blocks (not just blocks at corresponding offsets) to find the matching blocks, even if they've shifted to a different offset.... > Also, I think one could argue that rsync should have an option to deal with > this situation - file content not significantly changing, but file name > changing. At *least* for files in the same directory. That's a problem solvable outside of rsync, though. And maybe doing so is better than asking RH to make pseudo-ISOs? later, chris From johnsonm at redhat.com Sat Oct 18 14:05:41 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Sat, 18 Oct 2003 10:05:41 -0400 Subject: Better packaging for older hardware? In-Reply-To: <20031018113648.GA392@inwind.it>; from m.fioretti@inwind.it on Sat, Oct 18, 2003 at 01:36:48PM +0200 References: <20031018062944.GB32004@inwind.it> <200310180951.h9I9p5Y25510@devserv.devel.redhat.com> <20031018113648.GA392@inwind.it> Message-ID: <20031018100541.C12648@devserv.devel.redhat.com> On Sat, Oct 18, 2003 at 01:36:48PM +0200, M. Fioretti wrote: > On Sat, Oct 18, 2003 05:51:05 at 05:51:05AM -0400, Alan Cox (alan at redhat.com) wrote: > > 386/486 kernel RPMs make sense but you probably also want to think > > about that as a seperate kernel with less options selected and > > without the more high end tuning Red Hat has. > > Absolutely. The problem is that we realize this would be a very good > thing, but, almost by definition, have not enough expertise, > bandwidth, and CPU power to investigate all the possible > alternatives. > > Please have a look to the archives of the Linux Kernel Mailing List: > less than a week ago I started a thread there, called "unbloating the > kernel". I almost explicitly say there that few things would make me > happier (software wise, of course) if some real kernel hacker spends > some day explaining to us how to tweak for RULE scenarios the > *official* SRPMs of Red Hat, soon Fedora kernels. > > We can walk (almost) alone after that, just need a very good initial > push in the right direction. Right .config, proper /proc settings, > whatever. It wouldn't be hard for us to provide an appropriately trimmed config file in the kernel srpm, automatically maintained to follow generic changes to the config files but with specific slimming changing, even if we didn't build that kernel by default. It might break without our noticing in that case, but then that could always be fixed... However, the only "slimming" bits we have expertise of any sort in is summed up in the BOOT kernel config file, so we'd need a pretty good idea of what kinds of changes we were going to make that would really satisfy most everyone... That's the real hard part. 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 kaboom at gatech.edu Sat Oct 18 14:06:13 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Sat, 18 Oct 2003 10:06:13 -0400 (EDT) Subject: rsync and rawhide In-Reply-To: <20031017115605.B18024@devserv.devel.redhat.com> References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017115605.B18024@devserv.devel.redhat.com> Message-ID: On Fri, 17 Oct 2003, Bill Nottingham wrote: > Jeremy Portzer (jeremyp at pobox.com) said: > > If the rsync tree was built into ISOs, or some other larger archive > > files that could be loopback-mounted, it would be a better situation for > > rsync. It can then check for differences in the old and new versions > > and only download the differences. > > Building rawhide as ISOs would a) complicate the build process b) > make it more of a hassle to grab a single fix. I was thinking of it in addition to, not in place of, the existing tree > Adding ISOs in *addition* to the files would lead to a rather dramatic > increase in disk space required. At least right now, it looks like 2 gigs for SRPMs, and 2 gigs for each architecture. I'm not sure there'd be much demand for more than i386.... later, chris From johnsonm at redhat.com Sat Oct 18 14:08:09 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Sat, 18 Oct 2003 10:08:09 -0400 Subject: PowerPC support In-Reply-To: ; from pjones@redhat.com on Wed, Oct 01, 2003 at 10:15:31AM -0400 References: <3F79F6AA.6050103@digitalme.com> Message-ID: <20031018100809.D12648@devserv.devel.redhat.com> On Wed, Oct 01, 2003 at 10:15:31AM -0400, Peter Jones wrote: > In principle, as a Red Hat person and an Aurora person, I think you're > right. In practice, not much is going to happen here until we get a real > policy for how to merge changes "upstream" to Fedora, and external access > to some build system for it. I suspect this will still take quite some > time. Right, we have to walk before we can run. :-) First priority is external CVS so that we have a place to merge in, before we can so much as start merging in build systems. 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 kaboom at gatech.edu Sat Oct 18 14:32:28 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Sat, 18 Oct 2003 10:32:28 -0400 (EDT) Subject: rsync and rawhide In-Reply-To: <20031017155935.BB27EF7D61@voldemort.scrye.com> References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017155935.BB27EF7D61@voldemort.scrye.com> Message-ID: On Fri, 17 Oct 2003, Kevin Fenzi wrote: > Someone the other day was telling me that with updates for SuSe you > could pull down all the new rpms, or just pull down changes between > the updated rpm and your current version... > > Ah, there they are... called 'patch rpms'. > From: > > http://www.suse.com/us/private/download/updates/90_i386.html > > "New: Patch RPMs > > As of now we are offering so called Patch RPM packages. A Patch RPM > updates an already installed RPM. It only contains files which have > changed - therefore it is (much) smaller than the complete RPM > package. Prerequisite for installation is an already installed basic > RPM. The packages included on the SUSE LINUX 9.0-CDs/DVD are > considered as basic RPMs. If you want to update an already installed > package, please download the smaller Patch RPM package." > > Something like this would be very handy for keeping up with rawhide, > saving redhat bandwith, and making more people use it as it became > smaller/faster/easer to do. > > Anyone know how they do those? Would that be hard to implement? Interesting. Looking at just one patch.rpm, ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/bluez-bluefw-1.0-68.i586.patch.rpm Dumping the rpm contents shows it contains just a single file (the one which needed to be changed) rpm -qlp on the patch.rpm, however, lists it as containing all the files which are normally in the bluez-bluefw package I guess when it gets installed, it leaves the old files on, replaces the one which needs fixing, then registers in rpmdb? I wonder what happens if you rpm -e the patch? Do you go back to the original package, or do you uninstall the whole package? Looking at the spec file for the rpm, I see no evidence of how the patch.rpm is generated.... At any rate, this on one level at least seems like a bad idea to me. One of the nice things about managing Linux (versus other Unixen) is that on most major Linux distros patch management and software management are the same thing -- patches are just new versions of existing packages, and you install, track, etc. the way you do any packages. That's better than the usual "one set of tools to manage packages, another to manage bugfixes to packages".... The patch.rpm's seem a bit of a step backwards, at least in that respect. later, chris From jensknutson at yahoo.com Sat Oct 18 15:19:20 2003 From: jensknutson at yahoo.com (Jens Knutson) Date: Sat, 18 Oct 2003 10:19:20 -0500 Subject: Union mounts Message-ID: <1066490360.4640.27.camel@binah.upevil.net> I've been doing some research on getting union mounts to work on Linux, but it doesn't appear that Fedora currently supports it! Is this accurate? If so, is there anything on the horizon, or will I have to use *BSD to get this? (ewwwwww.) - jck -- "The bugs in Sawfish, and its greater configurability, are not orthogonal/unrelated facts" -- Havoc Pennington From peter.backlund at home.se Sat Oct 18 21:00:36 2003 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 18 Oct 2003 23:00:36 +0200 Subject: RPM segfaulting In-Reply-To: <1066479975.21286.22.camel@localhost.localdomain> References: <1066479975.21286.22.camel@localhost.localdomain> Message-ID: <1066510836.6118.1.camel@h24n2fls33o1121.telia.com> > I've caught several segmentation faults and other problems with > rpm-4.2.1-0.30 in Fedora 0.95 when installing software that's been Call off the hounds! Problem went away after a --rebuilddb. /Peter From kevin at rocketred.com.au Sat Oct 18 22:36:07 2003 From: kevin at rocketred.com.au (Kevin O'Neill) Date: Sun, 19 Oct 2003 08:36:07 +1000 Subject: Laptop power management In-Reply-To: <20031018011157.GA16185@ra.is> References: <1066433325.9185.44.camel@stantz.corp.sgi.com> <20031018011157.GA16185@ra.is> Message-ID: <1066516567.4815.0.camel@titus.rocketred.net> On Sat, 2003-10-18 at 11:11, Richard Allen wrote: > I just got a HP NX7000 laptop. Beta3 installs nicely (failed to propperly > detect the monitor) and runs very well also. It's even 3D enabled > right out of the box. > > It has no idea on power management tho. "AC on-line, no system battery" You probably need to add acpi=on to your kernel config. -k. -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://blogs.codehaus.org/people/kevin/ Pub Key: http://blogs.codehaus.org/people/kevin/public.asc -------------- 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 czar at czarc.net Sat Oct 18 23:39:37 2003 From: czar at czarc.net (Gene C.) Date: Sat, 18 Oct 2003 19:39:37 -0400 Subject: RPM segfaulting In-Reply-To: <1066510836.6118.1.camel@h24n2fls33o1121.telia.com> References: <1066479975.21286.22.camel@localhost.localdomain> <1066510836.6118.1.camel@h24n2fls33o1121.telia.com> Message-ID: <200310181939.37759.czar@czarc.net> On Saturday 18 October 2003 17:00, Peter Backlund wrote: > > I've caught several segmentation faults and other problems with > > rpm-4.2.1-0.30 in Fedora 0.95 when installing software that's been > > Call off the hounds! Problem went away after a --rebuilddb. It is strange that some of us have this segfault problem which then disappears after we do --rebuilddb -- Gene From wcooley at nakedape.cc Sun Oct 19 00:05:41 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Sat, 18 Oct 2003 17:05:41 -0700 Subject: RPM segfaulting In-Reply-To: <200310181939.37759.czar@czarc.net> References: <1066479975.21286.22.camel@localhost.localdomain> <1066510836.6118.1.camel@h24n2fls33o1121.telia.com> <200310181939.37759.czar@czarc.net> Message-ID: <1066521941.2846.0.camel@denk.nakedape.priv> On Sat, 2003-10-18 at 16:39, Gene C. wrote: > On Saturday 18 October 2003 17:00, Peter Backlund wrote: > > > I've caught several segmentation faults and other problems with > > > rpm-4.2.1-0.30 in Fedora 0.95 when installing software that's been > > > > Call off the hounds! Problem went away after a --rebuilddb. > > It is strange that some of us have this segfault problem which then disappears > after we do --rebuilddb Jeff would probably be very interested in looking at your RPM db and a log of verbose output, since --rebuilddb is supposed to not be necessary any more. 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 paul at gear.dyndns.org Sun Oct 19 00:49:00 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Sun, 19 Oct 2003 10:49:00 +1000 Subject: rsync and rawhide In-Reply-To: References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017155935.BB27EF7D61@voldemort.scrye.com> Message-ID: <3F91DF7C.7010300@gear.dyndns.org> Chris Ricker wrote: > ... > At any rate, this on one level at least seems like a bad idea to me. One of > the nice things about managing Linux (versus other Unixen) is that on most > major Linux distros patch management and software management are the same > thing -- patches are just new versions of existing packages, and you > install, track, etc. the way you do any packages. That's better than the > usual "one set of tools to manage packages, another to manage bugfixes to > packages".... The patch.rpm's seem a bit of a step backwards, at least in > that respect. Hear, hear! Anyone who complains about RPM dependency hell has obviously never needed to deal with HP-UX Software Distributor patch bundle hell. :-) -- 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 paul at gear.dyndns.org Sun Oct 19 00:54:12 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Sun, 19 Oct 2003 10:54:12 +1000 Subject: Better packaging for older hardware? In-Reply-To: References: <20031018062944.GB32004@inwind.it> <20031018084346.GC32004@inwind.it> <3F91055A.90603@gear.dyndns.org> Message-ID: <3F91E0B4.4070305@gear.dyndns.org> Mike A. Harris wrote: > ... >> >>Not a complaint, but why did they/you move changelogs from the doc >>directory into the RPM database? It doesn't seem like a very necessary >>thing... > > > I/we did not and have not ever moved changelogs from doc > directory to rpm database. You misunderstand what an rpm > changelog is. > ... > The two changelogs are totally different in concept, and the rpm > spec file changelog has always existed in rpm and been stored in > the rpm database, and a given upstream program's changelog - if > one exists for a given piece of software has never been stored in > the rpm database. OK - i am now enlightened. Please forgive my ignorance. -- 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 behdad at cs.toronto.edu Sun Oct 19 01:48:30 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sat, 18 Oct 2003 21:48:30 -0400 Subject: Live DVD In-Reply-To: <3F8CE482.3030700@koziarski.com> References: <3F8CE482.3030700@koziarski.com> Message-ID: Is there any plan to have a live DVD out of Fedora? On Wed, 15 Oct 2003, Michael A. Koziarski wrote: > Hey guys, > > I see in the FAQ (http://fedora.redhat.com/about/faq/) that fedora > intends to provide DVD ISOs. Are these available? > > I have a lovely new DVD-Writer and I'm more than happy to help test. > > Cheers > > Koz > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > behdad, who is going to study after finishing this mail. From cmadams at hiwaay.net Sun Oct 19 01:52:34 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 18 Oct 2003 20:52:34 -0500 Subject: rsync and rawhide In-Reply-To: <3F91DF7C.7010300@gear.dyndns.org> References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017155935.BB27EF7D61@voldemort.scrye.com> <3F91DF7C.7010300@gear.dyndns.org> Message-ID: <20031019015234.GB859049@hiwaay.net> Once upon a time, Paul Gear said: > Hear, hear! Anyone who complains about RPM dependency hell has > obviously never needed to deal with HP-UX Software Distributor patch > bundle hell. :-) Try OSF/1^WDigital Unix^W^WCompaq Tru64 Unix^W^W^WHP Tru64 Unix (phew!). Oh wait, I guess one of us will soon be learning the other's pain, since HPAQ is "merging" HP-UX and Tru64! -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From buildsys at porkchop.devel.redhat.com Sun Oct 19 09:29:59 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Sun, 19 Oct 2003 05:29:59 -0400 Subject: rawhide report: 20031019 changes Message-ID: <200310190929.h9J9Txa11660@porkchop.devel.redhat.com> Updated Packages: caching-nameserver-7.2-9 ------------------------ * Sun Oct 19 2003 Dan Walsh - Fix post install processing gnopernicus-0.7.0-4 ------------------- * Sat Oct 18 2003 Florian La Roche - prereq scrollkeeper-update rawhide-release-20031019-1 -------------------------- From peter.backlund at home.se Sun Oct 19 10:01:02 2003 From: peter.backlund at home.se (Peter Backlund) Date: Sun, 19 Oct 2003 12:01:02 +0200 Subject: RPM segfaulting In-Reply-To: <1066521941.2846.0.camel@denk.nakedape.priv> References: <1066479975.21286.22.camel@localhost.localdomain> <1066510836.6118.1.camel@h24n2fls33o1121.telia.com> <200310181939.37759.czar@czarc.net> <1066521941.2846.0.camel@denk.nakedape.priv> Message-ID: <1066557662.6118.5.camel@h24n2fls33o1121.telia.com> > It is strange that some of us have this segfault problem which then disappears > > after we do --rebuilddb > Jeff would probably be very interested in looking at your RPM db and a > log of verbose output, since --rebuilddb is supposed to not be necessary > any more. I ran gdb on a coredump, generating the following output when doing a backtrace: (gdb) bt #0 0x0048bdb2 in _int_malloc () from /lib/tls/libc.so.6 #1 0x0048b10d in malloc () from /lib/tls/libc.so.6 #2 0x007a1727 in headerNEVRA () from /usr/lib/librpmdb-4.2.so #3 0x007ab48f in rpmdbNextIterator () from /usr/lib/librpmdb-4.2.so #4 0x0084c1e1 in ?? () from /usr/lib/librpmdb-4.2.so #5 0x0085a008 in rpmTagTableSize () from /usr/lib/librpmdb-4.2.so #6 0x00000020 in ?? () #7 0x080879e8 in ?? () #8 0x08086528 in ?? () If anyone's interested, I can put the coredump on the web, it's just 900k bzipped. /Peter From Axel.Thimm at physik.fu-berlin.de Sun Oct 19 10:05:51 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Sun, 19 Oct 2003 12:05:51 +0200 Subject: rawhide full install: xemacs-sumo-el and aspell-it Message-ID: <20031019100551.GC8144@puariko.nirvana> The above packages are obsoleted by xemacs-el and aspell. Should they be removed from rawhide? -- 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 peter.backlund at home.se Sun Oct 19 10:29:28 2003 From: peter.backlund at home.se (Peter Backlund) Date: Sun, 19 Oct 2003 12:29:28 +0200 Subject: Repository feature proposal Message-ID: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> Hi. I've been thinking a bit of how to make it easier for people to use repositories as opposed to downloading single pieces of software from the web. Normally, if you come from another operating system, you're used to going to a website, downloading a single installation program, installing it and you're done. So let's say some project or even some company wants to distribute software for Linux (Fedora to be specific). The best way would of course be if they set up a repository with their stuff, since downloading, installation _and_ automatic update checking can be performed within a single application (apt/yum/up2date). >From an (inexperienced) end user perspective, it's not really practical to edit some file in a text editor. It's the weak link in the gui chain. Now, my idea is to create some sort of file format describing the repository, that can be "imported" by the software management program (up2date/r-c-packages). That way, you can publish one such repository description file on your website, that users download an import (or even open directly from in the browser), and then all your software can be accessed from the same management tool. Perhaps one could create "repository rpms", similar to how public GPG keys are imported and stored in the rpm db? Advantages over even the Windows(r)(tm)(c) way are: - Automatic update checking. - Consistent installation (and removal) procedure across all applications. An example of how another distribution handles 3:rd party repositories can be found at http://plf.zarb.org/~nanardon/ It boils down to "paste these commands in a root terminal". This is a very small step up from the traditional "put this in your source.list". So, what do you all think about this? /Peter From alan at redhat.com Sun Oct 19 12:23:40 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 19 Oct 2003 08:23:40 -0400 (EDT) Subject: Repository feature proposal In-Reply-To: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> from "Peter Backlund" at Hyd 19, 2003 12:29:28 Message-ID: <200310191223.h9JCNet03317@devserv.devel.redhat.com> > Now, my idea is to create some sort of file format describing the > repository, that can be "imported" by the software management program > (up2date/r-c-packages). That way, you can publish one such repository > description file on your website, that users download an import (or even > open directly from in the browser), and then all your software can be > accessed from the same management tool. Perhaps one could create > "repository rpms", similar to how public GPG keys are imported and > stored in the rpm db? An "application/x-yum-repository" file format which mozilla knew how to feed to a simple app would certainly be nice. You'd still need a simple management tool as you say - so people can remove them, but "click here to add Nethack" is a nice interface 8) From occy at occy.net Sun Oct 19 12:26:31 2003 From: occy at occy.net (Trae McCombs) Date: Sun, 19 Oct 2003 08:26:31 -0400 Subject: rsync and rawhide In-Reply-To: References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017155935.BB27EF7D61@voldemort.scrye.com> Message-ID: <1066566391.3352.45.camel@miami> On Sat, 2003-10-18 at 10:32, Chris Ricker wrote: > On Fri, 17 Oct 2003, Kevin Fenzi wrote: > > > Someone the other day was telling me that with updates for SuSe you > > could pull down all the new rpms, or just pull down changes between > > the updated rpm and your current version... > > > > Ah, there they are... called 'patch rpms'. > > From: > > > > http://www.suse.com/us/private/download/updates/90_i386.html > > > > "New: Patch RPMs > > > > As of now we are offering so called Patch RPM packages. A Patch RPM > > updates an already installed RPM. It only contains files which have > > changed - therefore it is (much) smaller than the complete RPM > > package. Prerequisite for installation is an already installed basic > > RPM. The packages included on the SUSE LINUX 9.0-CDs/DVD are > > considered as basic RPMs. If you want to update an already installed > > package, please download the smaller Patch RPM package." > > > > Something like this would be very handy for keeping up with rawhide, > > saving redhat bandwith, and making more people use it as it became > > smaller/faster/easer to do. > > > > Anyone know how they do those? Would that be hard to implement? > > Interesting. Looking at just one patch.rpm, > > ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/bluez-bluefw-1.0-68.i586.patch.rpm > > Dumping the rpm contents shows it contains just a single file (the one which > needed to be changed) > > rpm -qlp on the patch.rpm, however, lists it as containing all the files > which are normally in the bluez-bluefw package > > I guess when it gets installed, it leaves the old files on, replaces the one > which needs fixing, then registers in rpmdb? I wonder what happens if you > rpm -e the patch? Do you go back to the original package, or do you > uninstall the whole package? > > Looking at the spec file for the rpm, I see no evidence of how the patch.rpm > is generated.... > > At any rate, this on one level at least seems like a bad idea to me. One of > the nice things about managing Linux (versus other Unixen) is that on most > major Linux distros patch management and software management are the same > thing -- patches are just new versions of existing packages, and you > install, track, etc. the way you do any packages. That's better than the > usual "one set of tools to manage packages, another to manage bugfixes to > packages".... The patch.rpm's seem a bit of a step backwards, at least in > that respect. (putting this at the bottom like a good little boy...) I know I'm not the most technically inclined person, and I know I've not fully followed this thread. However, I do feel in the case of saving bandwidth, and making upgrades more accessible to those that are limited with their pipes, I think it makes sense to have a low-file-sized solution for those wishing to upgrade their full systems. For instance, Let's say I've completed a full install of FC1.0 (I know it's not out), and then when the next release comes, I could download a "patch.ISO" of roughly 300megs or so, I'm guessing(probably incorrectly) that this would be the difference from one version to the next. At any rate, it would be nice to be able to download a patch.ISO that's one CD, and have it patch/upgrade your system, instead of having to download 3 iso's. Again, I'm sure I've missed the point, but it's my 2 pennies. Trae From julo at altern.org Sun Oct 19 12:34:43 2003 From: julo at altern.org (Julien Olivier) Date: Sun, 19 Oct 2003 13:34:43 +0100 Subject: Repository feature proposal In-Reply-To: <200310191223.h9JCNet03317@devserv.devel.redhat.com> References: <200310191223.h9JCNet03317@devserv.devel.redhat.com> Message-ID: <1066566883.2960.2.camel@localhost.localdomain> On Sun, 2003-10-19 at 13:23, Alan Cox wrote: > > Now, my idea is to create some sort of file format describing the > > repository, that can be "imported" by the software management program > > (up2date/r-c-packages). That way, you can publish one such repository > > description file on your website, that users download an import (or even > > open directly from in the browser), and then all your software can be > > accessed from the same management tool. Perhaps one could create > > "repository rpms", similar to how public GPG keys are imported and > > stored in the rpm db? > > An "application/x-yum-repository" file format which mozilla knew how to > feed to a simple app would certainly be nice. > > You'd still need a simple management tool as you say - so people can remove > them, but "click here to add Nethack" is a nice interface 8) > IMO, the main problem would be that you need root privileges to modify yum sources, don't you ? But Mozilla could as well launch a gnome-su-type application... > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Julien Olivier From veillard at redhat.com Sun Oct 19 12:49:09 2003 From: veillard at redhat.com (Daniel Veillard) Date: Sun, 19 Oct 2003 08:49:09 -0400 Subject: Repository feature proposal In-Reply-To: <200310191223.h9JCNet03317@devserv.devel.redhat.com>; from alan@redhat.com on Sun, Oct 19, 2003 at 08:23:40AM -0400 References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> Message-ID: <20031019084909.D16905@redhat.com> On Sun, Oct 19, 2003 at 08:23:40AM -0400, Alan Cox wrote: > > Now, my idea is to create some sort of file format describing the > > repository, that can be "imported" by the software management program > > (up2date/r-c-packages). That way, you can publish one such repository > > description file on your website, that users download an import (or even > > open directly from in the browser), and then all your software can be > > accessed from the same management tool. Perhaps one could create > > "repository rpms", similar to how public GPG keys are imported and > > stored in the rpm db? > > An "application/x-yum-repository" file format which mozilla knew how to > feed to a simple app would certainly be nice. > > You'd still need a simple management tool as you say - so people can remove > them, but "click here to add Nethack" is a nice interface 8) May I suggest using an XML file format [1] ? In that case adding a "+xml" suffix to the Mime-Type is a good idea (c.f. RFC 3023). There is also some work on-going to define XML description of packages. Daniel [1] mostly for I18N support and extensibility for the format -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From tdiehl at rogueind.com Sun Oct 19 13:54:19 2003 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 19 Oct 2003 09:54:19 -0400 (EDT) Subject: rsync and rawhide In-Reply-To: <1066566391.3352.45.camel@miami> Message-ID: On Sun, 19 Oct 2003, Trae McCombs wrote: > (putting this at the bottom like a good little boy...) Trimming like a good little boy would have been even better. :-) > I know I'm not the most technically inclined person, and I know I've not > fully followed this thread. However, I do feel in the case of saving > bandwidth, and making upgrades more accessible to those that are limited > with their pipes, I think it makes sense to have a low-file-sized > solution for those wishing to upgrade their full systems. > > For instance, Let's say I've completed a full install of FC1.0 (I know > it's not out), and then when the next release comes, I could download a > "patch.ISO" of roughly 300megs or so, I'm guessing(probably incorrectly) > that this would be the difference from one version to the next. At any > rate, it would be nice to be able to download a patch.ISO that's one CD, > and have it patch/upgrade your system, instead of having to download 3 > iso's. Sounds good on the surface but in reality it does not get you much when you go from major release to major release. The changes are just too great. I have used rsync to "update" iso's many times and while it does save some time/bandwidth on a major release it typically does not save much. Generally speaking even when going from a test1 to test2 etc. the savings are minimal. HTH, -- ......Tom Registered Linux User #14522 http://counter.li.org tdiehl at rogueind.com My current SpamTrap -------> mtd123 at rogueind.com From mike at theoretic.com Sun Oct 19 14:23:01 2003 From: mike at theoretic.com (Mike Hearn) Date: Sun, 19 Oct 2003 15:23:01 +0100 Subject: Repository feature proposal In-Reply-To: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> Message-ID: <1066573381.2987.16.camel@littlegreen> I think a nicer way to do this would be to extend the .desktop file format, then teach browsers how to render them as icons. It's not hard to do, just needs somebody to either write a Netscape plugin or learn XBL/XPCOM (that'd be the best way for mozilla i'd think) and then allow clicking on the icon to launch: yum add-repository http://foo.bar.org/repo yum install whatever consolehelper takes care of the authentication. Really, this is a job that'd take a few days, if that, the hard bit is getting the extensions to the .desktop format accepted by the community (obviously it'd be nice if they weren't yum specific). You then get a nice embedded launching UI in the browser, and it's not a big leap to go to a drag'n'drop UI from there. From peter.backlund at home.se Sun Oct 19 14:43:33 2003 From: peter.backlund at home.se (Peter Backlund) Date: Sun, 19 Oct 2003 16:43:33 +0200 Subject: Repository feature proposal In-Reply-To: <1066566883.2960.2.camel@localhost.localdomain> References: <200310191223.h9JCNet03317@devserv.devel.redhat.com> <1066566883.2960.2.camel@localhost.localdomain> Message-ID: <1066574612.6118.47.camel@h24n2fls33o1121.telia.com> > > An "application/x-yum-repository" file format which mozilla knew how to > > feed to a simple app would certainly be nice. > > > > You'd still need a simple management tool as you say - so people can remove > > them, but "click here to add Nethack" is a nice interface 8) > > > > IMO, the main problem would be that you need root privileges to modify > yum sources, don't you ? But Mozilla could as well launch a > gnome-su-type application... The repository management would be integrated to up2date-config (or perhaps r-c-packages), where you could list, edit and remove repositories - edit /etc/sysconfig/rhn/sources basically. This would fit repositories falling into the "3:rd party" category of the Fedora project quite well, I think. Especially now that up2date supports both apt, yum and up2date repositories. Instead of "download this file, double click it to start installation, click next, next, next, finish", you'd have "click here to import repository, then locate 'Nethack' under Amusement/Games in the Software Manager, click install". Slightly different, but comparably user-friendly. And you get the benefits of automatic updates and consistent installation that I mentioned earlier. /Peter From czar at czarc.net Sun Oct 19 15:25:38 2003 From: czar at czarc.net (Gene C.) Date: Sun, 19 Oct 2003 11:25:38 -0400 Subject: RPM segfaulting In-Reply-To: <1066521941.2846.0.camel@denk.nakedape.priv> References: <1066479975.21286.22.camel@localhost.localdomain> <200310181939.37759.czar@czarc.net> <1066521941.2846.0.camel@denk.nakedape.priv> Message-ID: <200310191125.38460.czar@czarc.net> On Saturday 18 October 2003 20:05, Wil Cooley wrote: > On Sat, 2003-10-18 at 16:39, Gene C. wrote: > > On Saturday 18 October 2003 17:00, Peter Backlund wrote: > > > > I've caught several segmentation faults and other problems with > > > > rpm-4.2.1-0.30 in Fedora 0.95 when installing software that's been > > > > > > Call off the hounds! Problem went away after a --rebuilddb. > > > > It is strange that some of us have this segfault problem which then > > disappears after we do --rebuilddb > > Jeff would probably be very interested in looking at your RPM db and a > log of verbose output, since --rebuilddb is supposed to not be necessary > any more. I agree ... but he would likely be interested in the copy BEFORE I ran --rebuilddb ... which I do not have. Since more than one person has had this problem, hopefully the next person to get the problem will save a copy before doing --rebuilddb. -- Gene From blizzard at redhat.com Sun Oct 19 15:32:56 2003 From: blizzard at redhat.com (Christopher Blizzard) Date: Sun, 19 Oct 2003 11:32:56 -0400 Subject: Repository feature proposal In-Reply-To: <200310191223.h9JCNet03317@devserv.devel.redhat.com> References: <200310191223.h9JCNet03317@devserv.devel.redhat.com> Message-ID: <3F92AEA8.3050505@redhat.com> Alan Cox wrote: >>Now, my idea is to create some sort of file format describing the >>repository, that can be "imported" by the software management program >>(up2date/r-c-packages). That way, you can publish one such repository >>description file on your website, that users download an import (or even >>open directly from in the browser), and then all your software can be >>accessed from the same management tool. Perhaps one could create >>"repository rpms", similar to how public GPG keys are imported and >>stored in the rpm db? >> >> > >An "application/x-yum-repository" file format which mozilla knew how to >feed to a simple app would certainly be nice. > >You'd still need a simple management tool as you say - so people can remove >them, but "click here to add Nethack" is a nice interface 8) > > > > To do so is trivial, of course. We need to have a nice app for people to use, of cource. Once that happens it's pretty easy to make an application mapping for Mozilla to use. --Chris -- ------------ Christopher Blizzard http://people.redhat.com/blizzard/ ------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nicolas.Mailhot at laPoste.net Sun Oct 19 15:34:56 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 19 Oct 2003 17:34:56 +0200 Subject: Repository feature proposal In-Reply-To: <20031019084909.D16905@redhat.com> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> Message-ID: <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> Le dim 19/10/2003 ? 14:49, Daniel Veillard a ?crit : > On Sun, Oct 19, 2003 at 08:23:40AM -0400, Alan Cox wrote: > > > Now, my idea is to create some sort of file format describing the > > > repository, that can be "imported" by the software management program > > > (up2date/r-c-packages). That way, you can publish one such repository > > > description file on your website, that users download an import (or even > > > open directly from in the browser), and then all your software can be > > > accessed from the same management tool. Perhaps one could create > > > "repository rpms", similar to how public GPG keys are imported and > > > stored in the rpm db? > > > > An "application/x-yum-repository" file format which mozilla knew how to > > feed to a simple app would certainly be nice. > > > > You'd still need a simple management tool as you say - so people can remove > > them, but "click here to add Nethack" is a nice interface 8) > > May I suggest using an XML file format [1] ? In that case adding > a "+xml" suffix to the Mime-Type is a good idea (c.f. RFC 3023). > There is also some work on-going to define XML description of packages. Really the on-disk format should be an xml file per repository in a foo.d directory that is scanned by the package manager on startup. Life is so much easier when you don't have to share a single file. This repository descriptor could contain the name and description of the repository (maybe in several languages) and the full list of mirrors urls, maybe even en embedded list of gpg keys the repository rpms are supposed to be signed with. The repository manager would just then ping all the mirrors on the list, get the "best" one (closest/more up-to date) and check that the downloaded packages match the declared keys. Removing a repository would then just consist in rm-ing the repository descriptor. This is more or less how fedora.us handles the macromedia plugin repository, except the descriptor format is not too nice and apt requires several files per repository (urls, vendor keys, etc) 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 Sun Oct 19 15:45:34 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 19 Oct 2003 11:45:34 -0400 Subject: Repository feature proposal In-Reply-To: <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> Message-ID: <1066578334.30112.9.camel@binkley> > Really the on-disk format should be an xml file per repository in a > foo.d directory that is scanned by the package manager on startup. > > Life is so much easier when you don't have to share a single file. There is work going on in the development branch of yum to allow for a dir like this. We're using configparser format instead of xml b/c it makes the config files very easy for humans to grok, I have a few problems using xml for a config file that people need to edit b/c I've found xml config files tend to confuse users. xml for data that a program has to use/parse is excellent but while xml IS human editable it's not always trivially so. The functionality mentioned above won't be in 2.0.X but it will be in 2.Y.X where Y > 0 :) -sv From jaap_haitsma at zonnet.nl Sun Oct 19 15:53:53 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Sun, 19 Oct 2003 17:53:53 +0200 Subject: Gnome System Tools toughts Message-ID: <3F92B391.6090501@zonnet.nl> Hi, I came across the announcement of a new version of Gnome System Tools (a project lead by Ximian) a few days ago. They resemble the redhat config tools quite a bit, though they have only have 5 tools up to now (not really production ready according to the website but still) # Users and groups # Date and time # Network configuration # Bootloaders # Runlevels See: http://www.gnome.org/projects/gst/index.html The nice thing is that the front end (The GUI) is distribution independent and the backend (configuration files etc.) are distribution dependent. Just some thoughts/questions. Wouldn't it be better for RedHat, SuSE, Debian etc. to just join this effort. It's a lot more effective then every distro provider making their own tools. (I see that there's maybe an issue for KDE users) Are there any initiatives to have a standard of configuration files, which are used by all providers. I heard of LSB, but it seems to me they do not standardise configuration files. Jaap From Nicolas.Mailhot at laPoste.net Sun Oct 19 16:10:20 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 19 Oct 2003 18:10:20 +0200 Subject: rsync and rawhide In-Reply-To: <1066566391.3352.45.camel@miami> References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017155935.BB27EF7D61@voldemort.scrye.com> <1066566391.3352.45.camel@miami> Message-ID: <1066579820.11018.48.camel@m70.net81-64-235.noos.fr> Le dim 19/10/2003 ? 14:26, Trae McCombs a ?crit : > (putting this at the bottom like a good little boy...) > > I know I'm not the most technically inclined person, and I know I've not > fully followed this thread. However, I do feel in the case of saving > bandwidth, and making upgrades more accessible to those that are limited > with their pipes, I think it makes sense to have a low-file-sized > solution for those wishing to upgrade their full systems. [...] Sure. Everyone here recognises saving bandwidth is good. What a lot of people said is you don't have to compromise the standalone-package system to get it. Most people who have been working with "patch" systems just know they are a hell to manage. There are many ways to save on bandwidth without going the patch route (I'll talk one-computer setups here - people with big/medium/small networks will probably be better of with a private rsynced mirror of the iso area) - only download the packages that need updating. This has been possible for years now with apt/yum and before with solutions like autorpm. You should realise most people only use one DE (with bits of the other), office stuff or server stuff, etc Just using apt/yum this will probably save you between one and 1.5 "isos" now. You won't get the special update routines one can slip into a full-distro just-for-this-release updater, but really all the special one-off stuff should be merged into the packages themselves. It's a testimony to RH's overall quality that has been mostly working for a long time. And I'm firmly convinced Fedora will require more people doing Rawhide syncs, ie you'd better get this working all the times because one can not roll out a new updater for each rawhide update. - perform rsync-like operations so the diffing between packages is handled automagically and you still get full packages after the download (ie have a mirror area of all installed packages, and let the download manager reconstitue new packages with bits of the old ones). With modern disks sizes maintaining this mirror area is nothing, and anyway it can help a lot if part of the fs is destroyed (ie have something do a rpm -Va and reinstall all damaged stuff). The main problem with vanilla rsync is packages filenames change, and the packages themselves can be reorganised (split/merged/renamed whatever). But if apt/yum can know what package replaces another, it should certainly be possible to write a specialized rsync that knows it too. The main point of all this is any patches system puts the burden of reassembling on the user (and packager, if the Suse system is what I think it is they have to manually roll patch rpms in addition to regular packages), just like traditional click-to-download systems put the burden of dependency checking on the user. I don't want to spend a minute of my precious time doing patch management - it should be handled transparently and automatically, ie the user gets the same results as if he'd done a full download without having to bother minding the tricks the system used to save ressources. 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 Nicolas.Mailhot at laPoste.net Sun Oct 19 16:24:43 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 19 Oct 2003 18:24:43 +0200 Subject: Repository feature proposal In-Reply-To: <1066578334.30112.9.camel@binkley> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> Message-ID: <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> Le dim 19/10/2003 ? 17:45, seth vidal a ?crit : > > Really the on-disk format should be an xml file per repository in a > > foo.d directory that is scanned by the package manager on startup. > > > > Life is so much easier when you don't have to share a single file. > > There is work going on in the development branch of yum to allow for a > dir like this. We're using configparser format instead of xml b/c it > makes the config files very easy for humans to grok, I have a few > problems using xml for a config file that people need to edit b/c I've > found xml config files tend to confuse users. xml for data that a > program has to use/parse is excellent but while xml IS human editable > it's not always trivially so. Sure - however xml is getting more prevalent and even if it's not the easiest format to grok for a human it's always easier than learn yet-another-config-file format. (speaking from experience I was severilly disoriented when I first discovered the xml files tomcat uses - it was not "the apache way". Now I'd kill to get apache xml-ize it's format) Really if one doesn't forget to put comments in the file, use strict dtd checks so the app can tell on startup what errors were made, does not forget to indent properly its file and uses a logical namespace xml can be a joy to read. People do forget xml "verbosity" is here to help human readers. fontconfig & tomcat are great examples of readable xml. gconf stuff OTOH shows what one can get when people use xml like some sort of primal soup (kind of strange when one of the goals of gconf was to avoid opaque binary formats). 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 Sun Oct 19 16:23:47 2003 From: julo at altern.org (Julien Olivier) Date: Sun, 19 Oct 2003 17:23:47 +0100 Subject: Gnome System Tools toughts In-Reply-To: <3F92B391.6090501@zonnet.nl> References: <3F92B391.6090501@zonnet.nl> Message-ID: <1066580627.3179.3.camel@localhost.localdomain> (snip) > Wouldn't it be better for RedHat, SuSE, Debian etc. to just join this > effort. It's a lot more effective then every distro provider making > their own tools. (I see that there's maybe an issue for KDE users) > Upper, you said that the UI was split from the backend. If that's true, that means that it should be possible to add a KDE GUI too, shouldn't it ? From kevin-redhat-devel at scrye.com Sun Oct 19 16:33:53 2003 From: kevin-redhat-devel at scrye.com (Kevin Fenzi) Date: Sun, 19 Oct 2003 10:33:53 -0600 Subject: rsync and rawhide References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017155935.BB27EF7D61@voldemort.scrye.com> Message-ID: <20031019163357.6693BF7D61@voldemort.scrye.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Chris" == Chris Ricker writes: Chris> On Fri, 17 Oct 2003, Kevin Fenzi wrote: >> Someone the other day was telling me that with updates for SuSe you >> could pull down all the new rpms, or just pull down changes between >> the updated rpm and your current version... >> >> Ah, there they are... called 'patch rpms'. From: >> >> http://www.suse.com/us/private/download/updates/90_i386.html >> >> "New: Patch RPMs >> >> As of now we are offering so called Patch RPM packages. A Patch RPM >> updates an already installed RPM. It only contains files which have >> changed - therefore it is (much) smaller than the complete RPM >> package. Prerequisite for installation is an already installed >> basic RPM. The packages included on the SUSE LINUX 9.0-CDs/DVD are >> considered as basic RPMs. If you want to update an already >> installed package, please download the smaller Patch RPM package." >> >> Something like this would be very handy for keeping up with >> rawhide, saving redhat bandwith, and making more people use it as >> it became smaller/faster/easer to do. >> >> Anyone know how they do those? Would that be hard to implement? Chris> Interesting. Looking at just one patch.rpm, Chris> ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/bluez-bluefw-1.0-68.i586.patch.rpm Chris> Dumping the rpm contents shows it contains just a single file Chris> (the one which needed to be changed) Chris> rpm -qlp on the patch.rpm, however, lists it as containing all Chris> the files which are normally in the bluez-bluefw package Chris> I guess when it gets installed, it leaves the old files on, Chris> replaces the one which needs fixing, then registers in rpmdb? I Yeah, that looks to be the case... so this 'patch.rpm' is newer than the version you have installed. It 'upgrades' to it, which just changes the one file leaving the others in place just as they were, and now the rpm database has that version as the installed version. Chris> wonder what happens if you rpm -e the patch? Do you go back to Chris> the original package, or do you uninstall the whole package? uninstall the entire package I would think. Chris> Looking at the spec file for the rpm, I see no evidence of how Chris> the patch.rpm is generated.... Yeah, not much info on it. ;( Chris> At any rate, this on one level at least seems like a bad idea Chris> to me. One of the nice things about managing Linux (versus Chris> other Unixen) is that on most major Linux distros patch Chris> management and software management are the same thing -- Chris> patches are just new versions of existing packages, and you Chris> install, track, etc. the way you do any packages. That's better Chris> than the usual "one set of tools to manage packages, another to Chris> manage bugfixes to packages".... The patch.rpm's seem a bit of Chris> a step backwards, at least in that respect. Well, the would still use rpm or whatever package management, just would require less download time. Without the infrastructure that Suse has setup for it tho, it would take a while to implement. I guess we are back to rsync and clever re-naming for now. Chris> later, chris kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQE/krz13imCezTjY0ERArDBAJ4xEEON3dMlYf2NnlsFPyHbFcEJ3QCgjWBA t5xuffWrbU0h8xzhBUtPq7U= =eoRj -----END PGP SIGNATURE----- From icon at linux.duke.edu Sun Oct 19 16:59:26 2003 From: icon at linux.duke.edu (Konstantin Riabitsev) Date: Sun, 19 Oct 2003 12:59:26 -0400 Subject: Repository feature proposal In-Reply-To: <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> Message-ID: <1066582765.23774.190.camel@localhost.localdomain> On Sun, 2003-10-19 at 12:24, Nicolas Mailhot wrote: > Sure - however xml is getting more prevalent and even if it's not the > easiest format to grok for a human it's always easier than learn > yet-another-config-file format. Win-ini style config is really easy to learn and edit: [section] variable = value > Really if one doesn't forget to put comments in the file, use strict dtd > checks so the app can tell on startup what errors were made, does not > forget to indent properly its file and uses a logical namespace xml can > be a joy to read. People do forget xml "verbosity" is here to help human > readers. There are several significant drawbacks to using xml for config files. Here is an incomplete list: 1. Having to escape values. You have to make sure that all <, >, & and " characters are escaped, otherwise your config file will break. Reading content with escaped characters is NOT easy or simple, or obvious. Alternatively, one must use &, but are questionably better]]> 2. Having to watch your comments. This section has been commented out, but is illegal, because it has a nested comment inside. --> It is very important for a sysadmin to be able to comment out parts of some config files. It quickly becomes very irritating if they have to constantly make sure that there are no nested comments inside these config files, or that there are no double dashes used anywhere. 3. Keeping your DTD/Schema definitions current quickly becomes a burden. You can't just add a new configuration directive -- if your app relies on DTD checking for validity, you then have to edit your DTD. My rule has been: 1. If the config file can be expressed in simple section/variable/value pairs, then use win.ini-style config files. They are easy to read, easy to edit, and they don't require extra effort to keep valid. If, however, that is not sufficient to express your config, then use XML. Let's face it -- most config data is just assigning values to variables, and for that XML is an overkill. Regards, -- Konstantin Riabitsev Linux at DUKE From Nicolas.Mailhot at laPoste.net Sun Oct 19 17:06:18 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 19 Oct 2003 19:06:18 +0200 Subject: Repository feature proposal In-Reply-To: <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> Message-ID: <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> Le dim 19/10/2003 ? 18:24, Nicolas Mailhot a ?crit : > Le dim 19/10/2003 ? 17:45, seth vidal a ?crit : > > There is work going on in the development branch of yum to allow for a > > dir like this. We're using configparser format instead of xml b/c it > > makes the config files very easy for humans to grok, I have a few > > problems using xml for a config file that people need to edit b/c I've > > found xml config files tend to confuse users. > > Sure - however xml is getting more prevalent and even if it's not the > easiest format to grok for a human it's always easier than learn > yet-another-config-file format. [ Replying to myself since I fear I wasn't too clear ] Something like this is perfectly human-readable and valid xml. I fail to see how un-xmlizing could make it more readable. Fedora ..... ..... ..... ..... ..... Red Hat .... .... Foo University Universit? Foo Only .edus please R?serv? au monde ?ducatif ... -- 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 Sun Oct 19 17:30:59 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 19 Oct 2003 19:30:59 +0200 Subject: Repository feature proposal In-Reply-To: <1066582765.23774.190.camel@localhost.localdomain> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> <1066582765.23774.190.camel@localhost.localdomain> Message-ID: <1066584658.11670.42.camel@m70.net81-64-235.noos.fr> Le dim 19/10/2003 ? 18:59, Konstantin Riabitsev a ?crit : > On Sun, 2003-10-19 at 12:24, Nicolas Mailhot wrote: > > Sure - however xml is getting more prevalent and even if it's not the > > easiest format to grok for a human it's always easier than learn > > yet-another-config-file format. > > Win-ini style config is really easy to learn and edit: > > [section] > variable = value > > > Really if one doesn't forget to put comments in the file, use strict dtd > > checks so the app can tell on startup what errors were made, does not > > forget to indent properly its file and uses a logical namespace xml can > > be a joy to read. People do forget xml "verbosity" is here to help human > > readers. > > There are several significant drawbacks to using xml for config files. > Here is an incomplete list: > > 1. Having to escape values. > > You have to make sure that all <, >, & and " characters > are escaped, otherwise your config file will break. Reading content > with escaped characters is NOT easy or simple, or obvious. > Alternatively, one must use constructs, which allow <>&, but are questionably better]]> > Which is fine and nice to say for non-i18ned stuff. In real life win.ini-style files fail in strange and wonderful ways when one uses non-english comments/data (of course it all depends on your data, if you need lots of <, >, & XML can be a PITA) The " is a non-problem unless you are abusing attributes to get long textual descriptions. > 2. Having to watch your comments. > > > > This section has been commented out, but is illegal, because it has a > nested comment inside. > --> > > > > It is very important for a sysadmin to be able to comment out parts of > some config files. It quickly becomes very irritating if they have to > constantly make sure that there are no nested comments inside these > config files, or that there are no double dashes used anywhere. This one is a little pain, right. Most modern text editors however grok xml, will do syntax highlighting and show where comments start/end. > 3. Keeping your DTD/Schema definitions current quickly becomes a burden. > You can't just add a new configuration directive -- if your app relies > on DTD checking for validity, you then have to edit your DTD. So what ? If you are advocating skipping checks to save development time I disagree. I've been bitten enough times by apps that behaved in strange way because they "saved time" by not checking their conf file validity, and I made a typo. We are talking about people changing stuff in the files manually. Saving on checks won't do them any service. > My rule has been: > 1. If the config file can be expressed in simple section/variable/value > pairs, then use win.ini-style config files. They are easy to read, easy > to edit, and they don't require extra effort to keep valid. If, however, > that is not sufficient to express your config, then use XML. Let's face > it -- most config data is just assigning values to variables, and for > that XML is an overkill. I more or less agree with you except my threshold to switch to xml is much lower (ie use flat files for flat short ascii name-value data, even a single section-level hierarchy justifies moving to xml). Suppressing checks won't help users. Writing your own check system is more painful than using dtds/schemas. If you have enough entries your file could be made more readable by adding hierarchy. Most text editors are more and more xml-aware when other formats have reached a ceiling long ago. A good xml mode can provide contexts, hints etc. smb.conf is a perfect example of win.ini hell. java .properties are another example of flat-files retrofitted to host hierarchical data without consideration for humans. 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 jaap_haitsma at zonnet.nl Sun Oct 19 18:01:07 2003 From: jaap_haitsma at zonnet.nl (Jaap A. Haitsma) Date: Sun, 19 Oct 2003 20:01:07 +0200 Subject: Gnome System Tools toughts In-Reply-To: <1066580627.3179.3.camel@localhost.localdomain> References: <3F92B391.6090501@zonnet.nl> <1066580627.3179.3.camel@localhost.localdomain> Message-ID: <3F92D163.7080909@zonnet.nl> Julien Olivier wrote: > (snip) > > >>Wouldn't it be better for RedHat, SuSE, Debian etc. to just join this >>effort. It's a lot more effective then every distro provider making >>their own tools. (I see that there's maybe an issue for KDE users) >> > > > Upper, you said that the UI was split from the backend. If that's true, > that means that it should be possible to add a KDE GUI too, shouldn't it > ? Sorry for not being really with the issue. Of course it can run under KDE you'll only need to install a whole lot of gnome libraries to get it to run. KDE purist maybe don't like that. But then current redhat tools you also need to have a lot of stuff installed you'll probably never use. Jaap From tdiehl at rogueind.com Sun Oct 19 18:04:37 2003 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 19 Oct 2003 14:04:37 -0400 (EDT) Subject: Repository feature proposal In-Reply-To: <1066578334.30112.9.camel@binkley> Message-ID: On Sun, 19 Oct 2003, seth vidal wrote: > > > Really the on-disk format should be an xml file per repository in a > > foo.d directory that is scanned by the package manager on startup. > > > > Life is so much easier when you don't have to share a single file. > > There is work going on in the development branch of yum to allow for a > dir like this. We're using configparser format instead of xml b/c it > makes the config files very easy for humans to grok, I have a few > problems using xml for a config file that people need to edit b/c I've > found xml config files tend to confuse users. xml for data that a > program has to use/parse is excellent but while xml IS human editable > it's not always trivially so. + 10!! -- ......Tom Registered Linux User #14522 http://counter.li.org tdiehl at rogueind.com My current SpamTrap -------> mtd123 at rogueind.com From alan at redhat.com Sun Oct 19 18:38:27 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 19 Oct 2003 14:38:27 -0400 (EDT) Subject: Repository feature proposal In-Reply-To: <1066582765.23774.190.camel@localhost.localdomain> from "Konstantin Riabitsev" at Hyd 19, 2003 12:59:26 Message-ID: <200310191838.h9JIcRx18636@devserv.devel.redhat.com> > 1. Having to escape values. > > You have to make sure that all <, >, & and " characters > are escaped, otherwise your config file will break. Reading content > with escaped characters is NOT easy or simple, or obvious. > Alternatively, one must use constructs, which allow <>&, but are questionably better]]> > Similar problems occur with other formats. Try a multibyte character one byte of which is '"' or '\n' in .ini format. XML also makes the format extensible and means you already have tools to autogenerate it, to turn it into up2date lines, yum lines, html, or edit it. Alan From skvidal at phy.duke.edu Sun Oct 19 18:45:15 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 19 Oct 2003 14:45:15 -0400 Subject: Repository feature proposal In-Reply-To: <200310191838.h9JIcRx18636@devserv.devel.redhat.com> References: <200310191838.h9JIcRx18636@devserv.devel.redhat.com> Message-ID: <1066589115.3612.6.camel@binkley> > Similar problems occur with other formats. Try a multibyte character one > byte of which is '"' or '\n' in .ini format. > > XML also makes the format extensible and means you already have tools to > autogenerate it, to turn it into up2date lines, yum lines, html, or edit it. > This was something I was talking about with some other folks on irc - if there was an xml representation of a 'definition' of a repository/channel - then you could write converters/renderers for all the other layouts. going from xml to any other format is pretty easy. -sv From barryn at pobox.com Sun Oct 19 19:23:04 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Sun, 19 Oct 2003 12:23:04 -0700 Subject: RPM segfaulting In-Reply-To: <200310191125.38460.czar@czarc.net> References: <1066479975.21286.22.camel@localhost.localdomain> <200310181939.37759.czar@czarc.net> <1066521941.2846.0.camel@denk.nakedape.priv> <200310191125.38460.czar@czarc.net> Message-ID: <20031019192304.GA26100@ip68-4-255-84.oc.oc.cox.net> On Sun, Oct 19, 2003 at 11:25:38AM -0400, Gene C. wrote: > I agree ... but he would likely be interested in the copy BEFORE I ran > --rebuilddb ... which I do not have. > > Since more than one person has had this problem, hopefully the next person to > get the problem will save a copy before doing --rebuilddb. I have a few questions for anyone experiencing this: (a) Are these systems, experiencing this problem, fresh installs of Fedora Core 0.95 (or upgraded from Fedora Core 0.94) -- or were they upgraded from Red Hat 9.0.93 or earlier? If the latter, what release was it upgraded from? (b) Does the system have an i586 CPU (Pentium, Pentium MMX, AMD K6, and some others I don't remember right now)? (c) If the answer to (b) is "no", are you running the kernel shipped with Fedora Core (or a 2.6 kernel), or are you running something else (like a Red Hat 9 kernel or a mainline kernel)? Thanks in advance. -Barry K. Nathan From skvidal at phy.duke.edu Sun Oct 19 19:22:06 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 19 Oct 2003 15:22:06 -0400 Subject: Repository feature proposal In-Reply-To: <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> Message-ID: <1066591326.3612.23.camel@binkley> > > Red Hat > .... > > arch="x86" > every="3h"/> > arch="opteronium" > every="24h"/> > .... > arch="src" > every="3h"/> > > let me say now, for the record, branding a channel/repo as only for one arch is a bad bad bad bad bad idea. you will get into far more trouble here than any other place as pkg coloring becomes more obvious/prevalent. Also - what you're describing above appears to be configuration ABOUT a repository - rather than purely descriptive of a repository. I think repository information that will be on a server shouldn't have too much prescriptive information. also - the mirroring information is tricky b/c most mirrors won't know about the other ones - mirroring information is probably best left OUT of the information for any one repository. -sv From veillard at redhat.com Sun Oct 19 19:29:35 2003 From: veillard at redhat.com (Daniel Veillard) Date: Sun, 19 Oct 2003 15:29:35 -0400 Subject: Repository feature proposal In-Reply-To: <1066589115.3612.6.camel@binkley>; from skvidal@phy.duke.edu on Sun, Oct 19, 2003 at 02:45:15PM -0400 References: <200310191838.h9JIcRx18636@devserv.devel.redhat.com> <1066589115.3612.6.camel@binkley> Message-ID: <20031019152935.F16905@redhat.com> On Sun, Oct 19, 2003 at 02:45:15PM -0400, seth vidal wrote: > > Similar problems occur with other formats. Try a multibyte character one > > byte of which is '"' or '\n' in .ini format. > > > > XML also makes the format extensible and means you already have tools to > > autogenerate it, to turn it into up2date lines, yum lines, html, or edit it. > > > > This was something I was talking about with some other folks on irc - if > there was an xml representation of a 'definition' of a > repository/channel - then you could write converters/renderers for all > the other layouts. > > going from xml to any other format is pretty easy. Right. XML doesn't have to be the only representation for those data, but it's a good one for interchange and automated processing. I'm not suggesting to expose it to users, there should be more appropriate ways to show them or update them. As well as HTML became an ubiquitous format for informations targetting humans, 99% of the time we never look at the HTML format directly but though tools, the ability of editing XML directly is not the best reason to use it, it's overall reliability, ubiquity, precise parsing semantic, I18N and extensibility which are the long term reasons to choose it when it makes sense. I didn't expected to raise such a thread just about this. Speaking with my Red Hat hat off... Having metadata about mirrors would be generally useful, not only for yum but in a more general sense for mirroring. Integrating mirror informations within those metadata might be an interesting way to propagate this information up to the client and split the load among servers. This can connect to a large amount of other information pools like centralized list of mirrors, relationship with extra add-on repositories, etc... As the person who manage rpmfind.net and who somewhat failed to build a working distributed infrastructure I'm really interested in the technical solutions we may build to propagate the repositories and mirrors informations down to the client and have a good working distributed framework to automatically update systems. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Nicolas.Mailhot at laPoste.net Sun Oct 19 19:59:49 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 19 Oct 2003 21:59:49 +0200 Subject: Repository feature proposal In-Reply-To: <1066591326.3612.23.camel@binkley> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> <1066591326.3612.23.camel@binkley> Message-ID: <1066593588.12170.24.camel@m70.net81-64-235.noos.fr> Le dim 19/10/2003 ? 21:22, seth vidal a ?crit : > > > > Red Hat > > .... > > > > > arch="x86" > > every="3h"/> > > > arch="opteronium" > > every="24h"/> > > .... > > > arch="src" > > every="3h"/> > > > > > let me say now, for the record, branding a channel/repo as only for one > arch is a bad bad bad bad bad idea. > > you will get into far more trouble here than any other place as pkg > coloring becomes more obvious/prevalent. I hate to say it - but if you want to spread the load you'll need massive mirroring and there's no way all mirrors will host all obscure arch people have been talking about (and some will not carry all available streams/channels) Having more mirror sources for some arches is ok - x86 for example is massively more used, all arches were not created equal. If anything I suspect this proposal is not fine-grained enough for the mirror people. > Also - what you're describing above appears to be configuration ABOUT a > repository - rather than purely descriptive of a repository. I purely converted the kind of info one can fine in a fedora.us apt sources.list for example. Weren't we talking about exactly this ? > I think repository information that will be on a server shouldn't have > too much prescriptive information. Well in my mind it was more informative than prescriptive:) > also - the mirroring information is tricky b/c most mirrors won't know > about the other ones - mirroring information is probably best left OUT > of the information for any one repository. But the core org knows about it's official mirrors. And this official mirror list should be made available to the end-users download manager so it can choose automatically the closest/less loaded available mirror (maybe even spread the load between several mirrors). Relying on the users to uncomment a mirror in a list means most people won't bother and just hit the mother site. Allowing people to add private mirrors to the upstream list is really easy : just change the core descriptor to *** Fedora ..... ..... Core Packages .... Core Packages .... ... ... Red Hat .... .... Foo University Universit? Foo Only .edus please R?serv? au monde ?ducatif *** And allow people to drop files like : *** My org My intranet private mirror *** If the download manager logic is properly implemented it will always use the new mirror instead of the others, because if you won't have added it to the list if it's worst than the official ones (ie it will always be closer/have more bandwidth available than the others). Apt is pretty good at it - I have a several sources declared, including my own private mirror and after querying sources apt will always pull stuff from my mirror (except when another source synced with upstream more recently than my cron, in which case a few packages will be downloaded from external sources). 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 Sun Oct 19 20:43:39 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 19 Oct 2003 16:43:39 -0400 Subject: Repository feature proposal In-Reply-To: <1066593588.12170.24.camel@m70.net81-64-235.noos.fr> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> <1066591326.3612.23.camel@binkley> <1066593588.12170.24.camel@m70.net81-64-235.noos.fr> Message-ID: <1066596219.3612.52.camel@binkley> > > also - the mirroring information is tricky b/c most mirrors won't know > > about the other ones - mirroring information is probably best left OUT > > of the information for any one repository. > > But the core org knows about it's official mirrors. And this official > mirror list should be made available to the end-users download manager > so it can choose automatically the closest/less loaded available mirror > (maybe even spread the load between several mirrors). untrue - they know about tier1 mirrors - but not tier2 or tier3. > Relying on the users to uncomment a mirror in a list means most people > won't bother and just hit the mother site. have you seen how the mirrors are used for red hat's mirrors? they use the first one in the list that responds in < 2s. and that seems simple to you? if you're going to have that as the config file then you're going to need a program to edit/manage those. > If the download manager logic is properly implemented it will always use > the new mirror instead of the others, because if you won't have added it > to the list if it's worst than the official ones (ie it will always be > closer/have more bandwidth available than the others). the amount of data you'll have to include is growing and growing. -sv From julo at altern.org Sun Oct 19 20:45:57 2003 From: julo at altern.org (Julien Olivier) Date: Sun, 19 Oct 2003 21:45:57 +0100 Subject: Gnome System Tools toughts In-Reply-To: <3F92D163.7080909@zonnet.nl> References: <3F92B391.6090501@zonnet.nl> <1066580627.3179.3.camel@localhost.localdomain> <3F92D163.7080909@zonnet.nl> Message-ID: <1066596357.3367.1.camel@localhost.localdomain> On Sun, 2003-10-19 at 19:01, Jaap A. Haitsma wrote: > Julien Olivier wrote: > > (snip) > > > > > >>Wouldn't it be better for RedHat, SuSE, Debian etc. to just join this > >>effort. It's a lot more effective then every distro provider making > >>their own tools. (I see that there's maybe an issue for KDE users) > >> > > > > > > Upper, you said that the UI was split from the backend. If that's true, > > that means that it should be possible to add a KDE GUI too, shouldn't it > > ? > Sorry for not being really with the issue. > Of course it can run under KDE you'll only need to install a whole lot > of gnome libraries to get it to run. KDE purist maybe don't like that. > But then current redhat tools you also need to have a lot of stuff > installed you'll probably never use. > Well, in fact I was talking of creating a native KDE frontend (using QT), not running the GTK frontend in KDE. > Jaap > > > > -- > 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 Sun Oct 19 21:39:07 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 19 Oct 2003 23:39:07 +0200 Subject: Repository feature proposal In-Reply-To: <1066596219.3612.52.camel@binkley> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> <1066591326.3612.23.camel@binkley> <1066593588.12170.24.camel@m70.net81-64-235.noos.fr> <1066596219.3612.52.camel@binkley> Message-ID: <1066599546.12170.60.camel@m70.net81-64-235.noos.fr> Le dim 19/10/2003 ? 22:43, seth vidal a ?crit : > > > also - the mirroring information is tricky b/c most mirrors won't know > > > about the other ones - mirroring information is probably best left OUT > > > of the information for any one repository. > > > > But the core org knows about it's official mirrors. And this official > > mirror list should be made available to the end-users download manager > > so it can choose automatically the closest/less loaded available mirror > > (maybe even spread the load between several mirrors). > > untrue - they know about tier1 mirrors - but not tier2 or tier3. So people can add tier2 or tier3 mirrors if they know about them. Tier2 or tier3 mirrors can even provide complementary descriptors people just drop in their config dir alongside the "official" list. (they can even roll up their own packages that will do just that). A list, even if it's woefully incomplete one is much better than a system where we just "hope" the user will "find" a better source than ftp.redhat.com (hint - most people don't bother and hit ftp.redhat.com directly) > > Relying on the users to uncomment a mirror in a list means most people > > won't bother and just hit the mother site. > > have you seen how the mirrors are used for red hat's mirrors? > they use the first one in the list that responds in < 2s. Actually one can be smarter than that - query all mirrors the few first times, record response time/freshness/effective bandwidth when downloading, and use only the best sources after a while (re-doing a full query every once in a while) I think autorpm did something like this at one time. > > and that seems simple to you? Considering the information density yes (I won't say this is the best format, this is just something I cooked in 20s to show what could be done - one should probably add a few gpg elements to register the keys a repository is supposed to use for example). If you look at real-world fedora.us usage for example this is the level of info one finds today. I merely organised it a bit so a user could read it easily instead of mastering obscure apt convention. > if you're going to have that as the config file then you're going to > need a program to edit/manage those. A file for a big repository like Fedora will be long sure. Now the syntax itself is simple enough people can tweak the files easily. Sure it may seem heavy - but it's a lot less heavy than the current method where one has to read a lengthy doc describing syntax, another describing channels, yet another describing mirrors, yet another one what gpg keys will be used, etc (people hunting rawhide mirrors and/or non-x86 ones know the pain) The point is to have full repository info in a single file so the package downloader can make the correct download decisions without user intervention, and the user can choose channels without having to go elsewhere to learn what "fedora extra" means". Spec files may seem verbose too - they are information-rich so the system can take care automatically of updates, and the user forget all the king of manual checks he'd have to do otherwise. Note how the complementary intranet descriptor was small - it could be because xml enabled to reference stuff in the master repository descriptor. People may need a special app to write a full-blown descriptor - but they won't just to tweak one. > > If the download manager logic is properly implemented it will always use > > the new mirror instead of the others, because if you won't have added it > > to the list if it's worst than the official ones (ie it will always be > > closer/have more bandwidth available than the others). > > the amount of data you'll have to include is growing and growing. Maybe - just show me some of it is useless and I'll drop it. Having people manually collect this info somewhere else doesn't make the system simpler, quite the contrary. 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 Sun Oct 19 21:48:46 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 19 Oct 2003 17:48:46 -0400 Subject: Repository feature proposal In-Reply-To: <1066599546.12170.60.camel@m70.net81-64-235.noos.fr> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> <1066591326.3612.23.camel@binkley> <1066593588.12170.24.camel@m70.net81-64-235.noos.fr> <1066596219.3612.52.camel@binkley> <1066599546.12170.60.camel@m70.net81-64-235.noos.fr> Message-ID: <1066600126.3612.57.camel@binkley> > So people can add tier2 or tier3 mirrors if they know about them. > Tier2 or tier3 mirrors can even provide complementary descriptors people > just drop in their config dir alongside the "official" list. (they can > even roll up their own packages that will do just that). > A list, even if it's woefully incomplete one is much better than a > system where we just "hope" the user will "find" a better source than > ftp.redhat.com (hint - most people don't bother and hit ftp.redhat.com > directly) incomplete isn't the issue - it's woefully out of data that's the problems. mirrors in fail-over only work if they are identical. > Actually one can be smarter than that - query all mirrors the few first > times, record response time/freshness/effective bandwidth when > downloading, and use only the best sources after a while (re-doing a > full query every once in a while) I think autorpm did something like > this at one time. and the heuristic was fairly questionable iirc. > Considering the information density yes (I won't say this is the best > format, this is just something I cooked in 20s to show what could be > done - one should probably add a few gpg elements to register the keys a > repository is supposed to use for example). > > If you look at real-world fedora.us usage for example this is the level > of info one finds today. I merely organised it a bit so a user could > read it easily instead of mastering obscure apt convention. > > > if you're going to have that as the config file then you're going to > > need a program to edit/manage those. > > A file for a big repository like Fedora will be long sure. > Now the syntax itself is simple enough people can tweak the files > easily. I disagree - people have a hard enough time with key=value. I don't think that file is human editable at all. > Sure it may seem heavy - but it's a lot less heavy than the current > method where one has to read a lengthy doc describing syntax, another > describing channels, yet another describing mirrors, yet another one > what gpg keys will be used, etc (people hunting rawhide mirrors and/or > non-x86 ones know the pain) bye current method you mean 'for apt' this is just a good reason why apt's configuration is a mess, not why this has to be done on the repo-side. > Maybe - just show me some of it is useless and I'll drop it. > Having people manually collect this info somewhere else doesn't make the > system simpler, quite the contrary. the trick is combining the information density with sensible defaults. This is why the gnome people have taken a lot of time trying to get config options more sane - it is not a trivial undertaking. -sv From mharris at redhat.com Sun Oct 19 21:52:29 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 19 Oct 2003 17:52:29 -0400 (EDT) Subject: Union mounts In-Reply-To: <1066490360.4640.27.camel@binah.upevil.net> References: <1066490360.4640.27.camel@binah.upevil.net> Message-ID: On Sat, 18 Oct 2003, Jens Knutson wrote: >I've been doing some research on getting union mounts to work on >Linux, but it doesn't appear that Fedora currently supports it! >Is this accurate? Linux _period_ does not support union mounting, and never has - at least to my knowledge. I've heard kernel folk discussing that this is something which might happen in 2.7.x however. Just so you know that there's nothing "Fedora" specific about the lack of union mount capability. >If so, is there anything on the horizon, or will I have to use >*BSD to get this? (ewwwwww.) See above. You'll have to use BSD for the time being, or some other OS that supports union mount. Unless I'm totally on crack and far outdated WRT this on Linux. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sun Oct 19 22:04:24 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 19 Oct 2003 18:04:24 -0400 (EDT) Subject: Gnome System Tools toughts In-Reply-To: <3F92B391.6090501@zonnet.nl> References: <3F92B391.6090501@zonnet.nl> Message-ID: On Sun, 19 Oct 2003, Jaap A. Haitsma wrote: >I came across the announcement of a new version of Gnome System Tools (a >project lead by Ximian) a few days ago. They resemble the redhat config >tools quite a bit, though they have only have 5 tools up to now (not >really production ready according to the website but still) > ># Users and groups ># Date and time ># Network configuration ># Bootloaders ># Runlevels > >See: http://www.gnome.org/projects/gst/index.html >The nice thing is that the front end (The GUI) is distribution >independent and the backend (configuration files etc.) are distribution >dependent. > >Just some thoughts/questions. > >Wouldn't it be better for RedHat, SuSE, Debian etc. to just join this >effort. It's a lot more effective then every distro provider making >their own tools. (I see that there's maybe an issue for KDE users) > >Are there any initiatives to have a standard of configuration files, >which are used by all providers. I heard of LSB, but it seems to me they > do not standardise configuration files. We've been down that road before. "Linuxconf", as well as other config tools here and there throughout the years. The biggest problem with externally maintained configuration tools, is that they tend to *NOT* be distribution specific, and so they don't track the development of the given distribution. As such, they suffer greatly from NIH syndrome (Not Invented Here), and tend to not match what the distribution has to offer without a LOT of customization, tweaking and bug fixing, which must then be repeated by internal developers every single release. It was decided to develop our own configuration tools internally, so that we know they are up to date with the software we ship, and we are the upstream maintainers, as well as not having to worry about distribution specifics being ignored because an external maintainer uses some other distribution, etc. Before we'd be willing to throw away all of the tools we've already written, and future plans to improve upon that, there'd have to be a rather major selling point. And "same tool works the same on all distros" is a nice thought, but that's not the *highest* priority. What is more important than our tool being the same one SuSE and/or Mandrake, etc. uses, is that our tool actually works for our distribution without a lot of hacking, or developmental latency. Our tools are developed on _our_ distribution release cycle. An upstream tool is developed on volunteer time, and different components of such a suite would more likely than not have different release cycles. So, while it is interesting to see a new tool being developed, the tool would have to prove itself out there before any consideration would be giving to throwing away a couple of years worth of invested development which does work for us now already. That is just my own personal opinion however. I do not speak for Red Hat specifically, nor would I be the one here making such a decision as to wether or not Red Hat would include such software in future distributions. Such a decision would be based on meritocracy of the software in question, and wether it would meet the project's goals and/or Red Hat's goals. TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From skvidal at phy.duke.edu Sun Oct 19 22:15:29 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 19 Oct 2003 18:15:29 -0400 Subject: yum 2.0.4 Message-ID: <1066601729.3612.73.camel@binkley> hey, yum 2.0.4 is out: Changes: - update the russian translations from Grigory Bakunov - make reference to the yum howto from README - fix distroverpkg to look for something providing the name - not just the pkg named that - arch cleanups - add some stuff for sparc64, ppc64 and x86_64 might not be perfect for those but in the right ballpark. - better error reporting for file and other conflicts. - make modes work better for yum list and yum info in the event it's being run as a user and the headers haven't been updated recently - yum provides/ yum search more intuitive with use of wildcards - progress bar - update out of dep loop - increased default number of retries from 3 to 6. - misc bugfixes and cleanups. Get it from here: tarball: http://linux.duke.edu/yum/download/2.0/yum-2.0.4.tar.gz MD5SUM = 17a436b024a9e7144ae2183bb731b726 srpm: http://linux.duke.edu/yum/download/2.0/yum-2.0.4-1.src.rpm rpm: http://linux.duke.edu/yum/download/2.0/yum-2.0.4-1.noarch.rpm let me know what's broken - yum bugzilla: https://devel.linux.duke.edu/bugzilla/ -sv -------------- 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 Sun Oct 19 22:44:14 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 20 Oct 2003 00:44:14 +0200 Subject: Repository feature proposal In-Reply-To: <1066600126.3612.57.camel@binkley> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> <1066591326.3612.23.camel@binkley> <1066593588.12170.24.camel@m70.net81-64-235.noos.fr> <1066596219.3612.52.camel@binkley> <1066599546.12170.60.camel@m70.net81-64-235.noos.fr> <1066600126.3612.57.camel@binkley> Message-ID: <1066603454.12170.87.camel@m70.net81-64-235.noos.fr> Le dim 19/10/2003 ? 23:48, seth vidal a ?crit : > > So people can add tier2 or tier3 mirrors if they know about them. > > Tier2 or tier3 mirrors can even provide complementary descriptors people > > just drop in their config dir alongside the "official" list. (they can > > even roll up their own packages that will do just that). > > > A list, even if it's woefully incomplete one is much better than a > > system where we just "hope" the user will "find" a better source than > > ftp.redhat.com (hint - most people don't bother and hit ftp.redhat.com > > directly) > > incomplete isn't the issue - it's woefully out of data that's the > problems. mirrors in fail-over only work if they are identical. That's not a problem here. Remember - we are talking about mirrors of packages. You can evaluate a mirror freshness pretty easily by comparing the metadata it declares to the master site metadata. > > Actually one can be smarter than that - query all mirrors the few first > > times, record response time/freshness/effective bandwidth when > > downloading, and use only the best sources after a while (re-doing a > > full query every once in a while) I think autorpm did something like > > this at one time. > > and the heuristic was fairly questionable iirc. It's less questionable than having people choose a mirror in a list by country and have them "assume" the mirror is up-to-date. If you give the package manager the full mirror list it can find pretty easily what mirrors are usually up-to-date and accessible form you network location (of course checking for better mirrors every once in a while is good to, and comparing mirror freshness to the master site should happen often) > > Considering the information density yes (I won't say this is the best > > format, this is just something I cooked in 20s to show what could be > > done - one should probably add a few gpg elements to register the keys a > > repository is supposed to use for example). > > > > If you look at real-world fedora.us usage for example this is the level > > of info one finds today. I merely organised it a bit so a user could > > read it easily instead of mastering obscure apt convention. > > > > > if you're going to have that as the config file then you're going to > > > need a program to edit/manage those. > > > > A file for a big repository like Fedora will be long sure. > > Now the syntax itself is simple enough people can tweak the files > > easily. > > I disagree - people have a hard enough time with key=value. > > I don't think that file is human editable at all. I think it is but maybe I'm biased. Surely breaking it in lots of key=value pair will make it *less* editable, not more. > > Sure it may seem heavy - but it's a lot less heavy than the current > > method where one has to read a lengthy doc describing syntax, another > > describing channels, yet another describing mirrors, yet another one > > what gpg keys will be used, etc (people hunting rawhide mirrors and/or > > non-x86 ones know the pain) > > bye current method you mean 'for apt' > > this is just a good reason why apt's configuration is a mess, not why > this has to be done on the repo-side. No. It's a reason why apt *works*. How can you expect your download manager to work if you don't feed it the necessary info ? (and one can disagree on what info is necessary or not - when people have been taking the pain of making some info public for a long time that's a pretty good indicator this info is needed. > > Maybe - just show me some of it is useless and I'll drop it. > > Having people manually collect this info somewhere else doesn't make the > > system simpler, quite the contrary. > > the trick is combining the information density with sensible defaults. > > This is why the gnome people have taken a lot of time trying to get > config options more sane - it is not a trivial undertaking. Please. What the hell the defaults have to do with this ? You won't get people to mirror all arches because you want to simplify your config file. You won't get them to reorganise their tree structure just for RedHat - for big mirror sites RedHat is just a small part of their ftp. You won't get Mandrake/Suse/etc change their ftp structure to accommodate you - and some people here need to target more than RedHat-only (up2date was a big flop for 3rd-party repositories because it was so RedHat-specific). I've given you a half-cooked example and I freely admit it may be far from perfect. Just give me yours and I'll tell you if it fits my needs (as a end-user, sysadmin and member of another third-party packaging project. I will take whatever technical solution that solves my problems, even if it's not the one I pushed myself;) 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 katzj at redhat.com Sun Oct 19 23:31:24 2003 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 19 Oct 2003 19:31:24 -0400 Subject: Repository feature proposal In-Reply-To: <1066600126.3612.57.camel@binkley> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> <1066591326.3612.23.camel@binkley> <1066593588.12170.24.camel@m70.net81-64-235.noos.fr> <1066596219.3612.52.camel@binkley> <1066599546.12170.60.camel@m70.net81-64-235.noos.fr> <1066600126.3612.57.camel@binkley> Message-ID: <1066606284.1214.11.camel@edoras.local.net> On Sun, 2003-10-19 at 17:48, seth vidal wrote: > > So people can add tier2 or tier3 mirrors if they know about them. > > Tier2 or tier3 mirrors can even provide complementary descriptors people > > just drop in their config dir alongside the "official" list. (they can > > even roll up their own packages that will do just that). > > > A list, even if it's woefully incomplete one is much better than a > > system where we just "hope" the user will "find" a better source than > > ftp.redhat.com (hint - most people don't bother and hit ftp.redhat.com > > directly) > > incomplete isn't the issue - it's woefully out of data that's the > problems. mirrors in fail-over only work if they are identical. Mirror information is a problem that has to be solved, for a variety of reasons. My initial thoughts are that someone needs to step forward to work with the mirrors to maintain a list (our IS guys try, but they're far too overworked to really be able to spend significant amounts of time on this -- I'm sure smooge will jump in to ditto this ;) Then, we can make the list available via http in a standardized location (for the Fedora Core repository, probably http://fedora.redhat.com/something) and then the first time you run an update program, it snags the current list of mirrors -- likely with a built-in set of defaults that you know isn't going to go away, just in case you can't get to the mirror data for whatever reason. But there's going to have to be a lot of data in that mirror data file, especially if we want to go the next step and have the installer able to pull the file and use it to provide you a list of potential install sources for an ftp/http install. Even completely discounting using with various tools, though, something has to be done to make using mirrors sane. The current way things works provides lots of frustration for users and mirror admins alike, at least, IMHO. Cheers, Jeremy From notting at redhat.com Mon Oct 20 04:44:31 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Oct 2003 00:44:31 -0400 Subject: rsync and rawhide In-Reply-To: ; from kaboom@gatech.edu on Sat, Oct 18, 2003 at 10:06:13AM -0400 References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017115605.B18024@devserv.devel.redhat.com> Message-ID: <20031020004431.A1267@devserv.devel.redhat.com> Chris Ricker (kaboom at gatech.edu) said: > > Adding ISOs in *addition* to the files would lead to a rather dramatic > > increase in disk space required. > > At least right now, it looks like 2 gigs for SRPMs, and 2 gigs for each > architecture. I'm not sure there'd be much demand for more than i386.... Yeah, but start adding in the debuginfo... >:) Bill From notting at redhat.com Mon Oct 20 05:01:40 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Oct 2003 01:01:40 -0400 Subject: rawhide full install: xemacs-sumo-el and aspell-it In-Reply-To: <20031019100551.GC8144@puariko.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Sun, Oct 19, 2003 at 12:05:51PM +0200 References: <20031019100551.GC8144@puariko.nirvana> Message-ID: <20031020010140.B1267@devserv.devel.redhat.com> Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > The above packages are obsoleted by xemacs-el and aspell. Should they > be removed from rawhide? aspell-it whacked. xemacs-sumo is going to need to be rebuilt, please file a bug. Bill From veillard at redhat.com Mon Oct 20 06:55:26 2003 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Oct 2003 02:55:26 -0400 Subject: Repository feature proposal In-Reply-To: <1066606284.1214.11.camel@edoras.local.net>; from katzj@redhat.com on Sun, Oct 19, 2003 at 07:31:24PM -0400 References: <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> <1066591326.3612.23.camel@binkley> <1066593588.12170.24.camel@m70.net81-64-235.noos.fr> <1066596219.3612.52.camel@binkley> <1066599546.12170.60.camel@m70.net81-64-235.noos.fr> <1066600126.3612.57.camel@binkley> <1066606284.1214.11.camel@edoras.local.net> Message-ID: <20031020025526.M16905@redhat.com> On Sun, Oct 19, 2003 at 07:31:24PM -0400, Jeremy Katz wrote: > Mirror information is a problem that has to be solved, for a variety of > reasons. My initial thoughts are that someone needs to step forward to > work with the mirrors to maintain a list (our IS guys try, but they're > far too overworked to really be able to spend significant amounts of > time on this -- I'm sure smooge will jump in to ditto this ;) Then, we > can make the list available via http in a standardized location (for the > Fedora Core repository, probably http://fedora.redhat.com/something) and > then the first time you run an update program, it snags the current list > of mirrors -- likely with a built-in set of defaults that you know isn't > going to go away, just in case you can't get to the mirror data for > whatever reason. Totally agree. You also refetch if you hit an unavailble mirror. > But there's going to have to be a lot of data in that mirror data file, > especially if we want to go the next step and have the installer able to > pull the file and use it to provide you a list of potential install > sources for an ftp/http install. That file doesn't have to be updated frequently, once per fedora core release ought to be sufficient, honnestly even if the file grows a lot it really not a big deal. > Even completely discounting using with various tools, though, something > has to be done to make using mirrors sane. The current way things works > provides lots of frustration for users and mirror admins alike, at > least, IMHO. Really, in my perspective it's really smooth, at least for Red Hat mirroring, it's in my biased opinion by far the easiest distro to mirror ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From buildsys at porkchop.devel.redhat.com Mon Oct 20 09:39:29 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Mon, 20 Oct 2003 05:39:29 -0400 Subject: rawhide report: 20031020 changes Message-ID: <200310200939.h9K9dTs19912@porkchop.devel.redhat.com> From Axel.Thimm at physik.fu-berlin.de Mon Oct 20 10:07:46 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 20 Oct 2003 12:07:46 +0200 Subject: up2date and yum: failover mode? Message-ID: <20031020100746.GC15294@puariko.nirvana> Something invaluable in yum is its failover system, e.g. pointing N mirrors of the same repo in the config giving yum a chance to pick another one, when a failure is detected. Is that feature already in up2date, or will it be brought to it? -- 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 morrildl at nycap.rr.com Mon Oct 20 12:25:23 2003 From: morrildl at nycap.rr.com (Dan Morrill) Date: Mon, 20 Oct 2003 08:25:23 -0400 Subject: yum/apt/up2date + distributed dependencies Message-ID: <3F93D433.1060105@nycap.rr.com> Since up2date now supports multiple repositories, this opens a question in my mind: what happens when you have distributed dependencies? Here's a specific (though partially contrived) example: - Install xmms-42.0 from Fedora Core - Install xmms-mp3-42.0 from freshrpms because you live in a jurisdiction where you are legally able to do so What happens when Fedora Core releases xmms-42.1? FC doesn't include xmms-mp3, but xmms-mp3 depends on xmms. Hence, the upgrade of xmms will fail so as not to break xmms-mp3. Beyond that, suppose that freshrpms does release xmms-mp3-42.1. In this case, up2date COULD resolve the dependency and complete the upgrade -- but to do so it would have to resolve dependencies across two different repositories. Is it able to do so? (This XMMS example is the first one that came to my mind, but it is easy to imagine more sinister dependency trees.) Before I go exploring this in depth, I figured I'd ask the list. This issue seems like it could become more relevant later, as Fedora Extras repositories begin to proliferate. Any comments appreciated; apologies if this has been covered before. - Dan Morrill From skvidal at phy.duke.edu Mon Oct 20 12:46:56 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 20 Oct 2003 08:46:56 -0400 Subject: yum/apt/up2date + distributed dependencies In-Reply-To: <3F93D433.1060105@nycap.rr.com> References: <3F93D433.1060105@nycap.rr.com> Message-ID: <1066654015.3610.6.camel@binkley> > FC doesn't include xmms-mp3, but xmms-mp3 depends on xmms. Hence, the > upgrade of xmms will fail so as not to break xmms-mp3. > > Beyond that, suppose that freshrpms does release xmms-mp3-42.1. In this > case, up2date COULD resolve the dependency and complete the upgrade -- but > to do so it would have to resolve dependencies across two different > repositories. Is it able to do so? (This XMMS example is the first one that > came to my mind, but it is easy to imagine more sinister dependency trees.) The above is, in fact, the point of having multiple repositories. -sv From Nicolas.Mailhot at laPoste.net Mon Oct 20 12:54:48 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 20 Oct 2003 14:54:48 +0200 Subject: yum/apt/up2date + distributed dependencies In-Reply-To: <3F93D433.1060105@nycap.rr.com> References: <3F93D433.1060105@nycap.rr.com> Message-ID: <1066654487.5983.0.camel@ulysse.olympe.o2t> Le lun 20/10/2003 ? 14:25, Dan Morrill a ?crit : > Since up2date now supports multiple repositories, this opens a question > in my mind: what happens when you have distributed dependencies? > > Here's a specific (though partially contrived) example: > > - Install xmms-42.0 from Fedora Core > - Install xmms-mp3-42.0 from freshrpms because you live in a jurisdiction > where you are legally able to do so > > What happens when Fedora Core releases xmms-42.1? > > FC doesn't include xmms-mp3, but xmms-mp3 depends on xmms. Hence, the > upgrade of xmms will fail so as not to break xmms-mp3. On an apt system apt will most likely warn you updating xmms requires the removal of xmms-mp3. 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 nphilipp at redhat.com Mon Oct 20 13:34:22 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 20 Oct 2003 15:34:22 +0200 Subject: yum/apt/up2date + distributed dependencies In-Reply-To: <3F93D433.1060105@nycap.rr.com> References: <3F93D433.1060105@nycap.rr.com> Message-ID: <1066656860.7065.41.camel@gibraltar.stuttgart.redhat.com> On Mon, 2003-10-20 at 14:25, Dan Morrill wrote: > Since up2date now supports multiple repositories, this opens a question > in my mind: what happens when you have distributed dependencies? > > Here's a specific (though partially contrived) example: > > - Install xmms-42.0 from Fedora Core > - Install xmms-mp3-42.0 from freshrpms because you live in a jurisdiction > where you are legally able to do so > > What happens when Fedora Core releases xmms-42.1? > > FC doesn't include xmms-mp3, but xmms-mp3 depends on xmms. Hence, the > upgrade of xmms will fail so as not to break xmms-mp3. The problem in that case is not primarily that one repo depending on another one lags behind, but an over-zealous dependency in the xmms-mp3 package -- it should not require "xmms = %{version}-%{release}". A proper solution could be for the xmms RPM to provide something like "plugin-ABI(xmms) = :" and xmms-mp3 to depend on that. If upstream doesn't "officially" or reliably stick to a plugin API/ABI, could still be an integer incremented with each non-backwardly-compatible API/ABI change and covering changes in e.g. the compiler that change the ABI without any upstream change. In this particular case, perhaps depending on libxmms.so.1 would be a first step into the right direction, provided that it actually represents the plugin API of XMMS (I don't know if it does). 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 brugolsky at telemetry-investments.com Mon Oct 20 14:00:00 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Mon, 20 Oct 2003 10:00:00 -0400 Subject: Union mounts In-Reply-To: References: <1066490360.4640.27.camel@binah.upevil.net> Message-ID: <20031020140000.GA12350@ti19> On Sun, Oct 19, 2003 at 05:52:29PM -0400, Mike A. Harris wrote: > Linux _period_ does not support union mounting, and never has - > at least to my knowledge. I've heard kernel folk discussing that > this is something which might happen in 2.7.x however. Just so > you know that there's nothing "Fedora" specific about the lack of > union mount capability. Both union mount (i.e., union of directories), and unionfs (overlay of filesystems) has been on Al Viro's TODO list for *years*. He intends to get the semantics right and avoid the problems of the BSD implementations. Linux's has multimount and private namespaces complicate the matter somewhat: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=linux.fsdevel.Pine.GSO.4.21.0111161318040.7552-100000%40weyl.math.psu.edu&rnum=17c%40ifi.uio.no&rnum=1&prev=/groups%3Fq%3Dalexander.viro%2Bunion%2Bmount%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dfa.lad3g7v.7ngljc%2540ifi.uio.no%26rnum%3D1 At some point Viro had a more-or-less complete union-mount and was soliticing comments; see this thread: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&frame=right&th=3137774f238d4626&seekm=fa.lad3g7v.7ngljc%40ifi.uio.no#link1 Unfortunately, Viro has seemingly been occupied with higher priority things during the 2.5 series, including cleaning up cruft, fixing races, and cleaning up the block layer interfaces and dev_t. Erez Zadok and his students at Columbia U. are working on the more general problem of filesystem "fan-out" as part of the FiST stackable template filesystem project. Their work encompasses unionfs, versioning, replication (where, e.g., one or more of the filesystems could be remote mounts, like NFS/CIFS/AFS, etc.), and other forms of stacking. Zadok said back in August that they hoped to have something released by late October. Whether their semantic design will meet Viro's stringent requirements remains to be seen. Regards, Bill Rugolsky From jfm512 at free.fr Sun Oct 19 14:20:10 2003 From: jfm512 at free.fr (Jean Francois Martinez) Date: 19 Oct 2003 16:20:10 +0200 Subject: rsync and rawhide In-Reply-To: <1066566391.3352.45.camel@miami> References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017155935.BB27EF7D61@voldemort.scrye.com> <1066566391.3352.45.camel@miami> Message-ID: <1066573209.3006.25.camel@agnes.fremen.dune> On Sun, 2003-10-19 at 14:26, Trae McCombs wrote: > On Sat, 2003-10-18 at 10:32, Chris Ricker wrote: > > On Fri, 17 Oct 2003, Kevin Fenzi wrote: > > > > > Someone the other day was telling me that with updates for SuSe you > > > could pull down all the new rpms, or just pull down changes between > > > the updated rpm and your current version... > > > > > > Ah, there they are... called 'patch rpms'. > > > From: > > > > > > http://www.suse.com/us/private/download/updates/90_i386.html > > > > > > "New: Patch RPMs > > > > > > As of now we are offering so called Patch RPM packages. A Patch RPM > > > updates an already installed RPM. It only contains files which have > > > changed - therefore it is (much) smaller than the complete RPM > > > package. Prerequisite for installation is an already installed basic > > > RPM. The packages included on the SUSE LINUX 9.0-CDs/DVD are > > > considered as basic RPMs. If you want to update an already installed > > > package, please download the smaller Patch RPM package." > > > > > > Something like this would be very handy for keeping up with rawhide, > > > saving redhat bandwith, and making more people use it as it became > > > smaller/faster/easer to do. > > > > > > Anyone know how they do those? Would that be hard to implement? > > > > Interesting. Looking at just one patch.rpm, > > > > ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/bluez-bluefw-1.0-68.i586.patch.rpm > > > > Dumping the rpm contents shows it contains just a single file (the one which > > needed to be changed) > > > > rpm -qlp on the patch.rpm, however, lists it as containing all the files > > which are normally in the bluez-bluefw package > > > > I guess when it gets installed, it leaves the old files on, replaces the one > > which needs fixing, then registers in rpmdb? I wonder what happens if you > > rpm -e the patch? Do you go back to the original package, or do you > > uninstall the whole package? > > > > Looking at the spec file for the rpm, I see no evidence of how the patch.rpm > > is generated.... > > > > At any rate, this on one level at least seems like a bad idea to me. One of > > the nice things about managing Linux (versus other Unixen) is that on most > > major Linux distros patch management and software management are the same > > thing -- patches are just new versions of existing packages, and you > > install, track, etc. the way you do any packages. That's better than the > > usual "one set of tools to manage packages, another to manage bugfixes to > > packages".... The patch.rpm's seem a bit of a step backwards, at least in > > that respect. > > (putting this at the bottom like a good little boy...) > > I know I'm not the most technically inclined person, and I know I've not > fully followed this thread. However, I do feel in the case of saving > bandwidth, and making upgrades more accessible to those that are limited > with their pipes, I think it makes sense to have a low-file-sized > solution for those wishing to upgrade their full systems. > > For instance, Let's say I've completed a full install of FC1.0 (I know > it's not out), and then when the next release comes, I could download a > "patch.ISO" of roughly 300megs or so, I'm guessing(probably incorrectly) > that this would be the difference from one version to the next. At any > rate, it would be nice to be able to download a patch.ISO that's one CD, > and have it patch/upgrade your system, instead of having to download 3 > iso's. > > Again, I'm sure I've missed the point, but it's my 2 pennies. > The problem is that RPM is a compressed format. Change one byte in it and there are chances ALL the remainder of the file is different. One thing who is not technically impossible would be to post files containing the additional patches and the spec file for building the new RPM (provided the base software has not changed. However a thing most people don't realize is that software building is not reproducible unless you have a very tightly defined environment (much more tightly than in your usual spec file). For instance when you build the Gimp the configure script will check for some optional libraries (eg allowing it to handle additional formats) if it doesn't find them then the build will still succceed but the product will have less capabilities. And of course it will be a support nightmare. I think the right answer is to get CD distributors in the bandwagon. JFM From aoliva at redhat.com Mon Oct 20 17:09:13 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 20 Oct 2003 15:09:13 -0200 Subject: rsync and rawhide In-Reply-To: <1066573209.3006.25.camel@agnes.fremen.dune> References: <20031017105450.E4974@devserv.devel.redhat.com> <1066405108.7029.24.camel@jeremy.dtcc.cc.nc.us> <20031017155935.BB27EF7D61@voldemort.scrye.com> <1066566391.3352.45.camel@miami> <1066573209.3006.25.camel@agnes.fremen.dune> Message-ID: On Oct 19, 2003, Jean Francois Martinez wrote: > The problem is that RPM is a compressed format. The solution for this would be an rsync-based download program that would collect bits from an installed rpm and an rsync server that was file-format-aware and actually looked at the uncompressed payload of the rpm, with local-recompression. Since RPM signatures and md5s are computed over the compressed payload, the same compressor must be available at both ends, and the same compression level must be used. This need could be minimized by computing signatures and md5sums on the uncompressed payload. Then, you can even choose to recompress an RPM with better compression levels to save on storage size, without invalidating signatures. A further improvement would be to enable recompression of sources without invalidating spec files or their signatures. Spec files could list sources without their compression suffixes, that would then be ``completed'' automatically by rpm. Alternatively, installing a SRPM formerly recompressed could implicitly uncompress/recompress files into their original extensions. The point here is to not invalidate the signature by requiring changes to the spec file to accommodate changes in the compression extensions. As a last step, the rsync file-format-aware program could then peek into the compressed tarballs and patches forming an SRPM and save on downloads even for SRPMS that have had small changes to the tar files. :-) Yeah, it's a long way from where we are... :-( -- 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 m.fioretti at inwind.it Sun Oct 19 14:07:15 2003 From: m.fioretti at inwind.it (M. Fioretti) Date: Sun, 19 Oct 2003 16:07:15 +0200 Subject: Better packaging for older hardware? In-Reply-To: <20031018100541.C12648@devserv.devel.redhat.com> References: <20031018062944.GB32004@inwind.it> <200310180951.h9I9p5Y25510@devserv.devel.redhat.com> <20031018113648.GA392@inwind.it> <20031018100541.C12648@devserv.devel.redhat.com> Message-ID: <20031019140715.GA3623@inwind.it> On Sat, Oct 18, 2003 10:05:41 at 10:05:41AM -0400, Michael K. Johnson (johnsonm at redhat.com) wrote: > It wouldn't be hard for us to provide an appropriately trimmed > config file in the kernel srpm Please do it! This would be an excellent solution. RULE and similar projects could create the RPMs with the confidence that they have been reviewed by expert, and that the resulting kernel would have the highest probabilities to work fine with fedora libraries and userland packages. At the same time, FC would not see uninteresting packages added. > > However, the only "slimming" bits we have expertise of any sort in > is summed up in the BOOT kernel config file, so we'd need a pretty > good idea of what kinds of changes we were going to make that would > really satisfy most everyone... That's the real hard part. > Maybe is not so hard. Once we have agreed on the procedure above, whenever we at RULE find or are told some other trick we'll pass along it here and/or the srpms maintainers, maybe after testing them ourselves: In this way, everybody would know it, even if not immediately interested, and you would know how to further patch that special .config file whenever the official FC kernel is updated. When it comes to "what would really satisfy everyone" it might be even simpler. As far as I can see, today everybody who needs to run a Red Hat/Fedora distro on low end hardware: 1) does it himself, for fun and profit, or 2) is already involved/using RULE, or 3) is told to go try RULE (I'm just summing up the current situation, not pretending to establish any kind or monopoly/hegemony: this is just what I see from where I sit. So far, almost everybody passing through point 3) because 1) was above his possibilities: ended up happily in point 2), or changed distro altogether because eventually no Red Hat lookalike would not fit his bill) In other words, you might look at the RULE requirements, and just go for them. Specifically, a good starting point are these urls: http://www.rule-project.org/en/en/what_can_rule_do.php (use cases) http://www.rule-project.org/en/test/ (the kind of HW we need to make useful) I have to leave now, but will be happy to provide whatever further feedback you might need. The corner case(s) we could safely ignore is somebody who just needs to use some extremely weird piece of NON-standard very old hardware, only 100 units still existing on the whole planet, which requires more patching of the kernel. Nobody can do miracles. Ciao, Marco Fioretti -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ The whole world is a tuxedo and you are a pair of brown shoes. -- George Gobel From johnsonm at redhat.com Mon Oct 20 19:26:27 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 20 Oct 2003 15:26:27 -0400 Subject: Better packaging for older hardware? In-Reply-To: <20031019140715.GA3623@inwind.it>; from m.fioretti@inwind.it on Sun, Oct 19, 2003 at 04:07:15PM +0200 References: <20031018062944.GB32004@inwind.it> <200310180951.h9I9p5Y25510@devserv.devel.redhat.com> <20031018113648.GA392@inwind.it> <20031018100541.C12648@devserv.devel.redhat.com> <20031019140715.GA3623@inwind.it> Message-ID: <20031020152627.A9589@devserv.devel.redhat.com> On Sun, Oct 19, 2003 at 04:07:15PM +0200, M. Fioretti wrote: > On Sat, Oct 18, 2003 10:05:41 at 10:05:41AM -0400, Michael K. Johnson (johnsonm at redhat.com) wrote: > > It wouldn't be hard for us to provide an appropriately trimmed > > config file in the kernel srpm > > Please do it! This would be an excellent solution. What we can't do is come up with the definition of what to trim... So when you have an initial set of suggestions for changes, lets discuss the suggestions of changes here. Just post them as # CONFIG_FOO is not set CONFIG_BLAH=128 etc, for discussion. > In other words, you might look at the RULE requirements, and just go > for them. Specifically, a good starting point are these urls: Well, Red Hat isn't going to create the set of suggested changes. We can review suggestions and if some general agreement is reached we can help keep a config file in sync because we have the infrastructure to do it without too much pain; as I said before, that would be opportunistic and when it broke, we wouldn't know until the breakage was reported, and then we'd want to see the suggested fix from RULE. 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 alan at redhat.com Mon Oct 20 21:45:13 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 20 Oct 2003 17:45:13 -0400 (EDT) Subject: Repository feature proposal In-Reply-To: <1066606284.1214.11.camel@edoras.local.net> from "Jeremy Katz" at Hyd 19, 2003 07:31:24 Message-ID: <200310202145.h9KLjDr24976@devserv.devel.redhat.com> > reasons. My initial thoughts are that someone needs to step forward to > work with the mirrors to maintain a list (our IS guys try, but they're > far too overworked to really be able to spend significant amounts of > time on this -- I'm sure smooge will jump in to ditto this ;) Then, we Why isnt it automated ? You need a sign up form, a script to verify a mirror seems to be valid/complete, and I guess 10,000 lines of idiot proofing 8) Alan From alan at redhat.com Mon Oct 20 21:53:36 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 20 Oct 2003 17:53:36 -0400 (EDT) Subject: rsync and rawhide In-Reply-To: <1066573209.3006.25.camel@agnes.fremen.dune> from "Jean Francois Martinez" at Hyd 19, 2003 04:20:10 Message-ID: <200310202153.h9KLraO30315@devserv.devel.redhat.com> > The problem is that RPM is a compressed format. Change one byte in it and > there are chances ALL the remainder of the file is different. One thing gzip can be patched to avoid this. Debian have done so for apt/dpkg (Rusty did a talk on this). It was tried ages ago but caused a problem that should now be fixed. Another big problem for the ftp sites is that rsync is relatively cpu/mem intensive so 3000 parallel rsyncs isnt too cool From katzj at redhat.com Mon Oct 20 21:59:19 2003 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Oct 2003 17:59:19 -0400 Subject: Repository feature proposal In-Reply-To: <200310202145.h9KLjDr24976@devserv.devel.redhat.com> References: <200310202145.h9KLjDr24976@devserv.devel.redhat.com> Message-ID: <1066687158.6365.34.camel@mirkwood.devel.redhat.com> On Mon, 2003-10-20 at 17:45, Alan Cox wrote: > > reasons. My initial thoughts are that someone needs to step forward to > > work with the mirrors to maintain a list (our IS guys try, but they're > > far too overworked to really be able to spend significant amounts of > > time on this -- I'm sure smooge will jump in to ditto this ;) Then, we > > Why isnt it automated ? You need a sign up form, a script to verify a > mirror seems to be valid/complete, and I guess 10,000 lines of idiot There's nothing that says it can't be automated, but it still requires someone to do some work to begin with :-) Jeremy From brugolsky at telemetry-investments.com Mon Oct 20 22:08:59 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Mon, 20 Oct 2003 18:08:59 -0400 Subject: rsync and rawhide In-Reply-To: <200310202153.h9KLraO30315@devserv.devel.redhat.com> References: <1066573209.3006.25.camel@agnes.fremen.dune> <200310202153.h9KLraO30315@devserv.devel.redhat.com> Message-ID: <20031020220859.GB16682@ti19.telemetry-investments.com> On Mon, Oct 20, 2003 at 05:53:36PM -0400, Alan Cox wrote: > > The problem is that RPM is a compressed format. Change one byte in it and > > there are chances ALL the remainder of the file is different. One thing > > gzip can be patched to avoid this. Debian have done so for apt/dpkg (Rusty > did a talk on this). It was tried ages ago but caused a problem that should > now be fixed. > > Another big problem for the ftp sites is that rsync is relatively cpu/mem > intensive so 3000 parallel rsyncs isnt too cool Which of course is trivially solved by reverse-rsync, reducing the whole protocol to a get on the signature file followed by a bunch of range-gets on the target file. This can be done with any static web server, notably RHCA aka TUX. Instead of 10-50 rsync clients, one could have 5000 reverse-rsync clients. Unfortunately, so we are told, this obvious change to the protocol is covered by one or more silly patents. Bill Rugolsky From mark at mark.mielke.cc Mon Oct 20 22:35:33 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Mon, 20 Oct 2003 18:35:33 -0400 Subject: rsync and rawhide In-Reply-To: <200310202153.h9KLraO30315@devserv.devel.redhat.com> References: <1066573209.3006.25.camel@agnes.fremen.dune> <200310202153.h9KLraO30315@devserv.devel.redhat.com> Message-ID: <20031020223533.GA7662@mark.mielke.cc> On Mon, Oct 20, 2003 at 05:53:36PM -0400, Alan Cox wrote: > Another big problem for the ftp sites is that rsync is relatively cpu/mem > intensive so 3000 parallel rsyncs isnt too cool I have to wonder, then, whether the bandwidth is considered to be cheaper than the hardware. I would guess that RedHat spends quite a bit of money allowing free downloads from ftp.redhat.com. This will only increase as the products become more popular, and larger. The price of bandwidth doesn't seem to be dropping anywhere near the same rate. mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From m.fioretti at inwind.it Tue Oct 21 08:03:13 2003 From: m.fioretti at inwind.it (M. Fioretti) Date: Tue, 21 Oct 2003 10:03:13 +0200 Subject: Better packaging for older hardware? In-Reply-To: <20031020152627.A9589@devserv.devel.redhat.com> References: <20031018062944.GB32004@inwind.it> <200310180951.h9I9p5Y25510@devserv.devel.redhat.com> <20031018113648.GA392@inwind.it> <20031018100541.C12648@devserv.devel.redhat.com> <20031019140715.GA3623@inwind.it> <20031020152627.A9589@devserv.devel.redhat.com> Message-ID: <20031021080313.GE906@inwind.it> On Mon, Oct 20, 2003 15:26:27 at 03:26:27PM -0400, Michael K. Johnson (johnsonm at redhat.com) wrote: > So when you have an initial set of suggestions for changes, lets > discuss the suggestions of changes here. > > Just post them as > # CONFIG_FOO is not set > CONFIG_BLAH=128 > etc, for discussion. > I will forward this to the RULE mailing list. Personally, I have almost no idea about the settings to change. Others on the list are more expert. Every suggestion here is still welcome, of course. Ciao, Marco Fioretti -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ Furious activity is no substitute for understanding. -- H.H. Williams From Axel.Thimm at physik.fu-berlin.de Mon Oct 20 10:04:53 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Mon, 20 Oct 2003 12:04:53 +0200 Subject: Split & move yum headers deeper into the hierachy? Message-ID: <20031020100453.GB15294@puariko.nirvana> Currently (or last time I checked) yum headers were created for all archs in the rawhide toplevel hierarchy. Would it make sense to create the yum headers per arch and closer to the RPMS directory, so that it is mirrored and usable in partial mirrors, too? -- 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 Tue Oct 21 08:26:21 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 21 Oct 2003 10:26:21 +0200 Subject: Split & move yum headers deeper into the hierachy? Message-ID: <20031021082621.GH16134@puariko.nirvana> [The original message had a bad To: address, please reply to this one instead.] Currently (or last time I checked) yum headers were created for all archs in the rawhide toplevel hierarchy. Would it make sense to create the yum headers per arch and closer to the RPMS directory, so that it is mirrored and usable in partial mirrors, too? -- 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 thomas at apestaart.org Tue Oct 21 09:07:19 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 21 Oct 2003 11:07:19 +0200 Subject: new release of mach Message-ID: <1066727238.2260.60.camel@ana.onshuis> Hey people, With the new severn beta 3 out, I updated mach to work for this one as well. If someone could try it with fedora core 0.95 *as the host*, let me know how it works out. Release notes attached. Thomas Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> They say if you love somebody you have got to set them free but I would rather be locked to you than living in this pain and misery <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ -------------- next part -------------- mach - make a chroot - RELEASE NOTES ------------------------------------ Announcing the release of mach 0.4.2 - "No More Betas" WHAT IS IT ---------- mach allows you to set up clean roots from scratch for any distribution or distribution variation supported. This clean build root can be used to run jailed services, create disk images, or build clean packages. mach can currently set up roots for the following distributions: - Red Hat 7.0 (basic, updated, FreshRPMS) - Red Hat 7.1 (basic, updated, FreshRPMS) - Red Hat 7.2 (basic, updated, FreshRPMS, JPackage) - Red Hat 7.3 (basic, updated, FreshRPMS, JPackage) - Red Hat 8.0 (basic, updated, Fedora, JPackage, GStreamer, FreshRPMS) - Red Hat 9 (basic, updated, Fedora, JPackage, GStreamer, FreshRPMS) - Fedora Core 0.94 (basic, updated) - Fedora Core 0.95 (basic, updated) - SuSE 8.1/8.2 - Yellowdog Linux 2.3 (basic, updated, FreshRPMS) - Yellowdog Linux 3.0 (basic, updated, FreshRPMS) - Dave/Dina oven/fridge Read the README included in the distribution for a better overview. WHY WOULD YOU USE IT -------------------- mach is helpful: - to create minimal chroot environments to jail services in - to create clean packages for distributions - to catch spec file mistakes, missing buildrequires, and more INFORMATION ----------- mach's homepage is at http://thomas.apestaart.org/projects/mach/ mach is hosted on SourceForge; the project page is http://www.sourceforge.net/projects/mach/ There is a mailing list for development and use of mach. See http://lists.sourceforge.net/lists/listinfo/mach-devel QUICKSTART ---------- a) On a Red Hat 9 system, install the mach rpm from http://thomas.apestaart.org/download/mach b) su - mach c) mach setup base d) mach chroot poke around a bit in the fresh root e) exit f) mach rebuild http://ayo.freshrpms.net/redhat/9/i386/SRPMS.os/vorbis-tools-1.0-3.src.rpm If all goes well, you'll get a nice freshly built vorbis-tools package. Now go out, experiment and bug report ! BUGS ---- Please report all bugs to me at thomas (at) apestaart (dot) org. Always state what platform you are running on, if it's a clean install or somehow updated, how I can reproduce the bug, and output of a run of the failed command with -d (debugging). From shekhar.tiwatne at ensim.com Tue Oct 21 09:26:18 2003 From: shekhar.tiwatne at ensim.com (Shekhar) Date: 21 Oct 2003 14:56:18 +0530 Subject: code2html rpm packaging In-Reply-To: <20031020160011.32405.33569.Mailman@listman.back-rdu.redhat.com> References: <20031020160011.32405.33569.Mailman@listman.back-rdu.redhat.com> Message-ID: <1066728378.3691.62.camel@stiwatne.india.ensim.com> Hello, Today I came across code2html package. I found it very useful. I have packaged it for RedHat / Fedora. What is the formal procedure to send a request for including it in the fedora distro. Source is available here:http://www.palfrader.org/code2html/ Thanks, -- shekhar From Nicolas.Mailhot at laPoste.net Tue Oct 21 09:41:44 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 21 Oct 2003 11:41:44 +0200 Subject: Repository feature proposal In-Reply-To: <1066593588.12170.24.camel@m70.net81-64-235.noos.fr> References: <1066559368.6118.35.camel@h24n2fls33o1121.telia.com> <200310191223.h9JCNet03317@devserv.devel.redhat.com> <20031019084909.D16905@redhat.com> <1066577695.11018.12.camel@m70.net81-64-235.noos.fr> <1066578334.30112.9.camel@binkley> <1066580683.11018.62.camel@m70.net81-64-235.noos.fr> <1066583178.11670.20.camel@m70.net81-64-235.noos.fr> <1066591326.3612.23.camel@binkley> <1066593588.12170.24.camel@m70.net81-64-235.noos.fr> Message-ID: <1066729303.3690.41.camel@ulysse.olympe.o2t> [ Keeping on pretending this stuff interests someone - if not just tell me so ] Evil XML ahead Fell free to flame me - general remarks like "xml sucks" will be /dev/nulled %<------------- Fedora ..... ..... Core Packages .... Core Packages .... Core Packages .... ... Red Hat .... ... ... ... -- 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 buildsys at porkchop.devel.redhat.com Tue Oct 21 10:03:49 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Tue, 21 Oct 2003 06:03:49 -0400 Subject: rawhide report: 20031021 changes Message-ID: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> Updated Packages: anaconda-9.0.96-0.20031020190818 -------------------------------- * Mon Oct 20 2003 Anaconda team - built new version from CVS * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 * Mon Sep 09 2002 Jeremy Katz - can't buildrequire dietlibc and kernel-pcmcia-cs since they don't always exist * Wed Aug 21 2002 Jeremy Katz - added URL * Thu May 23 2002 Jeremy Katz - add require and buildrequire on rhpl * Tue Apr 02 2002 Michael Fulbright - added some more docs * Fri Feb 22 2002 Jeremy Katz - buildrequire kernel-pcmcia-cs as we've sucked the libs the loader needs to there now * Thu Feb 07 2002 Michael Fulbright - goodbye reconfig * Thu Jan 31 2002 Jeremy Katz - update the BuildRequires a bit * Fri Jan 04 2002 Jeremy Katz - ddcprobe is now done from kudzu * Wed Jul 18 2001 Jeremy Katz - own /usr/lib/anaconda and /usr/share/anaconda * Fri Jan 12 2001 Matt Wilson - sync text with specspo * Thu Aug 10 2000 Matt Wilson - build on alpha again now that I've fixed the stubs * Wed Aug 09 2000 Michael Fulbright - new build * Fri Aug 04 2000 Florian La Roche - allow also subvendorid and subdeviceid in trimpcitable * Fri Jul 14 2000 Matt Wilson - moved init script for reconfig mode to /etc/init.d/reconfig - move the initscript back to /etc/rc.d/init.d - Prereq: /etc/init.d * Thu Feb 03 2000 Michael Fulbright - strip files - add lang-table to file list * Wed Jan 05 2000 Michael Fulbright - added requirement for rpm-python * Mon Dec 06 1999 Michael Fulbright - rename to 'anaconda' instead of 'anaconda-reconfig' * Fri Dec 03 1999 Michael Fulbright - remove ddcprobe since we don't do X configuration in reconfig now * Tue Nov 30 1999 Michael Fulbright - first try at packaging reconfiguration tool anaconda-help-9.0.95-1.200310201633 ----------------------------------- man-pages-ja-20031015-1 ----------------------- * Tue Oct 21 2003 Akira TAGOH 20031015-1 - updates to 20031015. miniChinput-0.0.3-52 -------------------- * Tue Oct 21 2003 Yu Shao 52 - Bug 106807, use Dynamic Event Flow model, XIM updates. nvi-m17n-1.79-20011024.15 ------------------------- * Mon Oct 20 2003 Akira TAGOH 1.79-20011024.15 - nvi-1.79-fix-build-warnings.patch: updated to fix some build warnings. (#105843) openjade-1.3.2-8 ---------------- * Mon Oct 20 2003 Tim Waugh 1.3.2-8 - Rebuilt. * Tue Sep 23 2003 Florian La Roche 1.3.2-7 - do not link against -lnsl * Thu Aug 07 2003 Tim Waugh 1.3.2-6 - Rebootstrap to create a libtool that actually works. * Wed Aug 06 2003 Tim Waugh 1.3.2-5 - Rebuilt. * Wed Jun 04 2003 Elliot Lee 1.3.2-4 - rebuilt * Thu May 22 2003 Tim Waugh 1.3.2-3 - Fixes for GCC 3.3. - Use --parents for %doc. * Tue Mar 18 2003 Tim Waugh 1.3.2-2 - Provide sgml2xml man page (bug #83759). - Add devel subpackage. * Fri Mar 14 2003 Tim Waugh 1.3.2-1 - OpenSP 1.5, openjade 1.3.2. - Renumber patches. * Thu Feb 13 2003 Elliot Lee 1.3.1-13 - Add openjade-ppc64.patch * Wed Jan 22 2003 Tim Powers - rebuilt * Tue Jan 07 2003 Jeff Johnson 1.3.1-11 - don't include -debuginfo files in package. * Thu Dec 12 2002 Tim Waugh - Fix typo in description (bug #79395). * Mon Nov 04 2002 Tim Waugh 1.3.1-10 - Fix DTD retrieval from virtual hosts (bug #77137). * Sat Aug 10 2002 Elliot Lee - rebuilt with gcc-3.2 (we hope) * Mon Jul 22 2002 Tim Powers 1.3.1-8 - rebuild using gcc-3.2-0.1 * Fri Jun 21 2002 Tim Powers 1.3.1-7 - automated rebuild * Thu Jun 13 2002 Tim Waugh 1.3.1-6 - Fix sgmlnorm(1) man page (bug #64136). - Fix %files list (bug #64323). * Thu May 23 2002 Tim Powers 1.3.1-5 - automated rebuild * Thu Feb 21 2002 Tim Waugh 1.3.1-4 - Avoid bad triggers. * Thu Feb 21 2002 Tim Waugh 1.3.1-3 - Rebuild in new environment. * Mon Jan 28 2002 Tim Waugh 1.3.1-2 - Ship man pages. * Mon Jan 28 2002 Tim Waugh 1.3.1-1 - 1.3.1. - Patches no longer needed: decl, strdup, foo, size_t, 31525, indev, ligature, twosidestartonright. - Updated lt patch. * Mon Jan 14 2002 Tim Waugh 1.3-22 - Enable build on GCC 3.0 onwards. - Run libtoolize. * Fri Nov 02 2001 Tim Waugh 1.3-21 - Enable HTTP support. Now a DocBook XML document can be processed by either xsltproc or openjade. * Tue Oct 30 2001 Tim Waugh 1.3-20 - Apply twosidestartonright patch from Ian Castle. * Thu Oct 11 2001 Tim Waugh 1.3-19 - s/Copyright:/License:/ - Use %{_tmppath}. - Fix up libtool libraries (bug #46212). * Wed Sep 12 2001 Tim Powers 1.3-18 - rebuild with new gcc and binutils * Fri Jun 15 2001 Tim Waugh 1.3-17 - Apply patch from CVS to break up unintentional ligatures (bugs #11497, * Mon Jun 04 2001 Tim Waugh 1.3-16 - Apply the iNdev openjade-1.3.patch patch. * Tue May 29 2001 Tim Waugh 1.3-15 - ldconfig (bug #32824). - Fix up some libtool problems. * Fri Apr 27 2001 Bill Nottingham 1.3-14 - rebuild for C++ exception handling on ia64 - build with optimization on ia64 * Tue Mar 13 2001 Tim Waugh - Avoid creating bogus TeX output for section headings containing special characters (#bug 31525). * Mon Jan 22 2001 Florian La Roche - Apply original autoconf patch to s390 s390x only. This patch can be deleted once s390* uses a current compiler. * Fri Jan 19 2001 Tim Waugh - Don't conflict with stylesheets; require sgml-common >= 0.5 instead. - Revert autoconf change, as it's still broken. * Wed Jan 17 2001 Florian La Roche - fix this autoconf macro to work on all archs :-) * Wed Jan 17 2001 Florian La Roche - apply patch from Fritz Elfert - removed explicit stripping - Added autoconf macro for correctly recognizing if size_t is unsigned int * Tue Jan 16 2001 Tim Waugh - Default catalog file is /etc/sgml/catalog. * Mon Jan 08 2001 Tim Waugh - Conflict with stylesheets (new-trials location changes). - /usr/lib/sgml -> /usr/share/sgml/%{name}-%{version}. - Remove %post and %postun. * Wed Oct 18 2000 Matt Wilson - rebuilt against g++-2.96-60, fixes jade on alpha * Wed Jul 12 2000 Prospector - automatic rebuild * Tue Jul 04 2000 Jakub Jelinek - Rebuild with new C++ * Wed May 31 2000 Matt Wilson - fix several C++ build problems (declarations) - build against new libstdc++ * Wed May 17 2000 Matt Wilson - build with -O0 on alpha - fix -j testing * Fri May 05 2000 Bill Nottingham - openjade is maintained, and actually builds. Let's try that. * Thu Mar 09 2000 Bill Nottingham - this package is way too huge. strip *everything* * Mon Feb 21 2000 Matt Wilson - build with CXXFLAGS="-O2 -ggdb" to work around segfault on alpha * Thu Feb 03 2000 Bill Nottingham - strip binaries * Wed Jan 05 2000 Bill Nottingham - sanitize spec file some * Tue Aug 17 1999 Tim Powers - fixed conflict problem with sgml-tools * Sat Jul 17 1999 Tim Powers - changed buildroot path to /var/tmp - rebuilt for 6.1 * Fri Apr 23 1999 Michael K. Johnson - quiet scripts * Fri Apr 23 1999 Owen Taylor - Made requires for sgml-common into prereq perl-Net-DNS-0.31-3.2 --------------------- * Mon Oct 20 2003 Chip Turner 0.31-3.2 - fix interactive build issue rawhide-release-20031021-1 -------------------------- redhat-config-nfs-1.1.2-2 ------------------------- * Mon Oct 20 2003 Brent Fox 1.1.2-2 - remove leftover import in mainWindow.py * Mon Oct 20 2003 Brent Fox 1.1.2-1 - use htmlview to find default browser (bug #107603) redhat-config-packages-1.2.6-1 ------------------------------ * Mon Oct 20 2003 Jeremy Katz 1.2.6-1 - make timestamp requirements less strict since .discinfo's were getting truncated timestamps (#105767 and others) * Wed Sep 24 2003 Jeremy Katz 1.2.5-1 - Throw out packages which aren't for our arch earlier (#105005) * Fri Sep 19 2003 Jeremy Katz 1.2.4-1 - fix requirement formatting (#104715) * Thu Sep 04 2003 Jeremy Katz 1.2.3-1 - fix help message * Fri Aug 29 2003 Jeremy Katz 1.2.2-1 - fix for ppc64 (#103375) * Wed Aug 20 2003 Jeremy Katz 1.2.1-1 - fix for case without order in comps file (#102278) * Tue Aug 12 2003 Jeremy Katz 1.2.0-1 - update for multilib fun * Fri Apr 18 2003 Jeremy Katz 1.1.9-1 - we can't check sigs with the db closed (#88343) * Mon Feb 24 2003 Jeremy Katz 1.1.8-1 - fix for backwards of what I expected flags stuff in single package mode (reported on phoebe list) * Sun Feb 23 2003 Jeremy Katz 1.1.7-1 - add startup notification - update translations * Tue Feb 11 2003 Jeremy Katz - update requires on rpm (#84039) * Sun Feb 09 2003 Jeremy Katz 1.1.6-1 - various minor bugfixes * Mon Jan 13 2003 Jeremy Katz 1.1.5-1 - name change in desktop file * Fri Jan 03 2003 Than Ngo 1.1.4-1 - fix bug #80468 * Thu Jan 02 2003 Jeremy Katz 1.1.3-1 - add url support (--tree={ftp,http}://) (#79000) * Wed Jan 01 2003 Jeremy Katz 1.1.2-1 - few minor fixes (#80800) * Sat Dec 28 2002 Jeremy Katz 1.1.1-1 - fs for cds can now be udf,iso9660 as well - fix up state reading to be faster (bug in rpm 4.2 porting) * Wed Oct 30 2002 Jeremy Katz - update to work with rpm 4.2 * Fri Oct 11 2002 Jeremy Katz - add scrollkeeper to removal blacklist so that we can't mistakenly most of GNOME (#74958) - RPMTAG_PROVIDES can be None in some cases; don't try to iterate over None (#74877) - don't allow src.rpms to be installed into the database (#75388) - fix size string translation (#75584) - fix spanish translation which caused a segfault due to missing (#74973) - make instProvs and providesDict use lists as their values so we don't remove packages erroneously if multiple packages provide something (#75661) - more translation updates * Tue Sep 03 2002 Jeremy Katz - update translations * Fri Aug 30 2002 Jeremy Katz - set hint so that nautilus won't pop up windows while installing - fix pixmap path for CDs - add a way for centering for firstboot - miscellaneous other minor bug fixes * Thu Aug 29 2002 Jeremy Katz - oops, another typo fix build * Thu Aug 29 2002 Jeremy Katz - obsolete gnorpm - other minor fixes - fix bad interactions with magicdev * Wed Aug 28 2002 Jeremy Katz - add README * Wed Aug 28 2002 Jeremy Katz - handle extra CDs having dependencies on packages within the main distribution * Tue Aug 27 2002 Jeremy Katz - handle multiple CD-ROM drives more sanely - start handling packages from multiple sources better - fix textdomain of specspo * Sat Aug 24 2002 Jeremy Katz - fix a typo * Sat Aug 24 2002 Jeremy Katz - Make the single-package tool faster if dependencies are already installed. - Various other minor bugfixes * Thu Aug 15 2002 Preston Brown - handle package installation in KDE as well. * Wed Aug 14 2002 Jonathan Blandford - new version. Added the single-package tool * Mon Aug 12 2002 Jeremy Katz - another new version with lots more changes - add sample autorun to included docs * Tue Aug 06 2002 Jonathan Blandford - New version * Sun Aug 04 2002 Jeremy Katz - huge numbers of changes. starting to work a lot better * Fri Jul 26 2002 Jeremy Katz - fix desktop file so that we show up in the main apps menu - fix requires * Tue Jul 23 2002 Jonathan Blandford - Create spec file redhat-config-printer-0.6.79-1 ------------------------------ * Mon Oct 20 2003 Tim Waugh 0.6.79-1 - 0.6.79: - Small display bugfix for print.py. - Don't adjust LogLevel when printing a test page (bug #107537). redhat-config-users-1.2.3-1 --------------------------- * Mon Oct 20 2003 Brent Fox 1.2.3-1 - use htmlview to find default browser (bug #107604) rhgb-0.11.1-2 ------------- s390utils-1.2.1-3.1 ------------------- * Mon Oct 20 2003 Phil Knirsch 2:1.2.1-3.1 - rebuilt * Mon Oct 20 2003 Phil Knirsch 2:1.2.1-3 - Small fix for the new automenu patch, default section didn't work correctly * Mon Oct 20 2003 Phil Knirsch 2:1.2.1-2.1 - rebuilt * Fri Oct 17 2003 Phil Knirsch 2:1.2.1-2 - Patched new zipl to be backwards compatible to old multiboot feature. * Thu Oct 09 2003 Harald Hoyer 2:1.2.1-1 - second round at updating to 1.2.1 * Thu Oct 09 2003 Florian La Roche - first round at updating to 1.2.1 * Sat Sep 27 2003 Florian La Roche - add /boot/tape0 for .tdf tape boots * Fri Jul 25 2003 Florian La Roche - apply dasdfmt patch from 1.2.1 * Fri Jun 20 2003 Phil Knirsch 1.1.7-1 - Updated to latest upstream version 1.1.7 * Fri May 02 2003 Pete Zaitcev 1.1.6-7 - Fix usage of initialized permissions for bootmap. * Tue Apr 29 2003 Florian La Roche - add extra tape loader from Pete Zaitcev * Mon Apr 14 2003 Karsten Hopp 2:1.1.6-5 - drop cpint support * Mon Mar 24 2003 Karsten Hopp 1.1.6-4 - use multiboot as default - add option to disable multiboot * Sat Mar 22 2003 Karsten Hopp 1.1.6-3 - add multiboot patch * Mon Mar 10 2003 Karsten Hopp 1.1.6-2 - added percentage patch (used by anaconda to display progress bars) * Thu Feb 27 2003 Phil Knirsch 1.1.6-1 - Updated to newest upstream version 1.1.6 * Tue Feb 04 2003 Phil Knirsch 1.1.5-1 - Updated to newest upstream version 1.1.5 * Tue Feb 04 2003 Karsten Hopp 1.1.4-3 - install libraries in /lib*, not /usr/lib*, they are required by some tools in /sbin * Sun Feb 02 2003 Florian La Roche - fix filelist to not include debug files * Fri Jan 24 2003 Phil Knirsch 1.1.4-1 - Updated to latest upstream version of IBM. - Removed all unecessary patches and updated still needed patches. - Fixed version number. Needed to introduce epoch though. - A little specfile cleanup. - Dropped oco-setver and oco-convert as we don't need them anymore. * Wed Jan 22 2003 Phil Knirsch 20020226-4 - Added ExclusiveArch tag. * Mon Oct 21 2002 Phil Knirsch 20020226-3 - Removed fdisk -> fdasd symlink. Is now provided by util-linux. - Disabled f5 patch for s390x for now. Enable it later for newer kernels again. * Mon May 27 2002 Phil Knirsch - Fixed dasdview to build on kernels > 2.4.18. * Wed Apr 24 2002 Karsten Hopp - add IBM 5 patch * Tue Jan 29 2002 Karsten Hopp - add IBM 4 patch - add profile.d scripts to set correct TERM in 3270 console * Tue Dec 18 2001 Karsten Hopp - add cpint programs * Mon Nov 26 2001 Harald Hoyer 20011012-6 - fix for #56720 * Thu Nov 15 2001 Karsten Hopp - add fdisk - > fdasd symlink * Mon Nov 12 2001 Karsten Hopp - add IBM patch (11/09/2001) and redo percentage patch * Thu Nov 08 2001 Karsten Hopp - re-enable DASD if dasdfmt is interrupted with Ctrl-C * Mon Nov 05 2001 Harald Hoyer 20011012-4 - added s390-tools-dasdfmt-percentage.patch * Mon Oct 22 2001 Karsten Hopp - remove postinstall script * Mon Oct 15 2001 Karsten Hopp - add IBM's s390-utils-2.patch - add console to securetty * Mon Oct 01 2001 Karsten Hopp - added oco-setkver and oco-convert * Fri Aug 31 2001 Karsten Hopp - don't write error message in silent mode * Thu Aug 23 2001 Harald Hoyer - added s390-tools-dasdfmt-status.patch * Tue Aug 21 2001 Karsten Hopp - update to the version from Aug 20 * Tue Aug 14 2001 Karsten Hopp - fix permissions * Mon Aug 13 2001 Karsten Hopp - rename package to s390utils. s390-tools is no longer needed. * Thu Aug 02 2001 Karsten Hopp - initial build xinitrc-3.34-1 -------------- * Mon Oct 20 2003 Mike A. Harris 3.34-1 - Changed the default background colour argument passed to xsetroot in both the Xsession and Xsetup_0 scripts from "#5477A0" to "#20305A" From veillard at redhat.com Tue Oct 21 10:55:53 2003 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 21 Oct 2003 06:55:53 -0400 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <20031021082621.GH16134@puariko.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Tue, Oct 21, 2003 at 10:26:21AM +0200 References: <20031021082621.GH16134@puariko.nirvana> Message-ID: <20031021065553.A16905@redhat.com> On Tue, Oct 21, 2003 at 10:26:21AM +0200, Axel Thimm wrote: > [The original message had a bad To: address, please reply to this one > instead.] > > Currently (or last time I checked) yum headers were created for all > archs in the rawhide toplevel hierarchy. > > Would it make sense to create the yum headers per arch and closer to > the RPMS directory, so that it is mirrored and usable in partial > mirrors, too? Hunnestly, yum-arch run so fast, that I think it's simpler to simply rerun it on your mirror than mirror the header directories ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Nicolas.Mailhot at laPoste.net Tue Oct 21 11:01:09 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 21 Oct 2003 13:01:09 +0200 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <20031021065553.A16905@redhat.com> References: <20031021082621.GH16134@puariko.nirvana> <20031021065553.A16905@redhat.com> Message-ID: <1066734069.4514.1.camel@ulysse.olympe.o2t> Le mar 21/10/2003 ? 12:55, Daniel Veillard a ?crit : > On Tue, Oct 21, 2003 at 10:26:21AM +0200, Axel Thimm wrote: > > [The original message had a bad To: address, please reply to this one > > instead.] > > > > Currently (or last time I checked) yum headers were created for all > > archs in the rawhide toplevel hierarchy. > > > > Would it make sense to create the yum headers per arch and closer to > > the RPMS directory, so that it is mirrored and usable in partial > > mirrors, too? > > Hunnestly, yum-arch run so fast, that I think it's simpler to simply > rerun it on your mirror than mirror the header directories ! However a lot of mirrors just do blind ftp mirroring and won't reindex any stuff. You can't ask them to special-case rpm mirrors. 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 Tue Oct 21 11:27:45 2003 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 21 Oct 2003 07:27:45 -0400 (EDT) Subject: Newer ATI Radeon, ATI FireGL, and Nvidia GeForce/Quadro hardware support Message-ID: This document concerns the current state of the XFree86 video driver support for ATI Radeon, FireGL, and Nvidia GeForce and Quadro video hardware which is present in Red Hat rawhide, and the current Fedora Core OS test release. I'm posting this in order to solicit feedback, and also to get more people involved in reporting bugs and also notifying Red Hat and myself of any missing hardware support, etc. for these 2 video drivers. More information on the Fedora Project, and our current Fedora Core test release can be found at: http://fedora.redhat.com Just to be clear, this information does not apply to any previous Red Hat operating systems such as Red Hat Linux 8.0, 7.x, but is exclusive to Fedora Core test 3 and later. Also, this video hardware support will also be released as an update for Red Hat Linux 9 in the near future, as: XFree86-4.3.0-2.90.$RAWHIDE_RELEASE_NUMBER ATI Radeon and FireGL support status: XFree86 4.3.0, which is in Fedora Core test releases and rawhide currently, contains additional patches to support newer ATI Radeon and FireGL video hardware than what the stock XFree86 4.3.0 release supports. This support is a combination of 4 things: 1) Enhancements I've implemented myself voluntarily on weekends, etc. and included, which either have been committed to XFree86 CVS already, or will be in the future hopefully. 2) Code that I have backported from the XFree86 developmental CVS head, either developed by ATI, or by other people who work on the "radeon" driver. 3) Code contributed to me directly by ATI. 4) Code contributed to me directly by other developers. Currently, our customized 4.3.0 "radeon" driver supports almost all ATI Radeon and FireGL hardware. 3D is supported on all video hardware up to and including the Radeon 9000 and 9100, FireGL 8700, 8800, and it may or may not also work on the 9200 hardware (untested). 2D support is present for all hardware including the 9500/9600/9700/9800 series cards also, and the newer ATI FireGL X1/Z1 hardware. There are different variants of these cards out there however, and some cards have different PCI device IDs than others, and so for example, while Radeon 9800 is supported 2D only, it's possible that someone might have a Radeon 9800 card that is unknown to our pcitable, and unknown to the video driver, but which otherwise should/would work ok once the PCI ID is made known to the video driver and pcitable database. About 2 weeks ago I updated the driver with a newer list of PCI IDs sent to me from ATI which was believed to cover all of the existing hardware at the point ATI sent me the files. I tested this on the hardware I personally have available, and everything worked fine, however I don't have one of every single card for every single PCI device ID out there, so I can only vouch for the particular chips I physically have available to test. Since then a number of newer ATI Radeon and FireGL hardware has been released by ATI, such as the 9800Pro XT and SE, 9600 XT/SE, and new FireGL cards. I do not yet have all of this hardware, however some of this hardware might work with the existing driver currently in rawhide, while other cards might still need to have their PCI IDs added before they're functional. This also goes for the Radeon Mobility, FireGL Mobility, and ATI Radeon IGP and Mobility IGP chipsets. Here is a list of all chips that the driver currently supports: ATI Radeon QD (AGP) ATI Radeon QE (AGP) ATI Radeon QF (AGP) ATI Radeon QG (AGP) ATI Radeon VE/7000 QY (AGP) ATI Radeon VE/7000 QZ (AGP) ATI Radeon Mobility M7 LW (AGP) ATI Mobility FireGL 7800 M7 LX (AGP) ATI Radeon Mobility M6 LY (AGP) ATI Radeon Mobility M6 LZ (AGP) ATI Radeon IGP320 (A3) 4136 ATI Radeon IGP320M (U1) 4336 ATI Radeon IGP330/340/350 (A4) 4137 ATI Radeon IGP330M/340M/350M (U2) 4337 ATI Radeon 7000 IGP (A4+) 4237 ATI Radeon Mobility 7000 IGP 4437 ATI FireGL 8700/8800 QH (AGP) ATI Radeon 8500 QI (AGP) ATI Radeon 8500 QJ (AGP) ATI Radeon 8500 QK (AGP) ATI Radeon 8500 QL (AGP) ATI Radeon 9100 QM (AGP) ATI Radeon 8500 QN (AGP) ATI Radeon 8500 QO (AGP) ATI Radeon 8500 Qh (AGP) ATI Radeon 8500 Qi (AGP) ATI Radeon 8500 Qj (AGP) ATI Radeon 8500 Qk (AGP) ATI Radeon 8500 Ql (AGP) ATI Radeon 8500 BB (AGP) ATI Radeon 7500 QW (AGP) ATI Radeon 7500 QX (AGP) ATI Radeon 9000 Id (AGP) ATI Radeon 9000 Ie (AGP) ATI Radeon 9000 If (AGP) ATI Radeon 9000 Ig (AGP) ATI Radeon Mobility M9 Ld (AGP) ATI Radeon Mobility M9 Le (AGP) ATI Radeon Mobility M9 Lf (AGP) ATI Radeon Mobility M9 Lg (AGP) ATI Radeon 9000 IGP (A5) 5834 ATI Radeon Mobility 9000 IGP (U3) 5835 ATI Radeon 9200 5960 (AGP) ATI Radeon 9200 5961 (AGP) ATI Radeon 9200 5962 (AGP) ATI Radeon 9200 5963 (AGP) ATI Radeon 9200 5964 (AGP) ATI Radeon M9+ 5968 (AGP) ATI Radeon M9+ 5969 (AGP) ATI Radeon M9+ 596A (AGP) ATI Radeon M9+ 596B (AGP) ATI Radeon 9500 AD (AGP) ATI Radeon 9500 AE (AGP) ATI Radeon 9500 AF (AGP) ATI FireGL Z1/X1 AG (AGP) ATI Radeon 9700 Pro ND (AGP) ATI Radeon 9700/9500Pro NE (AGP) ATI Radeon 9700 NF (AGP) ATI FireGL X1 NG (AGP) ATI Radeon 9600 AP (AGP) ATI Radeon 9600 Pro AR (AGP) ATI Radeon Mobility M10 NP (AGP) ATI FireGL (R350) AK (AGP) ATI Radeon 9800 NH (AGP) ATI FireGL (R350) NK (AGP) If someone has an ATI Radeon or FireGL card which is not on this list, it is currently not supported by the driver. Run "lspci" and look and see if it lists the card by name, or if it says "unknown" or similar. If lspci doesn't know what the card is, even if it isn't on the above list, please file a bug report in bugzilla, and include full details of the video card, and also manually choose any Radeon video card from the list of hardware in redhat-config-xfree86 and test the card out with X. Report any problems found in your bugzilla bug report. I plan on improving our 4.3.0 radeon driver to support any new cards that come out whenever I have the information I need to do the work, and have some spare weekend-hacker time to do the necessary volunteer work. Currently the XT/SE cards wont work I don't think, however you can probably trick them into working by using the "ChipID" config file directive in the config file to lie to the driver about what card you have. "man XF86Config" documents this option and how to use it. ie: ChipId "0x4150" That line would probably allow a Radeon 9600 SE/XT/whatever to work by faking that it is a "Radeon 9600 AP". You can get the various PCI ID numbers for various supported cards from: /usr/share/hwdata/pcitable So, if your card is not autodetected by our config tool and/or not autodetected by the video driver, please report a bug report or request for enhancement in bugzilla, so that I at least know about the missing hardware support and might be able to add support for it when I have spare time, for future XFree86 4.3.0 update releases. I can't guarantee any kind of speedy resolution of course, but it'd be nice to have a list of various cards in bugzilla that need work, so that when I do have the time to hack on it, I can add them all at once. ;o) Nvidia support status: The "nv" driver in 4.3.0 supports the majority of Nvidia hardware that existed in February 2003, plus it has code to support similar hardware that Nvidia planned on shipping later than that, but which the driver will claim is "unknown Nvidia blah blah" and try to drive it nonethless. The "nv" driver *only* supports CRT displays officially, flat panel display types are not officially supported, but the driver has experimental support which might or might not work depending on the exact brand/make/model/phase of the moon, etc. It is also possible that there are newer Nvidia boards that aren't supported or just don't work at all for one reason or another. User's experiencing problems with the "nv" driver, be they general bugs, or lack of support for their particular card, should also file bug reports in Red Hat bugzilla, however they should also file them in XFree86 bugzilla as Nvidia doesn't release their specifications nor any detailed information on how their hardware works, so adding support for new chips is nowhere near as simple as doing it for the Radeon driver. All Nvidia "nv" driver related bug reports if filed in Red Hat bugzilla, should also be filed at: http://bugs.xfree86.org including complete details of any problems, and having config file and log file attachments. Where possible, I will try to also update the Nvidia "nv" driver to support newer Nvidia hardware as volunteer time permits. NOTE: This is STRICTLY for the Red Hat/XFree86 supplied "nv" driver. DO NOT file bug reports about using the proprietary Nvidia video drivers, as we do not support those drivers at all. Any problems experienced while using the Nvidia proprietary drivers should be reported to Nvidia directly and discussed on their end user web support forums (don't have the URL handy) as this is Nvidia Inc.'s preferred mechanism for handling problems in their drivers. If a user is using both the proprietary and the "nv" driver on their system and having problems with the "nv" driver, before reporting problems, disable the proprietary driver and it's kernel module completely, then do a full system reboot in order to reset the video hardware to it's default power on state, as the different drivers can and do program the Nvidia hardware a bit differently and this can cause the 'nv' driver to fail once the proprietary driver has been used since boot time. Final comments: I must ask politely that people please do NOT email me personally for help configuring their hardware or solving X configuration problems, etc. I generally get 20-50 or more email requests for special help from people when I send an email like this out, and unfortunately, I really truely do not have time to help that many people out individually. Any email based tech support or discussion of any problems should take place on xfree86-list at redhat.com, or fedora-devel-list at redhat.com, or even xfree86 at xfree86.org, so that numerous developers and other people can possibly assist with a given problem someone is experiencing. Any generic questions about future X support or development should also be directed to one of those mailing lists, or dri-devel on sourceforge, rather than directly to me. Bug reports and RFEs should be filed at: http://bugzilla.redhat.com http://bugs.xfree86.org While this email is rather lengthy, if I've missed anything and someone decides to respond, please respond on the mailing list that you received this email from and do not reply directly to me privately. I'll probably reply to any discussions on our mailing lists that crop up from this mail, but probably ignore all private replies. ;o) Thanks in advance for testing out this new hardware support, and for contributing bug reports and enhancement requests so that we can hopefully end up being able to support the latest video hardware for y'all. ;o) Enjoy. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Tue Oct 21 11:35:04 2003 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 21 Oct 2003 07:35:04 -0400 (EDT) Subject: rawhide report: 20031021 changes In-Reply-To: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> Message-ID: On Tue, 21 Oct 2003, Build System wrote: >Date: Tue, 21 Oct 2003 06:03:49 -0400 >From: Build System >To: fedora-devel-list at redhat.com >List-Id: For developers, developers, developers >Subject: rawhide report: 20031021 changes [SNIP] Just a suggestion.... These emails are useful, but they could be greatly improved upon IMHO. It appears that when a package gets updated, it's complete changelog, or a large portion of it gets sent out in the emails, the majority of which is ancient information from as far back as 1999, which only blurs the actual useful information of what has changed. I suggest that the changelogs are trimmed to only include the relevant changes since the last rawhide push, or if that's too difficult to implement, just include the last 2-4 changelog entries so that the most relevant and recent changes are shown only. Also, it is hard when scanning through the emails to visually spot where one package's changes begin and another ends. I recommend putting a single line of "###################" characters between each package changelog to provide a visual cue to allow people to more easily scan through the emails and find the information that might be useful to them. If XFree86's changelog got posted verbatim in these emails, some people's MTAs would probably reject the email based on size alone. ;o) I don't think anyone is interested in bugs Bero fixed in XFree86 back in 1999 for example. ;o) Again, just a suggestion... What do others in the community think about the idea? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Tue Oct 21 11:44:14 2003 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 21 Oct 2003 07:44:14 -0400 (EDT) Subject: rawhide report: 20031021 changes In-Reply-To: References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> Message-ID: On Tue, 21 Oct 2003, Mike A. Harris wrote: >If XFree86's changelog got posted verbatim in these emails, some >people's MTAs would probably reject the email based on size >alone. ;o) I don't think anyone is interested in bugs Bero >fixed in XFree86 back in 1999 for example. ;o) I went looking, and found that the XFree86 changelog is actually trimmed to the last 3-4 changelog entries, so that is good at least. ;o) Another suggestion for improvement in the emails is that it would be nice if there was a summary listing just the package names that have been updated were at the top of the mail. ie: New packages updated: --------------------- foo-1.2-3 bar-2.3-4 baz-4.5-6 XFree86-4.3.0-42 Individual package changelog highlights: ---------------------------------------- foo-1.2-3 * Sun Oct 12 2003 ........ - foo updated to fix bug blah #################################################### bar-2.3-4 * Sun Oct 12 2003 ........ - bar updated to fix bug blah #################################################### baz-4.5-6 * Sun Oct 12 2003 ........ - baz updated to fix bug blah #################################################### XFree86-4.3.0-42 * Sun Oct 12 2003 ........ - Complete support for all video hardware ever manufactureed, including full support for all features of that hardware has now been implemented, and all bugs in all drivers and in the X server itself, and all libraries have now been fixed. Looks much nicer now doesn't it? ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From rezso at rdsor.ro Tue Oct 21 11:50:53 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Tue, 21 Oct 2003 14:50:53 +0300 Subject: rawhide report: 20031021 changes In-Reply-To: References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> Message-ID: <200310211450.53770.rezso@rdsor.ro> On Tuesday 21 October 2003 14:35, Mike A. Harris wrote: > On Tue, 21 Oct 2003, Build System wrote: > >Date: Tue, 21 Oct 2003 06:03:49 -0400 > > From: Build System > > >To: fedora-devel-list at redhat.com > >List-Id: For developers, developers, developers > > Subject: rawhide report: 20031021 changes The email is very useful, was a very good idea, till now was hellish: I am happy to see a report of changelog, rather to connect ftp.redhat.com at my 17:00 PM and do ftp again again and again till i catch a free conection than do sort by change-date and knoledge what is changed .... > If XFree86's changelog got posted verbatim in these emails, some > people's MTAs would probably reject the email based on size > alone. ;o) I don't think anyone is interested in bugs Bero > fixed in XFree86 back in 1999 for example. ;o) > > Again, just a suggestion... What do others in the community > think about the idea? As Mike suggested, I would be _more_ nice to show only changelog since previous package not the whole changelog, for me is an effort to keep my eye on screen to find what is the "package-name" and what is the "changelog" ... from the kilometric e-mail, plus probably other people not too happy about huge mails ... More suggestions: And would be more nice to see colored highlight (red coloured aka "redhat" for e.g :) ) of package-name and in rest changelog to be normal black eventualy the changelog "date" numbers to be grey, but that implies html mail instead of text mail. thanks for atention ! cristian From rezso at rdsor.ro Tue Oct 21 11:54:39 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Tue, 21 Oct 2003 14:54:39 +0300 Subject: rawhide report: 20031021 changes In-Reply-To: References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> Message-ID: <200310211454.39801.rezso@rdsor.ro> On Tuesday 21 October 2003 14:44, Mike A. Harris wrote: > On Tue, 21 Oct 2003, Mike A. Harris wrote: > >If XFree86's changelog got posted verbatim in these emails, some > >people's MTAs would probably reject the email based on size > >alone. ;o) I don't think anyone is interested in bugs Bero > >fixed in XFree86 back in 1999 for example. ;o) > > I went looking, and found that the XFree86 changelog is actually > trimmed to the last 3-4 changelog entries, so that is good at > least. ;o) > > Another suggestion for improvement in the emails is that it would > be nice if there was a summary listing just the package names > that have been updated were at the top of the mail. > > ie: > > New packages updated: > --------------------- > > foo-1.2-3 > bar-2.3-4 > baz-4.5-6 > XFree86-4.3.0-42 > > > Individual package changelog highlights: > ---------------------------------------- > > foo-1.2-3 > * Sun Oct 12 2003 ........ > - foo updated to fix bug blah > > #################################################### > > bar-2.3-4 > * Sun Oct 12 2003 ........ > - bar updated to fix bug blah > > #################################################### > > baz-4.5-6 > * Sun Oct 12 2003 ........ > - baz updated to fix bug blah > > #################################################### > > XFree86-4.3.0-42 > * Sun Oct 12 2003 ........ > - Complete support for all video hardware ever manufactureed, > including full support for all features of that hardware has > now been implemented, and all bugs in all drivers and in the > X server itself, and all libraries have now been fixed. > > > > Looks much nicer now doesn't it? ;o) Oh , lot more nice :), first begin with simple list of packages does to not to take up my glasses to see what changes is going on .... :)) If colours get implied too .... (just suggest) I completly renunce to any glases thx. From pzb at datastacks.com Tue Oct 21 11:51:15 2003 From: pzb at datastacks.com (Peter Bowen) Date: Tue, 21 Oct 2003 07:51:15 -0400 Subject: rawhide report: 20031021 changes In-Reply-To: References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> Message-ID: <1066737074.12023.2.camel@localhost.localdomain> On Tue, 2003-10-21 at 07:35, Mike A. Harris wrote: > Just a suggestion.... These emails are useful, but they could > be greatly improved upon IMHO. It appears that when a package > gets updated, it's complete changelog, or a large portion of it > gets sent out in the emails, the majority of which is ancient > information from as far back as 1999, which only blurs the actual > useful information of what has changed. I suggest that the > changelogs are trimmed to only include the relevant changes since > the last rawhide push, or if that's too difficult to implement, > just include the last 2-4 changelog entries so that the most > relevant and recent changes are shown only. This has been brought up before, and the relevant snippets are being sent. However we are still seeing some packages for the first time in this system, so their entire changelogs are being sent. And then there is anaconda, which I think is causing the system heartburn, as its changelog hasn't been updated in ages and does not contain any EVR markers. So, yes, I fully support sending only changelog diffs, but I think that is the current intent. Thanks. Peter From Nicolas.Mailhot at laPoste.net Tue Oct 21 11:56:22 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 21 Oct 2003 13:56:22 +0200 Subject: rawhide report: 20031021 changes In-Reply-To: <200310211450.53770.rezso@rdsor.ro> References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> <200310211450.53770.rezso@rdsor.ro> Message-ID: <1066737382.4822.1.camel@ulysse.olympe.o2t> Le mar 21/10/2003 ? 13:50, Balint Cristian a ?crit : > More suggestions: > > And would be more nice to see colored highlight (red coloured aka "redhat" for e.g :) ) of package-name > and in rest changelog to be normal black eventualy the changelog "date" numbers to be grey, but that implies html > mail instead of text mail. However with html mail you can get nice features like index links to jump directly to the interesting part of the report. 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 Tue Oct 21 11:56:58 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 21 Oct 2003 13:56:58 +0200 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <1066734069.4514.1.camel@ulysse.olympe.o2t> References: <20031021082621.GH16134@puariko.nirvana> <20031021065553.A16905@redhat.com> <1066734069.4514.1.camel@ulysse.olympe.o2t> Message-ID: <20031021115658.GJ16134@puariko.nirvana> On Tue, Oct 21, 2003 at 01:01:09PM +0200, Nicolas Mailhot wrote: > Le mar 21/10/2003 ? 12:55, Daniel Veillard a ?crit : > > On Tue, Oct 21, 2003 at 10:26:21AM +0200, Axel Thimm wrote: > > > Currently (or last time I checked) yum headers were created for all > > > archs in the rawhide toplevel hierarchy. > > > > > > Would it make sense to create the yum headers per arch and closer to > > > the RPMS directory, so that it is mirrored and usable in partial > > > mirrors, too? > > > > Hunnestly, yum-arch run so fast, that I think it's simpler to simply > > rerun it on your mirror than mirror the header directories ! > > However a lot of mirrors just do blind ftp mirroring and won't reindex > any stuff. You can't ask them to special-case rpm mirrors. Yes, and also the generated headers would not be at some canonical place since the topdir is not mirrored. -- 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 mharris at redhat.com Tue Oct 21 12:24:51 2003 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 21 Oct 2003 08:24:51 -0400 (EDT) Subject: rawhide report: 20031021 changes In-Reply-To: <200310211450.53770.rezso@rdsor.ro> References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> <200310211450.53770.rezso@rdsor.ro> Message-ID: On Tue, 21 Oct 2003, Balint Cristian wrote: >> Again, just a suggestion... What do others in the community >> think about the idea? > >As Mike suggested, > >I would be _more_ nice to show only changelog since previous >package not the whole changelog, for me is an effort to keep my >eye on screen to find what is the "package-name" and what is the >"changelog" ... from the kilometric e-mail, plus probably other >people not too happy about huge mails ... Agreed. I saw anaconda changes, and I don't much care to read them, especially since it was so lengthy. I had trouble trying to find the start of the next package. I'd love to overview what is changing in the distro via the rawhide changes reports, but not if it takes me 10 minutes to review. ;o) >More suggestions: > >And would be more nice to see colored highlight (red coloured >aka "redhat" for e.g :) ) of package-name and in rest changelog >to be normal black eventualy the changelog "date" numbers to be >grey, but that implies html mail instead of text mail. That is best suited for a web page, not for email. Email doesn't have colour, it's just text - unless you use HTML, and HTML is considered a sin. I filter HTML email to /dev/null except for specially crafted procmail rules for common emails in which I consider HTML ok (very few cases). IMHO, text email with the proposed changes, plus a URL that links to a colourized fancier version on fedora.redhat.com would be great! -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From johnsonm at redhat.com Tue Oct 21 12:54:48 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 21 Oct 2003 08:54:48 -0400 Subject: code2html rpm packaging In-Reply-To: <1066728378.3691.62.camel@stiwatne.india.ensim.com>; from shekhar.tiwatne@ensim.com on Tue, Oct 21, 2003 at 02:56:18PM +0530 References: <20031020160011.32405.33569.Mailman@listman.back-rdu.redhat.com> <1066728378.3691.62.camel@stiwatne.india.ensim.com> Message-ID: <20031021085448.A9585@devserv.devel.redhat.com> On Tue, Oct 21, 2003 at 02:56:18PM +0530, Shekhar wrote: > Today I came across code2html package. I found it very useful. > I have packaged it for RedHat / Fedora. > What is the formal procedure to send a request for including it in the fedora distro. For now, use the www.fedora.us process. 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 Oct 21 13:20:40 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 21 Oct 2003 09:20:40 -0400 Subject: rawhide report: 20031021 changes In-Reply-To: ; from mharris@redhat.com on Tue, Oct 21, 2003 at 08:24:51AM -0400 References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> <200310211450.53770.rezso@rdsor.ro> Message-ID: <20031021092040.B9585@devserv.devel.redhat.com> On Tue, Oct 21, 2003 at 08:24:51AM -0400, Mike A. Harris wrote: > IMHO, text email with the proposed changes, plus a URL that links > to a colourized fancier version on fedora.redhat.com would be > great! I agree about the change of putting a list of changed packages at the top. It will take longer to public to fedora.redhat.com -- we'll need a proper CMS to do that for reasons involving infrastructure (pushing web site content is currently too heavyweight a process for that to work). It's still a good idea, though. :-) 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 Oct 21 13:32:55 2003 From: czar at czarc.net (Gene C.) Date: Tue, 21 Oct 2003 09:32:55 -0400 Subject: RPM segfaulting In-Reply-To: <20031019192304.GA26100@ip68-4-255-84.oc.oc.cox.net> References: <1066479975.21286.22.camel@localhost.localdomain> <200310191125.38460.czar@czarc.net> <20031019192304.GA26100@ip68-4-255-84.oc.oc.cox.net> Message-ID: <200310210932.55844.czar@czarc.net> On Sunday 19 October 2003 15:23, Barry K. Nathan wrote: > On Sun, Oct 19, 2003 at 11:25:38AM -0400, Gene C. wrote: > > I agree ... but he would likely be interested in the copy BEFORE I ran > > --rebuilddb ... which I do not have. > > > > Since more than one person has had this problem, hopefully the next > > person to get the problem will save a copy before doing --rebuilddb. > > I have a few questions for anyone experiencing this: > > (a) Are these systems, experiencing this problem, fresh installs of > Fedora Core 0.95 (or upgraded from Fedora Core 0.94) -- or were they > upgraded from Red Hat 9.0.93 or earlier? If the latter, what release was > it upgraded from? > > (b) Does the system have an i586 CPU (Pentium, Pentium MMX, AMD K6, and > some others I don't remember right now)? > > (c) If the answer to (b) is "no", are you running the kernel shipped > with Fedora Core (or a 2.6 kernel), or are you running something else > (like a Red Hat 9 kernel or a mainline kernel)? OK, I had the problem with a fresh everything install of FC 0.95 (deleted some language packages to get some space) and then also applied a couple of days worth of rawhide updates. The problem "went away" after I did the --rebuilddb (unfortunately, I did not capature before/after info). I tried to recreate the problem with an "almost everything" install (select everything I could but not a true "everything" install) and then (again) applied the updates then available from rawhide ... this time, there was no segfault problem. As Jeff Johnson pointed out to me, this is some kind of data problem in the rpm db. At this point, I am moving on because I do not believe that I can truely recreate the problem (I am sure it is still there and will pop up again for someone in the future but I cannot help define the problem now). Some sequence of install/remove elft the db is bad shape ... what that is is currently unknown. The hardware is a 800MHz PIII and runs the Fedora kernel. -- Gene From kaboom at gatech.edu Tue Oct 21 13:53:51 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Tue, 21 Oct 2003 09:53:51 -0400 (EDT) Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <20031021065553.A16905@redhat.com> References: <20031021082621.GH16134@puariko.nirvana> <20031021065553.A16905@redhat.com> Message-ID: On Tue, 21 Oct 2003, Daniel Veillard wrote: > On Tue, Oct 21, 2003 at 10:26:21AM +0200, Axel Thimm wrote: > > [The original message had a bad To: address, please reply to this one > > instead.] > > > > Currently (or last time I checked) yum headers were created for all > > archs in the rawhide toplevel hierarchy. > > > > Would it make sense to create the yum headers per arch and closer to > > the RPMS directory, so that it is mirrored and usable in partial > > mirrors, too? IMHO, yes > > Hunnestly, yum-arch run so fast, that I think it's simpler to simply > rerun it on your mirror than mirror the header directories ! lots of mirrors, including the one I run, can't / won't ever run yum-arch. linux, python, rpm, and xml goop are not ubiquitious, and they're NOT going on my Solaris ftp servers. later, chris From kaboom at gatech.edu Tue Oct 21 14:00:33 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Tue, 21 Oct 2003 10:00:33 -0400 (EDT) Subject: rawhide report: 20031021 changes In-Reply-To: References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> Message-ID: On Tue, 21 Oct 2003, Mike A. Harris wrote: > Another suggestion for improvement in the emails is that it would > be nice if there was a summary listing just the package names > that have been updated were at the top of the mail. this would be nice > XFree86-4.3.0-42 > * Sun Oct 12 2003 ........ > - Complete support for all video hardware ever manufactureed, > including full support for all features of that hardware has > now been implemented, and all bugs in all drivers and in the > X server itself, and all libraries have now been fixed. Too bad this hasn't hit rawhide yet. I could use it ;-) later, chris From skvidal at phy.duke.edu Tue Oct 21 14:18:38 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 21 Oct 2003 10:18:38 -0400 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: References: <20031021082621.GH16134@puariko.nirvana> <20031021065553.A16905@redhat.com> Message-ID: <1066745918.7859.36.camel@binkley> > lots of mirrors, including the one I run, can't / won't ever run yum-arch. > linux, python, rpm, and xml goop are not ubiquitious, and they're NOT going > on my Solaris ftp servers. python, rpm are all that yum-arch requires. there is no 'xml goop' required for yum-arch to run -sv From ms-nospam-0306 at arcor.de Tue Oct 21 14:25:12 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 21 Oct 2003 16:25:12 +0200 Subject: rawhide report: 20031021 changes In-Reply-To: References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> Message-ID: <20031021162512.610a4577.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 21 Oct 2003 07:35:04 -0400 (EDT), Mike A. Harris wrote: > alone. ;o) I don't think anyone is interested in bugs Bero > fixed in XFree86 back in 1999 for example. ;o) > > Again, just a suggestion... What do others in the community > think about the idea? I've suggested a temporary enhancement before: sed -e '/\* [a-zA-Z]\{3\} [a-zA-Z]\{3\} [0-9]\{2\} \(200[0-2]\|199?\).*/,99999 d' applied on a changelog would drop changelog entries older than 2003. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/lUHI0iMVcrivHFQRAooeAJoDv0XJHn2NDsga7VXjdlz0dmfHEgCeIDbO Zep1ZQMZ3JH1n7JF30V1fgE= =/WYB -----END PGP SIGNATURE----- From kaboom at gatech.edu Tue Oct 21 14:52:56 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Tue, 21 Oct 2003 10:52:56 -0400 (EDT) Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <1066745918.7859.36.camel@binkley> References: <20031021082621.GH16134@puariko.nirvana> <20031021065553.A16905@redhat.com> <1066745918.7859.36.camel@binkley> Message-ID: On Tue, 21 Oct 2003, seth vidal wrote: > > lots of mirrors, including the one I run, can't / won't ever run yum-arch. > > linux, python, rpm, and xml goop are not ubiquitious, and they're NOT going > > on my Solaris ftp servers. > > python, rpm are all that yum-arch requires. > > there is no 'xml goop' required for yum-arch to run libxml2-python is required by yum, but that's probably just the comps.xml parsing that yum-arch needn't do? At any rate, my point was that if you limit yourself to just mirrors which will run yum-arch over the tree once they mirror, you won't even get all the current Red Hat mirror sites -- some have practical reasons not to (like the pain of compiling rpm on non-Linux), while some just won't want to have to run a command over the tree. Mirroring needs to be kept as simple and flexible as possible.... later, chris From skvidal at phy.duke.edu Tue Oct 21 14:59:26 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 21 Oct 2003 10:59:26 -0400 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: References: <20031021082621.GH16134@puariko.nirvana> <20031021065553.A16905@redhat.com> <1066745918.7859.36.camel@binkley> Message-ID: <1066748366.7859.58.camel@binkley> On Tue, 2003-10-21 at 10:52, Chris Ricker wrote: > On Tue, 21 Oct 2003, seth vidal wrote: > > > > lots of mirrors, including the one I run, can't / won't ever run yum-arch. > > > linux, python, rpm, and xml goop are not ubiquitious, and they're NOT going > > > on my Solaris ftp servers. > > > > python, rpm are all that yum-arch requires. > > > > there is no 'xml goop' required for yum-arch to run > > libxml2-python is required by yum, but that's probably just the comps.xml > parsing that yum-arch needn't do? > right - not by yum-arch. > At any rate, my point was that if you limit yourself to just mirrors which > will run yum-arch over the tree once they mirror, you won't even get all the > current Red Hat mirror sites -- some have practical reasons not to (like the > pain of compiling rpm on non-Linux), while some just won't want to have to > run a command over the tree. Mirroring needs to be kept as simple and > flexible as possible.... sure - I understand - I was just countering the point about yum-arch needing libxml -sv From mharris at redhat.com Tue Oct 21 15:48:05 2003 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 21 Oct 2003 11:48:05 -0400 (EDT) Subject: rawhide report: 20031021 changes In-Reply-To: <20031021162512.610a4577.ms-nospam-0306@arcor.de> References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> <20031021162512.610a4577.ms-nospam-0306@arcor.de> Message-ID: On Tue, 21 Oct 2003, Michael Schwendt wrote: >> alone. ;o) I don't think anyone is interested in bugs Bero >> fixed in XFree86 back in 1999 for example. ;o) >> >> Again, just a suggestion... What do others in the community >> think about the idea? > >I've suggested a temporary enhancement before: > >sed -e '/\* [a-zA-Z]\{3\} [a-zA-Z]\{3\} [0-9]\{2\} \(200[0-2]\|199?\).*/,99999 d' > >applied on a changelog would drop changelog entries older than 2003. In heavily developed packages with accurate detailed spec file changelogs, like oh, I dunno, I'll pick a package at random - XFree86 ;o), the changelog entries just from Jan 2003 to date are 1114 lines long, and 65Kb in size. Do y'all want 65Kb emails when I release new X packages into rawhide every couple days? ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From jkeating at j2solutions.net Tue Oct 21 16:07:16 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 21 Oct 2003 09:07:16 -0700 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <1066748366.7859.58.camel@binkley> References: <20031021082621.GH16134@puariko.nirvana> <1066748366.7859.58.camel@binkley> Message-ID: <200310210907.16212.jkeating@j2solutions.net> On Tuesday 21 October 2003 07:59, seth vidal wrote: > sure - I understand - I was just countering the point about yum-arch > needing libxml Why not split yum-arch off as it's own package, that has lighter requirements? -- 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 Tue Oct 21 16:11:26 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 21 Oct 2003 12:11:26 -0400 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <200310210907.16212.jkeating@j2solutions.net> References: <20031021082621.GH16134@puariko.nirvana> <1066748366.7859.58.camel@binkley> <200310210907.16212.jkeating@j2solutions.net> Message-ID: <1066752686.7859.60.camel@binkley> On Tue, 2003-10-21 at 12:07, Jesse Keating wrote: > On Tuesday 21 October 2003 07:59, seth vidal wrote: > > sure - I understand - I was just countering the point about yum-arch > > needing libxml > > Why not split yum-arch off as it's own package, that has lighter > requirements? why? quite frankly - if you have rpm and python then getting libxml is not going to be any harder. -sv From jkeating at j2solutions.net Tue Oct 21 16:32:40 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 21 Oct 2003 09:32:40 -0700 Subject: Boot Loader Proposal Message-ID: <200310210932.40889.jkeating@j2solutions.net> Ok, here is how I feel about this long, tiresome argument. There are many people that like grub, and for the majority of the userbase, grub does what it needs to do. Sure there could be some improvement, but from what I'm told by the people who work on grub, it's somewhat trivial, and possibly the community could do it. Lilo is still very usefull, and does have some special needs requirements. For this reason, lilo can't be left out in the dark. Syslinux (aaah, nobody talked about this yet) is a very handy tool, but it is also a boot loader, shoot, not anotherone. The key thing here is that syslinux is quite handy for bootable isos, floppies, PXE boots, etc.. things that neither lilo nor grub do very well. Here is what I propose: Grub and Syslinux remain in Core. They will cover the mass majority of the userbase, with minimal duplication. Lilo shall be relegated to Alternatives or Extras. Lilo seems to have a smaller need base, but still needs to be available. This should satisfy the majority of the people on this list right? /me prepares napalm umbrella.. -- 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 ms-nospam-0306 at arcor.de Tue Oct 21 16:37:26 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 21 Oct 2003 18:37:26 +0200 Subject: rawhide report: 20031021 changes In-Reply-To: References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> <20031021162512.610a4577.ms-nospam-0306@arcor.de> Message-ID: <20031021183726.36b7bb5a.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 21 Oct 2003 11:48:05 -0400 (EDT), Mike A. Harris wrote: > In heavily developed packages with accurate detailed spec file > changelogs, like oh, I dunno, I'll pick a package at random - > XFree86 ;o), the changelog entries just from Jan 2003 to date are > 1114 lines long, and 65Kb in size. > > Do y'all want 65Kb emails when I release new X packages into > rawhide every couple days? ;o) IIRC, it has been pointed out that the current "rawhide report bot" only posts new changelog entries after an older version of the package had been posted earlier. So, that would limit the changelog "junk" to the first time a package makes it into the report. ;) Stripping off old entries, e.g entries older than a given timestamp, should be easy to do. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/lWDG0iMVcrivHFQRAj7oAJ4h5Fmt6ovXK0POyT8hdmIToVBX8QCfRTun gJEq9pmfnlMl760HALQh99o= =xdUD -----END PGP SIGNATURE----- From notting at redhat.com Tue Oct 21 17:39:40 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Oct 2003 13:39:40 -0400 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <20031021082621.GH16134@puariko.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Tue, Oct 21, 2003 at 10:26:21AM +0200 References: <20031021082621.GH16134@puariko.nirvana> Message-ID: <20031021133940.D4312@devserv.devel.redhat.com> Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > [The original message had a bad To: address, please reply to this one > instead.] > > Currently (or last time I checked) yum headers were created for all > archs in the rawhide toplevel hierarchy. > > Would it make sense to create the yum headers per arch and closer to > the RPMS directory, so that it is mirrored and usable in partial > mirrors, too? Are there really that many mirrors that don't carry the toplevel rawhide directory? Bill From notting at redhat.com Tue Oct 21 17:43:05 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Oct 2003 13:43:05 -0400 Subject: rawhide report: 20031021 changes In-Reply-To: ; from mharris@redhat.com on Tue, Oct 21, 2003 at 07:35:04AM -0400 References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> Message-ID: <20031021134305.E4312@devserv.devel.redhat.com> Mike A. Harris (mharris at redhat.com) said: > On Tue, 21 Oct 2003, Build System wrote: > > >Date: Tue, 21 Oct 2003 06:03:49 -0400 > >From: Build System > >To: fedora-devel-list at redhat.com > >List-Id: For developers, developers, developers > >Subject: rawhide report: 20031021 changes > [SNIP] > > Just a suggestion.... These emails are useful, but they could > be greatly improved upon IMHO. It appears that when a package > gets updated, it's complete changelog, or a large portion of it > gets sent out in the emails, the majority of which is ancient > information from as far back as 1999, This has already been discussed multiple times on the list. Please read the archives. :) Bill From Nicolas.Mailhot at laPoste.net Tue Oct 21 17:51:58 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 21 Oct 2003 19:51:58 +0200 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <20031021133940.D4312@devserv.devel.redhat.com> References: <20031021082621.GH16134@puariko.nirvana> <20031021133940.D4312@devserv.devel.redhat.com> Message-ID: <1066758717.5574.2.camel@m70.net81-64-235.noos.fr> Le mar 21/10/2003 ? 19:39, Bill Nottingham a ?crit : > Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > > [The original message had a bad To: address, please reply to this one > > instead.] > > > > Currently (or last time I checked) yum headers were created for all > > archs in the rawhide toplevel hierarchy. > > > > Would it make sense to create the yum headers per arch and closer to > > the RPMS directory, so that it is mirrored and usable in partial > > mirrors, too? > > Are there really that many mirrors that don't carry the toplevel > rawhide directory? It's not that they don't carry the toplevel directory, it's that they often do not carry one or more of the arch subdirs. So either people mirror headers (and export misleading info) or they zap it with obscure archs. 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 notting at redhat.com Tue Oct 21 18:34:40 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Oct 2003 14:34:40 -0400 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <1066758717.5574.2.camel@m70.net81-64-235.noos.fr>; from Nicolas.Mailhot@laPoste.net on Tue, Oct 21, 2003 at 07:51:58PM +0200 References: <20031021082621.GH16134@puariko.nirvana> <20031021133940.D4312@devserv.devel.redhat.com> <1066758717.5574.2.camel@m70.net81-64-235.noos.fr> Message-ID: <20031021143440.A25423@devserv.devel.redhat.com> Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > Are there really that many mirrors that don't carry the toplevel > > rawhide directory? > > It's not that they don't carry the toplevel directory, it's that they > often do not carry one or more of the arch subdirs. So either people > mirror headers (and export misleading info) or they zap it with obscure > archs. However, the SRPMS are at the toplevel, so you'd have to do symlink tricks to include them. Bill From Nicolas.Mailhot at laPoste.net Tue Oct 21 18:55:41 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 21 Oct 2003 20:55:41 +0200 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <20031021143440.A25423@devserv.devel.redhat.com> References: <20031021082621.GH16134@puariko.nirvana> <20031021133940.D4312@devserv.devel.redhat.com> <1066758717.5574.2.camel@m70.net81-64-235.noos.fr> <20031021143440.A25423@devserv.devel.redhat.com> Message-ID: <1066762540.6378.2.camel@m70.net81-64-235.noos.fr> Le mar 21/10/2003 ? 20:34, Bill Nottingham a ?crit : > Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > > Are there really that many mirrors that don't carry the toplevel > > > rawhide directory? > > > > It's not that they don't carry the toplevel directory, it's that they > > often do not carry one or more of the arch subdirs. So either people > > mirror headers (and export misleading info) or they zap it with obscure > > archs. > > However, the SRPMS are at the toplevel, so you'd have to do symlink > tricks to include them. Well, SRPMS are another thing that might end up zapped (though only at the very small mirror level - intranet mirroring typically). And with debuginfo packages growing there'll probably be a need at some point to strip them easily (not that they're not needed they are massively less used than the other stuff so it makes no sense to push them in every mirror) 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 sopwith at redhat.com Tue Oct 21 19:41:27 2003 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 21 Oct 2003 15:41:27 -0400 (EDT) Subject: Fedora Core 1 freeze warning Message-ID: In preparation for the release of Fedora Core 1, we will be freezing the tree on this schedule: October 24 anaconda (installer) October 27 kernel October 28 everything Make sure your bug reports & changes are in BEFORE those dates. The things to focus on are bugs that _must_ be fixed for this release - reports of 'should fix' bugs are welcome but definitely won't get fixed. After the freeze, only stop-ship bugs will get attention/fixes. Like all software, this release will not be perfect, but it will be better. Thanks for your help in making it that way! -- Elliot Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. From cmadams at hiwaay.net Tue Oct 21 20:02:07 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 21 Oct 2003 15:02:07 -0500 Subject: Boot Loader Proposal In-Reply-To: <200310210932.40889.jkeating@j2solutions.net> References: <200310210932.40889.jkeating@j2solutions.net> Message-ID: <20031021200207.GM1366551@hiwaay.net> Once upon a time, Jesse Keating said: > Grub and Syslinux remain in Core. They will cover the mass majority of > the userbase, with minimal duplication. Lilo shall be relegated to > Alternatives or Extras. Lilo seems to have a smaller need base, but > still needs to be available. This should satisfy the majority of the > people on this list right? I use GRUB myself, as it supports 115200 on the serial port (which LILO does not or at least did not). However, the boot loader is kind of a "special case", as you pretty much need it included and supported in the installer. If you have a problem that GRUB can't solve, having LILO available for download isn't much help if you can't get booted. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From aoliva at redhat.com Tue Oct 21 20:10:44 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 21 Oct 2003 18:10:44 -0200 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <1066758717.5574.2.camel@m70.net81-64-235.noos.fr> References: <20031021082621.GH16134@puariko.nirvana> <20031021133940.D4312@devserv.devel.redhat.com> <1066758717.5574.2.camel@m70.net81-64-235.noos.fr> Message-ID: On Oct 21, 2003, Nicolas Mailhot wrote: > It's not that they don't carry the toplevel directory, it's that they > often do not carry one or more of the arch subdirs. I've used something like this: --include=/headers/*.info --include=/headers/\*.i\[3456\]86.hdr --include=/headers/*.athlon.hdr --include=/headers/*.noarch.hdr --exclude=/headers/*.hdr before I realized how easy it was to just run yum-arch locally (because I could). up2date would fail to download headers for missing architectures back then, but I hear it's fixed now. -- 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 Tue Oct 21 20:14:57 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 21 Oct 2003 18:14:57 -0200 Subject: rawhide report: 20031021 changes In-Reply-To: References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> <20031021162512.610a4577.ms-nospam-0306@arcor.de> Message-ID: On Oct 21, 2003, "Mike A. Harris" wrote: > Do y'all want 65Kb emails when I release new X packages into > rawhide every couple days? ;o) I was under the impression that this output was taken out of something like diff between spec files as of yesterday's push and as of today's. I frankly don't understand why we get the complete logs for some packages, and incremental logs for others. If I had to guess, I'd say it's probably a bug in the script that generates the report. -- 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 notting at redhat.com Tue Oct 21 21:46:33 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Oct 2003 17:46:33 -0400 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <1066762540.6378.2.camel@m70.net81-64-235.noos.fr>; from Nicolas.Mailhot@laPoste.net on Tue, Oct 21, 2003 at 08:55:41PM +0200 References: <20031021082621.GH16134@puariko.nirvana> <20031021133940.D4312@devserv.devel.redhat.com> <1066758717.5574.2.camel@m70.net81-64-235.noos.fr> <20031021143440.A25423@devserv.devel.redhat.com> <1066762540.6378.2.camel@m70.net81-64-235.noos.fr> Message-ID: <20031021174633.D11075@devserv.devel.redhat.com> Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > Well, SRPMS are another thing that might end up zapped (though only at > the very small mirror level - intranet mirroring typically). > > And with debuginfo packages growing there'll probably be a need at some > point to strip them easily (not that they're not needed they are > massively less used than the other stuff so it makes no sense to push > them in every mirror) They're in a different directory. However, I think it may be practical to say that if you're not doing a full mirror, you may need to regenerate the yum data. Bill From Nicolas.Mailhot at laPoste.net Tue Oct 21 21:54:32 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 21 Oct 2003 23:54:32 +0200 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <20031021174633.D11075@devserv.devel.redhat.com> References: <20031021082621.GH16134@puariko.nirvana> <20031021133940.D4312@devserv.devel.redhat.com> <1066758717.5574.2.camel@m70.net81-64-235.noos.fr> <20031021143440.A25423@devserv.devel.redhat.com> <1066762540.6378.2.camel@m70.net81-64-235.noos.fr> <20031021174633.D11075@devserv.devel.redhat.com> Message-ID: <1066773271.4427.3.camel@m70.net81-64-235.noos.fr> Le mar 21/10/2003 ? 23:46, Bill Nottingham a ?crit : > Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > Well, SRPMS are another thing that might end up zapped (though only at > > the very small mirror level - intranet mirroring typically). > > > > And with debuginfo packages growing there'll probably be a need at some > > point to strip them easily (not that they're not needed they are > > massively less used than the other stuff so it makes no sense to push > > them in every mirror) > > They're in a different directory. However, I think it may > be practical to say that if you're not doing a full mirror, you may > need to regenerate the yum data. Some mirrors do not run linux at all. Other run old distros without yum. Yet others have a mirroring infrastructure that does not allow for running commands after syncing.... It's a bit stupid to require data regeneration when the core problem is it's not in the right place, not that's its wrong (for mirroring anyway). Making life easier for mirror people will only lead to more mirrors, and that's what we want, right ? -- 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 Tue Oct 21 23:02:04 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Oct 2003 19:02:04 -0400 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <1066773271.4427.3.camel@m70.net81-64-235.noos.fr>; from Nicolas.Mailhot@laPoste.net on Tue, Oct 21, 2003 at 11:54:32PM +0200 References: <20031021082621.GH16134@puariko.nirvana> <20031021133940.D4312@devserv.devel.redhat.com> <1066758717.5574.2.camel@m70.net81-64-235.noos.fr> <20031021143440.A25423@devserv.devel.redhat.com> <1066762540.6378.2.camel@m70.net81-64-235.noos.fr> <20031021174633.D11075@devserv.devel.redhat.com> <1066773271.4427.3.camel@m70.net81-64-235.noos.fr> Message-ID: <20031021190204.E8857@devserv.devel.redhat.com> Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > They're in a different directory. However, I think it may > > be practical to say that if you're not doing a full mirror, you may > > need to regenerate the yum data. > > Some mirrors do not run linux at all. Other run old distros without yum. > Yet others have a mirroring infrastructure that does not allow for > running commands after syncing.... > > It's a bit stupid to require data regeneration when the core problem is > it's not in the right place, not that's its wrong (for mirroring > anyway). > > Making life easier for mirror people will only lead to more mirrors, and > that's what we want, right ? Yes, but there's a level of sanity required. If you don't mirror everything, things might break; that's sort of how it works.... Even if we do it per arch, it will break if someone removes the source RPMs. Or the debug info. And setting up separate repositories for those would be silly. Bill From gemi at bluewin.ch Tue Oct 21 23:04:35 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Wed, 22 Oct 2003 01:04:35 +0200 Subject: Submitting packages Message-ID: <1066777475.4342.6.camel@scriabin.tannenrauch.ch> I submitted some packages to the old fedora bugzilla. I hope I didn't drive crazy the QA people there :-) Anyways, they have been helpful. What I would like to know, how long does the reviewing process go until the packages are included in the repository? What happens to these packages? Will they be automatically included in the future Fedora extras repository? I haven't found any information about this, only about the core distribution which for the most part will stay the same as the planned RedHat beta. As I understand it, the (original) goal of the Fedora project was to build up a large repository of high quality packages and I wish to contribute to this goal. I should be as easier (or easier) as in Debian for the normal user to install packages. Regards -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From alikins at redhat.com Tue Oct 21 23:12:00 2003 From: alikins at redhat.com (Adrian Likins) Date: Tue, 21 Oct 2003 19:12:00 -0400 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <20031020100453.GB15294@puariko.nirvana> References: <20031020100453.GB15294@puariko.nirvana> Message-ID: <20031021231159.GE4887@redhat.com> On Mon, Oct 20, 2003 at 12:04:53PM +0200, Axel Thimm wrote: > Currently (or last time I checked) yum headers were created for all > archs in the rawhide toplevel hierarchy. > > Would it make sense to create the yum headers per arch and closer to > the RPMS directory, so that it is mirrored and usable in partial > mirrors, too? I'd prefer this just since it makes like a bit easier on up2date. the sources config file supports $ARCH that can figure out the right path. It also works better for x86_64/ia64/ppc64 machines (okay, granted, not that many folks care about that atm...) Since there is currently no way to tell apart the "x86 packages blessed for x86_64" and just any old x86 package in the same pile. So potential conflicts there (though, it's -><- close to "just working" having up2date on x86_64 pointing at both a x86_64 and a x86 repo). Adrian From kaboom at gatech.edu Tue Oct 21 23:22:22 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Tue, 21 Oct 2003 19:22:22 -0400 (EDT) Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <20031021190204.E8857@devserv.devel.redhat.com> References: <20031021082621.GH16134@puariko.nirvana> <20031021133940.D4312@devserv.devel.redhat.com> <1066758717.5574.2.camel@m70.net81-64-235.noos.fr> <20031021143440.A25423@devserv.devel.redhat.com> <1066762540.6378.2.camel@m70.net81-64-235.noos.fr> <20031021174633.D11075@devserv.devel.redhat.com> <1066773271.4427.3.camel@m70.net81-64-235.noos.fr> <20031021190204.E8857@devserv.devel.redhat.com> Message-ID: On Tue, 21 Oct 2003, Bill Nottingham wrote: > Yes, but there's a level of sanity required. If you don't mirror everything, > things might break; that's sort of how it works.... Even if we do it > per arch, it will break if someone removes the source RPMs. Or the debug > info. And setting up separate repositories for those would be silly. why? I think just the opposite -- that you want separate debuginfo and source repositories. The last thing most users want (and honestly, that you want most users to see) is to see 1400 debuginfo packages when they run, say, yum list available. later, chris From alikins at redhat.com Tue Oct 21 23:25:44 2003 From: alikins at redhat.com (Adrian Likins) Date: Tue, 21 Oct 2003 19:25:44 -0400 Subject: yum/apt/up2date + distributed dependencies In-Reply-To: <1066654015.3610.6.camel@binkley> References: <3F93D433.1060105@nycap.rr.com> <1066654015.3610.6.camel@binkley> Message-ID: <20031021232544.GF4887@redhat.com> On Mon, Oct 20, 2003 at 08:46:56AM -0400, seth vidal wrote: > > > FC doesn't include xmms-mp3, but xmms-mp3 depends on xmms. Hence, the > > upgrade of xmms will fail so as not to break xmms-mp3. > > > > Beyond that, suppose that freshrpms does release xmms-mp3-42.1. In this > > case, up2date COULD resolve the dependency and complete the upgrade -- but > > to do so it would have to resolve dependencies across two different > > repositories. Is it able to do so? (This XMMS example is the first one that > > came to my mind, but it is easy to imagine more sinister dependency trees.) > > The above is, in fact, the point of having multiple repositories. And yes, up2date supports resolving deps acros repos. It's not all that smart about it at the moment though. It basically looks for the dep in repo1, repo2, repo3, till it finds what it wants. Which is slightly "dumb" but at least predictable. No real heuristic for "the packages involved in this dep problem looks like they may have come from freshrpms, so look there first" exists. Something like that might be doable, but it's a bit of a guess. Adrian From alikins at redhat.com Tue Oct 21 23:34:53 2003 From: alikins at redhat.com (Adrian Likins) Date: Tue, 21 Oct 2003 19:34:53 -0400 Subject: up2date and yum: failover mode? In-Reply-To: <20031020100746.GC15294@puariko.nirvana> References: <20031020100746.GC15294@puariko.nirvana> Message-ID: <20031021233453.GG4887@redhat.com> On Mon, Oct 20, 2003 at 12:07:46PM +0200, Axel Thimm wrote: > Something invaluable in yum is its failover system, e.g. pointing N > mirrors of the same repo in the config giving yum a chance to pick > another one, when a failure is detected. > > Is that feature already in up2date, or will it be brought to it? not officially planned, but plan to try to get to at some point. Adrian From jensknutson at yahoo.com Tue Oct 21 23:43:12 2003 From: jensknutson at yahoo.com (Jens Knutson) Date: Tue, 21 Oct 2003 18:43:12 -0500 Subject: sound-juicer update?? Message-ID: <1066779792.4664.126.camel@localhost.localdomain> Will Sound Juicer .5.5 make it into FC-final 1? It includes what I think are probably rather important bug fixes, including the following, excerpted from the changelog: * Threaded MusicBrainz lookup * Open directory actually opens the best directory * Pipeline rebuilt after every track, works around gst-lame crashes * Correctly handle the artist in multiple artist albums * Fix crashes when closing dialogs with escape (Frederic) I don't mean to nag, but the release date for FC-final 1 looms, and it'd be a shame if such a nice music ripper shipped with those stupid bugs. Feel free to call me a spaz if this is already on the table and just hasn't been released yet... - jck -- "The bugs in Sawfish, and its greater configurability, are not orthogonal/unrelated facts" -- Havoc Pennington From notting at redhat.com Wed Oct 22 01:01:45 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Oct 2003 21:01:45 -0400 Subject: Split & move yum headers deeper into the hierachy? In-Reply-To: <20031021231159.GE4887@redhat.com>; from alikins@redhat.com on Tue, Oct 21, 2003 at 07:12:00PM -0400 References: <20031020100453.GB15294@puariko.nirvana> <20031021231159.GE4887@redhat.com> Message-ID: <20031021210145.C30166@devserv.devel.redhat.com> Adrian Likins (alikins at redhat.com) said: > On Mon, Oct 20, 2003 at 12:04:53PM +0200, Axel Thimm wrote: > > Currently (or last time I checked) yum headers were created for all > > archs in the rawhide toplevel hierarchy. > > > > Would it make sense to create the yum headers per arch and closer to > > the RPMS directory, so that it is mirrored and usable in partial > > mirrors, too? > > I'd prefer this just since it makes like a bit easier > on up2date. the sources config file supports $ARCH that can > figure out the right path. > > It also works better for x86_64/ia64/ppc64 machines > (okay, granted, not that many folks care about that atm...) > Since there is currently no way to tell apart the "x86 packages > blessed for x86_64" and just any old x86 package in the same > pile. So potential conflicts there (though, it's -><- close > to "just working" having up2date on x86_64 pointing at both > a x86_64 and a x86 repo). However, given the current rawhide scenario, if you split it up, you get *no* x86 packages for x86_64, *no* ppc packages for ppc64, etc. Bill From wcooley at nakedape.cc Wed Oct 22 01:21:38 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Tue, 21 Oct 2003 18:21:38 -0700 Subject: rawhide report: 20031021 changes In-Reply-To: <20031021092040.B9585@devserv.devel.redhat.com> References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> <200310211450.53770.rezso@rdsor.ro> <20031021092040.B9585@devserv.devel.redhat.com> Message-ID: <1066785698.19393.69.camel@denk.nakedape.priv> On Tue, 2003-10-21 at 06:20, Michael K. Johnson wrote: > It will take longer to public to fedora.redhat.com -- we'll need > a proper CMS to do that for reasons involving infrastructure > (pushing web site content is currently too heavyweight a process > for that to work). It's still a good idea, though. :-) So are you saying that http://www.redhat.com/software/rha/cms/ isn't a "proper CMS"? :) Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- 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 wcooley at nakedape.cc Wed Oct 22 01:25:04 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Tue, 21 Oct 2003 18:25:04 -0700 Subject: code2html rpm packaging In-Reply-To: <20031021085448.A9585@devserv.devel.redhat.com> References: <20031020160011.32405.33569.Mailman@listman.back-rdu.redhat.com> <1066728378.3691.62.camel@stiwatne.india.ensim.com> <20031021085448.A9585@devserv.devel.redhat.com> Message-ID: <1066785904.19393.73.camel@denk.nakedape.priv> On Tue, 2003-10-21 at 05:54, Michael K. Johnson wrote: > On Tue, Oct 21, 2003 at 02:56:18PM +0530, Shekhar wrote: > > Today I came across code2html package. I found it very useful. > > I have packaged it for RedHat / Fedora. > > What is the formal procedure to send a request for including it in the fedora distro. > > For now, use the www.fedora.us process. I guess this question has been asked recently and is probably in the FAQ... But should people submitting packages use the fedora.us version scheme or the more palatable "regular" package versioning? Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- 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 Oct 22 01:26:19 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 21 Oct 2003 21:26:19 -0400 Subject: rawhide report: 20031021 changes In-Reply-To: <1066785698.19393.69.camel@denk.nakedape.priv> References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> <200310211450.53770.rezso@rdsor.ro> <20031021092040.B9585@devserv.devel.redhat.com> <1066785698.19393.69.camel@denk.nakedape.priv> Message-ID: <1066785979.7859.153.camel@binkley> On Tue, 2003-10-21 at 21:21, Wil Cooley wrote: > On Tue, 2003-10-21 at 06:20, Michael K. Johnson wrote: > > > It will take longer to public to fedora.redhat.com -- we'll need > > a proper CMS to do that for reasons involving infrastructure > > (pushing web site content is currently too heavyweight a process > > for that to work). It's still a good idea, though. :-) > > So are you saying that http://www.redhat.com/software/rha/cms/ isn't a > "proper CMS"? :) > reasons why it doesn't seem like a real cms to me: 1. source code is included - but under what license? 2. it's in java 3. it's in java 4. The Red Hat CMS approach can have a company running a content management system in as little as two months. - umm - 2months? -sv From kaboom at gatech.edu Wed Oct 22 01:31:57 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Tue, 21 Oct 2003 21:31:57 -0400 (EDT) Subject: rsyncing rawhide -- statistics Message-ID: Out of curiosity, I decided to see how effective rsync would be for mirroring rawhide. I already had a full copy of rawhide/i386/RPMS made yesterday morning, so I made a single large file of the contents of that directory. I then updated the mirror this evening. 246 megs of RPMs were downloaded during the mirror update. I then made a single large file of the updated mirror. I then rsync'ed yesterday's file with today's file. The statistics for that were: Number of files: 1 Number of files transferred: 1 Total file size: 1823997952 bytes Total transferred file size: 1823997952 bytes Literal data: 16334848 bytes Matched data: 1807663104 bytes File list size: 79 Total bytes written: 667988 Total bytes read: 16778637 So, for a daily update of the rawhide binary RPMs, rsync downloaded 16 megs, while ftp downloaded 246 megs. That's a very significant savings, bandwidth-wise! Of course, this was only one trial, and it may have been anomalous -- for example, it might be the case that more of the differences between today and yesterday's rawhide trees were simply repushes of now-signed packages than is usually the case w/ a daily rawhide update.... I'll benchmark a couple more days and see what it looks like with repeated samples. later, chris From notting at redhat.com Wed Oct 22 01:44:06 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Oct 2003 21:44:06 -0400 Subject: rawhide disabled, will be back tomorrow-ish Message-ID: <20031021214406.B18542@devserv.devel.redhat.com> rawhide is currently disabled while we reorganize some of its content. It should be back sometime tomorrow. (2003-10-22). We apologize for the inconvenience. Bill From ms-nospam-0306 at arcor.de Wed Oct 22 02:09:45 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 22 Oct 2003 04:09:45 +0200 Subject: Submitting packages In-Reply-To: <1066777475.4342.6.camel@scriabin.tannenrauch.ch> References: <1066777475.4342.6.camel@scriabin.tannenrauch.ch> Message-ID: <20031022040945.216a9b3a.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [All of the following is just my own point of view and does not reflect any project's official policies or anything like that.] Wed, 22 Oct 2003 01:04:35 +0200, Gerard Milmeister wrote: > I submitted some packages to the old fedora bugzilla. > I hope I didn't drive crazy the QA people there :-) > Anyways, they have been helpful. > What I would like to know, how long does the > reviewing process go until the packages are included > in the repository? First of all, [at fedora.us] it's completely uncertain how long a package remains in the queue before someone takes a first look at it. With the limited human resources [at fedora.us], it is not guaranteed that package requests are processed in first-come first-served order. Especially when it is a big package which likely requires a reviewer to have a good bit of familiarity with the software in order to test whether the packaged files work and whether the set of included files is complete and makes sense. This can be a big issue with special purpose programming language packages, like you have submitted, which have a special [and probably limited] target group [compared with media players, for instance]. Even when the packager is trusted to assure that the packaged software works on the chosen target platforms, it may need additional community commitment before a package in the queue gets the necessary attention. For the time the Fedora merger takes and as long as fedora.us serves as a kind of testbed for Fedora Extras, it continues as a community project where people with interest in particular packages to be published can contribute, and help with QA/testing for instance. The package queue is open (http://www.fedora.us/QA), basic documentation is available (entry via main page). To speed up package reviews and approvals, preferably new packagers team up with interested users and process package requests in accordance with the published policies/guidelines (or even beyond) and notify the fedora-devel at fedora.us list when a package has been reviewed and is considered ready. Even normal users, who fear they can't help with technical issues or low-level package reviews, can give feedback on most-wanted software, whether in the queue already or not even packaged yet. > What happens to these packages? > Will they be automatically included in the future Fedora extras > repository? Most likely not. Details of the Fedora Project package submission procedure are not known yet. I can imagine that the requirements and policies will be more strict. For instance with regard to registering official package maintainers and assigning QA resources. The Fedora Project will also have to deal with resource problems and emergency response teams to allow for security fixes. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/lebp0iMVcrivHFQRAgMIAKCGfb0B/LgRn6Ok4RagRgzNyAIsfwCeOEEC vdAd3jABlgpVbytQiJ4GKJU= =SZAP -----END PGP SIGNATURE----- From mike at flyn.org Wed Oct 22 02:35:26 2003 From: mike at flyn.org (W. Michael Petullo) Date: Tue, 21 Oct 2003 21:35:26 -0500 Subject: PowerPC support In-Reply-To: References: <3F79F6AA.6050103@digitalme.com> Message-ID: <20031022023526.GA24134@imp.flyn.org> I finally found some time to build some of severn's SRPMs on my YellowDog iBook. I now have many PPC RPMs built and more on the way. I have no place to put them to share: if anyone wishes to host them, please let me know. As I mentioned before, I am very interested in contributing to Fedora on PPC. Now that my iBook is starting to run Fedora, I should be able to help. It would be great if the Fedora project aided distributions like YellowDog as they support alternative platforms. On a related note, is there a way to do a one-command build of a release like severn, similar to OpenBSD's build system? I am currently building in dependency order by hand and I would like to automate things more. -- Mike :wq From bfox at redhat.com Wed Oct 22 03:22:57 2003 From: bfox at redhat.com (Brent Fox) Date: Tue, 21 Oct 2003 23:22:57 -0400 Subject: sound-juicer update?? In-Reply-To: <1066779792.4664.126.camel@localhost.localdomain> References: <1066779792.4664.126.camel@localhost.localdomain> Message-ID: <20031022032257.GA29914@redhat.com> On Tue, Oct 21, 2003 at 06:43:12PM -0500, Jens Knutson wrote: > Will Sound Juicer .5.5 make it into FC-final 1? It includes what I > think are probably rather important bug fixes, including the following, > excerpted from the changelog: > > * Threaded MusicBrainz lookup > * Open directory actually opens the best directory > * Pipeline rebuilt after every track, works around gst-lame crashes > * Correctly handle the artist in multiple artist albums > * Fix crashes when closing dialogs with escape (Frederic) > > I don't mean to nag, but the release date for FC-final 1 looms, and it'd > be a shame if such a nice music ripper shipped with those stupid bugs. > > Feel free to call me a spaz if this is already on the table and just > hasn't been released yet... I just ran sound-juicer-0.5.5-1 through the build system. Please try it out once it appears in Rawhide. It's working fine for me. Cheers, Brent From jensknutson at yahoo.com Wed Oct 22 03:46:18 2003 From: jensknutson at yahoo.com (Jens Knutson) Date: Tue, 21 Oct 2003 22:46:18 -0500 Subject: sound-juicer update?? In-Reply-To: <20031022032257.GA29914@redhat.com> References: <1066779792.4664.126.camel@localhost.localdomain> <20031022032257.GA29914@redhat.com> Message-ID: <1066794377.4860.0.camel@localhost.localdomain> On Tue, 2003-10-21 at 22:22, Brent Fox wrote: > > Feel free to call me a spaz if this is already on the table and just > > hasn't been released yet... > > I just ran sound-juicer-0.5.5-1 through the build system. Please try > it out once it appears in Rawhide. It's working fine for me. Excellent! I'll try it and report back either way. - spaz -- "The bugs in Sawfish, and its greater configurability, are not orthogonal/unrelated facts" -- Havoc Pennington From whiplash at planetfurry.com Wed Oct 22 05:43:47 2003 From: whiplash at planetfurry.com (Ricky Boone) Date: Wed, 22 Oct 2003 01:43:47 -0400 (EDT) Subject: Vector-based Fedora Logo Available? Message-ID: <1097.24.167.186.98.1066801427.squirrel@us1.planetfurry.com> Probably a really stupid question..., but will there be a version of the (final) Fedora logo as a vector-based image, in a format like EPS, SVG, etc? Just an off the wall question. :) From jspaleta at princeton.edu Wed Oct 22 05:59:32 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 22 Oct 2003 01:59:32 -0400 Subject: 'MUSTFIX' Fedora Bug Day: Tomorrow err I mean Today!!!!!!!!! Message-ID: <1066802371.2743.16.camel@localhost.localdomain> That's right i wasn't joking. It's Wednesday again, which means another Fedora Bug Day. Today is the second unofficial attempt at a fedora bug day. Today's bug hunting theme are Fedora Core release 'mustfix' bugs. Heres a list: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=100643 There are more than a few NEEDSINFO and NEW bugs in that list that the 'right' people in community could probably chime in on with useful information. So take a look over the list and see if there is any issue yuu can get closer to a meaningful resolution. More info about Fedora triage and bug days: http://www.fedora.us/wiki/FedoraTriage -jef"must sleep now"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 gtg990h at mail.gatech.edu Wed Oct 22 07:56:02 2003 From: gtg990h at mail.gatech.edu (gtg990h at mail.gatech.edu) Date: Wed, 22 Oct 2003 03:56:02 -0400 Subject: Window resize synchronization Message-ID: <1066809362.3f96381230061@webmail.mail.gatech.edu> I recently tried Fedora Test 3 with the GNOME 2.4 desktop, and I was very surprised to find out how smoothly GNOME and GTK apps resized. In every other distribution I have used, even the simplest GTK app would very visibly lag behind its window frame. In Fedora, even complex apps like Gnumeric and Nautilus resize without any lag at all. My question is: Does Fedora include any special patches to accomplish this? I know that some experimental code was written for metacity and GTK+ that used the X11 SYNC extension to synchronize frame and window repaints. However, I don't know if this patch was ever integrated into GTK+ because it doesn't appear to be in the CVS logs. My main reason for asking this is because the effect only seems to work with the XFree86 'nv' driver, and dissapears when using the 'nvidia' binary driver. According to all my benchmarks, the 'nvidia' driver is much faster in 2D, and also provides every extension the 'nv' driver does. The 'nvidia' driver also performs very well in KDE and GTK 1.x apps. I was just wondering if your version of GTK+ did anything special to hit some sort of bad behavior in those drivers. Thanks for your time, Rayiner H. From Nicolas.Mailhot at laPoste.net Wed Oct 22 08:01:52 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 22 Oct 2003 10:01:52 +0200 Subject: up2date and yum: failover mode? In-Reply-To: <20031021233453.GG4887@redhat.com> References: <20031020100746.GC15294@puariko.nirvana> <20031021233453.GG4887@redhat.com> Message-ID: <1066809712.3699.16.camel@ulysse.olympe.o2t> Le mer 22/10/2003 ? 01:34, Adrian Likins a ?crit : > On Mon, Oct 20, 2003 at 12:07:46PM +0200, Axel Thimm wrote: > > Something invaluable in yum is its failover system, e.g. pointing N > > mirrors of the same repo in the config giving yum a chance to pick > > another one, when a failure is detected. > > > > Is that feature already in up2date, or will it be brought to it? > > not officially planned, but plan to try to get to at > some point. Well, what's more interesting is a failover system when you poll several sources of the same channels (maybe that's how yum already works, from your description it doesn't look like this) ie : poll upstream source, first-level mirror and deep-level mirror. Download most packages from deep-level, then packages that didn't make it yet from first-level, then packages just updated from source. This way you have the benefits of mirroring (lightening the load on the core servers) without the problems (out-of-sync mirrors). Ideally you could even have a loopback iso as lowest source. 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 erc.caldera at gmx.net Wed Oct 22 09:00:31 2003 From: erc.caldera at gmx.net (=?ISO-8859-9?Q?Er=E7in?= EKER) Date: Wed, 22 Oct 2003 12:00:31 +0300 Subject: Fedora Core 1 freeze warning In-Reply-To: References: Message-ID: <20031022120031.4c4fc012.erc.caldera@gmx.net> Tue, 21 Oct 2003 15:41:27 -0400 (EDT) tarihinde Elliot Lee 'nin yazd?klar?: > In preparation for the release of Fedora Core 1, we will be freezing > the tree on this schedule: > > October 24 anaconda (installer) > October 27 kernel > October 28 everything so is the translation freeze in process as mentioned before? -- Er?in EKER UIN: 8216618 Born to be free, born to use Linux. -------------- 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 Wed Oct 22 09:03:28 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 22 Oct 2003 11:03:28 +0200 Subject: up2date and yum: failover mode? In-Reply-To: <20031021233453.GG4887@redhat.com> References: <20031020100746.GC15294@puariko.nirvana> <20031021233453.GG4887@redhat.com> Message-ID: <1066809712.3699.16.camel@ulysse.olympe.o2t> Le mer 22/10/2003 ? 01:34, Adrian Likins a ?crit : > On Mon, Oct 20, 2003 at 12:07:46PM +0200, Axel Thimm wrote: > > Something invaluable in yum is its failover system, e.g. pointing N > > mirrors of the same repo in the config giving yum a chance to pick > > another one, when a failure is detected. > > > > Is that feature already in up2date, or will it be brought to it? > > not officially planned, but plan to try to get to at > some point. Well, what's more interesting is a failover system when you poll several sources of the same channels (maybe that's how yum already works, from your description it doesn't look like this) ie : poll upstream source, first-level mirror and deep-level mirror. Download most packages from deep-level, then packages that didn't make it yet from first-level, then packages just updated from source. This way you have the benefits of mirroring (lightening the load on the core servers) without the problems (out-of-sync mirrors). Ideally you could even have a loopback iso as lowest source. 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 Wed Oct 22 09:11:35 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 22 Oct 2003 11:11:35 +0200 Subject: yum/apt/up2date + distributed dependencies In-Reply-To: <20031021232544.GF4887@redhat.com> References: <3F93D433.1060105@nycap.rr.com> <1066654015.3610.6.camel@binkley> <20031021232544.GF4887@redhat.com> Message-ID: <1066813895.4713.1.camel@ulysse.olympe.o2t> Le mer 22/10/2003 ? 01:25, Adrian Likins a ?crit : > No real heuristic for "the packages involved in this > dep problem looks like they may have come from freshrpms, so > look there first" exists. Something like that might be doable, but > it's a bit of a guess. Get it to use the highest version in all repos first - you'll almost never have two repositories with the same EVR anyway. 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 Wed Oct 22 12:19:19 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 22 Oct 2003 08:19:19 -0400 Subject: up2date and yum: failover mode? In-Reply-To: <1066809712.3699.16.camel@ulysse.olympe.o2t> References: <20031020100746.GC15294@puariko.nirvana> <20031021233453.GG4887@redhat.com> <1066809712.3699.16.camel@ulysse.olympe.o2t> Message-ID: <1066825159.7859.178.camel@binkley> > > Well, what's more interesting is a failover system when you poll several > sources of the same channels (maybe that's how yum already works, from > your description it doesn't look like this) > it is in fact: yum has a failovermethod which lets it roundrobin or priority failover b/t repos of the same packages example: [somerepo] name=some guy's repo baseurl=url://somewhere/somepath url://somewhereelse/somepath url://somewhereelse/someotherpath failovermethod=roundrobin -sv From sopwith at redhat.com Wed Oct 22 13:22:48 2003 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 22 Oct 2003 09:22:48 -0400 (EDT) Subject: PowerPC support In-Reply-To: <20031022023526.GA24134@imp.flyn.org> Message-ID: On Tue, 21 Oct 2003, W. Michael Petullo wrote: > I finally found some time to build some of severn's SRPMs on my YellowDog > iBook. I now have many PPC RPMs built and more on the way. I have no > place to put them to share: if anyone wishes to host them, please let > me know. The effort is cool, but unnecessary - ftp://ftp.redhat.com/pub/redhat/linux/rawhide/ppc/ (Once Rawhide is back, that is.) -- Elliot Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. From darryl at snakegully.nu Wed Oct 22 13:38:25 2003 From: darryl at snakegully.nu (Darryl Luff) Date: Wed, 22 Oct 2003 23:38:25 +1000 Subject: Submitting packages In-Reply-To: <1066777475.4342.6.camel@scriabin.tannenrauch.ch> References: <1066777475.4342.6.camel@scriabin.tannenrauch.ch> Message-ID: <3F968851.5080701@snakegully.nu> Gerard Milmeister wrote: >I submitted some packages to the old fedora bugzilla. >I hope I didn't drive crazy the QA people there :-) >Anyways, they have been helpful. >What I would like to know, how long does the >reviewing process go until the packages are included >in the repository? > I used to (and still do) package a fair bit of software into RPM format for my own use. I decided my efforts would be better placed if I submitted my packages to Fedora. This way, the software I used could be included in an online yum repository, and other people besides myself could help keep them up to date. I submitted one test package to (old) Fedora (p0f). My plan was to watch the process as this package went through, and then once I was familiar with the process, to get involved with processing packages, both my own and others. Unfortunately, just after I did this the Redhat/Fedora merge happened. So my trial package has gone nowhere. I am not sure about the value of this merger. The 'old' Fedora allowed anyone to contribute any package they thought was important. So if a single person anywhere in the world thought that some software was useful, it could be included. The 'new' Fedora on the other hand seems more focussed on a 'product' where packages are only included if they fill a hole. The different classes of packages ('extras' etc) are OK, but from what I've read things still need to be approved for inclusion. What I think will happen now is that great repositories like Matthias's Freshrpm's will have a short burst of renewed vigour, Fedora will become committee-bound and die, and eventually another repository will arise to fill the hole left by 'old fedora'. In the meantime, I still see the occasional package announcement from 'old fedora'. So maybe I'll forget about waiting for 'p0f' to be approved, and just dive in anyway. What would I like to see? The 'new' Fedora forget it's ideals of control and return to allowing anyone, anywhere, to submit packages for any reason. Freedom is having the choice of 22 browsers. From mike at flyn.org Wed Oct 22 13:42:48 2003 From: mike at flyn.org (mike at flyn.org) Date: Wed, 22 Oct 2003 09:42:48 -0400 Subject: PowerPC support Message-ID: <20031022134248.095B7314E1@neuromancer.voxel.net> >> I finally found some time to build some of severn's SRPMs on my YellowDog >> iBook. I now have many PPC RPMs built and more on the way. I have no >> place to put them to share: if anyone wishes to host them, please let >> me know. > The effort is cool, but unnecessary - > ftp://ftp.redhat.com/pub/redhat/linux/rawhide/ppc/ Great! Where did these PPC RPMs come from and how long have they been around? I've been following this PowerPC support thread; did I miss something? -- Mike From tcallawa at redhat.com Wed Oct 22 13:48:50 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 22 Oct 2003 08:48:50 -0500 Subject: rawhide report: 20031021 changes In-Reply-To: <1066785979.7859.153.camel@binkley> References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> <200310211450.53770.rezso@rdsor.ro> <20031021092040.B9585@devserv.devel.redhat.com> <1066785698.19393.69.camel@denk.nakedape.priv> <1066785979.7859.153.camel@binkley> Message-ID: <1066830530.12664.6.camel@zorak> On Tue, 2003-10-21 at 20:26, seth vidal wrote: > On Tue, 2003-10-21 at 21:21, Wil Cooley wrote: > > On Tue, 2003-10-21 at 06:20, Michael K. Johnson wrote: > > > > > It will take longer to public to fedora.redhat.com -- we'll need > > > a proper CMS to do that for reasons involving infrastructure > > > (pushing web site content is currently too heavyweight a process > > > for that to work). It's still a good idea, though. :-) > > > > So are you saying that http://www.redhat.com/software/rha/cms/ isn't a > > "proper CMS"? :) > > > > reasons why it doesn't seem like a real cms to me: > 1. source code is included - but under what license? The CCMPL. http://www.redhat.com/licenses/ccmpl.html While interesting, this does not appear to be an OSI Certified open source license (check the list at http://opensource.org/licenses/index.php ). You learn something new every day. ;) > 2. it's in java > 3. it's in java Would you rather C#? Wait, don't answer that. > 4. The Red Hat CMS approach can have a company running a content > management system in as little as two months. - umm - 2months? Compared to the time effort required to deploy a traditional proprietary CMS, 2 months isn't bad. ~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 jeremyp at pobox.com Wed Oct 22 13:51:54 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: Wed, 22 Oct 2003 09:51:54 -0400 Subject: PowerPC support In-Reply-To: <20031022134248.095B7314E1@neuromancer.voxel.net> References: <20031022134248.095B7314E1@neuromancer.voxel.net> Message-ID: <1066830714.26733.6.camel@jeremy.dtcc.cc.nc.us> On Wed, 2003-10-22 at 09:42, mike at flyn.org wrote: > >> I finally found some time to build some of severn's SRPMs on my YellowDog > >> iBook. I now have many PPC RPMs built and more on the way. I have no > >> place to put them to share: if anyone wishes to host them, please let > >> me know. > > > The effort is cool, but unnecessary - > > ftp://ftp.redhat.com/pub/redhat/linux/rawhide/ppc/ > > Great! Where did these PPC RPMs come from and how long have they been > around? I've been following this PowerPC support thread; did I miss > something? Rawhide has often provided provided builds for the various other archictures, besides the i386 family. All you have to do is open up your FTP client to go get them... :-) --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 jross at redhat.com Wed Oct 22 13:24:23 2003 From: jross at redhat.com (Justin Ross) Date: Wed, 22 Oct 2003 09:24:23 -0400 (EDT) Subject: rawhide report: 20031021 changes In-Reply-To: <1066830530.12664.6.camel@zorak> Message-ID: On Wed, 22 Oct 2003, Tom 'spot' Callaway wrote: > On Tue, 2003-10-21 at 20:26, seth vidal wrote: > > reasons why it doesn't seem like a real cms to me: > > 1. source code is included - but under what license? > > The CCMPL. > http://www.redhat.com/licenses/ccmpl.html > > While interesting, this does not appear to be an OSI Certified open > source license (check the list at > http://opensource.org/licenses/index.php ). > You learn something new every day. ;) CCMPL is IBMPL with IBM string replaced, and if I'm not mistaken, IBMPL is OSI approved, so CCMPL is at least worthy of OSI approval. Justin From tcallawa at redhat.com Wed Oct 22 14:25:09 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 22 Oct 2003 09:25:09 -0500 Subject: rawhide report: 20031021 changes In-Reply-To: References: Message-ID: <1066832709.12664.18.camel@zorak> On Wed, 2003-10-22 at 08:24, Justin Ross wrote: > > The CCMPL. > > http://www.redhat.com/licenses/ccmpl.html > > > > While interesting, this does not appear to be an OSI Certified open > > source license (check the list at > > http://opensource.org/licenses/index.php ). > > You learn something new every day. ;) > > CCMPL is IBMPL with IBM string replaced, and if I'm not mistaken, IBMPL is > OSI approved, so CCMPL is at least worthy of OSI approval. IANAL, but it looked that way to me too. I was just a little suprised that it wasn't OSI approved. IMHO, if Red Hat is going to the trouble of making a new license, it can at least jump through the one hoop to get it added to OSI's list. ~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 lfarkas at bnap.hu Wed Oct 22 14:39:56 2003 From: lfarkas at bnap.hu (Farkas Levente) Date: Wed, 22 Oct 2003 16:39:56 +0200 Subject: the only VPN solution is not in rh Message-ID: <3F9696BC.4080103@bnap.hu> hi, currently there is not any real vpn solution in rh distro. what are the alternatives: - freeswan (ipsec) - cipe - openvpn although ipsec is the future, it has many probles. the old kernel implementation is not accepted while the new is just in the 2.6 series (the backport is...) and the freeswan's user space part is not compiled for the the ipsec implementation. and we don't the quality of that part of the code (that was the reason why the old kernel psace can't get into the kernel). the x509 patch still not in the mainstream freeswan which is essential for windows clients. imho it needs a year to be stable and usable. cipe is old and no longer supported. so the only solution is openvpn. we use the linux version for a year without any problem. which is working and finaly has windows port to, so the road warrior can be a windows now. so imho it should have to be included in fedora. just my 2c. -- Levente "Si vis pacem para bellum!" From elanthis at awesomeplay.com Wed Oct 22 15:04:54 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 22 Oct 2003 11:04:54 -0400 Subject: the only VPN solution is not in rh In-Reply-To: <3F9696BC.4080103@bnap.hu> References: <3F9696BC.4080103@bnap.hu> Message-ID: <1066835093.1040.0.camel@support02.civic.twp.ypsilanti.mi.us> On Wed, 2003-10-22 at 10:39, Farkas Levente wrote: > so the only solution is openvpn. we use the linux version for a year > without any problem. which is working and finaly has windows port to, so > the road warrior can be a windows now. What is OpenVPN's security record? Ease of use completely worthless next to actual security for stuff like this... > > so imho it should have to be included in fedora. > just my 2c. -- Sean Middleditch AwesomePlay Productions, Inc. From jkeating at j2solutions.net Wed Oct 22 15:05:46 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 22 Oct 2003 08:05:46 -0700 Subject: the only VPN solution is not in rh In-Reply-To: <3F9696BC.4080103@bnap.hu> References: <3F9696BC.4080103@bnap.hu> Message-ID: <200310220805.46636.jkeating@j2solutions.net> On Wednesday 22 October 2003 07:39, Farkas Levente uttered: > cipe is old and no longer supported. > > so the only solution is openvpn. we use the linux version for a year > without any problem. which is working and finaly has windows port to, so > the road warrior can be a windows now. > > so imho it should have to be included in fedora. > just my 2c. Fedora Extras anybody? Sounds like a perfect candidate. -- 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 -------------- 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 Wed Oct 22 15:32:03 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 22 Oct 2003 11:32:03 -0400 Subject: Fedora Core 1 freeze warning In-Reply-To: <20031022120031.4c4fc012.erc.caldera@gmx.net>; from erc.caldera@gmx.net on Wed, Oct 22, 2003 at 12:00:31PM +0300 References: <20031022120031.4c4fc012.erc.caldera@gmx.net> Message-ID: <20031022113203.B27953@devserv.devel.redhat.com> Er?in EKER (erc.caldera at gmx.net) said: > > In preparation for the release of Fedora Core 1, we will be freezing > > the tree on this schedule: > > > > October 24 anaconda (installer) > > October 27 kernel > > October 28 everything > > so is the translation freeze in process as mentioned before? The translation freeze has already frozen, yes. Anything committed now has no guarantee of being included. Bill From ms-nospam-0306 at arcor.de Wed Oct 22 15:40:01 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 22 Oct 2003 17:40:01 +0200 Subject: Submitting packages In-Reply-To: <3F968851.5080701@snakegully.nu> References: <1066777475.4342.6.camel@scriabin.tannenrauch.ch> <3F968851.5080701@snakegully.nu> Message-ID: <20031022174001.2af3327d.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 22 Oct 2003 23:38:25 +1000, Darryl Luff wrote: > I submitted one test package to (old) Fedora (p0f). My plan was to watch > the process as this package went through, and then once I was familiar > with the process, to get involved with processing packages, both my own > and others. > > Unfortunately, just after I did this the Redhat/Fedora merge happened. > So my trial package has gone nowhere. Not true. Your package request is right here, https://bugzilla.fedora.us/show_bug.cgi?id=680 waiting together with 237 other requests. > I am not sure about the value of this merger. The 'old' Fedora allowed > anyone to contribute any package they thought was important. So if a > single person anywhere in the world thought that some software was > useful, it could be included. This hasn't changed. It's just that the more individuals submit packages, the more QA resources it takes to review and approve all these packages. > The 'new' Fedora on the other hand seems more focussed on a 'product' > where packages are only included if they fill a hole. The different > classes of packages ('extras' etc) are OK, but from what I've read > things still need to be approved for inclusion. Where have you read that? Package submission and approval for the Fedora Project has not even started yet. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/lqTR0iMVcrivHFQRAqLWAJ43AxkT5Vs7HlLt1B6TrsLtuBvtNACfdn0y X8hxrPF1HGUBLxCECKX0ZcI= =b/43 -----END PGP SIGNATURE----- From Axel.Thimm at physik.fu-berlin.de Wed Oct 22 16:05:32 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 22 Oct 2003 18:05:32 +0200 Subject: up2date and yum: failover mode? In-Reply-To: <1066825159.7859.178.camel@binkley> References: <20031020100746.GC15294@puariko.nirvana> <20031021233453.GG4887@redhat.com> <1066809712.3699.16.camel@ulysse.olympe.o2t> <1066825159.7859.178.camel@binkley> Message-ID: <20031022160532.GA26291@puariko.nirvana> On Wed, Oct 22, 2003 at 08:19:19AM -0400, seth vidal wrote: > > Well, what's more interesting is a failover system when you poll several > > sources of the same channels (maybe that's how yum already works, from > > your description it doesn't look like this) > > it is in fact: > yum has a failovermethod which lets it roundrobin or priority failover > b/t repos of the same packages example: > [somerepo] > name=some guy's repo > baseurl=url://somewhere/somepath > url://somewhereelse/somepath > url://somewhereelse/someotherpath > failovermethod=roundrobin But if url://somewhere/somepath is successful, it wouldn't check the next repo, would it? You could combine the failover with the "conventional" multirepo access of yum like [fastbutabitoutdated] name=fastbutabitoutdated baseurl=url://somewhere/somepath [master] name=masterbutfailessometimes baseurl=url://somewhereelse/somepath url://somewhere/somepath i.e. put your local mirror at front and as a failover to the master mirror, ensuring manximum bandwidth when the package is available at the local mirror and also being up to date with failover. -- 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 steven at silverorange.com Wed Oct 22 16:16:15 2003 From: steven at silverorange.com (Steven Garrity) Date: Wed, 22 Oct 2003 13:16:15 -0300 Subject: Vector-based Fedora Logo Available? In-Reply-To: <20031022160026.2750.49323.Mailman@listman.back-rdu.redhat.com> References: <20031022160026.2750.49323.Mailman@listman.back-rdu.redhat.com> Message-ID: <3F96AD4F.9070603@silverorange.com> > From: "Ricky Boone" > Subject: Vector-based Fedora Logo Available? > Probably a really stupid question..., but will > there be a version of the (final) Fedora logo as > a vector-based image, in a format like EPS, SVG, etc? I apologize if this question has been answered elsewhere - but I was wondering if there is a public repository for the artwork in general - vector/bitmap-originals of the bluecurve graphics, etc. Thanks, Steven Garrity From garrett at redhat.com Wed Oct 22 16:23:45 2003 From: garrett at redhat.com (Garrett LeSage) Date: Wed, 22 Oct 2003 12:23:45 -0400 Subject: Vector-based Fedora Logo Available? In-Reply-To: <3F96AD4F.9070603@silverorange.com> References: <20031022160026.2750.49323.Mailman@listman.back-rdu.redhat.com> <3F96AD4F.9070603@silverorange.com> Message-ID: <3F96AF11.4000407@redhat.com> Steven Garrity wrote: > > From: "Ricky Boone" > > Probably a really stupid question..., but will > > there be a version of the (final) Fedora logo as > > a vector-based image, in a format like EPS, SVG, etc? > > I apologize if this question has been answered elsewhere - but I was > wondering if there is a public repository for the artwork in general - > vector/bitmap-originals of the bluecurve graphics, etc. Not yet. It is something to definitely consider though... (: Garrett From johnsonm at redhat.com Wed Oct 22 16:55:59 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 22 Oct 2003 12:55:59 -0400 Subject: rawhide report: 20031021 changes In-Reply-To: <1066785698.19393.69.camel@denk.nakedape.priv>; from wcooley@nakedape.cc on Tue, Oct 21, 2003 at 06:21:38PM -0700 References: <200310211003.h9LA3nf01676@porkchop.devel.redhat.com> <200310211450.53770.rezso@rdsor.ro> <20031021092040.B9585@devserv.devel.redhat.com> <1066785698.19393.69.camel@denk.nakedape.priv> Message-ID: <20031022125559.A31549@devserv.devel.redhat.com> On Tue, Oct 21, 2003 at 06:21:38PM -0700, Wil Cooley wrote: > On Tue, 2003-10-21 at 06:20, Michael K. Johnson wrote: > > > It will take longer to public to fedora.redhat.com -- we'll need > > a proper CMS to do that for reasons involving infrastructure > > (pushing web site content is currently too heavyweight a process > > for that to work). It's still a good idea, though. :-) > > So are you saying that http://www.redhat.com/software/rha/cms/ isn't a > "proper CMS"? :) Heh. No, I meant we'll need a proper CMS *on fedora.redhat.com*. http://www.redhat.com/software/rha/cms/ is clearly a contender; it's most certainly a "proper CMS". I'm rather in awe of it, actually. :-) 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 Oct 22 16:56:58 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 22 Oct 2003 12:56:58 -0400 Subject: code2html rpm packaging In-Reply-To: <1066785904.19393.73.camel@denk.nakedape.priv>; from wcooley@nakedape.cc on Tue, Oct 21, 2003 at 06:25:04PM -0700 References: <20031020160011.32405.33569.Mailman@listman.back-rdu.redhat.com> <1066728378.3691.62.camel@stiwatne.india.ensim.com> <20031021085448.A9585@devserv.devel.redhat.com> <1066785904.19393.73.camel@denk.nakedape.priv> Message-ID: <20031022125658.B31549@devserv.devel.redhat.com> On Tue, Oct 21, 2003 at 06:25:04PM -0700, Wil Cooley wrote: > I guess this question has been asked recently and is probably in the > FAQ... But should people submitting packages use the fedora.us version > scheme or the more palatable "regular" package versioning? Follow fedora.us procedures for now. We'll have to make changes at a larger scale anyway when doing a proper merge, what's one or two packages more or less? 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 roozbeh at sharif.edu Wed Oct 22 17:00:37 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Wed, 22 Oct 2003 20:30:37 +0330 Subject: Time plan for merger Message-ID: <1066842037.7813.71.camel@guava.bamdad.org> Is there (even a general idea of) a time plan for the merger with "fedora.us"? Specifically, will it happen before Cambridge++ or after? roozbeh From skvidal at phy.duke.edu Wed Oct 22 17:41:10 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 22 Oct 2003 13:41:10 -0400 Subject: up2date and yum: failover mode? In-Reply-To: <20031022160532.GA26291@puariko.nirvana> References: <20031020100746.GC15294@puariko.nirvana> <20031021233453.GG4887@redhat.com> <1066809712.3699.16.camel@ulysse.olympe.o2t> <1066825159.7859.178.camel@binkley> <20031022160532.GA26291@puariko.nirvana> Message-ID: <1066844470.27197.20.camel@opus> > But if url://somewhere/somepath is successful, it wouldn't check the > next repo, would it? > that's what roundrobin vs priority is for. priority = go through the lists in order. roundrobin = select one at random and progress through them in sequence from there. and if you succeed in connecting to one server why would it want to check the next baseurl? > You could combine the failover with the "conventional" multirepo > access of yum like > > [fastbutabitoutdated] > name=fastbutabitoutdated > baseurl=url://somewhere/somepath > > [master] > name=masterbutfailessometimes > baseurl=url://somewhereelse/somepath > url://somewhere/somepath > > i.e. put your local mirror at front and as a failover to the master > mirror, ensuring manximum bandwidth when the package is available at > the local mirror and also being up to date with failover. huh? why not just include them in one repo and treat them in priority failover. I'm not sure what you're goal is above - if the repos are not identical then they shouldn't be treated as the same. -sv From johnsonm at redhat.com Wed Oct 22 18:15:17 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 22 Oct 2003 14:15:17 -0400 Subject: Time plan for merger In-Reply-To: <1066842037.7813.71.camel@guava.bamdad.org>; from roozbeh@sharif.edu on Wed, Oct 22, 2003 at 08:30:37PM +0330 References: <1066842037.7813.71.camel@guava.bamdad.org> Message-ID: <20031022141517.C31549@devserv.devel.redhat.com> On Wed, Oct 22, 2003 at 08:30:37PM +0330, Roozbeh Pournader wrote: > Is there (even a general idea of) a time plan for the merger with > "fedora.us"? Specifically, will it happen before Cambridge++ or after? We don't have dates. It won't be instantaneous. I'd like it to be well under way before Cambridge++ (Fedora Core 2) is released, for sure. We have some significant dependencies, including hardware infrastructure and software infrastructure, that simply aren't in place yet, but that we're going through the process of handling. 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 Wed Oct 22 18:35:21 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 22 Oct 2003 20:35:21 +0200 Subject: up2date and yum: failover mode? In-Reply-To: <1066844470.27197.20.camel@opus> References: <20031020100746.GC15294@puariko.nirvana> <20031021233453.GG4887@redhat.com> <1066809712.3699.16.camel@ulysse.olympe.o2t> <1066825159.7859.178.camel@binkley> <20031022160532.GA26291@puariko.nirvana> <1066844470.27197.20.camel@opus> Message-ID: <1066847721.2806.42.camel@m70.net81-64-235.noos.fr> Le mer 22/10/2003 ? 19:41, seth vidal a ?crit : > > But if url://somewhere/somepath is successful, it wouldn't check the > > next repo, would it? > > > > that's what roundrobin vs priority is for. > > priority = go through the lists in order. > roundrobin = select one at random and progress through them in sequence > from there. > > and if you succeed in connecting to one server why would it want to > check the next baseurl? > > > > You could combine the failover with the "conventional" multirepo > > access of yum like > > > > [fastbutabitoutdated] > > name=fastbutabitoutdated > > baseurl=url://somewhere/somepath > > > > [master] > > name=masterbutfailessometimes > > baseurl=url://somewhereelse/somepath > > url://somewhere/somepath > > > > i.e. put your local mirror at front and as a failover to the master > > mirror, ensuring manximum bandwidth when the package is available at > > the local mirror and also being up to date with failover. > > huh? why not just include them in one repo and treat them in priority > failover. > > I'm not sure what you're goal is above - if the repos are not identical > then they shouldn't be treated as the same. The repositories are the same - they are just potentially out of sync. The aim is to maximize acces to local/close/deep mirrors without losing ability to get the latest parts from the master site (accessing the master site is costly for the upstream source and potentially for the user if it means leaving an intranet through a congested shared pipe). A realistic scenario is : 1. search in a local partial source (download cache, local cd...) 2. search in the intranet mirror 3. search in several of the official project mirrors 4. search in any of the official upstream download sites 5. download packages with 1-2-3-4 priority. More recent packages always win, identical versions must be sourced from the closest/fastest source possible. All the download manager should need is a list of the X upstream level 1 sources, a list of all known mirror sources (sometimes a few 100 sites) and be able to choose by itself 2-3 mirrors it'll poll and one upstream source to check for completeness. What mirrors to hit can be determined with response time checks and keeping stats on the bandwidth achieved/level of freshness of previous accesses. (keeping track of the access hours might be smart too since net topology radically changes when the US wakes up for example, plus by correlating relative freshness with dates the program might even learn each mirror sync hours over time) All those checks are what a user is supposed to do manually before putting a particular mirror in his config file. There is no reason automating it can not give better results and produce more efficient ressource usage patterns for everyone. (plus this removes the manual configuration burden from the user) I hope this was clearer this time. 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 skvidal at phy.duke.edu Wed Oct 22 19:13:24 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 22 Oct 2003 15:13:24 -0400 Subject: up2date and yum: failover mode? In-Reply-To: <1066847721.2806.42.camel@m70.net81-64-235.noos.fr> References: <20031020100746.GC15294@puariko.nirvana> <20031021233453.GG4887@redhat.com> <1066809712.3699.16.camel@ulysse.olympe.o2t> <1066825159.7859.178.camel@binkley> <20031022160532.GA26291@puariko.nirvana> <1066844470.27197.20.camel@opus> <1066847721.2806.42.camel@m70.net81-64-235.noos.fr> Message-ID: <1066850004.27197.42.camel@opus> > > The repositories are the same - they are just potentially out of sync. END. If they are not in sync then they are not the same. If they are the same, then they don't need to both be listed as separate repositories. > The aim is to maximize acces to local/close/deep mirrors without losing > ability to get the latest parts from the master site (accessing the > master site is costly for the upstream source and potentially for the > user if it means leaving an intranet through a congested shared pipe). You're mixing the concepts of repository and mirror in ways that they shouldn't be mixed. a repository is a set of packages - distinct from any other repository in that it provides different items - they don't have to be discretely different but at least not claiming to provide the identical things. a mirror is an IDENTICAL COPY - hence the term mirror. in yum it works like this: [repo] baseurl=mirror mirror mirror mirror [repo2] baseurl=mirror2 mirror2 mirror2 mirror2 > All the download manager should need is a list of the X upstream level 1 > sources, a list of all known mirror sources (sometimes a few 100 sites) > and be able to choose by itself 2-3 mirrors it'll poll and one upstream > source to check for completeness. and if they're not in sync it will never know what it's getting - the suggestion that you appear to be saying is allow repo2 to provide something if repo fails. > What mirrors to hit can be determined with response time checks and > keeping stats on the bandwidth achieved/level of freshness of previous > accesses. (keeping track of the access hours might be smart too since > net topology radically changes when the US wakes up for example, plus by > correlating relative freshness with dates the program might even learn > each mirror sync hours over time) again - this is all about the failover of identical mirrors. That's fine - and that is why you can add options/cases to failover for that class - look at failover.py in yum. however, providing multiple repos that provide mostly the same thing and expecting repo1 to failover for repo2 is a misuse of the concept. > All those checks are what a user is supposed to do manually before > putting a particular mirror in his config file. There is no reason > automating it can not give better results and produce more efficient > ressource usage patterns for everyone. as long as a mirror is a mirror and not an alternate repo then listing multiple mirrors under a repository stanza and doing statistic tracking on them is not unreasonable. The tracking is not implemented and will take some time to implement correctly. -sv From sopwith at redhat.com Wed Oct 22 19:26:31 2003 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 22 Oct 2003 15:26:31 -0400 (EDT) Subject: Time plan for merger In-Reply-To: <1066842037.7813.71.camel@guava.bamdad.org> Message-ID: On Wed, 22 Oct 2003, Roozbeh Pournader wrote: > Is there (even a general idea of) a time plan for the merger with > "fedora.us"? Specifically, will it happen before Cambridge++ or after? The merger is an ongoing process that will take months. Are there more specific merger accomplishments you wanted to know the ETA of? -- Elliot Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. From Nicolas.Mailhot at laPoste.net Wed Oct 22 20:11:24 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 22 Oct 2003 22:11:24 +0200 Subject: up2date and yum: failover mode? In-Reply-To: <1066850004.27197.42.camel@opus> References: <20031020100746.GC15294@puariko.nirvana> <20031021233453.GG4887@redhat.com> <1066809712.3699.16.camel@ulysse.olympe.o2t> <1066825159.7859.178.camel@binkley> <20031022160532.GA26291@puariko.nirvana> <1066844470.27197.20.camel@opus> <1066847721.2806.42.camel@m70.net81-64-235.noos.fr> <1066850004.27197.42.camel@opus> Message-ID: <1066853484.2806.84.camel@m70.net81-64-235.noos.fr> Le mer 22/10/2003 ? 21:13, seth vidal a ?crit : > > > > The repositories are the same - they are just potentially out of sync. > > END. > > If they are not in sync then they are not the same. > If they are the same, then they don't need to both be listed as separate > repositories. On a volatile repository like Rawhide mirrors are always out of sync. The best ones are maybe 90% synchronized, but they always seem to lack the last tensome of updated packages. This doesn't mean that one can not use them, just that upstream must *always* be checked too to complete updates with this tensome of packages. > > > The aim is to maximize acces to local/close/deep mirrors without losing > > ability to get the latest parts from the master site (accessing the > > master site is costly for the upstream source and potentially for the > > user if it means leaving an intranet through a congested shared pipe). > > You're mixing the concepts of repository and mirror in ways that they > shouldn't be mixed. I may be mixing yum concepts. I was just talking plain layman site/mirror problems (and studiously avoided even writing repository here;) > a repository is a set of packages - distinct from any other repository > in that it provides different items - they don't have to be discretely > different but at least not claiming to provide the identical things. > > a mirror is an IDENTICAL COPY - hence the term mirror. There is no such thing in reality. The deepest the mirror, the more volatile the upstream source, the less true it is. What you can have at best is a set of sources with different epochs of the index/packages set. Traditional mirroring just "assumes" mirror=upstream source. Repository mirroring can be smarter, since the data is fully indexed and so it is possible to check precisely the level of out-of-sync-eness (freshness) without downloading the full upstream set. Therefore is is possible to do a big part of the download from mirrors, download from source only the delta of packages that wasn't mirrored yet, and get exactly the same results as if the full download was done ftom up-to-date upstream. > in yum it works like this: > [repo] > baseurl=mirror > mirror > mirror > mirror > > [repo2] > baseurl=mirror2 > mirror2 > mirror2 > mirror2 > > > > All the download manager should need is a list of the X upstream level 1 > > sources, a list of all known mirror sources (sometimes a few 100 sites) > > and be able to choose by itself 2-3 mirrors it'll poll and one upstream > > source to check for completeness. > > and if they're not in sync it will never know what it's getting - the > suggestion that you appear to be saying is allow repo2 to provide > something if repo fails. No. My suggestion is to recognize all mirrors are always more or less out of sync, so you get as much stuff as you can for mirrors, and you complete as needed from upstream. It's not an all-or-nothing proposition. If only package foo was updated since upstream was last mirrored it'd be stupid do download the gazillon other updates from upstream too. What you need is use the mirrors to update all stuff except foo package, and download foo from upstream (and skip the intermediary versions of foo that may be present on the mirrors) This also means you must explicitely tell your package manager what the level 1 source(s) is(are), since while you needn't check all available mirrors you *must* check upstream, if only to verify you're not using mirrors that stopped being updated a year ago (ie if you always end up not downloading anything from a mirror because it lags too much behind - stop polling it systematically even if its response time/bandwidth is excellent. This can happen if you're accustomed to daily syncs and this particular mirror is updated every week) And then there is the problem of partial mirrors, ie mirrors that only carry some channels (exemple : updates.redhat.com only carries the update part of ftp.redhat.com) or do not mirror rarely used ones (sources, debug stuff, exotic arches...). The solution for the package manager is probably to treat each channel as a separate repository, though the mirror list the upstream project will provide won't specify what mirrors are partials or not (and this may change over time), so to find X mirrors of a particular channel you may have to query Y>X mirrors. But you can get around this by "remembering" what mirror carried what channel, re-checking for better mirrors every month or so. 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 wcooley at nakedape.cc Wed Oct 22 20:25:49 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Wed, 22 Oct 2003 13:25:49 -0700 Subject: the only VPN solution is not in rh In-Reply-To: <3F9696BC.4080103@bnap.hu> References: <3F9696BC.4080103@bnap.hu> Message-ID: <1066854349.22831.6.camel@denk.nakedape.priv> On Wed, 2003-10-22 at 07:39, Farkas Levente wrote: > hi, > currently there is not any real vpn solution in rh distro. what are the > alternatives: > - freeswan (ipsec) > - cipe > - openvpn > > although ipsec is the future, it has many probles. the old kernel > implementation is not accepted while the new is just in the 2.6 series > (the backport is...) and the freeswan's user space part is not compiled > for the the ipsec implementation. and we don't the quality of that part > of the code (that was the reason why the old kernel psace can't get into > the kernel). the x509 patch still not in the mainstream freeswan which > is essential for windows clients. imho it needs a year to be stable and > usable. FreeS/WAN has problems, but it does work. I'd much rather see FreeS/WAN support than anything; it's standard and interoperates with lots of other IPSEC implementations; CIPE and OpenVPN are, AFAICT, not widely supported and "proprietary" (in the sense that they're non-standard and not even seeking standardization). FreeS/WAN itself works well enough as an external module; they only problem is if you want NAT-Traversal, it would need a patch to the actual kernel. 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 katzj at redhat.com Wed Oct 22 20:31:00 2003 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 22 Oct 2003 16:31:00 -0400 Subject: An end to the GRUB/LILO threads... Message-ID: <1066854659.7821.17.camel@mirkwood.devel.redhat.com> For Fedora Core 1, lilo has now been added back, but still on the deprecated list. To get to it in the installer, you'll have to boot with 'linux lilo' and I really want to remove it again after FC1 is out. To make this a more productive mail, the list of things to then target for FC2 are: 1) RAID support in grub-install. There are comments in bug 55484 that describe what needs doing. Shouldn't require more than fun with shell scripting, so this is a great project for someone who wants to start getting involved :) 2) Hardware that GRUB doesn't work with. If you have hardware on which this is the case, testing across multiple versions of grub (it's been shipped since Red Hat Linux 7.2, the old packages should all still install) as well as making sure your BIOS is current. 3) The a11y question, but the comments about placing ^G's in the title should make that moot I think, as that's essentially what you do with lilo as well. Jeremy From stevelist at silverorange.com Wed Oct 22 20:37:52 2003 From: stevelist at silverorange.com (Steven Garrity) Date: Wed, 22 Oct 2003 17:37:52 -0300 Subject: Vector-based Fedora Logo Available? Message-ID: <1066855072.3f96eaa0cb68a@secure2.silverorange.com> It would be nice if the working artwork files (I presume there are a bunch of Photoshop/Illustrator or equivalent files) could be sitting in a read-only anonymous FTP or something like that. I think this would encourage participation and improvements (it certainly would from me). Steven Garrity ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From xose at wanadoo.es Wed Oct 22 21:15:56 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 22 Oct 2003 23:15:56 +0200 Subject: An end to the GRUB/LILO threads... References: <1066854659.7821.17.camel@mirkwood.devel.redhat.com> Message-ID: <3F96F38C.1030305@wanadoo.es> Jeremy Katz wrote: > 2) Hardware that GRUB doesn't work with. If you have hardware on which > this is the case, testing across multiple versions of grub (it's been > shipped since Red Hat Linux 7.2, the old packages should all still > install) as well as making sure your BIOS is current. ^^^^^^^^^^^^^^^ maybe, a piece of advise in RELASE-NOTES about this will be nice -- HTML mails are going to trash automatically From garrett at redhat.com Wed Oct 22 21:17:57 2003 From: garrett at redhat.com (Garrett LeSage) Date: Wed, 22 Oct 2003 17:17:57 -0400 Subject: Vector-based Fedora Logo Available? In-Reply-To: <1066855072.3f96eaa0cb68a@secure2.silverorange.com> References: <1066855072.3f96eaa0cb68a@secure2.silverorange.com> Message-ID: <3F96F405.7010105@redhat.com> Steven Garrity wrote: >It would be nice if the working artwork files (I presume there are a bunch of >Photoshop/Illustrator or equivalent files) could be sitting in a read-only >anonymous FTP or something like that. > >I think this would encourage participation and improvements (it certainly would >from me). > > Most everything is either in AI (Illustrator) or in XCF format (GIMP native). I will start looking into the details after Fedora Core 1 is released. Thanks for offering to contribute; I could use the extra help. (: Garrett From chuckw at quantumlinux.com Wed Oct 22 21:26:28 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 22 Oct 2003 14:26:28 -0700 (PDT) Subject: An end to the GRUB/LILO threads... In-Reply-To: <3F96F38C.1030305@wanadoo.es> Message-ID: > > 2) Hardware that GRUB doesn't work with. If you have hardware on > > which this is the case, testing across multiple versions of grub (it's > > been shipped since Red Hat Linux 7.2, the old packages should all > > still install) as well as making sure your BIOS is current. > ^^^^^^^^^^^^^^^ > > maybe, a piece of advise in RELASE-NOTES about this will be nice So if I update the bios on my 486... -- 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 nhruby at uga.edu Wed Oct 22 21:35:06 2003 From: nhruby at uga.edu (nathan r. hruby) Date: Wed, 22 Oct 2003 17:35:06 -0400 (EDT) Subject: An end to the GRUB/LILO threads... In-Reply-To: References: Message-ID: On Wed, 22 Oct 2003, Chuck Wolber wrote: > > > So if I update the bios on my 486... > > You'll still have a machine that need massive quantities of Viagra after every power outage :) -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From xose at wanadoo.es Wed Oct 22 21:41:56 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 22 Oct 2003 23:41:56 +0200 Subject: An end to the GRUB/LILO threads... References: Message-ID: <3F96F9A4.4010203@wanadoo.es> Chuck Wolber wrote: >>maybe, a piece of advise in RELASE-NOTES about this will be nice > > So if I update the bios on my 486... > report it to :-P -- HTML mails are going to trash automatically From gemi at bluewin.ch Wed Oct 22 22:36:32 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Thu, 23 Oct 2003 00:36:32 +0200 Subject: Submitting packages Message-ID: <1066862192.13453.20.camel@scriabin.tannenrauch.ch> Michael, Thanks for clearifying. It may probably a good idea to put a little more information on this on the Fedora home page, so that potential contributors know what to expect. As for the QA process, it is clear that this should be strict. However I wouldn't agree with arguments like "Do we really need that?" or "Why three Prolog implementations, one should be enough". For the Fedora Core this policy is the right one, but the future extras should include any packages that might be of interest. This does not mean, however, that any shell script, that someone has written, should be packaged. Yes, most packages WILL have a special target group, but programming languages like Haskell and SML are not special purpose. I wish for Fedora to become a dominant distribution in the educational and research area. >From the original Fedora FAQ: "Fedora will forever put an end to incompatibilities due to repository mixing by eventually including all possible software." While this is an ideal probably impossible to achieve, I think it is a worthwhile goal, and the merger with the Redhat project, raised my hope that it could be actually achieved. Anyway, I will from time to time submit packages to Fedora, and look forward to the moment, where I install a fresh copy of Fedora and simply use up2date to install one of the packages, I myself contributed. (I hope the extras repository is included by default on a fresh install, not as something that users may find out to use from hearsay, otherwise it would not be much different from freshrpms and others) A further point: with a large repository, I think becomes necessary to extend the official application groups for rpm. Where should I but a computer algebra package, when there is not group called Application/Mathematics, for example. Maybe a naming convention more than 2 deep would also help. I look forward to a bright future :-) Regards -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From darryl at snakegully.nu Wed Oct 22 22:38:33 2003 From: darryl at snakegully.nu (Darryl Luff) Date: Thu, 23 Oct 2003 08:38:33 +1000 Subject: Submitting packages In-Reply-To: <20031022174001.2af3327d.ms-nospam-0306@arcor.de> References: <1066777475.4342.6.camel@scriabin.tannenrauch.ch> <3F968851.5080701@snakegully.nu> <20031022174001.2af3327d.ms-nospam-0306@arcor.de> Message-ID: <3F9706E9.3070509@snakegully.nu> Michael Schwendt wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Wed, 22 Oct 2003 23:38:25 +1000, Darryl Luff wrote: > > > >>I submitted one test package to (old) Fedora (p0f). My plan was to watch >>the process as this package went through, and then once I was familiar >>with the process, to get involved with processing packages, both my own >>and others. >> >>Unfortunately, just after I did this the Redhat/Fedora merge happened. >>So my trial package has gone nowhere. >> >> > >Not true. Your package request is right here, > > https://bugzilla.fedora.us/show_bug.cgi?id=680 > >waiting together with 237 other requests. > Yep, thats fine. I wasn't meaning to complain about the time it takes - that is to be expected. I guess I was just expressing a concern about the direction the project is taking. As long as any submitted packages will be accepted into the repositories, it will be great. I was worried that by changing the focus from 'high-quality, 3rd party rpms, for the RedHat Linux distribution' to 'a complete, general purpose operating system (built) exclusively from free software', that someone somewhere would be selecting which packages can be included, rather than allowing any packages someone wants to submit. From chuckw at quantumlinux.com Thu Oct 23 00:21:28 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 22 Oct 2003 17:21:28 -0700 (PDT) Subject: rawhide report: 20031021 changes In-Reply-To: <1066785979.7859.153.camel@binkley> Message-ID: > > > It will take longer to public to fedora.redhat.com -- we'll need a > > > proper CMS to do that for reasons involving infrastructure (pushing > > > web site content is currently too heavyweight a process for that to > > > work). It's still a good idea, though. :-) > > > > So are you saying that http://www.redhat.com/software/rha/cms/ isn't a > > "proper CMS"? :) > > reasons why it doesn't seem like a real cms to me: > 1. source code is included - but under what license? > 2. it's in java > 3. it's in java > 4. The Red Hat CMS approach can have a company running a content > management system in as little as two months. - umm - 2months? While we're talking about CMS, has anyone ever looked at Callisto? http://www.callistocms.com/ -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 pri.rhl1 at iadonisi.to Thu Oct 23 00:49:30 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 22 Oct 2003 20:49:30 -0400 Subject: the only VPN solution is not in rh In-Reply-To: <1066854349.22831.6.camel@denk.nakedape.priv> References: <3F9696BC.4080103@bnap.hu> <1066854349.22831.6.camel@denk.nakedape.priv> Message-ID: <1066870170.3799.15.camel@va.local.linuxlobbyist.org> On Wed, 2003-10-22 at 16:25, Wil Cooley wrote: [snip] > > for the the ipsec implementation. and we don't the quality of that part > > of the code (that was the reason why the old kernel psace can't get into > > the kernel). the x509 patch still not in the mainstream freeswan which > > is essential for windows clients. imho it needs a year to be stable and > > usable. > > FreeS/WAN has problems, but it does work. I'd much rather see FreeS/WAN > support than anything; it's standard and interoperates with lots of > other IPSEC implementations; CIPE and OpenVPN are, AFAICT, not widely > supported and "proprietary" (in the sense that they're non-standard and > not even seeking standardization). FreeS/WAN itself works well enough > as an external module; they only problem is if you want NAT-Traversal, > it would need a patch to the actual kernel. Depends on what you mean by nat traversal. You can initiate a connection to a FreeS/WAN server from behind a firewall fine, but you do need to use the X.509 patch so that you can use certificates AND only one client* behind that firewall can do key negotiation as port udp 500 needs to be reverse nat-ed to point to that client. Having a FreeS/Wan server* behind a firewall that you would like for clients* to be able to connect to from outside the firewall...now that's another story. Then, I think you do need to modify the kernel with the nat-traversal patches. FreeS/Wan does have other problems, though, the most difficult one to solve is probably non-technical in nature: unless the policy of the FreeS/Wan team has changed, they will not accept patches from anyone residing the USA due to past restrictions on the export of encryption. That makes it very difficult for a company like Red Hat to submit patches in the hopes that they will be incorporated in later upstream version. And that is one of the goals of the Fedora Project -- to remain closer to upstream. Nevertheless, I'm with the proponents of *some* kind of IPSec implementation, but for me, I'm willing to do my own packages for FreeS/Wan for the time being. Thankfully, it is no longer necessary to build a custom kernel ... the kernel module can be built independently. And since the stock, soon to be released kernel.org 2.6 kernel has built in ipsec, I'm willing to wait for that release, meanwhile using FreeS/Wan. If anyone else is interested, I'd be willing to post my spec file for FreeS/Wan as well as pointers to any patches. Mine builds for RHL9, but I haven't tried on fct3. I don't like the way the FreeS/Wan rpms are built on xs4all.nl, so I've done it a bit differently. Plus, I don't build an rpm for the kernel module ... it's only one file that I copy into the /lib/modules tree. * I use the terms 'client' and 'server' here relatively losely. In reality, IPSec peers are just that: peers. But when one is behind a firewall, the picture does change a bit. -- -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 mattharrison at sbcglobal.net Thu Oct 23 04:13:09 2003 From: mattharrison at sbcglobal.net (Matt Jones) Date: Wed, 22 Oct 2003 21:13:09 -0700 Subject: Vector-based Fedora Logo Available? In-Reply-To: <3F96F405.7010105@redhat.com> References: <1066855072.3f96eaa0cb68a@secure2.silverorange.com> <3F96F405.7010105@redhat.com> Message-ID: <1066882389.1455.2.camel@localhost.localdomain> On Wed, 2003-10-22 at 14:17, Garrett LeSage wrote: > Most everything is either in AI (Illustrator) or in XCF format (GIMP > native). > > I will start looking into the details after Fedora Core 1 is released. > > Thanks for offering to contribute; I could use the extra help. (: > > Garrett Yeah. It would be great to have all of the scalable files available. Are the xcf-format ones based on paths, or are they all pixel-based? It would be great to have a scalable bluecurve theme available (i like bigger icons sometimes, but the bluecurve ones don't scale too well). -- Matt -------------- 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 warren at togami.com Thu Oct 23 05:33:29 2003 From: warren at togami.com (Warren Togami) Date: Wed, 22 Oct 2003 19:33:29 -1000 Subject: Submitting packages In-Reply-To: <3F9706E9.3070509@snakegully.nu> References: <1066777475.4342.6.camel@scriabin.tannenrauch.ch> <3F968851.5080701@snakegully.nu> <20031022174001.2af3327d.ms-nospam-0306@arcor.de> <3F9706E9.3070509@snakegully.nu> Message-ID: <3F976829.4070305@togami.com> Darryl Luff wrote: > Yep, thats fine. I wasn't meaning to complain about the time it takes - > that is to be expected. I guess I was just expressing a concern about > the direction the project is taking. As long as any submitted packages > will be accepted into the repositories, it will be great. I was worried > that by changing the focus from 'high-quality, 3rd party rpms, for the > RedHat Linux distribution' to 'a complete, general purpose operating > system (built) exclusively from free software', that someone somewhere > would be selecting which packages can be included, rather than allowing > any packages someone wants to submit. > "high-quality, 3rd party rpms" currently describes fedora.us with our slowness and absolute refusal to approve anything that we haven't ourselves checked, then manually tested the binaries. That however is also our greatest problem since so few people are doing so. http://www.fedora.us/QA Currently at 228 packages that need QA analysis. Want to get involved? http://www.fedora.us/wiki/PackageSubmissionQAPolicy Read this first. http://www.fedora.us/wiki/SelfIntroduction Then do this. Warren Togami warren at togami.com From nos at utel.no Thu Oct 23 07:28:06 2003 From: nos at utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Thu, 23 Oct 2003 09:28:06 +0200 Subject: the only VPN solution is not in rh In-Reply-To: <7ff8cba20306fd07d3@[192.168.170.10]> References: <7ff8cba20306fd07d3@[192.168.170.10]> Message-ID: <1066894085.1233.1.camel@nos-rh> On Wed, 2003-10-22 at 16:39, Farkas Levente wrote: > hi, > currently there is not any real vpn solution in rh distro. what are the > alternatives: > - freeswan (ipsec) > - cipe > - openvpn tincd (http://tinc.nl.linux.org/) , it's a very nice and simple vpn solution. I'll take a stab at it and package it someday after fedora 1.0.. -- 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 benny+nospam at amorsen.dk Thu Oct 23 07:58:15 2003 From: benny+nospam at amorsen.dk (Benny Amorsen) Date: Thu, 23 Oct 2003 09:58:15 +0200 Subject: the only VPN solution is not in rh In-Reply-To: <1066870170.3799.15.camel@va.local.linuxlobbyist.org> References: <3F9696BC.4080103@bnap.hu> <1066854349.22831.6.camel@denk.nakedape.priv> <1066870170.3799.15.camel@va.local.linuxlobbyist.org> Message-ID: <1066895894.2068.66.camel@vega.amorsen.dk> On 2003-10-23 at 02:49, Paul Iadonisi wrote: > If anyone else is interested, I'd be willing to post my spec file for > FreeS/Wan as well as pointers to any patches. Mine builds for RHL9, but > I haven't tried on fct3. I don't like the way the FreeS/Wan rpms are > built on xs4all.nl, so I've done it a bit differently. Plus, I don't > build an rpm for the kernel module ... it's only one file that I copy > into the /lib/modules tree. If you get the freeswan version with the X.509 patch already incorporated, you can just cd packaging/redhat and make rpm. You need to have the kernel-source package installed. The only issue is that the automatic architecture detection in the init script failed for me. It has worked for me with earlier versions of freeswan. /Benny From paul at gear.dyndns.org Thu Oct 23 11:16:50 2003 From: paul at gear.dyndns.org (Paul Gear) Date: Thu, 23 Oct 2003 21:16:50 +1000 Subject: Boot Loader Proposal In-Reply-To: <200310210932.40889.jkeating@j2solutions.net> References: <200310210932.40889.jkeating@j2solutions.net> Message-ID: <3F97B8A2.2070807@gear.dyndns.org> Jesse Keating wrote: > ... > Grub and Syslinux remain in Core. They will cover the mass majority of > the userbase, with minimal duplication. Lilo shall be relegated to > Alternatives or Extras. Lilo seems to have a smaller need base, but > still needs to be available. This should satisfy the majority of the > people on this list right? Here is a bug which has one very good reason why lilo should continue to be included: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484 LILO supports RAID 1 boot disks, GRUB doesn't, except in the install process, which doesn't help you after you install another OS and it trashes your boot loader. -- 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 oden.eriksson at kvikkjokk.net Thu Oct 23 11:38:05 2003 From: oden.eriksson at kvikkjokk.net (Oden Eriksson) Date: Thu, 23 Oct 2003 13:38:05 +0200 Subject: Yo. In-Reply-To: <200310162130.h9GLUaX19702@devserv.devel.redhat.com> References: <200310162130.h9GLUaX19702@devserv.devel.redhat.com> Message-ID: <200310231338.05509.oden.eriksson@kvikkjokk.net> torsdagen den 16 oktober 2003 23.30 skrev Alan Cox: > > I don't know, I wasn't aware of any patents regarding this. > > http://www.computerworld.com/managementtopics/ebusiness/story/0,10801,59043 >,00.html http://www.i-d-n.net/#patents > > All very messy but I've not followed it since early 2002 to know > what happened or if it all died The impression I've got from the people I've talked to is that there is no problem with this. For one thing..., the Swedish TLD dot SE would probably not roll out this if there were patent issues. Cheers. From pekkas at netcore.fi Thu Oct 23 12:32:36 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 23 Oct 2003 15:32:36 +0300 (EEST) Subject: Yo. In-Reply-To: <200310231338.05509.oden.eriksson@kvikkjokk.net> Message-ID: On Thu, 23 Oct 2003, Oden Eriksson wrote: > > http://www.computerworld.com/managementtopics/ebusiness/story/0,10801,59043 > >,00.html http://www.i-d-n.net/#patents > > > > All very messy but I've not followed it since early 2002 to know > > what happened or if it all died > > The impression I've got from the people I've talked to is that there is no > problem with this. > > For one thing..., the Swedish TLD dot SE would probably not roll out this if > there were patent issues. Uhh, the patents would not be applicable in EU anyway, so I don't think this really means anything. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From sean at compu-aid.net Thu Oct 23 12:53:16 2003 From: sean at compu-aid.net (Sean Millichamp) Date: 23 Oct 2003 08:53:16 -0400 Subject: Proposal to better support custom kernel modules Message-ID: <1066913596.19098.18.camel@pc01.wks.enertronllc.com> I would like to make a proposal/request in the hope of soliciting feedback and ideas. Short summary: There should be a standard path supported by the distribution where RPM packages can install custom/updated kernel modules and know that the modutils will search there first before searching the path containing the distribution supplied modules in the kernel-* packages. Background: As part of supporting some of my systems I need to provide custom kernel modules. For example, two that I use frequently are Sangoma WANPIPE drivers (the ones that ship with the kernel are ancient) and the PPP MPPE compressor for PPTP support (the MPPE module requires a new ppp_generic.o). Because I strive for a fully RPM managed system I've been doing my best to produce clean RPM packages to manage these modules. The problem that I encounter is that both of these kernel module updates need to replace files that are provided by the Red Hat/Fedora supplied kernels. There is no mechanism that I have found in RPM to specify that files can be "stolen" by new packages so if I try to install RPMs with the modules to the standard locations I need to use --force to overwrite the existing files - which I don't consider a good solution in general and it is particularly bad when you are using something like apt/yum. The solution I have seen a number of times is to package the file in the RPM named differently and then use post-installation scripts to rename the old kernel module out of the way and then rename the new one in it's place. While this does avoid the --force issue it violates the spirit of package management and RPM "owning" the files and it breaks --verify runs on the kernel packages. What I have found to be the only good solution so far is to setup a new module path in /etc/modules.conf so that modutils searches that first and then if it doesn't find the module there then proceeds to the standard kernel location. So I have tested some RPMs that setup /etc/modules.conf to look something like: path=/lib/modules/custom/`uname -r`/kernel path=/lib/modules/`uname -r`/kernel Then I have the RPMs install the modules in the /lib/modules/custom hierarchy and they are found there first. This has worked well for me and seems to meet all the requirements from a packaging standpoint. I would like to request that whoever is in charge of modutils/kernel module issues (presumably someone @redhat.com) take a look at this idea and codify a standard path that is searched first and setup by default with the distribution so that there is a standard mechanism all kernel module packagers can take advantage of in a consistent fashion. Any comments and suggestions are welcome. Thank you. Sean From elanthis at awesomeplay.com Thu Oct 23 13:53:08 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Thu, 23 Oct 2003 09:53:08 -0400 Subject: the only VPN solution is not in rh In-Reply-To: <1066894085.1233.1.camel@nos-rh> References: <7ff8cba20306fd07d3@[192.168.170.10]> <1066894085.1233.1.camel@nos-rh> Message-ID: <1066917188.1042.3.camel@support02.civic.twp.ypsilanti.mi.us> On Thu, 2003-10-23 at 03:28, Nils O. Sel??sdal wrote: > On Wed, 2003-10-22 at 16:39, Farkas Levente wrote: > > hi, > > currently there is not any real vpn solution in rh distro. what are the > > alternatives: > > - freeswan (ipsec) > > - cipe > > - openvpn > tincd (http://tinc.nl.linux.org/) , it's a very nice and simple vpn > solution. > I'll take a stab at it and package it someday after fedora 1.0.. Please don't do this - tinc, cipe, and several other "home-grown" VPN solutions have been shown to be so weak/poorly designed as to be worse than plain text, since at least with plain text transactions the admins realize they're vulnerable. ;-) http://www.securityfocus.com/bid/8676 -- Sean Middleditch AwesomePlay Productions, Inc. From katzj at redhat.com Thu Oct 23 14:35:23 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 23 Oct 2003 10:35:23 -0400 Subject: Proposal to better support custom kernel modules In-Reply-To: <1066913596.19098.18.camel@pc01.wks.enertronllc.com> References: <1066913596.19098.18.camel@pc01.wks.enertronllc.com> Message-ID: <1066919723.16295.1.camel@edoras.local.net> On Thu, 2003-10-23 at 08:53, Sean Millichamp wrote: > Short summary: There should be a standard path supported by the > distribution where RPM packages can install custom/updated kernel > modules and know that the modutils will search there first before > searching the path containing the distribution supplied modules in the > kernel-* packages. /lib/modules/$(uname -r)/updates will get searched now by modutils (and mkinitrd) when looking for a module. Also, if you're packaging, if you have your package "Provides: kernel-modules", then it will get install instead of upgrade behavior by default from up2date. Cheers, Jeremy From nphilipp at redhat.com Thu Oct 23 14:46:41 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 23 Oct 2003 16:46:41 +0200 Subject: An end to the GRUB/LILO threads... In-Reply-To: <1066854659.7821.17.camel@mirkwood.devel.redhat.com> References: <1066854659.7821.17.camel@mirkwood.devel.redhat.com> Message-ID: <1066920400.1395.16.camel@gibraltar.stuttgart.redhat.com> On Wed, 2003-10-22 at 22:31, Jeremy Katz wrote: > 3) The a11y question, but the comments about placing ^G's in the title > should make that moot I think, as that's essentially what you do with > lilo as well. Unless I'm mistaken, there are have been raised other GRUB issues regarding accessibility which need to be addressed, such as: - It should be possible to choose a kernel image to boot via "alias" or "name" rather than full-screen with cursor keys. The "title" keyword doesn't qualify for that -- it's too long. For the longer term, having a "beep-when-ready" keyword in grub.conf rather than ^G hacks would also be nice. 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 sean at compu-aid.net Thu Oct 23 14:54:24 2003 From: sean at compu-aid.net (Sean Millichamp) Date: 23 Oct 2003 10:54:24 -0400 Subject: Proposal to better support custom kernel modules In-Reply-To: <1066919723.16295.1.camel@edoras.local.net> References: <1066913596.19098.18.camel@pc01.wks.enertronllc.com> <1066919723.16295.1.camel@edoras.local.net> Message-ID: <1066920864.19098.78.camel@pc01.wks.enertronllc.com> On Thu, 2003-10-23 at 10:35, Jeremy Katz wrote: > /lib/modules/$(uname -r)/updates will get searched now by modutils (and > mkinitrd) when looking for a module. Also, if you're packaging, if you > have your package "Provides: kernel-modules", then it will get install > instead of upgrade behavior by default from up2date. Jeremy, That's great news! Thank you for your prompt reply. I assume that this is a recent addition with Fedora Core Test and isn't supported in RHL 7.3 through 9? Sean From katzj at redhat.com Thu Oct 23 15:06:41 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 23 Oct 2003 11:06:41 -0400 Subject: Proposal to better support custom kernel modules In-Reply-To: <1066920864.19098.78.camel@pc01.wks.enertronllc.com> References: <1066913596.19098.18.camel@pc01.wks.enertronllc.com> <1066919723.16295.1.camel@edoras.local.net> <1066920864.19098.78.camel@pc01.wks.enertronllc.com> Message-ID: <1066921601.16295.3.camel@edoras.local.net> On Thu, 2003-10-23 at 10:54, Sean Millichamp wrote: > On Thu, 2003-10-23 at 10:35, Jeremy Katz wrote: > > /lib/modules/$(uname -r)/updates will get searched now by modutils (and > > mkinitrd) when looking for a module. Also, if you're packaging, if you > > have your package "Provides: kernel-modules", then it will get install > > instead of upgrade behavior by default from up2date. > That's great news! Thank you for your prompt reply. I assume that this > is a recent addition with Fedora Core Test and isn't supported in RHL > 7.3 through 9? Yep, it's new for Fedora Core 1 (also in Red Hat Enterprise Linux 3, for whatever it's worth) Jeremy From garrett at redhat.com Thu Oct 23 16:37:20 2003 From: garrett at redhat.com (Garrett LeSage) Date: Thu, 23 Oct 2003 12:37:20 -0400 Subject: Vector-based Fedora Logo Available? In-Reply-To: <1066882389.1455.2.camel@localhost.localdomain> References: <1066855072.3f96eaa0cb68a@secure2.silverorange.com> <3F96F405.7010105@redhat.com> <1066882389.1455.2.camel@localhost.localdomain> Message-ID: <3F9803C0.5080602@redhat.com> Matt Jones wrote: > Yeah. It would be great to have all of the scalable files available. Are > the xcf-format ones based on paths, or are they all pixel-based? It > would be great to have a scalable bluecurve theme available (i like > bigger icons sometimes, but the bluecurve ones don't scale too well). Making the icons in an SVG format at the current time is a bit difficult. It will take a good bit of work to convert them over and also improve the SVG renderers. Making the current vector art available can facilitate this. I should probably export the icons at a little larger size if I can find the time. (: The icons are all in a vector format, as are the splash screens. The XCF art I have is mostly just backgrounds and other misc. stuff which is probably more or less (depending on what it is) not applicable to the Fedora project, at least not when you consider icons and splash screens. Garrett From kaboom at gatech.edu Thu Oct 23 19:15:54 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 23 Oct 2003 15:15:54 -0400 (EDT) Subject: rsyncing rawhide -- statistics In-Reply-To: References: Message-ID: On Tue, 21 Oct 2003, Chris Ricker wrote: > So, for a daily update of the rawhide binary RPMs, rsync downloaded 16 megs, > while ftp downloaded 246 megs. That's a very significant savings, > bandwidth-wise! > > Of course, this was only one trial, and it may have been anomalous -- for > example, it might be the case that more of the differences between today and > yesterday's rawhide trees were simply repushes of now-signed packages than > is usually the case w/ a daily rawhide update.... I'll benchmark a couple > more days and see what it looks like with repeated samples. I just did a repeat now that rawhide's been updated again. For today's daily update (which was mostly newer versions of biggish packages, rather than resigning packages that already existed), ftp downloaded 150 megs, while an rsync update downloaded 160 megs. Looks like the patches to block-align gzip / bzip2 would definitely be needed for rsync to be useful for more than updating resigned packages.... later, chris From jfontain at free.fr Thu Oct 23 20:48:34 2003 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Thu, 23 Oct 2003 22:48:34 +0200 Subject: Self-Introduction: Jean-Luc Fontaine Message-ID: <3F983EA2.9070706@free.fr> - Full legal name: Jean-Luc FONTAINE - Country, City: Le Haillan, France (Le Haillan is a small city near Bordeaux, where they make excellent wines, I must say ;-) - Profession: MIS - Company: CERTIA (a computing regional center for the French Social Security) - Goals in the Fedora Project - Which packages do you want to see published? moodss, a modular monitoring application (GUI and daemon, http://jfontain.free.fr/moodss/) which in turn requires blt (graph widgets, http://www.sourceforge.net/projects/blt/files) and tktable (table widget, http://tktable.sourceforge.net/) (I'd take care of all those) - Do you want to do QA? Yes, but after I am somewhat done with my TODO list for moodss - Anything else special? If you have any ideas about new modules for moodss, especially for Linux, I'd be glad to work on them. - Historical qualifications - What other projects have you worked on in the past? tclperl (running Perl code from Tcl), tclpython (running Python code from Tcl), stooop (OO programming in Tcl), ... - What computer languages and other skills do you know? C, C++, Perl, Python, network monitoring with SNMP, Linux administration, Windows servers administration even... - Why should we trust you? Because I am a nice guy: just look at my picture at http://jfontain.free.fr/ ... More seriously, I have been using and enjoying Linux since 1993, and I wanted to give back, so I started to work steadily on system/database/network management free software from 1997. Very recently, my main software project made it in "The Art of UNIX Programming" book by Eric S. Raymond (more information on reviews, users experiences, ... at http://jfontain.free.fr/moodss/). - GPG KEYID and fingerprint: pub 1024D/F713D6A4 2003-10-04 Jean-Luc Fontaine Key fingerprint = 7AAD 7273 49B0 6A31 1226 28CB 906F CC32 F713 D6A4 sub 1024g/54AD07BC 2003-10-04 I am looking forward to contributing, Best regards, Jean-Luc PS: moodss blurb: Moodss 17.11 has just been released. Moodss is a modular multi-platform monitoring application, which supports operating systems (Linux, UNIX, Windows, ...), databases (MySQL, PostgreSQL, DB2, ODBC, ...), networking (SNMP, Apache, ...), and any device or process for which a module can be developed (in a scripting or compiled language: Tcl, Python, Perl, C). A very intuitive GUI with full drag'n'drop support allows the construction of powerful dashboards with graphs, pie charts, ..., such as one which would use the cpustats, memstats, apache and MySQL myhealth modules to monitor a busy dynamic web server. Proactive monitoring is achieved via a thorough thresholds functionality, including warning by multiple emails, user defined scripts, and an included daemon for background monitoring. Finally, on top of real-time monitoring, any part of the visible data can be archived in a SQL database (MySQL, ODBC or SQLite) by both the GUI and daemon applications, so that, for example, complete history over time can be made available in web pages, common spreadsheet software, or presentations. This GPL software is included in Suse Professional (rpms for Redhat also available on the author web page), used by IBM to monitor its Linux mainframe (see the "IBM e-server zSeries and S/390: System Management" redbook) and got an excellent review from Unix Review (further information with screenshots at http://jfontain.free.fr/moodss/). From alan at redhat.com Thu Oct 23 21:46:30 2003 From: alan at redhat.com (Alan Cox) Date: Thu, 23 Oct 2003 17:46:30 -0400 (EDT) Subject: Proposal to better support custom kernel modules In-Reply-To: <1066913596.19098.18.camel@pc01.wks.enertronllc.com> from "Sean Millichamp" at Hyd 23, 2003 08:53:16 Message-ID: <200310232146.h9NLkUx20162@devserv.devel.redhat.com> > distribution where RPM packages can install custom/updated kernel > modules and know that the modutils will search there first before > searching the path containing the distribution supplied modules in the > kernel-* packages. You never need to steal module names, you can always rename yours things like wanpipe-2.2 From gemi at bluewin.ch Fri Oct 24 01:14:14 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Fri, 24 Oct 2003 03:14:14 +0200 Subject: Self-Introduction: =?ISO-8859-1?Q?G=E9rard?= Milmeister Message-ID: <1066958054.1172.23.camel@scriabin.tannenrauch.ch> 1. Full legal name G?rard Milmeister 2. Country, City Switzerland, Zurich 3. Profession Research assistant 4. School University of Zurich (http://www.unizh.ch) 5. My goals in the Fedora Project Which packages? Mainly development software, i.e. tools and programming languages. But also Math software. QA? Sure, but only after I have a few of my submitted packages published, so that I can get insight of how the process works. Anything special? I would like to make Fedora a complete environment for developers and also the ideal distribution (especially) for computer science student. (I may then tell the students just to "yum install gprolog" for example) 6. Historical qualifications Other projects? Mainly university projects Computer languages and skills? C, C++, Java, Haskell, SML, Scheme, Prolog I know also quite a lot about XSL and MathML due to a project for an online Mathematics course. Why should you trust me? I have used Linux since 1993 and exclusively for more than 7 years, so you can bet I want it to succeed. I have graduated in computer science (Informatikingenieur) at the Swiss Federal Institute of Technology (http://www.ethz.ch) and have written a diploma thesis related to functional programming (so now you where my bias comes from). I am now working on my doctoral thesis at the University of Zurich in the field of Musicinformatics (http://www.ifi.unizh.ch/mml/musicmedia). I also maintain since 1999 a link page of development software for Linux (http://www.hotfeet.ch/~gemi/LDT). I want to Linux deployed in Universities, thus the type of software I would like to contribute. Regards -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From wcooley at nakedape.cc Fri Oct 24 02:21:41 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Thu, 23 Oct 2003 19:21:41 -0700 Subject: Boot Loader Proposal In-Reply-To: <3F97B8A2.2070807@gear.dyndns.org> References: <200310210932.40889.jkeating@j2solutions.net> <3F97B8A2.2070807@gear.dyndns.org> Message-ID: <1066962100.25610.39.camel@denk.nakedape.priv> On Thu, 2003-10-23 at 04:16, Paul Gear wrote: > Here is a bug which has one very good reason why lilo should continue to > be included: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484 > > LILO supports RAID 1 boot disks, GRUB doesn't, except in the install > process, which doesn't help you after you install another OS and it > trashes your boot loader. Yeah, I was bitten by this one just yesterday. :( 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 notting at redhat.com Fri Oct 24 02:26:52 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 23 Oct 2003 22:26:52 -0400 Subject: Fedora Core Bug Statistics - 2003-10-23 Message-ID: <20031023222652.A15941@devserv.devel.redhat.com> 2003-10-23 Total Closed Need Testing BLOCKER 334 252 ( 75.45 %) 25 ( 9.92 %) TARGET 594 170 ( 28.62 %) 22 ( 12.94 %) 2003-10-21 Total Closed Need Testing BLOCKER 334 226 ( 67.66 %) 39 ( 17.26 %) TARGET 589 153 ( 25.98 %) 18 ( 11.76 %) From tpride at dpiwe.tas.gov.au Fri Oct 24 04:47:26 2003 From: tpride at dpiwe.tas.gov.au (Tom Pride) Date: Fri, 24 Oct 2003 15:47:26 +1100 Subject: No acl bestbits patch in the Fedora kernel? Message-ID: <3F98AEDE.1080906@dpiwe.tas.gov.au> Why is it that Fedora comes with all the RPMS for acls and extended attributes yet the kernel does not come with the bestbits patches to enable you to mount a filesystem with acls and or extended attributes? To make matters worse, the bestbits patches will not work with the fedora core test3 kernel source. So you have to get a clean 2.4.22 kernel from www.kernel.org and apply the patches to that. Doing this sort of defeats the purpose because you then loose all the patchs that have been applied to the fedora core test3 kernel. Are there any plans to actually apply the bestbits patches to the Fedora core kernel? Cheers Tom From Frederic.Hornain at GB.BE Fri Oct 24 07:47:42 2003 From: Frederic.Hornain at GB.BE (=?iso-8859-1?Q?Hornain_Fr=E9d=E9ric?=) Date: Fri, 24 Oct 2003 09:47:42 +0200 Subject: Self-introduction : Frederic Hornain (RH Artwork) Message-ID: Hi, I will introduce myself as G?rard Milmeister did. Full legal Name Frederic Hornain Country, City Belgium, Brussels Profession Informix DBA & Linux System Administrator. School Centrale Lille -France- My Goal in the Fedora Project I would like to work for the moment for and with the RH Artwork Team. Unfortunatly, I really do not know how to start and where can I find the to do list as well as samples. I know that I have not a great skills in the domain but I will do my best. Thx for your answers. Historical Qualifications Computers Engineer Informix & Redhat Qualified. I have used RedHat Linux since 1997. Best Regards Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsonm at redhat.com Fri Oct 24 12:55:39 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 24 Oct 2003 08:55:39 -0400 Subject: No acl bestbits patch in the Fedora kernel? In-Reply-To: <3F98AEDE.1080906@dpiwe.tas.gov.au>; from tpride@dpiwe.tas.gov.au on Fri, Oct 24, 2003 at 03:47:26PM +1100 References: <3F98AEDE.1080906@dpiwe.tas.gov.au> Message-ID: <20031024085539.A3084@devserv.devel.redhat.com> On Fri, Oct 24, 2003 at 03:47:26PM +1100, Tom Pride wrote: > Why is it that Fedora comes with all the RPMS for acls and extended > attributes yet the kernel does not come with the bestbits patches to > enable you to mount a filesystem with acls and or extended attributes? Same reason as the past few releases: so that people who set up their system with a kernel with the ACL patches will have a system that Just Works. But now there's one thing that's changed; the ACL patches no longer destabilize the system under load; we finally found and fixed that bug while working on RHEL3. For this release, it changed to a pure matter of resources; if we'd had more time available, we would have put the ACL patches into FC1, but ACLs will certainly be in FC2. 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 mharris at redhat.com Fri Oct 24 14:08:44 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 24 Oct 2003 10:08:44 -0400 (EDT) Subject: xchat updated to be exec-shield friendly Message-ID: xchat contains a small amount of assembler, the short story of which causes it to not be exec-shield friendly. If exec-shield is enabled on one's system, xchat will run with it disabled. Since it is much preferable for any networked software to benefit from the type of security benefits that exec-shield provides, Arjan discovered this problem and wrote a small patch to make xchat exec-shield friendly. Arjan's patch is currently applied to xchat-2.0.4-4 which is in internal rawhide, and hopefully will be pushed out soon. Please test this heavily with and without exec-shield enabled. Please file any regressions in bugzilla. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From johnsonm at redhat.com Fri Oct 24 15:39:19 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 24 Oct 2003 11:39:19 -0400 Subject: xchat updated to be exec-shield friendly In-Reply-To: ; from mharris@redhat.com on Fri, Oct 24, 2003 at 10:08:44AM -0400 References: Message-ID: <20031024113919.A32705@devserv.devel.redhat.com> On Fri, Oct 24, 2003 at 10:08:44AM -0400, Mike A. Harris wrote: > Arjan's patch is currently applied to xchat-2.0.4-4 which is in > internal rawhide, and hopefully will be pushed out soon. Since it's not clear when all the fixes we're working on will finally work, I'm temporarily putting this up on my people site; update from the yum repository http://people.redhat.com/johnsonm/xchat/ and you'll have the version that needs testing. 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 aicra at well.com Fri Oct 24 16:00:53 2003 From: aicra at well.com (Marcia Wilbur) Date: Fri, 24 Oct 2003 09:00:53 -0700 (PDT) Subject: userpasswd In-Reply-To: <20031024113919.A32705@devserv.devel.redhat.com> References: <20031024113919.A32705@devserv.devel.redhat.com> Message-ID: In RH 9.. userpasswd is broken Reasons why: 1. shadow passwords require that etc/shadow file not be writeable by just anyone. This means that users cannot change it. Nor can any program run by the user. 2. You cannot set the userpasswd to be setuid root because then that would mean that any user can change any users password if they are at a terminal that someone forgot to log out from they can change the password for that user. 3. The userpasswd program simply assumes that the user who was trying to change the password is the one that is running the program. Some other approach must be done. -marcia From jkeating at j2solutions.net Fri Oct 24 16:27:26 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 24 Oct 2003 09:27:26 -0700 Subject: userpasswd In-Reply-To: References: <20031024113919.A32705@devserv.devel.redhat.com> Message-ID: <200310240927.30384.jkeating@j2solutions.net> On Friday 24 October 2003 09:00, Marcia Wilbur wrote: > Some other approach must be done. What about just plain old "passwd" ? -- 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 mharris at redhat.com Fri Oct 24 16:39:03 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 24 Oct 2003 12:39:03 -0400 (EDT) Subject: xchat updated to be exec-shield friendly In-Reply-To: <20031024113919.A32705@devserv.devel.redhat.com> References: <20031024113919.A32705@devserv.devel.redhat.com> Message-ID: On Fri, 24 Oct 2003, Michael K. Johnson wrote: >Date: Fri, 24 Oct 2003 11:39:19 -0400 >From: Michael K. Johnson >To: fedora-devel-list at redhat.com >Content-Type: text/plain; charset=us-ascii >List-Id: For developers, developers, developers >Subject: Re: xchat updated to be exec-shield friendly > >On Fri, Oct 24, 2003 at 10:08:44AM -0400, Mike A. Harris wrote: >> Arjan's patch is currently applied to xchat-2.0.4-4 which is in >> internal rawhide, and hopefully will be pushed out soon. > >Since it's not clear when all the fixes we're working on will >finally work, I'm temporarily putting this up on my people site; >update from the yum repository >http://people.redhat.com/johnsonm/xchat/ >and you'll have the version that needs testing. Good idea. I've pushed it to my repository also, for those who usually pick up my bits: Yum URL: ftp://people.redhat.com/mharris/testing/unstable -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From shahms at shahms.com Fri Oct 24 21:16:27 2003 From: shahms at shahms.com (Shahms King) Date: Fri, 24 Oct 2003 14:16:27 -0700 Subject: librsvg not linked correctly Message-ID: <1067030187.1278.13.camel@shahms.mesd.k12.or.us> For some reason librsvg is not linked against libcroco, meaning that nautilus crashes because of a missing symbol in librsvg-2. Everything else works because the gtk-engine and gdk-pixbuf plugins are linked against libcroco. I'm still at a loss about this one because nautilus *was* working fine until I clicked on a PNG and nautilus died. Checking ~/.xsession-errors revealed the tell-tale: nautilus: relocation error: /usr/lib/librsvg-2.so.2: undefined symbol: cr_doc_handler_new running: $ LD_PRELOAD=/usr/lib/libcroco.so.1 nautilus works as expected. I still don't know why it managed to start the first time or why it died, but I do know that ldd /usr/lib/librsvg-2.so.2.4.0 reveals no link to libcroco.so.1 (as should be expected). -- Shahms King From nphilipp at redhat.com Sat Oct 25 13:27:34 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 25 Oct 2003 15:27:34 +0200 Subject: librsvg not linked correctly In-Reply-To: <1067030187.1278.13.camel@shahms.mesd.k12.or.us> References: <1067030187.1278.13.camel@shahms.mesd.k12.or.us> Message-ID: <1067088454.30706.0.camel@wombat.tiptoe.de> On Fri, 2003-10-24 at 23:16, Shahms King wrote: > For some reason librsvg is not linked against libcroco, meaning that > nautilus crashes because of a missing symbol in librsvg-2. Everything > else works because the gtk-engine and gdk-pixbuf plugins are linked > against libcroco. I'm still at a loss about this one because nautilus > *was* working fine until I clicked on a PNG and nautilus died. Checking > ~/.xsession-errors revealed the tell-tale: > > nautilus: relocation error: /usr/lib/librsvg-2.so.2: undefined symbol: > cr_doc_handler_new > > running: > $ LD_PRELOAD=/usr/lib/libcroco.so.1 nautilus > works as expected. I still don't know why it managed to start the first > time or why it died, but I do know that ldd /usr/lib/librsvg-2.so.2.4.0 > reveals no link to libcroco.so.1 (as should be expected). Fixed in librsvg2-2.4.0-3 -- 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 ville.skytta at iki.fi Sat Oct 25 15:28:58 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 25 Oct 2003 18:28:58 +0300 Subject: Proposal to better support custom kernel modules In-Reply-To: <1066919723.16295.1.camel@edoras.local.net> References: <1066913596.19098.18.camel@pc01.wks.enertronllc.com> <1066919723.16295.1.camel@edoras.local.net> Message-ID: <1067095738.1704.140.camel@bobcat.mine.nu> On Thu, 2003-10-23 at 17:35, Jeremy Katz wrote: > /lib/modules/$(uname -r)/updates will get searched now by modutils (and > mkinitrd) when looking for a module. Also, if you're packaging, if you > have your package "Provides: kernel-modules", then it will get install > instead of upgrade behavior by default from up2date. Ah, neat. Regarding the provides, it's "kernel-modules", not "kernel-module", right? Some kernel module packages at fedora.us and probably elsewhere provide "kernel-module", based on some discussions earlier this year. No problem changing that but it would would like to be sure about the exact provides and some insurance that it won't change tomorrow :) Also, some discussion about implementing module packages which need modifications in modules.conf is at https://bugzilla.fedora.us/show_bug.cgi?id=503 in case someone's interested. From thomas.bludau at epost.de Sat Oct 25 17:01:19 2003 From: thomas.bludau at epost.de (Thomas Bludau) Date: 25 Oct 2003 19:01:19 +0200 Subject: German Translation Message-ID: <1067101279.5407.15.camel@localhost.localdomain> Hi, sorry if this is a double posting. But in Fedora beta 3 release 0.95 (Severn) i found a translation error in the Menu. Under System Configuration (Systemeinstellungen) i found "Drucke" instead of "Drucken" or "Drucker" (print, printer) Where can i told this failsure? in bugzilla.redhat.com? PS: Sorry i posted this at the first time on fedora-docs-list, that was my mistake. Best Regards Thomas Bludau From yinyang at eburg.com Sat Oct 25 22:47:34 2003 From: yinyang at eburg.com (Gordon Messmer) Date: Sat, 25 Oct 2003 15:47:34 -0700 Subject: userpasswd In-Reply-To: References: <20031024113919.A32705@devserv.devel.redhat.com> Message-ID: <3F9AFD86.9070203@eburg.com> Marcia Wilbur wrote: > In RH 9.. > userpasswd is broken > Reasons why: > > 1. shadow passwords require that etc/shadow file not be > writeable by just anyone. This means that users cannot change it. Nor can > any program run by the user. A SUID program run by the user can modify the shadow database. This is the case with the "passwd" program and "consolehelper". > 2. You cannot set the userpasswd to be setuid root because then that would > mean that any user can change any users password if they are at a terminal > that someone forgot to log out from they can change the password for that > user. userpasswd can't be SUID because it's GTK+, but it uses the program "consolehelper", which is SUID. Just because a program is SUID doesn't make it a danger to the system. In the case of both "passwd" and "consolehelper", the program is designed to allow users to modify files otherwise writable only by the root user, but only to modify their own information. In other words, they don't just allow the user to modify the file however the user wants. > 3. The userpasswd program simply assumes that the user who was trying to > change the password is the one that is running the program. Why is that wrong? It allows you to set your own password, and no one elses. That's what it's supposed to do. From jam at zoidtechnologies.com Sun Oct 26 01:42:57 2003 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Sat, 25 Oct 2003 21:42:57 -0400 Subject: German Translation In-Reply-To: <1067101279.5407.15.camel@localhost.localdomain> References: <1067101279.5407.15.camel@localhost.localdomain> Message-ID: <1067132577.27610.19.camel@eros.zoidtechnologies.com> On Sat, 2003-10-25 at 13:01, Thomas Bludau wrote: > Hi, > > sorry if this is a double posting. But in Fedora beta 3 release 0.95 > (Severn) i found a translation error in the Menu. Under System > Configuration (Systemeinstellungen) i found "Drucke" instead of > "Drucken" or "Drucker" (print, printer) > > Where can i told this failsure? in bugzilla.redhat.com? > > PS: Sorry i posted this at the first time on fedora-docs-list, that was > my mistake. > > Best Regards > Thomas Bludau > > yes, either redhat.com or fedora.us, prolly redhat.com is best. regards, J -- || Jeff MacDonald of Zoid Technologies, LLC. (MI-B7886K) || "Do not try to think outside the box. That's impossible. || Instead, realize the truth. There is no box." || url: gpg: <1024D/35172A42> -------------- 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 gemi at bluewin.ch Sun Oct 26 02:13:14 2003 From: gemi at bluewin.ch (Gerard Milmeister) Date: Sun, 26 Oct 2003 03:13:14 +0100 Subject: Making package documentation more accessible to users Message-ID: <1067134394.24829.3.camel@scriabin.tannenrauch.ch> In Gnome info and man pages are accessible using yelp. Now, a lot of packages have manuals in html, ps or pdf, usually in /usr/share/doc. These docs too should be accessible via yelp, opening the appropriate viewer if clicked. Of course, this would require a little help from the packager. Somehow a piece of documentation would have to registered. -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From ms-nospam-0306 at arcor.de Sun Oct 26 03:10:19 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 26 Oct 2003 04:10:19 +0100 Subject: German Translation In-Reply-To: <1067132577.27610.19.camel@eros.zoidtechnologies.com> References: <1067101279.5407.15.camel@localhost.localdomain> <1067132577.27610.19.camel@eros.zoidtechnologies.com> Message-ID: <20031026041019.766b48c4.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 25 Oct 2003 21:42:57 -0400, Jeff MacDonald wrote: > On Sat, 2003-10-25 at 13:01, Thomas Bludau wrote: > > Hi, > > > > sorry if this is a double posting. But in Fedora beta 3 release 0.95 > > (Severn) i found a translation error in the Menu. Under System > > Configuration (Systemeinstellungen) i found "Drucke" instead of > > "Drucken" or "Drucker" (print, printer) > > > > Where can i told this failsure? in bugzilla.redhat.com? > > > > PS: Sorry i posted this at the first time on fedora-docs-list, that was > > my mistake. > > > > Best Regards > > Thomas Bludau > > > > > > yes, either redhat.com or fedora.us, prolly redhat.com is best. Not fedora.us, because bugzilla.fedora.us is only for packages offered at fedora.us. This is still separate from the Fedora Project. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/mzsa0iMVcrivHFQRArSVAJ9ywtjUiZDZFWq5RmxdLosSbWF0VQCeKoh7 AlqLr3JUngQS5sTU79GxmmU= =FMQD -----END PGP SIGNATURE----- From jfontain at free.fr Sun Oct 26 15:04:00 2003 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 26 Oct 2003 16:04:00 +0100 Subject: why not provide Tcl/Tk 8.4? Message-ID: <3F9BE260.6000805@free.fr> Hello, I always wondered why Red Hat never upgraded to the latest stable Tcl/Tk 8.4.4 release (more performant and with bugs fixed), but instead sticks to the 8.3 series. Suse and others I believe have been using it for a while. Let me know if I can help (I make Tcl/Tk 8.4.4 rpms available on my homepage). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/m+IQkG/MMvcT1qQRAuwRAKCx8LctvjzmnyIk5VcroJPjHEFI9QCbB8Ol ptq4uW8Ut3sy6Opjuf4arDs= =hBa9 -----END PGP SIGNATURE----- -- Jean-Luc Fontaine mailto:jfontain at free.fr http://jfontain.free.fr/ From xose at wanadoo.es Sun Oct 26 16:46:48 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sun, 26 Oct 2003 17:46:48 +0100 Subject: why not provide Tcl/Tk 8.4? References: <3F9BE260.6000805@free.fr> Message-ID: <3F9BFA78.8010801@wanadoo.es> Jean-Luc Fontaine wrote: > I always wondered why Red Hat never upgraded to the latest stable Tcl/Tk > 8.4.4 release (more performant and with bugs fixed), but instead sticks > to the 8.3 series. Suse and others I believe have been using it for a > while. I filled a RFE on 2003-04-09 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88429 waiting... -- HTML mails are going to trash automatically From tmwg-fedorad at inxservices.com Sun Oct 26 17:11:30 2003 From: tmwg-fedorad at inxservices.com (George Garvey) Date: Sun, 26 Oct 2003 09:11:30 -0800 Subject: Packages RFC Message-ID: <20031026171130.GA9316@inxservices.com> For my own purposes, I'm going to package: prcs qmail distcc gcc to mingw cross-compiler fltk I doubt qmail is of interest to Fedora, but what about the others? Want them passed on? From jos at xos.nl Sun Oct 26 17:21:17 2003 From: jos at xos.nl (Jos Vos) Date: Sun, 26 Oct 2003 18:21:17 +0100 Subject: Packages RFC In-Reply-To: <20031026171130.GA9316@inxservices.com>; from tmwg-fedorad@inxservices.com on Sun, Oct 26, 2003 at 09:11:30AM -0800 References: <20031026171130.GA9316@inxservices.com> Message-ID: <20031026182117.A7716@xos037.xos.nl> On Sun, Oct 26, 2003 at 09:11:30AM -0800, George Garvey wrote: > For my own purposes, I'm going to package: > prcs > qmail > distcc > gcc to mingw cross-compiler > fltk > I doubt qmail is of interest to Fedora, but what about the others? Want > them passed on? Qmail has a non-Open Source license. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From anvil at livna.org Sun Oct 26 17:34:59 2003 From: anvil at livna.org (Dams) Date: Sun, 26 Oct 2003 18:34:59 +0100 Subject: Packages RFC In-Reply-To: <20031026171130.GA9316@inxservices.com> References: <20031026171130.GA9316@inxservices.com> Message-ID: <1067189699.15177.25.camel@localhost> If you're ever interested, fltk has been published in fedora.us some days ago. D Le dim 26/10/2003 ? 18:11, George Garvey a ?crit : > For my own purposes, I'm going to package: > prcs > qmail > distcc > gcc to mingw cross-compiler > fltk > I doubt qmail is of interest to Fedora, but what about the others? Want > them passed on? -- 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 ms-nospam-0306 at arcor.de Sun Oct 26 17:46:42 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 26 Oct 2003 18:46:42 +0100 Subject: Packages RFC In-Reply-To: <20031026171130.GA9316@inxservices.com> References: <20031026171130.GA9316@inxservices.com> Message-ID: <20031026184642.7d793a60.ms-nospam-0306@arcor.de> On Sun, 26 Oct 2003 09:11:30 -0800, George Garvey wrote: > For my own purposes, I'm going to package: > prcs > qmail > distcc > gcc to mingw cross-compiler > fltk > I doubt qmail is of interest to Fedora, but what about the others? Want > them passed on? Until Fedora Extras gets alive, FLTK has been packaged at fedora.us already. But usually there is much opportunity for team-work or taking over a package if you'd like to. Just talk to the current packager. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From icon at linux.duke.edu Sun Oct 26 17:52:16 2003 From: icon at linux.duke.edu (Konstantin Riabitsev) Date: 26 Oct 2003 12:52:16 -0500 Subject: Packages RFC In-Reply-To: <20031026182117.A7716@xos037.xos.nl> References: <20031026171130.GA9316@inxservices.com> <20031026182117.A7716@xos037.xos.nl> Message-ID: <1067190736.2328.22.camel@localhost.localdomain> On Sun, 2003-10-26 at 12:21, Jos Vos wrote: > > I doubt qmail is of interest to Fedora, but what about the others? Want > > them passed on? > > Qmail has a non-Open Source license. Allow me to add to that. The Qmail license strictly prohibits distribution of modified sources, and the same goes for binaries. This makes distribution of qmail for modern-day systems downright impossible, since Qmail does not compile at all on gcc-3.x. There is a patch that works around this problem, but, of course, one is not allowed to distribute binaries with this patch applied, so distributing legal binaries for a gcc-3 based system is therefore impossible. If this sounds nuts -- it is. (e.g. see http://linux.duke.edu/~icon/misc/qmail/debacle.html for a very lively conversation that I had with the qmail-dist list when I was looking to become a distributor myself. There are some real pearls in there). Due to its murky and restrictive license, I'm pretty sure that Qmail will never appear in Fedora Core. I myself would like to get out of distributing it, but that involves a migration effort. :) Regards, -- Konstantin Riabitsev Linux at DUKE From matt at tasonline.com Sun Oct 26 20:02:58 2003 From: matt at tasonline.com (Matt Jarjoura) Date: Sun, 26 Oct 2003 15:02:58 -0500 (EST) Subject: Packages RFC In-Reply-To: <1067190736.2328.22.camel@localhost.localdomain> References: <20031026171130.GA9316@inxservices.com> <20031026182117.A7716@xos037.xos.nl> <1067190736.2328.22.camel@localhost.localdomain> Message-ID: <2250.172.211.221.208.1067198578.squirrel@tasonline.com> Is there a way to fork QMail and make it a side project of Fedora? > On Sun, 2003-10-26 at 12:21, Jos Vos wrote: >> > I doubt qmail is of interest to Fedora, but what about the others? >> Want >> > them passed on? >> >> Qmail has a non-Open Source license. > > Allow me to add to that. The Qmail license strictly prohibits > distribution of modified sources, and the same goes for binaries. This > makes distribution of qmail for modern-day systems downright impossible, > since Qmail does not compile at all on gcc-3.x. There is a patch that > works around this problem, but, of course, one is not allowed to > distribute binaries with this patch applied, so distributing legal > binaries for a gcc-3 based system is therefore impossible. If this > sounds nuts -- it is. > > (e.g. see http://linux.duke.edu/~icon/misc/qmail/debacle.html for a very > lively conversation that I had with the qmail-dist list when I was > looking to become a distributor myself. There are some real pearls in > there). > > Due to its murky and restrictive license, I'm pretty sure that Qmail > will never appear in Fedora Core. > > I myself would like to get out of distributing it, but that involves a > migration effort. :) > > Regards, > -- > Konstantin Riabitsev > Linux at DUKE > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Matt Jarjoura From jos at xos.nl Sun Oct 26 20:15:05 2003 From: jos at xos.nl (Jos Vos) Date: Sun, 26 Oct 2003 21:15:05 +0100 Subject: Packages RFC In-Reply-To: <2250.172.211.221.208.1067198578.squirrel@tasonline.com>; from matt@tasonline.com on Sun, Oct 26, 2003 at 03:02:58PM -0500 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> Message-ID: <20031026211505.C8309@xos037.xos.nl> On Sun, Oct 26, 2003 at 03:02:58PM -0500, Matt Jarjoura wrote: > Is there a way to fork QMail and make it a side project of Fedora? License-wise: no. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From michael at koziarski.com Sun Oct 26 20:20:00 2003 From: michael at koziarski.com (Michael A. Koziarski) Date: Mon, 27 Oct 2003 09:20:00 +1300 Subject: Packages RFC In-Reply-To: <20031026211505.C8309@xos037.xos.nl> 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> Message-ID: <3F9C2C70.5070304@koziarski.com> Jos Vos wrote: > On Sun, Oct 26, 2003 at 03:02:58PM -0500, Matt Jarjoura wrote: > > >>Is there a way to fork QMail and make it a side project of Fedora? > > > License-wise: no. 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. Plus it will help people migrate to a more official fedora-core setup. Does anyone have any ideas? Cheers Koz From notting at redhat.com Sun Oct 26 20:33:05 2003 From: notting at redhat.com (Bill Nottingham) Date: Sun, 26 Oct 2003 15:33:05 -0500 Subject: Proposal to better support custom kernel modules In-Reply-To: <1067095738.1704.140.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Sat, Oct 25, 2003 at 06:28:58PM +0300 References: <1066913596.19098.18.camel@pc01.wks.enertronllc.com> <1066919723.16295.1.camel@edoras.local.net> <1067095738.1704.140.camel@bobcat.mine.nu> Message-ID: <20031026153305.A12444@devserv.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > On Thu, 2003-10-23 at 17:35, Jeremy Katz wrote: > > > /lib/modules/$(uname -r)/updates will get searched now by modutils (and > > mkinitrd) when looking for a module. Also, if you're packaging, if you > > have your package "Provides: kernel-modules", then it will get install > > instead of upgrade behavior by default from up2date. > > Ah, neat. > > Regarding the provides, it's "kernel-modules", not "kernel-module", > right? /etc/sysconfig/rhn/up2date:pkgsToInstallNotUpdate=kernel;kernel-modules; Correct. Bill From matt at tasonline.com Sun Oct 26 20:35:06 2003 From: matt at tasonline.com (Matt Jarjoura) Date: Sun, 26 Oct 2003 15:35:06 -0500 (EST) 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: <2284.172.211.221.208.1067200506.squirrel@tasonline.com> Well there exists that QMail Toaster project which forks Qmail quite a bit towards a pretty industrious email system. It's a shame that qmail is in such a mess, the source itself hasn't been updated in 2 years. *sigh* LOL, any influential people on this list who can get that Dan guy to move over to BSD or GPL license?? :-) -Matt > Jos Vos wrote: >> On Sun, Oct 26, 2003 at 03:02:58PM -0500, Matt Jarjoura wrote: >> >> >>>Is there a way to fork QMail and make it a side project of Fedora? >> >> >> License-wise: no. > > > 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. Plus it will help > people migrate to a more official fedora-core setup. > > Does anyone have any ideas? > > Cheers > > Koz > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Matt Jarjoura From f.l.f.devel-list at news.francoudi.com Sun Oct 26 20:50:36 2003 From: f.l.f.devel-list at news.francoudi.com (Leonid Mamchenkov) Date: Sun, 26 Oct 2003 20:50:36 +0000 (UTC) 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: <20031026205036.GA15871@francoudi.com> Dear "Michael A. Koziarski", Once you wrote about "Re: Packages RFC": MAK> Jos Vos wrote: MAK> >On Sun, Oct 26, 2003 at 03:02:58PM -0500, Matt Jarjoura wrote: MAK> >>Is there a way to fork QMail and make it a side project of Fedora? MAK> >License-wise: no. MAK> MAK> The qmail license situation is a bit of a mess. What would be nice is a MAK> guide to migrating to something that *can* be distributed by modern MAK> distributions. MAK> MAK> I currently have several gigabytes of my family's mail in hundreds of MAK> qmail Maildirs. An MDA that can read those as is, or can provide MAK> conversion scripts, would be greatly appreciated. Plus it will help MAK> people migrate to a more official fedora-core setup. MAK> MAK> Does anyone have any ideas? Have you looked into Exim ( http://www.exim.org ) ? -- Best regards, Leonid Mamtchenkov, RHCE System Administrator Francoudi & Stephanou Ltd. From warren at togami.com Sun Oct 26 20:54:05 2003 From: warren at togami.com (Warren Togami) Date: Sun, 26 Oct 2003 10:54:05 -1000 Subject: Packages RFC In-Reply-To: <2284.172.211.221.208.1067200506.squirrel@tasonline.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> <2284.172.211.221.208.1067200506.squirrel@tasonline.com> Message-ID: <1067201645.27503.130.camel@laptop> On Sun, 2003-10-26 at 10:35, Matt Jarjoura wrote: > Well there exists that QMail Toaster project which forks Qmail quite a bit > towards a pretty industrious email system. > > It's a shame that qmail is in such a mess, the source itself hasn't been > updated in 2 years. *sigh* > > LOL, any influential people on this list who can get that Dan guy to move > over to BSD or GPL license?? :-) > > -Matt Last I looked at qmail toaster SRPMS maybe two months ago, they were absolutely unacceptable in quality. Warren From rhldevel at assursys.co.uk Sun Oct 26 20:58:24 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Sun, 26 Oct 2003 20:58:24 +0000 (GMT) Subject: Packages RFC In-Reply-To: <1067190736.2328.22.camel@localhost.localdomain> References: <20031026171130.GA9316@inxservices.com> <20031026182117.A7716@xos037.xos.nl> <1067190736.2328.22.camel@localhost.localdomain> Message-ID: On Sun, 26 Oct 2003, Konstantin Riabitsev wrote: > On Sun, 2003-10-26 at 12:21, Jos Vos wrote: > > > I doubt qmail is of interest to Fedora, but what about the others? Want > > > them passed on? > > > > Qmail has a non-Open Source license. > > Allow me to add to that. The Qmail license strictly prohibits > distribution of modified sources, and the same goes for binaries. I believe that Debian works around this by distributing the equivalent of a src.rpm that wget's the qmail source as part of the build process. > Regards, Best Regards, Alex. From warren at togami.com Sun Oct 26 21:02:56 2003 From: warren at togami.com (Warren Togami) Date: Sun, 26 Oct 2003 11:02:56 -1000 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: <1067202176.27503.136.camel@laptop> On Sun, 2003-10-26 at 23:20, 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. Plus it will help > people migrate to a more official fedora-core setup. > > Does anyone have any ideas? All of my friends still using qmail absolutely refuse to migrate because they are using vpopmail. vpopmail itself is an abomination for packagers for several reasons, and it requires qmail for some aspect of its function. Sure it works with postfix, but it still requires qmail installed if you insist on using it with postfix. Warren From occy at occy.net Sun Oct 26 21:39:11 2003 From: occy at occy.net (Trae McCombs) Date: Sun, 26 Oct 2003 16:39:11 -0500 Subject: Open Music in Fedora Core? Message-ID: <1067204351.2212.70.camel@miami> Hi again gang... I have an interesting idea. What if we included an "Open Music" item on the FC desktop? How exactly could this work? Well, there are several ways, but two ways I can think of right off the bat are: Including songs from Open Artist: You could directly include a handful of songs from Open Artist into the Fedora Core distro. Providing download links in "Open Music" desktop folder: With this method, you could include more music, by simply pointing people to links where people can freely download said music. I guess the above begs the questions: What is Open Music? Where are these types of artist? What license would be viable in order to allow Fedora to package and ship these songs. Would linking allow for slightly less restrictive licensing. I mention it because I personally would like to make some of my music available where it could be traded and listened to. My feelings are that if people enjoy what we are doing, then they'll come to our shows, buy physical copies of our CD's, or find other ways to support us in our efforts. Another nice thing is that it would allow people to see that yes, you can have music on your Linux desktop. Thanks for your time, Trae -- Trae McCombs -- vocals, bass http://theinterference.com/ From wcooley at nakedape.cc Sun Oct 26 21:57:31 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Sun, 26 Oct 2003 13:57:31 -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: <1067205450.2209.164.camel@denk.nakedape.priv> On Mon, 2003-10-27 at 01:20, Michael A. Koziarski wrote: > 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. Plus it will help > people migrate to a more official fedora-core setup. > > Does anyone have any ideas? I believe that Postfix can deliver to Maildirs, and Dovecot can be used to access them over IMAP/POP. 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 alan at redhat.com Sun Oct 26 22:04:45 2003 From: alan at redhat.com (Alan Cox) Date: Sun, 26 Oct 2003 17:04:45 -0500 (EST) Subject: Open Music in Fedora Core? In-Reply-To: <1067204351.2212.70.camel@miami> from "Trae McCombs" at Hyd 26, 2003 04:39:11 Message-ID: <200310262204.h9QM4jO21119@devserv.devel.redhat.com> > I guess the above begs the questions: What is Open Music? Where are > these types of artist? What license would be viable in order to allow > Fedora to package and ship these songs. Would linking allow for slightly > less restrictive licensing. I'm not sure how music fits the 'computing' license view (but then I guess one could argue themes are the same kind of artistic material). > I mention it because I personally would like to make some of my music > available where it could be traded and listened to. My feelings are > that if people enjoy what we are doing, then they'll come to our shows, > buy physical copies of our CD's, or find other ways to support us in our > efforts. Sounds like freedesktop.org material. An agreed way to index, describe and find systemwide media files. The updating part is easy - you can keep music in rpm format too and yum update it. The automatic indexing for apps doesn't seem to be covered unless scrollkeeper is already happy with non document media ? Alan From behdad at cs.toronto.edu Sun Oct 26 22:24:01 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sun, 26 Oct 2003 17:24:01 -0500 Subject: Yum Feature Requests Message-ID: Hi, As Yum is very handy, it gets harder and harder as time pasts to go to the sites and download RPMs manually, so here I propose the following features. Let me know if they are already implemented / there's something wrong with them / ...: 1. Some way to install SRPMs. When you are testing a distro, it comes quite handy to install the SRPM with a single yum command when you find a bug and want to look at. 2. A way to force reinstall of a package. If by any chance I get one of my packages corrupted, the way I do right now is to rpm -e --nodeps it and then yum install. 3. A way to find out which repo contains the currently installed version of a package. It comes quite handy when you want to install SRPMs. Currently I have to guess, or go around all repos. 4. A way to downgrade a package (say for the moment, that's ok if update overrides that). On a side note: Is there any way, to keep updated on both 2.4 and 2.6 kernels? Without renaming one of the to say kernel2.6-...? behdad From m.fioretti at inwind.it Sun Oct 26 22:34:09 2003 From: m.fioretti at inwind.it (M. Fioretti) Date: Sun, 26 Oct 2003 23:34:09 +0100 Subject: Open Music in Fedora Core? In-Reply-To: <1067204351.2212.70.camel@miami> References: <1067204351.2212.70.camel@miami> Message-ID: <20031026223409.GD18234@inwind.it> On Sun, Oct 26, 2003 16:39:11 at 04:39:11PM -0500, Trae McCombs (occy at occy.net) wrote: > Hi again gang... > > I have an interesting idea. What if we included an "Open Music" item on > the FC desktop? > > Including songs from Open Artist: > You could directly include a handful of songs from Open Artist into the > Fedora Core distro. What do you mean by handful? a full music collection? This increases the distro size, unless you put it all on a separate ISO. Mixing it in the distro could also create problems like "we will not use/mirror stuff with songs offending our sensibility, religion, customs and what not" in some places. IIRC, one of the reasons to remove the fortune package was to stop complaints from people seeing (perceived or real) obscenities on their desktop. [snip] > Another nice thing is that it would allow people to see that yes, you > can have music on your Linux desktop. This can also be accomplished with entries like "CD/MP3/OGG player" and such in the menus. Mixing music collections straight into the product is one of the surest ways to guarantee that it is banned from any office desktop. Of course, including just some database of pointers to online resources, or 2/3 samples, not more, wouldn't hurt at all. Ciao, Marco Fioretti -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ If you have the right attitude, interesting problems will find you Eric S. Raymond, "The Cathedral and the bazaar", chapter 2 From tmwg-fedorad at inxservices.com Sun Oct 26 23:11:38 2003 From: tmwg-fedorad at inxservices.com (George Garvey) Date: Sun, 26 Oct 2003 15:11:38 -0800 Subject: Packages RFC In-Reply-To: <1067205450.2209.164.camel@denk.nakedape.priv> 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> <1067205450.2209.164.camel@denk.nakedape.priv> Message-ID: <20031026231137.GE9316@inxservices.com> > On Mon, 2003-10-27 at 01:20, Michael A. Koziarski wrote: > I believe that Postfix can deliver to Maildirs, and Dovecot can be used > to access them over IMAP/POP. Will Postfix handle qmail's hyphenated delivery? I personally have too many mailing lists using that feature right now. Don't want the work of switching them all over to something else. From jeremyp at pobox.com Sun Oct 26 23:38:25 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: 26 Oct 2003 18:38:25 -0500 Subject: Packages RFC In-Reply-To: <20031026231137.GE9316@inxservices.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> <1067205450.2209.164.camel@denk.nakedape.priv> <20031026231137.GE9316@inxservices.com> Message-ID: <1067211505.1133.3.camel@localhost.localdomain> On Sun, 2003-10-26 at 18:11, George Garvey wrote: > > On Mon, 2003-10-27 at 01:20, Michael A. Koziarski wrote: > > I believe that Postfix can deliver to Maildirs, and Dovecot can be used > > to access them over IMAP/POP. > > Will Postfix handle qmail's hyphenated delivery? I personally have too > many mailing lists using that feature right now. Don't want the work of > switching them all over to something else. What is hyphenated delivery? I googled and didn't find anything that seemed to make sense. (Feel free to point me to the FM.) I know that postfix can be configured to support things like jeremyp+fedora at example.com, and then deliver to the "jeremyp" mailbox so that you can sort on the To: line. Is that what you mean? --Jeremy -- /---------------------------------------------------------------------\ | Jeremy Portzer jeremyp at pobox.com trilug.org/~jeremy | | GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 | \---------------------------------------------------------------------/ From tmwg-fedorad at inxservices.com Mon Oct 27 00:38:45 2003 From: tmwg-fedorad at inxservices.com (George Garvey) Date: Sun, 26 Oct 2003 16:38:45 -0800 Subject: Packages RFC In-Reply-To: <1067211505.1133.3.camel@localhost.localdomain> 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> <1067205450.2209.164.camel@denk.nakedape.priv> <20031026231137.GE9316@inxservices.com> <1067211505.1133.3.camel@localhost.localdomain> Message-ID: <20031027003845.GF9316@inxservices.com> On Sun, Oct 26, 2003 at 06:38:25PM -0500, Jeremy Portzer wrote: > On Sun, 2003-10-26 at 18:11, George Garvey wrote: > > Will Postfix handle qmail's hyphenated delivery? I personally have too > > many mailing lists using that feature right now. Don't want the work of > > switching them all over to something else. > > What is hyphenated delivery? I googled and didn't find anything that > seemed to make sense. (Feel free to point me to the FM.) > > I know that postfix can be configured to support things like > jeremyp+fedora at example.com, and then deliver to the "jeremyp" mailbox so > that you can sort on the To: line. Is that what you mean? More or less. qmail does it with hyphens. See my from address. Believe qmail actually calls them "extension addresses." Had to look that up. Wouldn't be surprised that Postfix did it, but differently. Maybe there's compatibility in there samewhere. Will look into that when have time. All of this is pretty irrelevant. Don't expect Fedora or Redhat to ever support qmail, and can certainly understand not doing it. At the time qmail was started here, it was a better alternative than sendmail, and there weren't that many choices. From skvidal at phy.duke.edu Mon Oct 27 00:45:47 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 26 Oct 2003 19:45:47 -0500 Subject: Packages RFC In-Reply-To: <20031027003845.GF9316@inxservices.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> <1067205450.2209.164.camel@denk.nakedape.priv> <20031026231137.GE9316@inxservices.com> <1067211505.1133.3.camel@localhost.localdomain> <20031027003845.GF9316@inxservices.com> Message-ID: <1067215547.30785.4.camel@binkley> > More or less. qmail does it with hyphens. See my from address. Believe > qmail actually calls them "extension addresses." Had to look that up. > Wouldn't be surprised that Postfix did it, but differently. Maybe there's > compatibility in there samewhere. Will look into that when have time. > > All of this is pretty irrelevant. Don't expect Fedora or Redhat to ever > support qmail, and can certainly understand not doing it. At the time qmail > was started here, it was a better alternative than sendmail, and there > weren't that many choices. postfix can do this too with regexp for aliases. -sv From Nicolas.Mailhot at laPoste.net Mon Oct 27 00:46:54 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 27 Oct 2003 01:46:54 +0100 Subject: Packages RFC In-Reply-To: <1067205450.2209.164.camel@denk.nakedape.priv> 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> <1067205450.2209.164.camel@denk.nakedape.priv> Message-ID: <1067215614.2452.4.camel@m70.net81-64-235.noos.fr> Le dim 26/10/2003 ? 22:57, Wil Cooley a ?crit : > On Mon, 2003-10-27 at 01:20, Michael A. Koziarski wrote: > > > 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. Plus it will help > > people migrate to a more official fedora-core setup. > > > > Does anyone have any ideas? > > I believe that Postfix can deliver to Maildirs, and Dovecot can be used > to access them over IMAP/POP. I'm using this here (in fact fetchmail -> postfix -> procmail -> spamassassin -> maildir -> dovecot). And it's a real pleasure, much more than wu imap ever was (did you say rebuild to change a config option ?) You can skip the procmail -> spamassassin bit if you want, postfix can deliver directly to maildir. 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 wcooley at nakedape.cc Mon Oct 27 01:20:19 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Sun, 26 Oct 2003 17:20:19 -0800 Subject: Packages RFC In-Reply-To: <20031027003845.GF9316@inxservices.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> <1067205450.2209.164.camel@denk.nakedape.priv> <20031026231137.GE9316@inxservices.com> <1067211505.1133.3.camel@localhost.localdomain> <20031027003845.GF9316@inxservices.com> Message-ID: <1067217619.2209.172.camel@denk.nakedape.priv> On Sun, 2003-10-26 at 16:38, George Garvey wrote: > More or less. qmail does it with hyphens. See my from address. Believe > qmail actually calls them "extension addresses." Had to look that up. > Wouldn't be surprised that Postfix did it, but differently. Maybe there's > compatibility in there samewhere. Will look into that when have time. Yes. By default it uses '+', but it can be changed by setting 'recipient_delimiter'. 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 Nicolas.Mailhot at laPoste.net Mon Oct 27 00:50:25 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 27 Oct 2003 01:50:25 +0100 Subject: Packages RFC In-Reply-To: References: <20031026171130.GA9316@inxservices.com> <20031026182117.A7716@xos037.xos.nl> <1067190736.2328.22.camel@localhost.localdomain> Message-ID: <1067215825.2452.7.camel@m70.net81-64-235.noos.fr> Le dim 26/10/2003 ? 21:58, rhldevel at assursys.co.uk a ?crit : > On Sun, 26 Oct 2003, Konstantin Riabitsev wrote: > > > On Sun, 2003-10-26 at 12:21, Jos Vos wrote: > > > > I doubt qmail is of interest to Fedora, but what about the others? Want > > > > them passed on? > > > > > > Qmail has a non-Open Source license. > > > > Allow me to add to that. The Qmail license strictly prohibits > > distribution of modified sources, and the same goes for binaries. > > I believe that Debian works around this by distributing the equivalent of a > src.rpm that wget's the qmail source as part of the build process. Then just redistribute a src.rpm or even a nosrc.rpm only. Automated remote download during build process is plain ugly (and dangerous). 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 tmwg-fedorad at inxservices.com Mon Oct 27 02:10:35 2003 From: tmwg-fedorad at inxservices.com (George Garvey) Date: Sun, 26 Oct 2003 18:10:35 -0800 Subject: Packages RFC In-Reply-To: <1067215614.2452.4.camel@m70.net81-64-235.noos.fr> 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> <1067205450.2209.164.camel@denk.nakedape.priv> <1067215614.2452.4.camel@m70.net81-64-235.noos.fr> Message-ID: <20031027021035.GG9316@inxservices.com> I really appreciate the info about Postfix. It was very helpful. I won't be responding to anything more list mails on the subject of Postfix or qmail, though. This is really the wrong list for such things, and you've all been very gracious. From skvidal at phy.duke.edu Mon Oct 27 02:12:20 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 26 Oct 2003 21:12:20 -0500 Subject: [Yum] Yum Feature Requests In-Reply-To: References: Message-ID: <1067220739.30785.11.camel@binkley> Don't crosspost, it just makes life difficult. > 1. Some way to install SRPMs. When you are testing a distro, it > comes quite handy to install the SRPM with a single yum command > when you find a bug and want to look at. Read the yum list - If someone wants to implement this go for it. yum-arch -s indexes the src.rpms too. I have some other fish to fry before I get to this one. > 2. A way to force reinstall of a package. If by any chance I get > one of my packages corrupted, the way I do right now is to rpm -e > --nodeps it and then yum install. no. Again, read the yum list, hard and fast rule, - I won't implement --force or --nodeps. Darkness lies in that path. > 3. A way to find out which repo contains the currently installed > version of a package. It comes quite handy when you want to > install SRPMs. Currently I have to guess, or go around all > repos. so if #1 were implemented you wouldn't need this one? > 4. A way to downgrade a package (say for the moment, that's ok if > update overrides that). possibly, but not already planned. > On a side note: Is there any way, to keep updated on both 2.4 > and 2.6 kernels? Without renaming one of the to say > kernel2.6-...? not really. There the same package, two different versions, one of which is greater, how would you want it to know which sets to look for newer on? -sv From tdiehl at rogueind.com Mon Oct 27 02:42:50 2003 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 26 Oct 2003 21:42:50 -0500 (EST) Subject: Packages RFC In-Reply-To: <3F9C2C70.5070304@koziarski.com> Message-ID: On Mon, 27 Oct 2003, Michael A. Koziarski wrote: > 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. Plus it will help > people migrate to a more official fedora-core setup. > > Does anyone have any ideas? Postfix!! -- ......Tom Registered Linux User #14522 http://counter.li.org tdiehl at rogueind.com My current SpamTrap -------> mtd123 at rogueind.com From jm at jmason.org Mon Oct 27 04:09:33 2003 From: jm at jmason.org (Justin Mason) Date: Sun, 26 Oct 2003 20:09:33 -0800 Subject: why not provide Tcl/Tk 8.4? In-Reply-To: <3F9BE260.6000805@free.fr> Message-ID: <20031027040938.2896C16F12@jmason.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jean-Luc Fontaine writes: >I always wondered why Red Hat never upgraded to the latest stable Tcl/Tk >8.4.4 release (more performant and with bugs fixed), but instead sticks >to the 8.3 series. Suse and others I believe have been using it for a while. > >Let me know if I can help (I make Tcl/Tk 8.4.4 rpms available on my >homepage). Yeah -- +1 from me -- the current RH9 Tcl/Tk RPMs cause ExMH to use *massive* quantities of memory, due to some wchar_t patch Red Hat's specfile applies. ActiveTcl 8.4 -- which I use instead -- works much better, and still displays utf-8 ;) - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Exmh CVS iD8DBQE/nJp8QTcbUG5Y7woRAkvpAJ9oJNoKqwPblnjbpNRLJboozAsiawCgx+sQ SrbLfqaqKvT9GbQOMOwtNwc= =q1uo -----END PGP SIGNATURE----- From aicra at well.com Mon Oct 27 07:18:51 2003 From: aicra at well.com (Marcia Wilbur) Date: Sun, 26 Oct 2003 23:18:51 -0800 (PST) Subject: userpasswd In-Reply-To: <3F9AFD86.9070203@eburg.com> References: <20031024113919.A32705@devserv.devel.redhat.com> <3F9AFD86.9070203@eburg.com> Message-ID: On Sat, 25 Oct 2003, Gordon Messmer wrote: > Marcia Wilbur wrote: > > In RH 9.. > > userpasswd is broken > > Reasons why: > > > > 1. shadow passwords require that etc/shadow file not be > > writeable by just anyone. This means that users cannot change it. Nor can > > any program run by the user. > > A SUID program run by the user can modify the shadow database. This is > the case with the "passwd" program and "consolehelper". > ok > > 2. You cannot set the userpasswd to be setuid root because then that would > > mean that any user can change any users password if they are at a terminal > > that someone forgot to log out from they can change the password for that > > user. > > userpasswd can't be SUID because it's GTK+, but it uses the program > "consolehelper", which is SUID. Just because a program is SUID doesn't > make it a danger to the system. In the case of both "passwd" and > "consolehelper", the program is designed to allow users to modify files > otherwise writable only by the root user, but only to modify their own > information. In other words, they don't just allow the user to modify > the file however the user wants. > I see, so the consolehelper is a proxy for the password program and I'm sure probably others. > > 3. The userpasswd program simply assumes that the user who was trying to > > change the password is the one that is running the program. > > Why is that wrong? It allows you to set your own password, and no one > elses. That's what it's supposed to do. > I was assuming that the program simply accesses the file rather than feeding through a proxy. Given that, I cannot explain why I get a dialog that says unknown error. From salimma1 at yahoo.co.uk Mon Oct 27 07:58:03 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Mon, 27 Oct 2003 14:58:03 +0700 Subject: Self-Introduction: Michel Alexandre Salim Message-ID: <1067227132.6983.19.camel@bushido.localdomain> Greetings, I have been informally involved with the original Fedora Project from time to time, but have not actually submitted my complete details, so here it is.. 1. Full legal name Last name: Salim First names: Michel Alexandre 2. Address: Jakarta, Indonesia 3. Status: B.Eng in CS, aspiring graduate student 4. School: Previously with University of York, United Kingdom 5. Goals - maintaining deprecated packages like fortune-mod - packaging applets i.e. General Applet Interface toys - packaging weblog/RSS tools, e.g. PyDS, straw Willing to do QA, but might not be able to do large packages due to bandwith constraints 6. Qualifications: - beta tester for previous RH beta releases with several bug reports - packaged xmms-cdread, repackaged fortune-mod with added cookie files - familiar with Red Hat distributions (see above), Bugzilla and Python 7. GPG KEYID - B58A8357 pub 1024D/B58A8357 2002-10-10 Michel Alexandre Salim Key fingerprint = 2030 FCC0 39EF 8BB6 1518 8BAA B469 B1DE B58A 8357 uid Michel Alexandre Salim uid [jpeg image of size 2207] sub 3072g/53168D44 2002-10-10 Regards, Michel -------------- 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 Mon Oct 27 08:10:30 2003 From: nos at utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Mon, 27 Oct 2003 09:10:30 +0100 Subject: Packages RFC In-Reply-To: <7ff8cfcd000b2807d3@[192.168.170.10]> References: <7ff8cfcd000b2807d3@[192.168.170.10]> Message-ID: <1067242230.1225.2.camel@nos-rh> On Sun, 2003-10-26 at 18:11, George Garvey wrote: > For my own purposes, I'm going to package: > prcs > qmail > distcc > gcc to mingw cross-compiler > fltk > I doubt qmail is of interest to Fedora, but what about the others? Want > them passed on? Yes. But take a look at www.fedora.us. I Believe someone already packaged atleast fltk and distcc. -- 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 buildsys at porkchop.devel.redhat.com Mon Oct 27 11:46:38 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Mon, 27 Oct 2003 06:46:38 -0500 Subject: rawhide report: 20031027 changes Message-ID: <200310271146.h9RBkbh09266@porkchop.devel.redhat.com> From petersen at redhat.com Mon Oct 27 11:57:25 2003 From: petersen at redhat.com (Jens Petersen) Date: Mon, 27 Oct 2003 20:57:25 +0900 Subject: rawhide full install: xemacs-sumo-el and aspell-it In-Reply-To: <20031019100551.GC8144@puariko.nirvana> References: <20031019100551.GC8144@puariko.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> The above packages are obsoleted by xemacs-el and AT> aspell. Should they be removed from rawhide? Nice caught for xemacs-el. This is remnant from period between the previous xemacs-sumo incarnation and the present new one... should get fixed with the next xemacs build. Thanks, Jens From dawson at fnal.gov Mon Oct 27 14:32:53 2003 From: dawson at fnal.gov (Troy Dawson) Date: Mon, 27 Oct 2003 08:32:53 -0600 Subject: grubby (not grub) question In-Reply-To: <1067028935.3204.1.camel@mirkwood.devel.redhat.com> References: <3F993F3B.8050402@fnal.gov> <1067028935.3204.1.camel@mirkwood.devel.redhat.com> Message-ID: <3F9D2C95.5090701@fnal.gov> Thanks Jeremy, It's on bugzilla #108077 Jeremy Katz wrote: > On Fri, 2003-10-24 at 11:03, Troy Dawson wrote: > >>I'm having a hard time finding the right maillist and/or web pages for grubby >>(not grub). Can anyone point me to the right place? > > > fedora-devel-list or bugzilla (or here) > > >>When using grubby to add arguments to the kernel, for either lilo or grub, I >>am only able to add one instance of an item. >>My specific problem is that for a serial console, if you want to have the >>output go through both the video and serial console, you need to add >> >>console=tty0 console=ttyS0,9600n8 >> >>(ok, so you need to modify the serial part for your specific instance but >>that's not the question) >> >>grubby will only allow one instance of console= so I'm having some trouble >>using grubby to do this. > > > Hrmmm... grubby does this to change existing options without the > thought of multiple allowed of the same option. If you file something > in bugzilla, I'll look into making this behavior better. > > Cheers, > > Jeremy > > > -- > fedora-test-list mailing list > fedora-test-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-test-list -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From pauln at truemesh.com Mon Oct 27 14:54:02 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Mon, 27 Oct 2003 14:54:02 +0000 Subject: Fedora on PPC Message-ID: <20031027145352.GE5672@shitake.truemesh.com> I've got a very minimal install of Fedora on PPC (ibook2) working over the weekend. Main gotcha other than kernel packages was the mkinitrd from ppc rawhide repo required ppc64-utils - I assume that the conditional in mknitrd should be ifarch ppc64? I hope to get anaconda-runtime and anaconda on sometime this week and build iso images. Paul From mike at flyn.org Mon Oct 27 17:25:32 2003 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 27 Oct 2003 11:25:32 -0600 Subject: Fedora on PPC In-Reply-To: <20031027145352.GE5672@shitake.truemesh.com> References: <20031027145352.GE5672@shitake.truemesh.com> Message-ID: <20031027172532.GA7224@imp.flyn.org> > I've got a very minimal install of Fedora on PPC (ibook2) working over > the weekend. > > Main gotcha other than kernel packages was the mkinitrd from ppc rawhide > repo required ppc64-utils - I assume that the conditional in mknitrd > should be ifarch ppc64? > > I hope to get anaconda-runtime and anaconda on sometime this week and > build iso images. I've been working on this too. I have not attacked the anaconda/install process yet either. One thing that may interest you is a small bug report I just entered into Red Hat's bugzilla. Bug #108095 proposes a patch to initscripts that adds support for mouse-emulation on PPC (like YellowDog does). -- Mike :wq From sopwith at redhat.com Mon Oct 27 17:37:40 2003 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 27 Oct 2003 12:37:40 -0500 (EST) Subject: Fedora on PPC In-Reply-To: <20031027145352.GE5672@shitake.truemesh.com> Message-ID: On Mon, 27 Oct 2003, Paul Nasrat wrote: > I've got a very minimal install of Fedora on PPC (ibook2) working over > the weekend. > > Main gotcha other than kernel packages was the mkinitrd from ppc rawhide > repo required ppc64-utils - I assume that the conditional in mknitrd > should be ifarch ppc64? That won't work - the mkinitrd package itself is ppc (32-bit). I think probably what needs to be done is have the pmac-utils package into Fedora and have it provides: ppc64-utils. -- Elliot Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. From katzj at redhat.com Mon Oct 27 17:43:42 2003 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Oct 2003 12:43:42 -0500 Subject: Fedora on PPC In-Reply-To: <20031027145352.GE5672@shitake.truemesh.com> References: <20031027145352.GE5672@shitake.truemesh.com> Message-ID: <1067276621.21554.1.camel@mirkwood.devel.redhat.com> On Mon, 2003-10-27 at 09:54, Paul Nasrat wrote: > I hope to get anaconda-runtime and anaconda on sometime this week and > build iso images. FWIW, building second stage images and a boot.iso should work with rawhide anaconda unless I've broken something in the past few weeks. There is likely to be lurking weirdness with boot loader installation and partitioning constraints, though. Jeremy From jlaska at redhat.com Mon Oct 27 17:47:59 2003 From: jlaska at redhat.com (James A. Laska) Date: Mon, 27 Oct 2003 12:47:59 -0500 Subject: Fedora on PPC In-Reply-To: <20031027145352.GE5672@shitake.truemesh.com> References: <20031027145352.GE5672@shitake.truemesh.com> Message-ID: <1067276878.4336.8.camel@flatline.devel.redhat.com> FWI see: ftp://ftp.redhat.com/pub/redhat/linux/rawhide/ppc/Fedora anaconda-runtime includes mk-images.ppc which will create a bootable boot.iso image capable of performing installs. A Fedora PPC kernel is obviously missing, and formatting of hfs and hfs+ is not currently available. As mentioned, additional packages may need to be included into fedora, such as: nvsetenv, pbuttonsd, pmud, pmac-utils -- jlaska On Mon, 2003-10-27 at 09:54, Paul Nasrat wrote: > I've got a very minimal install of Fedora on PPC (ibook2) working over > the weekend. > > Main gotcha other than kernel packages was the mkinitrd from ppc rawhide > repo required ppc64-utils - I assume that the conditional in mknitrd > should be ifarch ppc64? > > I hope to get anaconda-runtime and anaconda on sometime this week and > build iso images. > > Paul > > > -- > 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 Mon Oct 27 19:52:48 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Mon, 27 Oct 2003 19:52:48 +0000 Subject: Fedora on PPC In-Reply-To: References: <20031027145352.GE5672@shitake.truemesh.com> Message-ID: <20031027195237.GH5672@shitake.truemesh.com> On Mon, Oct 27, 2003 at 12:37:40PM -0500, Elliot Lee wrote: > On Mon, 27 Oct 2003, Paul Nasrat wrote: > > Main gotcha other than kernel packages was the mkinitrd from ppc rawhide > > repo required ppc64-utils - I assume that the conditional in mknitrd > > should be ifarch ppc64? > > That won't work - the mkinitrd package itself is ppc (32-bit). Urgh arch vs arch/color. > I think probably what needs to be done is have the pmac-utils package into > Fedora and have it provides: ppc64-utils. Hmm, ok that's a good pointer,or should ppc64-utils provide pmac-utils, I guess it depends which is considered the special case. Paul From pauln at truemesh.com Mon Oct 27 20:00:27 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Mon, 27 Oct 2003 20:00:27 +0000 Subject: Fedora on PPC In-Reply-To: <1067276878.4336.8.camel@flatline.devel.redhat.com> References: <20031027145352.GE5672@shitake.truemesh.com> <1067276878.4336.8.camel@flatline.devel.redhat.com> Message-ID: <20031027200026.GI5672@shitake.truemesh.com> On Mon, Oct 27, 2003 at 12:47:59PM -0500, James A. Laska wrote: > FWI see: ftp://ftp.redhat.com/pub/redhat/linux/rawhide/ppc/Fedora Cheers I'd already downloaded that (plus noarch rpms from rawhide/i386/Fedora). > anaconda-runtime includes mk-images.ppc which will create a bootable > boot.iso image capable of performing installs. Yeah, I've seen that kicking about, I was hoping to just build the images from a tree on my x86 box but packageorder barfed which I think may have been due to arch scoring - but not 100% sure. > A Fedora PPC kernel is obviously missing, This will be the biggest chunk of work I feel... > and formatting of hfs and hfs+ is not currently available. OK, I might look at packaging http://www.ardistech.com/hfsplus/ as a fedora.us kernel module, although > As mentioned, additional packages may need to be included > into fedora, such as: nvsetenv, pbuttonsd, pmud, pmac-utils I'll just have to see how things go timewise :) Paul From dburcaw at terrasoftsolutions.com Tue Oct 28 00:11:47 2003 From: dburcaw at terrasoftsolutions.com (Dan Burcaw) Date: 27 Oct 2003 17:11:47 -0700 Subject: Fedora on PPC In-Reply-To: <1067276621.21554.1.camel@mirkwood.devel.redhat.com> References: <20031027145352.GE5672@shitake.truemesh.com> <1067276621.21554.1.camel@mirkwood.devel.redhat.com> Message-ID: <1067299907.1201.31.camel@localhost.localdomain> On Mon, 2003-10-27 at 10:43, Jeremy Katz wrote: > On Mon, 2003-10-27 at 09:54, Paul Nasrat wrote: > > I hope to get anaconda-runtime and anaconda on sometime this week and > > build iso images. > > FWIW, building second stage images and a boot.iso should work with > rawhide anaconda unless I've broken something in the past few weeks. > There is likely to be lurking weirdness with boot loader installation > and partitioning constraints, though. Lurking indeed. I'm planning to re-write the mac partitioning bit pretty soon, however. From michael at koziarski.com Tue Oct 28 06:03:03 2003 From: michael at koziarski.com (Michael A. Koziarski) Date: Tue, 28 Oct 2003 19:03:03 +1300 Subject: yum.conf shipped with 1.0 Message-ID: <3F9E0697.1070604@koziarski.com> Hi All, will the yum.conf shipped with Fedora Core 1.0 include entries for fedora.us? I think it's a good first step to introducing users to the idea of using yum repositories to get software. Plus it will enable software that has recently been added to fedora.us (such as gtkmm2) to provide simple installation instructions. I realise that the proper merger of fedora.us and fedora core is still a way off, but I believe that this would be an excellent first step. Any comments? Cheers Koz From warren at togami.com Tue Oct 28 06:23:02 2003 From: warren at togami.com (Warren Togami) Date: Mon, 27 Oct 2003 20:23:02 -1000 Subject: yum.conf shipped with 1.0 In-Reply-To: <3F9E0697.1070604@koziarski.com> References: <3F9E0697.1070604@koziarski.com> Message-ID: <3F9E0B46.9070606@togami.com> Michael A. Koziarski wrote: > Hi All, > > will the yum.conf shipped with Fedora Core 1.0 include entries for > fedora.us? I think it's a good first step to introducing users to the > idea of using yum repositories to get software. In theory I would agree with you, but there are several large obstacles that hinder this, the main being too much bandwidth usage for the mirror pointed by the default yum.conf. There there were a GUI/TUI mirror selection tool that people were forced to use prior to their first yum, that wouldn't be a problem. There are other large obstacles, but I will let the others speak of them. For now, I would highly advise spreading word of fedora.us repositories and other helpful 3rd party repositories. Our tools and infrastructure are not ready for the entire world. http://www.fedora.us/wiki/FedoraMirrorList While on the subject, if you currently use download.fedora.us, please change your apt/yum configuration and choose a nearer mirror. I *know* there are closer mirrors to everybody than Hawaii. Warren Togami warren at togami.com From mattharrison at sbcglobal.net Tue Oct 28 06:34:05 2003 From: mattharrison at sbcglobal.net (Matt Jones) Date: Mon, 27 Oct 2003 22:34:05 -0800 Subject: krb5-libs & krb5-devel Message-ID: <1067322845.30180.23.camel@localhost.localdomain> Hi - I upgraded from redhat 9 to rawhide a while back, and everything has been going fine. Except, krb5-libs and -devel have been showing up in my un-upgradable apt-get upgrade list for some time. Whenever I attempt to install them my system gets hosed (it tries to uninstall nearly everthing). Everything that depends on krb5-libs works, but nothing that depends on it to compile can compile (i get all kinds of missing symbols). If I manually upgrade (rpm -Uvh --force --nodeps krb5-libs.rpm krb5-devel.rpm) the system dies (rpm stops working etc.). I don't want to go through a complete reinstall again,so I wanted to ask the list first - is it possible to parallel install krb5-libs 1.2.8-4 and the newest version? Will programs that depend on either break? All of the packages depend upon libcom_err.so.3, but all I can find mention of is libcom_err.so.2 (.3 is provided by krb5-libs 1.2.8-4, .2 is provided by 1.3.1-6) Should I just reinstall from rawhide (from scratch) and hope it all goes away? (everything else is up-to-date as of this point in time) Thanks -- matt -------------- 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 Tue Oct 28 09:00:13 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 28 Oct 2003 10:00:13 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <3F9E0B46.9070606@togami.com> References: <3F9E0697.1070604@koziarski.com> <3F9E0B46.9070606@togami.com> Message-ID: <1067331613.2867.1.camel@ulysse.olympe.o2t> Le mar 28/10/2003 ? 07:23, Warren Togami a ?crit : > Michael A. Koziarski wrote: > > Hi All, > > > > will the yum.conf shipped with Fedora Core 1.0 include entries for > > fedora.us? I think it's a good first step to introducing users to the > > idea of using yum repositories to get software. > > In theory I would agree with you, but there are several large obstacles > that hinder this, the main being too much bandwidth usage for the mirror > pointed by the default yum.conf. There there were a GUI/TUI mirror > selection tool that people were forced to use prior to their first yum, > that wouldn't be a problem. If yum could handle a large mirror list all by itself that wouldn't be a problem. Better fix yum than add a gui/tui bandaid. 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 Tue Oct 28 10:07:11 2003 From: alan at redhat.com (Alan Cox) Date: Tue, 28 Oct 2003 05:07:11 -0500 (EST) Subject: yum.conf shipped with 1.0 In-Reply-To: <3F9E0B46.9070606@togami.com> from "Warren Togami" at Hyd 27, 2003 08:23:02 Message-ID: <200310281007.h9SA7BU01531@devserv.devel.redhat.com> > For now, I would highly advise spreading word of fedora.us repositories > and other helpful 3rd party repositories. Our tools and infrastructure > are not ready for the entire world. I'm still pondering whether yum is only half of the answer or whether an infrastructure built around bt would be better. Something like update-daemon queries DNS to get a TXT value to the 'current' bittorrent seed set (DNS is a nice scalable mechanism to distribute the regularly queried info) Use bt to sync the seed set and get an archive of current .hdr files, using the old one as the start point. Work out which packages are needed (Could skip this bit if you were caching for a collection of your own boxes) Map them to bt urls/seeds by a fixed algorithm Bittorrent those Sit around for a little while helping uplink packages Sleep Back to start From davej at redhat.com Tue Oct 28 10:53:04 2003 From: davej at redhat.com (Dave Jones) Date: Tue, 28 Oct 2003 10:53:04 +0000 Subject: yum.conf shipped with 1.0 In-Reply-To: <200310281007.h9SA7BU01531@devserv.devel.redhat.com> References: <3F9E0B46.9070606@togami.com> <200310281007.h9SA7BU01531@devserv.devel.redhat.com> Message-ID: <20031028105304.GC8541@redhat.com> On Tue, Oct 28, 2003 at 05:07:11AM -0500, Alan Cox wrote: > update-daemon queries DNS to get a TXT value to the 'current' > bittorrent seed set (DNS is a nice scalable > mechanism to distribute the regularly queried info) + check gpg signature of signed TXT ? Would this be sufficient against the possibilities of DNS poisoning? Dave From seyman at wanadoo.fr Tue Oct 28 11:48:42 2003 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Tue, 28 Oct 2003 12:48:42 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <3F9E0B46.9070606@togami.com> References: <3F9E0697.1070604@koziarski.com> <3F9E0B46.9070606@togami.com> Message-ID: <20031028114842.GA30607@orient.maison> On Mon, Oct 27, 2003 at 08:23:02PM -1000, Warren Togami wrote: > > In theory I would agree with you, but there are several large obstacles > that hinder this, the main being too much bandwidth usage for the mirror > pointed by the default yum.conf. There there were a GUI/TUI mirror Isn't possible to redirect everybody to their appropriate mirror? CPAN and the php download page both do this. Emmanuel From buildsys at porkchop.devel.redhat.com Tue Oct 28 11:59:30 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Tue, 28 Oct 2003 06:59:30 -0500 Subject: rawhide report: 20031028 changes Message-ID: <200310281159.h9SBxUX09073@porkchop.devel.redhat.com> From Nicolas.Mailhot at laposte.net Tue Oct 28 12:03:36 2003 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 28 Oct 2003 13:03:36 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <20031028114842.GA30607@orient.maison> References: <3F9E0697.1070604@koziarski.com> <3F9E0B46.9070606@togami.com> <20031028114842.GA30607@orient.maison> Message-ID: <1067342615.6820.1.camel@ulysse.olympe.o2t> Le mar 28/10/2003 ? 12:48, Emmanuel Seyman a ?crit : > On Mon, Oct 27, 2003 at 08:23:02PM -1000, Warren Togami wrote: > > > > In theory I would agree with you, but there are several large obstacles > > that hinder this, the main being too much bandwidth usage for the mirror > > pointed by the default yum.conf. There there were a GUI/TUI mirror > > Isn't possible to redirect everybody to their appropriate mirror? > CPAN and the php download page both do this. This won't ever work with local mirrors, and anyway the download manager has more info than the master site so it can select a better mirror all by itself given someone writes the code. 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 rezso at rdsor.ro Tue Oct 28 12:29:37 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Tue, 28 Oct 2003 14:29:37 +0200 Subject: rawhide report: 20031028 changes [empty ?] In-Reply-To: <200310281159.h9SBxUX09073@porkchop.devel.redhat.com> References: <200310281159.h9SBxUX09073@porkchop.devel.redhat.com> Message-ID: <200310281429.37236.rezso@rdsor.ro> On Tuesday 28 October 2003 13:59, Build System wrote: report empty ?!? again ? Yesterday 26->27 report was empty too but XFree86-4.3.0-42 was appeared in rawhide as 27 Oct. If i am wrong please corect me. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From ferry at silverback.nl Tue Oct 28 12:38:36 2003 From: ferry at silverback.nl (F.A. Miejndert) Date: Tue, 28 Oct 2003 13:38:36 +0100 Subject: rawhide report: 20031028 changes [empty ?] In-Reply-To: <200310281429.37236.rezso@rdsor.ro> References: <200310281159.h9SBxUX09073@porkchop.devel.redhat.com> <200310281429.37236.rezso@rdsor.ro> Message-ID: <1067344716.6334.4.camel@smirnoff.silverback.nl> Hi I don't think you are wrong i noticed the same thing yesterday. Ferry On Tue, 2003-10-28 at 13:29, Balint Cristian wrote: > On Tuesday 28 October 2003 13:59, Build System wrote: > > report empty ?!? > again ? > > > Yesterday 26->27 report was empty too but XFree86-4.3.0-42 was appeared in rawhide as 27 Oct. > > If i am wrong please corect me. > > > > -- > > 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 -------------- 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 matthias at rpmforge.net Tue Oct 28 13:04:33 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Tue, 28 Oct 2003 14:04:33 +0100 Subject: Fedora on PPC In-Reply-To: <1067299907.1201.31.camel@localhost.localdomain> References: <20031027145352.GE5672@shitake.truemesh.com> <1067276621.21554.1.camel@mirkwood.devel.redhat.com> <1067299907.1201.31.camel@localhost.localdomain> Message-ID: <20031028140433.7b36395c.matthias@rpmforge.net> Dan Burcaw wrote : > On Mon, 2003-10-27 at 10:43, Jeremy Katz wrote: > > On Mon, 2003-10-27 at 09:54, Paul Nasrat wrote: > > > I hope to get anaconda-runtime and anaconda on sometime this week and > > > build iso images. > > > > FWIW, building second stage images and a boot.iso should work with > > rawhide anaconda unless I've broken something in the past few weeks. > > There is likely to be lurking weirdness with boot loader installation > > and partitioning constraints, though. > > Lurking indeed. I'm planning to re-write the mac partitioning bit pretty > soon, however. Great the read that Dan! Seems like the right choice to get better general ppc support, and more precisely Macintosh support, directly in the "upstream" community project :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 0.95 (Severn) - Linux kernel 2.4.22-20.1.2024.2.36.nptl Load : 0.21 0.15 0.20 From salimma1 at yahoo.co.uk Tue Oct 28 13:08:48 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Tue, 28 Oct 2003 20:08:48 +0700 Subject: krb5-libs & krb5-devel In-Reply-To: <1067322845.30180.23.camel@localhost.localdomain> References: <1067322845.30180.23.camel@localhost.localdomain> Message-ID: <1067346528.16819.82.camel@bushido.localdomain> On Tue, 2003-10-28 at 13:34, Matt Jones wrote: [snip] > Should I just reinstall from rawhide (from scratch) and hope it all goes > away? (everything else is up-to-date as of this point in time) > You could install Fedora Test3; or you could wait until Monday when Fedora Core 1.0 should be released :) And yes, I still remember recently downloading Test3. But with XFree fixed, and Test3 being much nicer than RH9 was, it is not too soon. Regards, - Michel From kaboom at gatech.edu Tue Oct 28 14:06:28 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Tue, 28 Oct 2003 09:06:28 -0500 (EST) Subject: yum.conf shipped with 1.0 In-Reply-To: <20031028105304.GC8541@redhat.com> References: <3F9E0B46.9070606@togami.com> <200310281007.h9SA7BU01531@devserv.devel.redhat.com> <20031028105304.GC8541@redhat.com> Message-ID: On Tue, 28 Oct 2003, Dave Jones wrote: > On Tue, Oct 28, 2003 at 05:07:11AM -0500, Alan Cox wrote: > > > update-daemon queries DNS to get a TXT value to the 'current' > > bittorrent seed set (DNS is a nice scalable > > mechanism to distribute the regularly queried info) > > + check gpg signature of signed TXT ? > > Would this be sufficient against the possibilities of DNS poisoning? As long as packages themselves are always signed, DNS attacks don't really matter, since Trojans will be caught anyway later, chris who's well aware that packages aren't always signed, however ;-) From matt at tasonline.com Tue Oct 28 14:13:55 2003 From: matt at tasonline.com (Matt Jarjoura) Date: Tue, 28 Oct 2003 09:13:55 -0500 (EST) Subject: Fedora on PPC In-Reply-To: <20031028140433.7b36395c.matthias@rpmforge.net> References: <20031027145352.GE5672@shitake.truemesh.com><1067276621.21554.1.camel@mirkwood.devel.redhat.com><1067299907.1201.31.camel@localhost.localdomain> <20031028140433.7b36395c.matthias@rpmforge.net> Message-ID: <50809.130.85.216.138.1067350435.squirrel@tasonline.com> What about Yellow Dog Linux?! They have been supplying PPC RedHat for years now. My next impression is that it would be very easy to merge the modifications from YDL to Fedora. -Matt > Dan Burcaw wrote : > >> On Mon, 2003-10-27 at 10:43, Jeremy Katz wrote: >> > On Mon, 2003-10-27 at 09:54, Paul Nasrat wrote: >> > > I hope to get anaconda-runtime and anaconda on sometime this week >> and >> > > build iso images. >> > >> > FWIW, building second stage images and a boot.iso should work with >> > rawhide anaconda unless I've broken something in the past few weeks. >> > There is likely to be lurking weirdness with boot loader installation >> > and partitioning constraints, though. >> >> Lurking indeed. I'm planning to re-write the mac partitioning bit pretty >> soon, however. > > Great the read that Dan! Seems like the right choice to get better general > ppc support, and more precisely Macintosh support, directly in the > "upstream" community project :-) > > Matthias > > -- > Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ > Fedora Core release 0.95 (Severn) - Linux kernel > 2.4.22-20.1.2024.2.36.nptl > Load : 0.21 0.15 0.20 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Matt Jarjoura From matt at tasonline.com Tue Oct 28 14:13:55 2003 From: matt at tasonline.com (Matt Jarjoura) Date: Tue, 28 Oct 2003 09:13:55 -0500 (EST) Subject: Fedora on PPC In-Reply-To: <20031028140433.7b36395c.matthias@rpmforge.net> References: <20031027145352.GE5672@shitake.truemesh.com><1067276621.21554.1.camel@mirkwood.devel.redhat.com><1067299907.1201.31.camel@localhost.localdomain> <20031028140433.7b36395c.matthias@rpmforge.net> Message-ID: <50809.130.85.216.138.1067350435.squirrel@tasonline.com> What about Yellow Dog Linux?! They have been supplying PPC RedHat for years now. My next impression is that it would be very easy to merge the modifications from YDL to Fedora. -Matt > Dan Burcaw wrote : > >> On Mon, 2003-10-27 at 10:43, Jeremy Katz wrote: >> > On Mon, 2003-10-27 at 09:54, Paul Nasrat wrote: >> > > I hope to get anaconda-runtime and anaconda on sometime this week >> and >> > > build iso images. >> > >> > FWIW, building second stage images and a boot.iso should work with >> > rawhide anaconda unless I've broken something in the past few weeks. >> > There is likely to be lurking weirdness with boot loader installation >> > and partitioning constraints, though. >> >> Lurking indeed. I'm planning to re-write the mac partitioning bit pretty >> soon, however. > > Great the read that Dan! Seems like the right choice to get better general > ppc support, and more precisely Macintosh support, directly in the > "upstream" community project :-) > > Matthias > > -- > Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ > Fedora Core release 0.95 (Severn) - Linux kernel > 2.4.22-20.1.2024.2.36.nptl > Load : 0.21 0.15 0.20 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Matt Jarjoura From ted at cypress.com Tue Oct 28 14:38:44 2003 From: ted at cypress.com (Thomas Dodd) Date: Tue, 28 Oct 2003 08:38:44 -0600 Subject: yum.conf shipped with 1.0 In-Reply-To: <200310281007.h9SA7BU01531@devserv.devel.redhat.com> References: <200310281007.h9SA7BU01531@devserv.devel.redhat.com> Message-ID: <3F9E7F74.4030205@cypress.com> Alan Cox wrote: >>For now, I would highly advise spreading word of fedora.us repositories >>and other helpful 3rd party repositories. Our tools and infrastructure >>are not ready for the entire world. > > > I'm still pondering whether yum is only half of the answer or whether an > infrastructure built around bt would be better. Something like Interesting idea. > Bittorrent those > > Sit around for a little while helping uplink > packages How would that help those of use behind a firewall without configuration privileges? Does bit torrent support some sort of tunneling? Would it even be usefull to do so? If you have to go through a 3rd machine, I don't see any real benifit to my machine being in the mix. -Thomas From pauln at truemesh.com Tue Oct 28 14:58:02 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 28 Oct 2003 14:58:02 +0000 Subject: Fedora on PPC In-Reply-To: <50809.130.85.216.138.1067350435.squirrel@tasonline.com> References: <20031028140433.7b36395c.matthias@rpmforge.net> <50809.130.85.216.138.1067350435.squirrel@tasonline.com> Message-ID: <20031028145801.GR5672@shitake.truemesh.com> On Tue, Oct 28, 2003 at 09:13:55AM -0500, Matt Jarjoura wrote: > What about Yellow Dog Linux?! They have been supplying PPC RedHat for > years now. My next impression is that it would be very easy to merge the > modifications from YDL to Fedora. Indeed - I believe Dan knows YDL v. well, and has been supplying patches to anaconda, etc for ppc compatibility. As lots of development will go on in rawhide, more people running ppc rawhide will benefit both Fedora and YDL, so everyone should be happy. Rawhide seems more active than ruffpack. I'm sure a lot of FC 1 will go into YDL, and I wouldn't want to duplicate work - in fact installing/bootstrapping was extremely easy thanks to the work of Terrasoft and the fact that rawhide has been building for ppc. Once I got up2date installed I've happily got gnome working (I manually configured XF86Config from other sources). Paul From balister at vt.edu Tue Oct 28 15:34:18 2003 From: balister at vt.edu (Philip Balister) Date: Tue, 28 Oct 2003 10:34:18 -0500 Subject: Rawhide updates Message-ID: <20031028153418.GC9425@nemesis.maddog.net> Is there anyway way to get an idea of what has changed (changelog wise) in rawhide over the past couple of days? Philip From delmonico at gmx.net Tue Oct 28 15:51:09 2003 From: delmonico at gmx.net (Christoph Neuroth) Date: Tue, 28 Oct 2003 16:51:09 +0100 Subject: Rawhide updates In-Reply-To: <20031028153418.GC9425@nemesis.maddog.net> References: <20031028153418.GC9425@nemesis.maddog.net> Message-ID: <20031028165109.602b9b66.delmonico@gmx.net> On Tue, 28 Oct 2003 10:34:18 -0500 Philip Balister wrote: > Is there anyway way to get an idea of what has changed (changelog wise) in > rawhide over the past couple of days? There is a automatically generated (?) thread named "Rawhide report: changings" on this mailing list every day. Just look at the archive on the redhat-website to get the information of the last days. regards, -- Christoph 'delmonico' Neuroth Fighting for peace is like fucking for virginity! "What we do in life, echoes in Eternity..." [Russell Crowe as Maximus in Gladiator] From balister at vt.edu Tue Oct 28 16:20:39 2003 From: balister at vt.edu (Philip Balister) Date: Tue, 28 Oct 2003 11:20:39 -0500 Subject: Rawhide updates In-Reply-To: <20031028165109.602b9b66.delmonico@gmx.net> References: <20031028153418.GC9425@nemesis.maddog.net> <20031028165109.602b9b66.delmonico@gmx.net> Message-ID: <20031028162039.GD9425@nemesis.maddog.net> Um, this is the blank one we have received for the past coupe of days. I've been rooting around bugzilla. Is there a good search to use to get this information? Philip On Tue, Oct 28, 2003 at 04:51:09PM +0100, Christoph Neuroth wrote: > On Tue, 28 Oct 2003 10:34:18 -0500 > Philip Balister wrote: > > > Is there anyway way to get an idea of what has changed (changelog wise) in > > rawhide over the past couple of days? > > There is a automatically generated (?) thread named "Rawhide report: changings" on this mailing list every day. Just look at the archive on the redhat-website to get the information of the last days. > > regards, > -- > Christoph 'delmonico' Neuroth > > Fighting for peace is like fucking for virginity! > "What we do in life, echoes in Eternity..." [Russell Crowe as Maximus in Gladiator] > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From janina at rednote.net Tue Oct 28 17:00:22 2003 From: janina at rednote.net (Janina Sajka) Date: Tue, 28 Oct 2003 12:00:22 -0500 Subject: Vector-based Fedora Logo Available? In-Reply-To: <3F96AF11.4000407@redhat.com> References: <20031022160026.2750.49323.Mailman@listman.back-rdu.redhat.com> <3F96AD4F.9070603@silverorange.com> <3F96AF11.4000407@redhat.com> Message-ID: <20031028170022.GG22946@rednote.net> Garrett LeSage writes: > From: Garrett LeSage > > Steven Garrity wrote: > > >> From: "Ricky Boone" > >> Probably a really stupid question..., but will > >> there be a version of the (final) Fedora logo as > >> a vector-based image, in a format like EPS, SVG, etc? > > > >I apologize if this question has been answered elsewhere - but I was > >wondering if there is a public repository for the artwork in general - > >vector/bitmap-originals of the bluecurve graphics, etc. > > > Not yet. It is something to definitely consider though... (: Well, I will confess that I don't know much about EPS. However, SVG has the advantage, from where I sit, of having been designed from the ground up to support accessibility. http://www.w3.org/TR/SVG-access/ > > Garrett > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka Email: janina at rednote.net Phone: (202) 408-8175 Director, Technology Research and Development American Foundation for the Blind (AFB) http://www.afb.org Chair, Accessibility Work Group Free Standards Group http://accessibility.freestandards.org From nutello at sweetness.com Tue Oct 28 17:30:51 2003 From: nutello at sweetness.com (Rudi Chiarito) Date: Tue, 28 Oct 2003 18:30:51 +0100 Subject: Rawhide updates In-Reply-To: <20031028162039.GD9425@nemesis.maddog.net> References: <20031028153418.GC9425@nemesis.maddog.net> <20031028165109.602b9b66.delmonico@gmx.net> <20031028162039.GD9425@nemesis.maddog.net> Message-ID: <20031028173051.GA10370@server4.8080.it> On Tue, Oct 28, 2003 at 11:20:39AM -0500, Philip Balister wrote: > Um, this is the blank one we have received for the past coupe of days. > > I've been rooting around bugzilla. Is there a good search to use to get this > information? I wrote this script a long ago to show the changelog for a bunch of packages: http://uberh4x0r.org/~yax/rpm/scripts/changelogs I have a cleaner and improved version on one of my systems that I should upload soon (it uses bash arrays, etc.). You can provide names of package files or already installed packages. Every package changelog is introduced by a line such as *** zlib-1.2.0.7-2 < zlib-1.1.4-8 (package file version < installed package version) or *** zlib-1.1.4-8 (installed package version) The output is automatically redirected to less, which highlights the lines containing package version numbers. Press n and N to go back and forth between packages (entering your own search string will disrupt this, search again for ^\*\*\*.* to restore it). It's quicker to just try the script instead of having me describe it. If you use e.g. autoupdate, grab the latest updates, then just issue (files that do not end in .rpm are ignored): changelogs /var/spool/autoupdate/* Of course the script won't be of much help if you haven't downloaded the packages yet and need the changelog in advance. Rudi From veillard at redhat.com Tue Oct 28 17:36:18 2003 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 28 Oct 2003 12:36:18 -0500 Subject: yum.conf shipped with 1.0 In-Reply-To: <200310281007.h9SA7BU01531@devserv.devel.redhat.com>; from alan@redhat.com on Tue, Oct 28, 2003 at 05:07:11AM -0500 References: <3F9E0B46.9070606@togami.com> <200310281007.h9SA7BU01531@devserv.devel.redhat.com> Message-ID: <20031028123617.E23901@redhat.com> On Tue, Oct 28, 2003 at 05:07:11AM -0500, Alan Cox wrote: > > For now, I would highly advise spreading word of fedora.us repositories > > and other helpful 3rd party repositories. Our tools and infrastructure > > are not ready for the entire world. > > I'm still pondering whether yum is only half of the answer or whether an > infrastructure built around bt would be better. Something like > > > update-daemon queries DNS to get a TXT value to the 'current' > bittorrent seed set (DNS is a nice scalable > mechanism to distribute the regularly queried info) > > Use bt to sync the seed set and get an archive of > current .hdr files, using the old one as the start > point. Hum, do you suggest having all the .hdr on all the clients ? That sounds excessive to me. If not, then that mean that you would need a set of seeds, and considering the size of a .hdr and how bittorrent only really work well for large content (isn't the base BitTorrent chunk 1MByte ?) I don't really see how BT really fit the bill. But this looks good for repositories (except they would not limit themselves to the headers but the full packages). Another point is that the repository metadata evolves gradually, I am not sure BitTorrent act on a versionned or delta way when operating on a set, probably but I wonder how this would interfere with the change of the seed. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From jkeating at j2solutions.net Tue Oct 28 17:37:24 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 28 Oct 2003 09:37:24 -0800 Subject: Fedora on PPC In-Reply-To: <50809.130.85.216.138.1067350435.squirrel@tasonline.com> References: <20031027145352.GE5672@shitake.truemesh.com> <20031028140433.7b36395c.matthias@rpmforge.net> <50809.130.85.216.138.1067350435.squirrel@tasonline.com> Message-ID: <200310280937.24146.jkeating@j2solutions.net> On Tuesday 28 October 2003 06:13, Matt Jarjoura wrote: > What about Yellow Dog Linux?! They have been supplying PPC RedHat > for years now. My next impression is that it would be very easy to > merge the modifications from YDL to Fedora. Since YellowDog is a commercial product, and not freely available, I'm not so sure how keen they'd be on putting any bits into FC. Of course, I have absolutely no affiliation with the YD folks, and I have no clue what their motives are. I just know that I haven't touched their product yet. Can't justify the $$ (; -- 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 Nicolas.Mailhot at laPoste.net Tue Oct 28 18:07:12 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 28 Oct 2003 19:07:12 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <20031028123617.E23901@redhat.com> References: <3F9E0B46.9070606@togami.com> <200310281007.h9SA7BU01531@devserv.devel.redhat.com> <20031028123617.E23901@redhat.com> Message-ID: <1067364432.5898.3.camel@m70.net81-64-235.noos.fr> Le mar 28/10/2003 ? 18:36, Daniel Veillard a ?crit : > On Tue, Oct 28, 2003 at 05:07:11AM -0500, Alan Cox wrote: > > > For now, I would highly advise spreading word of fedora.us repositories > > > and other helpful 3rd party repositories. Our tools and infrastructure > > > are not ready for the entire world. > > > > I'm still pondering whether yum is only half of the answer or whether an > > infrastructure built around bt would be better. Something like > > > > > > update-daemon queries DNS to get a TXT value to the 'current' > > bittorrent seed set (DNS is a nice scalable > > mechanism to distribute the regularly queried info) How would a local mirror be managed in this system ? Setting up repository mirrors should not be made overly difficult, else all small edge mirrors disappear. (basically a mirror requirement should stay a ftp/http server with something responsible for getting the original packages/hdr/indexes on the file server. No local reindexing, no dns, just a stupid file server + wget cron) 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 jmcdermo at redhat.com Tue Oct 28 18:12:05 2003 From: jmcdermo at redhat.com (James McDermott) Date: 28 Oct 2003 13:12:05 -0500 Subject: Fedora on PPC In-Reply-To: <200310280937.24146.jkeating@j2solutions.net> References: <20031027145352.GE5672@shitake.truemesh.com> <20031028140433.7b36395c.matthias@rpmforge.net> <50809.130.85.216.138.1067350435.squirrel@tasonline.com> <200310280937.24146.jkeating@j2solutions.net> Message-ID: <1067364725.4321.127.camel@dhcp59-231.rdu.redhat.com> Yellow dog is available for free download at www.linuxiso.org additionally they had a message on their site a while back saying they were basically rebuilding the Red Hat Linux and adding their bits. Dont know if that helps...or if they have changed their messaging since then... (7.2 timeframe I think? ) Heres the link to the isos for download: http://www.linuxiso.org/distro.php?distro=12 On Tue, 2003-10-28 at 12:37, Jesse Keating wrote: > On Tuesday 28 October 2003 06:13, Matt Jarjoura wrote: > > What about Yellow Dog Linux?! They have been supplying PPC RedHat > > for years now. My next impression is that it would be very easy to > > merge the modifications from YDL to Fedora. > > Since YellowDog is a commercial product, and not freely available, I'm > not so sure how keen they'd be on putting any bits into FC. Of course, > I have absolutely no affiliation with the YD folks, and I have no clue > what their motives are. I just know that I haven't touched their > product yet. Can't justify the $$ (; From alan at redhat.com Tue Oct 28 18:14:15 2003 From: alan at redhat.com (Alan Cox) Date: Tue, 28 Oct 2003 13:14:15 -0500 (EST) Subject: yum.conf shipped with 1.0 In-Reply-To: <1067364432.5898.3.camel@m70.net81-64-235.noos.fr> from "Nicolas Mailhot" at Hyd 28, 2003 07:07:12 Message-ID: <200310281814.h9SIEFS19499@devserv.devel.redhat.com> > > > update-daemon queries DNS to get a TXT value to the 'current' > > > bittorrent seed set (DNS is a nice scalable=20 > > > mechanism to distribute the regularly queried info) > > How would a local mirror be managed in this system ? > Setting up repository mirrors should not be made overly difficult, else > all small edge mirrors disappear. If you are pushing updates between users by bittorrent you don't need mirrors although if you wanted you could use bittorrent to populate ftp/http mirrors too From alan at redhat.com Tue Oct 28 18:17:15 2003 From: alan at redhat.com (Alan Cox) Date: Tue, 28 Oct 2003 13:17:15 -0500 (EST) Subject: yum.conf shipped with 1.0 In-Reply-To: <20031028123617.E23901@redhat.com> from "Daniel Veillard" at Hyd 28, 2003 12:36:18 Message-ID: <200310281817.h9SIHFt21260@devserv.devel.redhat.com> > > Use bt to sync the seed set and get an archive of > > current .hdr files, using the old one as the start > > point. > > Hum, do you suggest having all the .hdr on all the clients ? That sounds Thats pretty much what you have now with up2date. Disk is cheap. You have all the base .hdr's from the install. > Another point is that the repository metadata evolves gradually, I am not sure > BitTorrent act on a versionned or delta way when operating on a set, probably > but I wonder how this would interfere with the change of the seed. If you start bt with a file that some segment has changed on then it thinks its restarting froma partial run so fills it in. If segments move its screwed up. That means a single hdr archive which simply grows on the end as errata should be ok as I understand it - and in part the idea relies on this. From veillard at redhat.com Tue Oct 28 18:27:31 2003 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 28 Oct 2003 13:27:31 -0500 Subject: yum.conf shipped with 1.0 In-Reply-To: <200310281817.h9SIHFt21260@devserv.devel.redhat.com>; from alan@redhat.com on Tue, Oct 28, 2003 at 01:17:15PM -0500 References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> Message-ID: <20031028132731.H23901@redhat.com> On Tue, Oct 28, 2003 at 01:17:15PM -0500, Alan Cox wrote: > > > Use bt to sync the seed set and get an archive of > > > current .hdr files, using the old one as the start > > > point. > > > > Hum, do you suggest having all the .hdr on all the clients ? That sounds > > Thats pretty much what you have now with up2date. Disk is cheap. You have > all the base .hdr's from the install. that sounds a bit extreme to me. I'm not sure that this behaviour is really needed, this might be true, but so far I'm not convinced that up2date fetching all the headers doesn't qualify as a bug rather than a feature. > > Another point is that the repository metadata evolves gradually, I am not sure > > BitTorrent act on a versionned or delta way when operating on a set, probably > > but I wonder how this would interfere with the change of the seed. > > If you start bt with a file that some segment has changed on then it thinks > its restarting froma partial run so fills it in. If segments move its > screwed up. That means a single hdr archive which simply grows on the end > as errata should be ok as I understand it - and in part the idea relies > on this. Well my question was more about the fact that the set will evolves with removal and additions in an incremental fashion. Assuming that the seed get regenerated for the torrent encapsulating the set of files, will BT check the fiels individually for idempotence and avoid a full transfert, in practice it would mean that a delta mechanism is available and regenerating seeds at each repository update (and if making sure yum-arch doesn't change the headers.info files at each run) would bring an easy large scale replication mechanism easilly. But I'm not sure we should propagate that to all the leaves. Disk ain't that cheap, and I hate when the /var of my systems gets full. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From dburcaw at terrasoftsolutions.com Tue Oct 28 18:30:54 2003 From: dburcaw at terrasoftsolutions.com (Dan Burcaw) Date: 28 Oct 2003 11:30:54 -0700 Subject: Fedora on PPC In-Reply-To: <200310280937.24146.jkeating@j2solutions.net> References: <20031027145352.GE5672@shitake.truemesh.com> <20031028140433.7b36395c.matthias@rpmforge.net> <50809.130.85.216.138.1067350435.squirrel@tasonline.com> <200310280937.24146.jkeating@j2solutions.net> Message-ID: <1067365853.1201.52.camel@localhost.localdomain> On Tue, 2003-10-28 at 10:37, Jesse Keating wrote: > On Tuesday 28 October 2003 06:13, Matt Jarjoura wrote: > > What about Yellow Dog Linux?! They have been supplying PPC RedHat > > for years now. My next impression is that it would be very easy to > > merge the modifications from YDL to Fedora. > > Since YellowDog is a commercial product, and not freely available, I'm > not so sure how keen they'd be on putting any bits into FC. Of course, > I have absolutely no affiliation with the YD folks, and I have no clue > what their motives are. I just know that I haven't touched their > product yet. Can't justify the $$ (; It's a good point. My conclusion is that we'll tend to send things upstream as much as possible and that Fedora ought to help make our job easier. That said, supporting us is really vital to continued, active, and continuous improvement of the PPC Linux platform. It is *not* a lucrative business, so literally every set of CD helps. Even if you want to run "stock" Fedora on your iBook instead of YDL, sending a few bucks our way, certainly helps keep things rolling. Regards, Dan From dburcaw at terrasoftsolutions.com Tue Oct 28 18:32:06 2003 From: dburcaw at terrasoftsolutions.com (Dan Burcaw) Date: 28 Oct 2003 11:32:06 -0700 Subject: Fedora on PPC In-Reply-To: <1067364725.4321.127.camel@dhcp59-231.rdu.redhat.com> References: <20031027145352.GE5672@shitake.truemesh.com> <20031028140433.7b36395c.matthias@rpmforge.net> <50809.130.85.216.138.1067350435.squirrel@tasonline.com> <200310280937.24146.jkeating@j2solutions.net> <1067364725.4321.127.camel@dhcp59-231.rdu.redhat.com> Message-ID: <1067365926.22889.56.camel@localhost.localdomain> On Tue, 2003-10-28 at 11:12, James McDermott wrote: > Yellow dog is available for free download at www.linuxiso.org > additionally they had a message on their site a while back saying they > were basically rebuilding the Red Hat Linux and adding their bits. Dont > know if that helps...or if they have changed their messaging since > then... (7.2 timeframe I think? ) > Heres the link to the isos for download: > > http://www.linuxiso.org/distro.php?distro=12 Basically the same today. We like Red Hat. It just happens that Red Hat doesn't have an official product on our platform of choice (minus IBM hardware). ISOs are also at: ftp://ftp.yellowdoglinux.com/pub/yellowdog/ Regards, Dan From Nicolas.Mailhot at laPoste.net Tue Oct 28 18:38:37 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 28 Oct 2003 19:38:37 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <200310281814.h9SIEFS19499@devserv.devel.redhat.com> References: <200310281814.h9SIEFS19499@devserv.devel.redhat.com> Message-ID: <1067366317.5898.11.camel@m70.net81-64-235.noos.fr> Le mar 28/10/2003 ? 19:14, Alan Cox a ?crit : > > > > update-daemon queries DNS to get a TXT value to the 'current' > > > > bittorrent seed set (DNS is a nice scalable=20 > > > > mechanism to distribute the regularly queried info) > > > > How would a local mirror be managed in this system ? > > Setting up repository mirrors should not be made overly difficult, else > > all small edge mirrors disappear. > > If you are pushing updates between users by bittorrent you don't need > mirrors although if you wanted you could use bittorrent to populate > ftp/http mirrors too You need them if you're behind a fw or if your link is too busy during the day (voip) so you must get the packages at night, but updates are performed by humans during the day (rawhide syncs, install of new packages, etc) Or else if you have a shitty isp and want to have a local cache so you can continue to operate when the link goes down. I'm not saying your solution is bad, just that it doesn't cover the whole problem space. Whatever the solution is local network caches are part of 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 skvidal at phy.duke.edu Tue Oct 28 21:08:52 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 28 Oct 2003 16:08:52 -0500 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067331613.2867.1.camel@ulysse.olympe.o2t> References: <3F9E0697.1070604@koziarski.com> <3F9E0B46.9070606@togami.com> <1067331613.2867.1.camel@ulysse.olympe.o2t> Message-ID: <1067375331.24390.63.camel@opus> > If yum could handle a large mirror list all by itself that wouldn't be a > problem. Better fix yum than add a gui/tui bandaid. Why can't it handle a mirror list now? just use multiple baseurls in each repo stanza. It will go from mirror to mirror, if failovermethod=roundrobin then it select one at random, first. -sv From Nicolas.Mailhot at laPoste.net Tue Oct 28 21:58:50 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 28 Oct 2003 22:58:50 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067375331.24390.63.camel@opus> References: <3F9E0697.1070604@koziarski.com> <3F9E0B46.9070606@togami.com> <1067331613.2867.1.camel@ulysse.olympe.o2t> <1067375331.24390.63.camel@opus> Message-ID: <1067378330.4700.0.camel@m70.net81-64-235.noos.fr> Le mar 28/10/2003 ? 22:08, seth vidal a ?crit : > > If yum could handle a large mirror list all by itself that wouldn't be a > > problem. Better fix yum than add a gui/tui bandaid. > > > Why can't it handle a mirror list now? > > just use multiple baseurls in each repo stanza. It will go from mirror > to mirror, if failovermethod=roundrobin then it select one at random, > first. Random is a pretty poor euristic:( 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 Tue Oct 28 22:03:30 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 28 Oct 2003 17:03:30 -0500 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067378330.4700.0.camel@m70.net81-64-235.noos.fr> References: <3F9E0697.1070604@koziarski.com> <3F9E0B46.9070606@togami.com> <1067331613.2867.1.camel@ulysse.olympe.o2t> <1067375331.24390.63.camel@opus> <1067378330.4700.0.camel@m70.net81-64-235.noos.fr> Message-ID: <1067378610.24390.74.camel@opus> On Tue, 2003-10-28 at 16:58, Nicolas Mailhot wrote: > Le mar 28/10/2003 ? 22:08, seth vidal a ?crit : > > > If yum could handle a large mirror list all by itself that wouldn't be a > > > problem. Better fix yum than add a gui/tui bandaid. > > > > > > Why can't it handle a mirror list now? > > > > just use multiple baseurls in each repo stanza. It will go from mirror > > to mirror, if failovermethod=roundrobin then it select one at random, > > first. > > Random is a pretty poor euristic:( for the first time it is run, how would you want them to be selected? You can use priority and it will go through them in order, but that's not BETTER for the first time it is run. at some level the user should have some involvement in what mirrors are better for them. -sv From notting at redhat.com Tue Oct 28 22:39:17 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 28 Oct 2003 17:39:17 -0500 Subject: Rawhide updates In-Reply-To: <20031028162039.GD9425@nemesis.maddog.net>; from balister@vt.edu on Tue, Oct 28, 2003 at 11:20:39AM -0500 References: <20031028153418.GC9425@nemesis.maddog.net> <20031028165109.602b9b66.delmonico@gmx.net> <20031028162039.GD9425@nemesis.maddog.net> Message-ID: <20031028173917.E27539@devserv.devel.redhat.com> Philip Balister (balister at vt.edu) said: > Um, this is the blank one we have received for the past coupe of days. Yeah, I think I broke it with the re-org (it's sort of sensitive to the tree layout :) ). I'll look at it later today. Bill From wcooley at nakedape.cc Tue Oct 28 23:10:29 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Tue, 28 Oct 2003 15:10:29 -0800 Subject: yum.conf shipped with 1.0 In-Reply-To: <20031028132731.H23901@redhat.com> References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> <20031028132731.H23901@redhat.com> Message-ID: <1067382628.11086.92.camel@denk.nakedape.priv> On Tue, 2003-10-28 at 10:27, Daniel Veillard wrote: > > Thats pretty much what you have now with up2date. Disk is cheap. You have > > all the base .hdr's from the install. > > that sounds a bit extreme to me. I'm not sure that this behaviour is really > needed, this might be true, but so far I'm not convinced that up2date fetching > all the headers doesn't qualify as a bug rather than a feature. Isn't this just how Yum works generally to handle dependecy resolution? Isn't it analogous to the repository info that apt uses? 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 Nicolas.Mailhot at laPoste.net Tue Oct 28 23:25:14 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 29 Oct 2003 00:25:14 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067382628.11086.92.camel@denk.nakedape.priv> References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> <20031028132731.H23901@redhat.com> <1067382628.11086.92.camel@denk.nakedape.priv> Message-ID: <1067383514.3302.6.camel@m70.net81-64-235.noos.fr> Le mer 29/10/2003 ? 00:10, Wil Cooley a ?crit : > On Tue, 2003-10-28 at 10:27, Daniel Veillard wrote: > > > Thats pretty much what you have now with up2date. Disk is cheap. You have > > > all the base .hdr's from the install. > > > > that sounds a bit extreme to me. I'm not sure that this behaviour is really > > needed, this might be true, but so far I'm not convinced that up2date fetching > > all the headers doesn't qualify as a bug rather than a feature. > > Isn't this just how Yum works generally to handle dependecy resolution? > Isn't it analogous to the repository info that apt uses? apt is very different with multiple sources (apt is *fast*). I'll trust yum dependency engine over apt's any day, but the fact is pulling hdrs instead of pulling apt indexes from the same set of sources (ie using repositories that do both apt & yum) makes one want to cry. apt indexes are lighter, apt does parallel checks, etc 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 Tue Oct 28 22:29:46 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 28 Oct 2003 23:29:46 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067378610.24390.74.camel@opus> References: <3F9E0697.1070604@koziarski.com> <3F9E0B46.9070606@togami.com> <1067331613.2867.1.camel@ulysse.olympe.o2t> <1067375331.24390.63.camel@opus> <1067378330.4700.0.camel@m70.net81-64-235.noos.fr> <1067378610.24390.74.camel@opus> Message-ID: <1067380186.4933.15.camel@m70.net81-64-235.noos.fr> Le mar 28/10/2003 ? 23:03, seth vidal a ?crit : > On Tue, 2003-10-28 at 16:58, Nicolas Mailhot wrote: > > Le mar 28/10/2003 ? 22:08, seth vidal a ?crit : > > > > If yum could handle a large mirror list all by itself that wouldn't be a > > > > problem. Better fix yum than add a gui/tui bandaid. > > > > > > > > > Why can't it handle a mirror list now? > > > > > > just use multiple baseurls in each repo stanza. It will go from mirror > > > to mirror, if failovermethod=roundrobin then it select one at random, > > > first. > > > > Random is a pretty poor euristic:( > > for the first time it is run, how would you want them to be selected? Response time (will catch close mirrors at least) ? Anyway the first time is difficult to get right - people that actually choose mirrors do so based on their past history, so that's what yum should do - scan all at first, collect stats, and get better choosing mirrors over time. > at some level the user should have some involvement in what mirrors are > better for them. Very often, the user does not care or does not have info enough. Whatever checks the user is supposed to do right now, a preogram can do too (except this url is prettier/easier to type rules, but do we need them ;) Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From michael at koziarski.com Tue Oct 28 23:46:57 2003 From: michael at koziarski.com (Michael A. Koziarski) Date: Wed, 29 Oct 2003 12:46:57 +1300 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067380186.4933.15.camel@m70.net81-64-235.noos.fr> References: <3F9E0697.1070604@koziarski.com> <3F9E0B46.9070606@togami.com> <1067331613.2867.1.camel@ulysse.olympe.o2t> <1067375331.24390.63.camel@opus> <1067378330.4700.0.camel@m70.net81-64-235.noos.fr> <1067378610.24390.74.camel@opus> <1067380186.4933.15.camel@m70.net81-64-235.noos.fr> Message-ID: <3F9EFFF1.8020104@koziarski.com> > Very often, the user does not care or does not have info enough. > Whatever checks the user is supposed to do right now, a preogram can do > too. This is not always true. I am charged less for bandwidth within New Zealand. How is the program meant to know that? My gentoo server uses an NZ portage mirror and this works well, however mirrorselect reports an australian one as being the fastest and won't let me choose another. Any tool to automatically select mirrors will *have* to let the user override its selection. That's not to say it can't default the selections, even hide them in a 'view selected mirror' pop-up. But I need to be able to change it. Admittedly, I'll be in the minority here, most people can just choose their mirror. Cheers Koz From aph.p at online.fr Wed Oct 29 00:07:37 2003 From: aph.p at online.fr (Alain) Date: Wed, 29 Oct 2003 01:07:37 +0100 Subject: Translation in French Message-ID: <1067386057.8146.16.camel@nyarlathotep.fedora> Hello, We'd like to create a website and a mailing list in french about Fedora. Is there anyone who has already began to translate it ? How can we manage: should we make an indipendant site or send you the translated pages ? (We already have a spaceweb for this : fedora.tuxfamily.org) Friendly yours. Colette and Alain. -------------- 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 seyman at wanadoo.fr Wed Oct 29 00:28:50 2003 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Wed, 29 Oct 2003 01:28:50 +0100 Subject: Translation in French In-Reply-To: <1067386057.8146.16.camel@nyarlathotep.fedora> References: <1067386057.8146.16.camel@nyarlathotep.fedora> Message-ID: <20031029002850.GA1439@orient.maison> On Wed, Oct 29, 2003 at 01:07:37AM +0100, Alain wrote: > > We'd like to create a website and a mailing list in french about Fedora. > Is there anyone who has already began to translate it ? Translation belongs to the documentation sub-project so you'll probably be better off sending an email to fedora-docs-list at redhat.com . > How can we manage: should we make an indipendant site or send you the > translated pages ? (We already have a spaceweb for this : > fedora.tuxfamily.org) The Traduc association coordinates translation projects for Gnome, KDE, the LDP and others (mozilla?). You might want to ask their advice. Emmanuel From salimma1 at yahoo.co.uk Wed Oct 29 03:11:54 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Wed, 29 Oct 2003 10:11:54 +0700 Subject: krb5-libs & krb5-devel In-Reply-To: <1067322845.30180.23.camel@localhost.localdomain> References: <1067322845.30180.23.camel@localhost.localdomain> Message-ID: <1067397114.8255.8.camel@bushido.localdomain> On Tue, 2003-10-28 at 13:34, Matt Jones wrote: > Hi - > I upgraded from redhat 9 to rawhide a while back, and everything has > been going fine. Except, krb5-libs and -devel have been showing up in my > un-upgradable apt-get upgrade list for some time. Whenever I attempt to > install them my system gets hosed (it tries to uninstall nearly > everthing). Everything that depends on krb5-libs works, but nothing that > depends on it to compile can compile (i get all kinds of missing > symbols). It occured to me afterwards - have you tried apt-get dist-upgrade? It's meant for situations like this. - Michel From salimma1 at yahoo.co.uk Wed Oct 29 03:23:22 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Wed, 29 Oct 2003 10:23:22 +0700 Subject: Rawhide updates In-Reply-To: <20031028153418.GC9425@nemesis.maddog.net> References: <20031028153418.GC9425@nemesis.maddog.net> Message-ID: <1067397802.8255.10.camel@bushido.localdomain> On Tue, 2003-10-28 at 22:34, Philip Balister wrote: > Is there anyway way to get an idea of what has changed (changelog wise) in > rawhide over the past couple of days? > > Philip > Something like this? http://rpmfind.net/linux/RPM/rawhide/1.0/i386/ByDate.html It's even available as an RDF channel. I used to use fr.rpmfind.net and fr2.rpmfind.net but they are rather flaky these days. - Michel From skvidal at phy.duke.edu Wed Oct 29 03:22:50 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 28 Oct 2003 22:22:50 -0500 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067383514.3302.6.camel@m70.net81-64-235.noos.fr> References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> <20031028132731.H23901@redhat.com> <1067382628.11086.92.camel@denk.nakedape.priv> <1067383514.3302.6.camel@m70.net81-64-235.noos.fr> Message-ID: <1067397769.3522.21.camel@binkley> > apt is very different with multiple sources (apt is *fast*). I'll trust > yum dependency engine over apt's any day, but the fact is pulling hdrs > instead of pulling apt indexes from the same set of sources (ie using > repositories that do both apt & yum) makes one want to cry. the first time downloading all the headers takes a while, but after that, provided you're not updating against a constantly rolling repository, you shouldn't have to download all that much, only the changes. Against rawhide headers don't work as well, but against a stable + updates configuration (which is the most common imo) the headers aren't shabby. the current rawhide configuration is also a pain b/c it's one repository for all archs, so you have to stew through a lot of crap. There is work being done to change how these things are handled in the future and to make the format for the metadata more extensible than either the yum or current apt metadata formats. -sv From warren at togami.com Wed Oct 29 05:04:52 2003 From: warren at togami.com (Warren Togami) Date: Tue, 28 Oct 2003 19:04:52 -1000 Subject: OSSNET - Proposal for Swarming Data Propagation Message-ID: <3F9F4A74.9010107@togami.com> (Alan Cox mentioned a theoretical idea for bittorrent in data propagation for yum... so this seemed like the most appropriate time to post this again. Comments would be greatly welcomed.) OSSNET Proposal October 28, 2003 Warren Togami The following describes my proposal for the "OSSNET" swarming data propagation network. This was originally posted to mirror-list-d during April 2003. This proposal has been cleaned up a bit and amended. Unified Namespace ================= This can be shared with all Open Source projects and distributions. Imagine this type of unified namespace for theoretical protocol "ossnet". ossnet://%{publisher}/path/to/data Where %{publisher} is the vendor or project's master tracker. The client finds it with standard DNS. Examples: ossnet://swarm.redhat.com/linux/fedora/1/en/iso/i386/ ossnet://ossnet.kernel.org/pub/linux/kernel/ ossnet://swarm.openoffice.org/stable/1.2beta/ ossnet://central.debian.org/dists/woody/ ossnet://swarm.k12ltsp.org/3.1.1/ ossnet://master.mozilla.org/mozilla1.7/ Each project tracker has their own official data source with the entire repository GPG signed for automatic ossnet client verification. Phase 1 - Swarming for Mirrors only =================================== Initial implementation would be something like rsync, except swarming like bittorrent and used only for mirror propagation. It may need encryption, some kind of access control, and tracking in order to prevent intrusion, i.e. hold new release secret until release day. (This paragraph below about access control and encryption was written after the release of RH9, and the failure of "Easy ISO" early access due to bandwidth overloading and bittorrent. In the new Fedora episteme this access control stuff may actually not be needed anymore. We can perhaps implement OSSNET without it at first.) I believe access control can be done with the central tracker (i.e. Red Hat) generating public/private keys, and giving the public key to the mirror maintainers. Each mirror maintainer would choose which directories they want to permanently mirror, and which to exclude. Each mirror server that communicates with another mirror would first need to verify identity with the master tracker somehow. If somebody leaks before a release, they can be punished by revoking their key, then the master tracker and other mirrors will reject them. Even without the encryption/authorization part this would be powerful. This would make mirror propagation far faster while dramatically reducing load on the master mirror. Huge money savings for the data publisher... but it gets better. Phase 2 - Swarming clients for users ==================================== I was also thinking about end-user swarming clients. up2date, apt or yum could integrate this functionality, and this would work well because they already maintain local caches. The protocol described above would need to behave differently for end-users in several ways. Other than the package manager tools, a simple "wget" like program would be best for ISO downloads. Unauthenticated clients could join the swarm with upload turned off by default and encryption turned off (reduce server CPU usage). Most users don't want to upload, and that's okay because the Linux mirrors are always swarming outgoing data. Clients can optionally turn on upload, set an upload rate cap, and specify network subnets where uploading is allowed. This would allow clients within an organization to act as caches for each other, or a network administrator could setup a client running as a swarm cache server uploading only to the LAN, saving tons of ISP bandwidth. A DSL/cable modem ISP would be easy to convince to setup their own cache server to efficiently serve their customers. This is because setting up a server can be done quickly & unofficially. Clients joining the swarm would greatly complicate things because the protocol would need to know about "nearby" nodes, like your nearest swarming mirror or your LAN cache server. This may need to be a configuration option for end-user clients. These clients would need to make more intelligent use of nearby caches rather than randomly swarm packets from hosts over the ISP link. The (bittorrent) protocol would need to be changed to allow "leeching" under certain conditions without returning packets to the network. Much additional thought would be needed in these design considerations. Region Complication =================== Due to higher costs of intercontinental bandwidth, or commodity Internet over I2 cost within America, we may need to implement a "cost table" system that calculates best near-nodes taking bandwidth cost into account. Perhaps this may somehow use dedicated "alternate master trackers" within each cost region, for example Australia, which are GPG identified by the master tracker as being authoritative for the entire region. Then end-user clients that connect to the master tracker are immediately told about their nearer regional tracker. Possible Multicasting ===================== This isn't required, but multicasting could be utilized in addition to unicast in order to more efficiently seed the larger and more connected worldwide mirrors. Multicast would significantly increase the complexity of network router setup and software complexity, so I am not advocating this be worked on until the rest of the system is mplemented. Possible Benefits? ================== * STATISTICS! As BitTorrent has demonstrated, end-user downloads could possibily be tracked and counted. It would be fairly easy to standardize data collection in this type of system. Today we have no realistic way to collect download data from many mirrors due to the setup hassles and many different types of servers. Imagine how useful package download frequency data would be. We would have a real idea of what software people are using, and possibly use that data to guage where QA should be focused to better and make users/customers happier. * Unified namespace! Users never have a need to find mirrors anymore, although optionally setting cache addresses would help it be faster and more efficient. * Public mirrors (even unofficial) can easily setup and shutdown at any time. Immediately after going online they will join the swarm and begin contributing packets to the world. THAT is an unprecedented and amazing ability. The server maintainer can set an upload cap so it never kills their network. For example, businesses or schools could increase their upload cap during periods of low activity (like night?) and contribute to the world. The only difference between an official and unofficial mirror would be unofficial cannot download or serve access controlled data since they are not cryptographically identified by the master tracker. Any client (client == mirror) can choose what data they want to serve, and what they do not want to serve. * Automatic failover: If your nearest or preferred mirror is down, as long as you can still reach the master tracker you can still download from the swarm. * Most of everything I described above is ALREADY WRITTEN AND PROVEN CONCEPTS in existing Open Source implementations like bittorrent (closest in features), freenet (unified namespace) and swarmcast (progenitor?). I think the access control and dynamic update mechanism has been implemented yet. bittorrent may be a good point to start development from since it is written in python ... although scalability may be a factor with python, so a C rewrite may be needed. (?) FAQ === 1. This idea sucks, I don't want to upload! RTFM! This proposal says that clients have upload DISABLED by default. 2. This idea sucks, I don't want to upload to other people! RTTM! In this proposal you can set your mirror to upload only to certain subnets, at certain set upload rate caps. 3. Wont this plan fail for clients behind NAT? Incoming TCP sessions are only needed if you upload to the swarm, as other clients connect to you. Uploading is DISABLED by default Downloading only requires outgoing TCP connections. 4. What if outgoing connections on high ports are disallowed? Then you are SOL, unless we implement a "proxy" mode. Your LAN can have a single proxy mirror that serves only your local network, and downloading your requests on your behalf. Conclusion ========== Just imagine how much of a benefit this would be to the entire Open Source community! Never again would anyone need to find mirrors. Simply point ossnet compatible clients to the unified namespace URI, and it *just works*. We could make a libossnet library, and easily extend existing programs like wget, curl, Mozilla, galeon, or Konqueror to browse this namespace. This is an AWESOME example of legitimate use of P2P, and far easier to police abuse than traditional illegal use of P2P clients. Data publishers need to run a publically accessible tracker and must be held legally accountable. This is more like a web server with legal content and millions of worldwide proxy caches. In any case the web server would be held accountable for the legality of their content. That is how this differs from Freenet which uses encryption everywhere and is decentralized. Freenet can be used for both good and evil, while ossnet can only sustainably used for good, because normal law enforcement can easily locate and (rightly) prosecute offenders. This is existing copyright law, how it was meant to be used. If this idea became reality, we could point to this glowing example of legitimate P2P as a weapon to fight RIAA/MPAA interests. I hope I can work on this project one day. This could be world changing... and sure would be a fun to develop. Maybe Red Hat could develop this, in cooperation with other community benefactors of such an awesome distribution system. Comments? =) Warren Togami warren at togami.com p.s. Time to short Akamai stock. From Axel.Thimm at physik.fu-berlin.de Wed Oct 29 08:15:00 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 29 Oct 2003 09:15:00 +0100 Subject: kernel to be backported to RH7.3-RH9? Message-ID: <20031029081500.GB28194@puariko.nirvana> The current rawhide kernels have some compatibility bits (like %{sevenexcompat}). Will the Fedora Core kernel be used for RHL errata (with deactivating nptl/exec-shield where appropriate)? -- 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 alan at redhat.com Wed Oct 29 08:29:53 2003 From: alan at redhat.com (Alan Cox) Date: Wed, 29 Oct 2003 03:29:53 -0500 (EST) Subject: OSSNET - Proposal for Swarming Data Propagation In-Reply-To: <3F9F4A74.9010107@togami.com> from "Warren Togami" at Hyd 28, 2003 07:04:52 Message-ID: <200310290829.h9T8Trs26336@devserv.devel.redhat.com> > FAQ > === > 1. This idea sucks, I don't want to upload! > RTFM! This proposal says that clients have upload DISABLED by default. Makes it hard to scale well. I was I admit thinking the reverse - if you don't upload you get very little. Economic motivations and all that. > Comments? =) Within a company it could also be very useful as a read only fs, where each inode is a torrent. Pull files from random clients not always from the NFS server 8) From barryn at pobox.com Wed Oct 29 08:45:06 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Wed, 29 Oct 2003 00:45:06 -0800 Subject: kernel to be backported to RH7.3-RH9? In-Reply-To: <20031029081500.GB28194@puariko.nirvana> References: <20031029081500.GB28194@puariko.nirvana> Message-ID: <20031029084506.GB26100@ip68-4-255-84.oc.oc.cox.net> On Wed, Oct 29, 2003 at 09:15:00AM +0100, Axel Thimm wrote: > The current rawhide kernels have some compatibility bits (like > %{sevenexcompat}). > > Will the Fedora Core kernel be used for RHL errata (with deactivating > nptl/exec-shield where appropriate)? AFAIR Red Hat did backporting with the 7.3, 8.0 and 9 kernels, so I would guess the answer is yes. -Barry K. Nathan From Nicolas.Mailhot at laPoste.net Wed Oct 29 08:51:14 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 29 Oct 2003 09:51:14 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <3F9EFFF1.8020104@koziarski.com> References: <3F9E0697.1070604@koziarski.com> <3F9E0B46.9070606@togami.com> <1067331613.2867.1.camel@ulysse.olympe.o2t> <1067375331.24390.63.camel@opus> <1067378330.4700.0.camel@m70.net81-64-235.noos.fr> <1067378610.24390.74.camel@opus> <1067380186.4933.15.camel@m70.net81-64-235.noos.fr> <3F9EFFF1.8020104@koziarski.com> Message-ID: <1067417474.2796.1.camel@ulysse.olympe.o2t> Le mer 29/10/2003 ? 00:46, Michael A. Koziarski a ?crit : > > Very often, the user does not care or does not have info enough. > > Whatever checks the user is supposed to do right now, a preogram can do > > too. > > This is not always true. > > I am charged less for bandwidth within New Zealand. How is the program > meant to know that? > > My gentoo server uses an NZ portage mirror and this works well, however > mirrorselect reports an australian one as being the fastest and won't > let me choose another. Any tool to automatically select mirrors will > *have* to let the user override its selection. > > That's not to say it can't default the selections, even hide them in a > 'view selected mirror' pop-up. But I need to be able to change it. > > Admittedly, I'll be in the minority here, most people can just choose > their mirror. can not you mean... Anyway sure there is room for ntp-like "prefer" overrides, but they should not be the 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 pros-n-cons at bak.rr.com Wed Oct 29 08:58:52 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Wed, 29 Oct 2003 00:58:52 -0800 Subject: OSSNET - Proposal for Swarming Data Propagation In-Reply-To: <3F9F4A74.9010107@togami.com> References: <3F9F4A74.9010107@togami.com> Message-ID: <20031029005852.4ee51385.pros-n-cons@bak.rr.com> On Tue, 28 Oct 2003 19:04:52 -1000 Warren Togami wrote: > (Alan Cox mentioned a theoretical idea for bittorrent in data > propagation for yum... so this seemed like the most appropriate time to > post this again. Comments would be greatly welcomed.) > > > OSSNET Proposal > October 28, 2003 > Warren Togami > --- SNIP --- All of this sounds excellent except for small files, If I grab a 1 MB file from bit-torrent, the time it takes to sync the servers is slower then it would take to download. Speed doesn't usually pick up till you're a few minutes into a d/l so for clients I'm not sure how usefull this would be seeing as most updates are tiny with exception to the obvious monsters. Maybe limits could be written in. If a file size is less then two megs its a direct download and for larger files this new 'yumtode' app could kick in. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From salimma1 at yahoo.co.uk Wed Oct 29 09:09:45 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Wed, 29 Oct 2003 16:09:45 +0700 Subject: OSSNET - Proposal for Swarming Data Propagation In-Reply-To: <200310290829.h9T8Trs26336@devserv.devel.redhat.com> References: <200310290829.h9T8Trs26336@devserv.devel.redhat.com> Message-ID: <1067418585.13376.4.camel@bushido.localdomain> On Wed, 2003-10-29 at 15:29, Alan Cox wrote: > > FAQ > > === > > 1. This idea sucks, I don't want to upload! > > RTFM! This proposal says that clients have upload DISABLED by default. > > Makes it hard to scale well. I was I admit thinking the reverse - if you > don't upload you get very little. Economic motivations and all that. > Force the user to configure the client program if no existing configuration is found? Uploading could be enabled/disabled as seems fit; within a company, for instance, the subnet restriction etc. could be programmed into their default configuration file that is used by all clients. - Michel From Nicolas.Mailhot at laPoste.net Wed Oct 29 08:17:09 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 29 Oct 2003 09:17:09 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067397769.3522.21.camel@binkley> References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> <20031028132731.H23901@redhat.com> <1067382628.11086.92.camel@denk.nakedape.priv> <1067383514.3302.6.camel@m70.net81-64-235.noos.fr> <1067397769.3522.21.camel@binkley> Message-ID: <1067415429.6947.0.camel@m70.net81-64-235.noos.fr> Le mer 29/10/2003 ? 04:22, seth vidal a ?crit : > > apt is very different with multiple sources (apt is *fast*). I'll trust > > yum dependency engine over apt's any day, but the fact is pulling hdrs > > instead of pulling apt indexes from the same set of sources (ie using > > repositories that do both apt & yum) makes one want to cry. > > the first time downloading all the headers takes a while, but after > that, provided you're not updating against a constantly rolling > repository, you shouldn't have to download all that much, only the > changes. I am using constantly rolling rawhide-like repositories:( -- 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 warren at togami.com Wed Oct 29 09:21:15 2003 From: warren at togami.com (Warren Togami) Date: Tue, 28 Oct 2003 23:21:15 -1000 Subject: OSSNET - Proposal for Swarming Data Propagation In-Reply-To: <200310290829.h9T8Trs26336@devserv.devel.redhat.com> References: <200310290829.h9T8Trs26336@devserv.devel.redhat.com> Message-ID: <3F9F868B.3000004@togami.com> Alan Cox wrote: >>FAQ >>=== >>1. This idea sucks, I don't want to upload! >>RTFM! This proposal says that clients have upload DISABLED by default. > > > Makes it hard to scale well. I was I admit thinking the reverse - if you > don't upload you get very little. Economic motivations and all that. Perhaps, but it still scales better than the one-to-one client to server model that we currently have. And unlike current BitTorrent where most traffic is supplied by tiny uplinks of asymmetric links, OSSNET is seeded by MONSTER bandwidth from hundreds of dedicated mirrors around the world, plus your local cable/DSL OSSNET cache server. > > >>Comments? =) > > > Within a company it could also be very useful as a read only fs, where > each inode is a torrent. Pull files from random clients not always from the > NFS server 8) > Um... =) Warren From Frederic.Hornain at GB.BE Wed Oct 29 10:12:08 2003 From: Frederic.Hornain at GB.BE (=?iso-8859-1?Q?Hornain_Fr=E9d=E9ric?=) Date: Wed, 29 Oct 2003 11:12:08 +0100 Subject: Date and Time Configuration Tool man page translation Message-ID: Hi, This the man page of the Date and Time Configuration Tool translated in french. I will as soon as possible do the same with the help html file. Keep me in touch if you need something else to translated in french. <> Best regards Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: redhat-config-date.8 Type: application/octet-stream Size: 873 bytes Desc: not available URL: From skvidal at phy.duke.edu Wed Oct 29 12:30:20 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 29 Oct 2003 07:30:20 -0500 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067415429.6947.0.camel@m70.net81-64-235.noos.fr> References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> <20031028132731.H23901@redhat.com> <1067382628.11086.92.camel@denk.nakedape.priv> <1067383514.3302.6.camel@m70.net81-64-235.noos.fr> <1067397769.3522.21.camel@binkley> <1067415429.6947.0.camel@m70.net81-64-235.noos.fr> Message-ID: <1067430620.3522.128.camel@binkley> > > > > the first time downloading all the headers takes a while, but after > > that, provided you're not updating against a constantly rolling > > repository, you shouldn't have to download all that much, only the > > changes. > > I am using constantly rolling rawhide-like repositories:( I think you're in the minority. -sv From Nicolas.Mailhot at laPoste.net Wed Oct 29 12:44:17 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 29 Oct 2003 13:44:17 +0100 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067430620.3522.128.camel@binkley> References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> <20031028132731.H23901@redhat.com> <1067382628.11086.92.camel@denk.nakedape.priv> <1067383514.3302.6.camel@m70.net81-64-235.noos.fr> <1067397769.3522.21.camel@binkley> <1067415429.6947.0.camel@m70.net81-64-235.noos.fr> <1067430620.3522.128.camel@binkley> Message-ID: <1067431456.5365.1.camel@ulysse.olympe.o2t> Le mer 29/10/2003 ? 13:30, seth vidal a ?crit : > > > > > > the first time downloading all the headers takes a while, but after > > > that, provided you're not updating against a constantly rolling > > > repository, you shouldn't have to download all that much, only the > > > changes. > > > > I am using constantly rolling rawhide-like repositories:( > > I think you're in the minority. Well it should still work. We do want more beta/rawhide testers right ? (plus it suspect more broadband availability will lead to more users of my kind) 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 Wed Oct 29 12:52:04 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 29 Oct 2003 07:52:04 -0500 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067431456.5365.1.camel@ulysse.olympe.o2t> References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> <20031028132731.H23901@redhat.com> <1067382628.11086.92.camel@denk.nakedape.priv> <1067383514.3302.6.camel@m70.net81-64-235.noos.fr> <1067397769.3522.21.camel@binkley> <1067415429.6947.0.camel@m70.net81-64-235.noos.fr> <1067430620.3522.128.camel@binkley> <1067431456.5365.1.camel@ulysse.olympe.o2t> Message-ID: <1067431924.3522.131.camel@binkley> > Well it should still work. We do want more beta/rawhide testers right ? > sure, and changes in the future will make that less of a bandwidth need. but I'm not going to force some changes into yum in 2.0.x before they're ready to deal with a very small subset of users. > (plus it suspect more broadband availability will lead to more users of > my kind) broadband users shouldn't really worry. I use rawhide on my laptop and it only takes about 30s to download the updated headers everyday. -sv From johnsonm at redhat.com Wed Oct 29 17:50:07 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 29 Oct 2003 12:50:07 -0500 Subject: kernel to be backported to RH7.3-RH9? In-Reply-To: <20031029084506.GB26100@ip68-4-255-84.oc.oc.cox.net>; from barryn@pobox.com on Wed, Oct 29, 2003 at 12:45:06AM -0800 References: <20031029081500.GB28194@puariko.nirvana> <20031029084506.GB26100@ip68-4-255-84.oc.oc.cox.net> Message-ID: <20031029125007.A28571@devserv.devel.redhat.com> On Wed, Oct 29, 2003 at 12:45:06AM -0800, Barry K. Nathan wrote: > On Wed, Oct 29, 2003 at 09:15:00AM +0100, Axel Thimm wrote: > > The current rawhide kernels have some compatibility bits (like > > %{sevenexcompat}). > > > > Will the Fedora Core kernel be used for RHL errata (with deactivating > > nptl/exec-shield where appropriate)? > > AFAIR Red Hat did backporting with the 7.3, 8.0 and 9 kernels, so I > would guess the answer is yes. Probably not. It's not a direct replacement like those kernels were; for example, RHCA is not patched into the FC kernel. For people whose needs it meets, I'd expect it to function just fine on Red Hat Linux 9, but that doesn't mean that we should release it as an errata kernel for Red Hat Linux 9. So my expectation right now is that it won't be the source of an errata release for Red Hat Linux. 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 kreg at virtual1.net Wed Oct 29 18:17:08 2003 From: kreg at virtual1.net (Kreg Steppe) Date: Wed, 29 Oct 2003 13:17:08 -0500 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067431924.3522.131.camel@binkley> References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> <20031028132731.H23901@redhat.com> <1067382628.11086.92.camel@denk.nakedape.priv> <1067383514.3302.6.camel@m70.net81-64-235.noos.fr> <1067397769.3522.21.camel@binkley> <1067415429.6947.0.camel@m70.net81-64-235.noos.fr> <1067430620.3522.128.camel@binkley> <1067431456.5365.1.camel@ulysse.olympe.o2t> <1067431924.3522.131.camel@binkley> Message-ID: <3FA00424.4000507@virtual1.net> Can the set of default headers be installed by default for base Fedora for which ever mirror you choose? I mean they shouldn't have to be fetched especially right after an installation. That way you only are looking for updates (which should be small to none). Just a thought. Kreg seth vidal wrote: >>Well it should still work. We do want more beta/rawhide testers right ? >> >> >> > >sure, and changes in the future will make that less of a bandwidth need. >but I'm not going to force some changes into yum in 2.0.x before they're >ready to deal with a very small subset of users. > > > >>(plus it suspect more broadband availability will lead to more users of >>my kind) >> >> > >broadband users shouldn't really worry. I use rawhide on my laptop and >it only takes about 30s to download the updated headers everyday. > >-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 Wed Oct 29 18:20:33 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 29 Oct 2003 13:20:33 -0500 Subject: yum.conf shipped with 1.0 In-Reply-To: <3FA00424.4000507@virtual1.net> References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> <20031028132731.H23901@redhat.com> <1067382628.11086.92.camel@denk.nakedape.priv> <1067383514.3302.6.camel@m70.net81-64-235.noos.fr> <1067397769.3522.21.camel@binkley> <1067415429.6947.0.camel@m70.net81-64-235.noos.fr> <1067430620.3522.128.camel@binkley> <1067431456.5365.1.camel@ulysse.olympe.o2t> <1067431924.3522.131.camel@binkley> <3FA00424.4000507@virtual1.net> Message-ID: <1067451633.1365.5.camel@opus> On Wed, 2003-10-29 at 13:17, Kreg Steppe wrote: > Can the set of default headers be installed by default for base Fedora > for which ever mirror you choose? I mean they shouldn't have to be > fetched especially right after an installation. > > That way you only are looking for updates (which should be small to none). > Just a thought. > fine w/me - and yes this is very possible. -sv From bfox at redhat.com Wed Oct 29 18:45:03 2003 From: bfox at redhat.com (Brent Fox) Date: Wed, 29 Oct 2003 13:45:03 -0500 Subject: Date and Time Configuration Tool man page translation In-Reply-To: References: Message-ID: <1067453102.29885.4.camel@bfox.devel.redhat.com> On Wed, 2003-10-29 at 05:12, Hornain Fr?d?ric wrote: > Hi, > > This the man page of the Date and Time Configuration Tool translated > in french. > I will as soon as possible do the same with the help html file. > Keep me in touch if you need something else to translated in french. Thanks for the translation! I've just committed it to cvs. Cheers, Brent From kreg at virtual1.net Wed Oct 29 18:52:37 2003 From: kreg at virtual1.net (Kreg Steppe) Date: Wed, 29 Oct 2003 13:52:37 -0500 Subject: yum.conf shipped with 1.0 In-Reply-To: <1067451633.1365.5.camel@opus> References: <20031028123617.E23901@redhat.com> <200310281817.h9SIHFt21260@devserv.devel.redhat.com> <20031028132731.H23901@redhat.com> <1067382628.11086.92.camel@denk.nakedape.priv> <1067383514.3302.6.camel@m70.net81-64-235.noos.fr> <1067397769.3522.21.camel@binkley> <1067415429.6947.0.camel@m70.net81-64-235.noos.fr> <1067430620.3522.128.camel@binkley> <1067431456.5365.1.camel@ulysse.olympe.o2t> <1067431924.3522.131.camel@binkley> <3FA00424.4000507@virtual1.net> <1067451633.1365.5.camel@opus> Message-ID: <3FA00C75.9070904@virtual1.net> I just thought that this would help address some of the bandwidth issues that some people were expressing, and also make yum quicker on the get go for new users. Kind of like the rpmdb. Kreg seth vidal wrote: >On Wed, 2003-10-29 at 13:17, Kreg Steppe wrote: > > >>Can the set of default headers be installed by default for base Fedora >>for which ever mirror you choose? I mean they shouldn't have to be >>fetched especially right after an installation. >> >>That way you only are looking for updates (which should be small to none). >>Just a thought. >> >> >> > >fine w/me - and yes this is very possible. > >-sv > > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From jaap at haitsma.org Wed Oct 29 19:26:55 2003 From: jaap at haitsma.org (Jaap A. Haitsma) Date: Wed, 29 Oct 2003 20:26:55 +0100 Subject: Run prelink and other stuff not in cron but when screensaver is active. Message-ID: <3FA0147F.8050209@haitsma.org> I sometime get a bit frustrated that a cron job starts while I'm working. Wouldn't it be nicer that this stuff would run when I'm not doing any work. I.e. when the screensaver is active. Maybe as a minor enhancement when the screensaver is active and there is not a process asking for cpu power /disk access. Sometimes I'm running compiling jobs which take quite a while. Jaap From roland at redhat.com Wed Oct 29 19:38:50 2003 From: roland at redhat.com (Roland McGrath) Date: Wed, 29 Oct 2003 11:38:50 -0800 Subject: Run prelink and other stuff not in cron but when screensaver is active. In-Reply-To: Jaap A. Haitsma's message of Wednesday, 29 October 2003 20:26:55 +0100 <3FA0147F.8050209@haitsma.org> Message-ID: <200310291938.h9TJco1Z027215@magilla.sf.frob.com> I think what you want is a new cron feature to use criteria other than just time to decide when to run something. i.e., so you can say "every day, when idle or every week even if not idle". From garrett at redhat.com Wed Oct 29 19:56:37 2003 From: garrett at redhat.com (Garrett LeSage) Date: Wed, 29 Oct 2003 14:56:37 -0500 Subject: Vector-based Fedora Logo Available? In-Reply-To: <20031028170022.GG22946@rednote.net> References: <20031022160026.2750.49323.Mailman@listman.back-rdu.redhat.com> <3F96AD4F.9070603@silverorange.com> <3F96AF11.4000407@redhat.com> <20031028170022.GG22946@rednote.net> Message-ID: <3FA01B75.1020502@redhat.com> Janina Sajka wrote: >Garrett LeSage writes: > > >>From: Garrett LeSage >> >>Steven Garrity wrote: >> >> >> >>>>From: "Ricky Boone" >>>>Probably a really stupid question..., but will >>>>there be a version of the (final) Fedora logo as >>>>a vector-based image, in a format like EPS, SVG, etc? >>>> >>>> >>>I apologize if this question has been answered elsewhere - but I was >>>wondering if there is a public repository for the artwork in general - >>>vector/bitmap-originals of the bluecurve graphics, etc. >>> >>> >>Not yet. It is something to definitely consider though... (: >> >> > >Well, I will confess that I don't know much about EPS. However, SVG has >the advantage, from where I sit, of having been designed from the ground >up to support accessibility. > >http://www.w3.org/TR/SVG-access/ > > > EPS is "Encapsulated PostScript" and it seems to be rendered much better with freely available PostScript renderers compared to SVG. Nearly every bit of SVG I have tossed at an open source SVG renderer has been incorrectly drawn on the screen, unfortunately. PostScript renderers are better than SVG renderers (for the time being) due to the fact that PostScript has been around for several years longer than SVG. Garrett From brugolsky at telemetry-investments.com Wed Oct 29 20:00:19 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Wed, 29 Oct 2003 15:00:19 -0500 Subject: Run prelink and other stuff not in cron but when screensaver is active. In-Reply-To: <3FA0147F.8050209@haitsma.org> References: <3FA0147F.8050209@haitsma.org> Message-ID: <20031029200019.GD2886@ti19.telemetry-investments.com> On Wed, Oct 29, 2003 at 08:26:55PM +0100, Jaap A. Haitsma wrote: > I sometime get a bit frustrated that a cron job starts while I'm > working. Wouldn't it be nicer that this stuff would run when I'm not > doing any work. I.e. when the screensaver is active. Maybe as a minor > enhancement when the screensaver is active and there is not a process > asking for cpu power /disk access. Sometimes I'm running compiling jobs > which take quite a while. Several things. 1. anacron(8) 2. batch(1) 3. nice(1) and renice(8) 4. xscreensaver-command(1) With some combination of these, it is not too difficult to roll a (sub-optimal) solution using nothing more than scripting. xscreensaver-command(1): -watch Prints a line each time the screensaver changes state: when the screen blanks, locks, unblanks, or when the running hack is changed. This option never returns; it is intended for use by shell scripts that want to react to the screensaver in some way. An example of its output would be: BLANK Fri Nov 5 01:57:22 1999 RUN 34 RUN 79 RUN 16 LOCK Fri Nov 5 01:57:22 1999 RUN 76 RUN 12 UNBLANK Fri Nov 5 02:05:59 1999 The above shows the screensaver activating, running three dif- ferent hacks, then locking (perhaps because the lock-timeout went off) then unblanking (because the user became active, and typed the correct password.) The hack numbers are their index in the ? list (starting with 1, not 0, as for the -select command.) For example, suppose you want to run a program that turns down the volume on your machine when the screen blanks, and turns it back up when the screen un-blanks. You could do that by run- ning a Perl program like the following in the background. The following program tracks the output of the -watch command and reacts accordingly: #!/usr/bin/perl my $blanked = 0; open (IN, "xscreensaver-command -watch |"); while () { if (m/^(BLANK|LOCK)/) { if (!$blanked) { system "sound-off"; $blanked = 1; } } elsif (m/^UNBLANK/) { system "sound-on"; $blanked = 0; } } Note that LOCK might come either with or without a preceeding BLANK (depending on whether the lock-timeout is non-zero), so the above program keeps track of both of them. Regards, Bill Rugolsky From buildsys at porkchop.devel.redhat.com Wed Oct 29 21:13:52 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Wed, 29 Oct 2003 16:13:52 -0500 Subject: rawhide report: 20031029 changes Message-ID: <200310292113.h9TLDqA09186@porkchop.devel.redhat.com> From xose at wanadoo.es Wed Oct 29 21:40:08 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 29 Oct 2003 22:40:08 +0100 Subject: rawhide report: 20031029 changes References: <200310292113.h9TLDqA09186@porkchop.devel.redhat.com> Message-ID: <3FA033B8.2030702@wanadoo.es> Build System wrote: > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > Fedora motto: no news, good news }:-) -- HTML mails are going to trash automagically From thompsma at colorado.edu Wed Oct 29 22:17:50 2003 From: thompsma at colorado.edu (The Matt) Date: Wed, 29 Oct 2003 15:17:50 -0700 Subject: rawhide report: 20031029 changes In-Reply-To: <3FA033B8.2030702@wanadoo.es> References: <200310292113.h9TLDqA09186@porkchop.devel.redhat.com> <3FA033B8.2030702@wanadoo.es> Message-ID: <1067465870.2581.59.camel@ixion.colorado.edu> On Wed, 2003-10-29 at 14:40, Xose Vazquez Perez wrote: > Build System wrote: > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > Fedora motto: no news, good news }:-) Except when quite a few package *were* changed (e.g., new kernel). Then no news, file a bug. -- I am a theoretical chemist. Fear me! Please. Matt Thompson -- http://ucsub.colorado.edu/~thompsma/ 440 UCB, Boulder, CO 80309-0440 JILA A510, 303-492-4662 -------------- 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 bobhenry at ix.netcom.com Thu Oct 30 00:26:46 2003 From: bobhenry at ix.netcom.com (R.P. Henry) Date: Wed, 29 Oct 2003 16:26:46 -0800 Subject: rawhide report: 20031029 changes In-Reply-To: <1067465870.2581.59.camel@ixion.colorado.edu> References: <200310292113.h9TLDqA09186@porkchop.devel.redhat.com> <3FA033B8.2030702@wanadoo.es> <1067465870.2581.59.camel@ixion.colorado.edu> Message-ID: <200310291626.52889.bobhenry@ix.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 29 October 2003 14:17, The Matt wrote: > On Wed, 2003-10-29 at 14:40, Xose Vazquez Perez wrote: > > Build System wrote: > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > Fedora motto: no news, good news }:-) > > Except when quite a few package *were* changed (e.g., new kernel). Then > no news, file a bug. the script is probably pointed at RedHat subdir rawhide/i386/RedHat/RPMS/ rather than the Fedora subdir rawhide/i386/Fedora/RPMS/ as it changed after 1021 just my 2 cents worth. R.P. Henry bobhenry at ix.netcom.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUBP6BaxjXRIDjpOKy0AQLjXgP/cDzgy1SLFieh0SxcwUOVAhBPFB/Iqv7q OM4qs8o8nU9mdBldbk3Tv+xZcfkAx8vPyW0H0cWd/0Ut5r8OniHk9G7V7lcdW4+E AKyX1J0WNroU6vqh0wA5rBv5BN/MZliDPkkY53tfQ3imrm3Be9qK8NFQVQMTyky3 XMCtpUjxThc= =VUAA -----END PGP SIGNATURE----- From mike at flyn.org Thu Oct 30 02:01:21 2003 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 29 Oct 2003 20:01:21 -0600 Subject: Gnome-common and gnome-autogen.sh Message-ID: <20031030020121.GA1190@imp.flyn.org> Many GNOME CVS trees require a script called gnome-autogen.sh to build their configure scripts and such. Mandrake and Debian provide gnome-autogen.sh within their gnome-common package but it seems missing from Red Hat/Fedora. Am I missing something? -- Mike :wq From katzj at redhat.com Thu Oct 30 05:00:39 2003 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 30 Oct 2003 00:00:39 -0500 Subject: Gnome-common and gnome-autogen.sh In-Reply-To: <20031030020121.GA1190@imp.flyn.org> References: <20031030020121.GA1190@imp.flyn.org> Message-ID: <1067490039.2058.2.camel@edoras.local.net> On Wed, 2003-10-29 at 21:01, W. Michael Petullo wrote: > Many GNOME CVS trees require a script called gnome-autogen.sh to build > their configure scripts and such. Mandrake and Debian provide > gnome-autogen.sh within their gnome-common package but it seems missing > from Red Hat/Fedora. If you're building GNOME bits from CVS, is it too much to think that you should expect to build gnome-common from CVS as well? Cheers, Jeremy From mattharrison at sbcglobal.net Thu Oct 30 05:17:26 2003 From: mattharrison at sbcglobal.net (Matt Jones) Date: Wed, 29 Oct 2003 21:17:26 -0800 Subject: Static Libraries In-Reply-To: <1067490039.2058.2.camel@edoras.local.net> References: <20031030020121.GA1190@imp.flyn.org> <1067490039.2058.2.camel@edoras.local.net> Message-ID: <1067491045.6813.3.camel@localhost.localdomain> On Wed, 2003-10-29 at 21:00, Jeremy Katz wrote: > On Wed, 2003-10-29 at 21:01, W. Michael Petullo wrote: > > Many GNOME CVS trees require a script called gnome-autogen.sh to build > > their configure scripts and such. Mandrake and Debian provide > > gnome-autogen.sh within their gnome-common package but it seems missing > > from Red Hat/Fedora. > > If you're building GNOME bits from CVS, is it too much to think that you > should expect to build gnome-common from CVS as well? > > Cheers, > > Jeremy In a somewhat related note about building gnome stuff from cvs - why does redhat not include static libraries? is there a good reason not to that I am completely unaware of (space, compatability or something like that)? Or are the .la files hidden in some obscure directory? Most builds don't seem to require static libraries, but some things do. I end up having to build a gtk srpm and linking the .la's from the redhat/BUILD/gtk* dir to /usr/lib to build stuff. Is their anyway redhat/fedora could start providing -static packages (like -devel or -debuginfo)? --Matt -------------- 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 poprocks at linux.net Thu Oct 30 05:27:39 2003 From: poprocks at linux.net (Logan Rathbone) Date: Wed, 29 Oct 2003 21:27:39 -0800 (PST) Subject: Self-Introduction: Logan Rathbone Message-ID: <20031030052745.E260A7267@sitemail.everyone.net> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From salimma1 at yahoo.co.uk Thu Oct 30 05:47:14 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Thu, 30 Oct 2003 12:47:14 +0700 Subject: Self-Introduction: Logan Rathbone In-Reply-To: <20031030052745.E260A7267@sitemail.everyone.net> References: <20031030052745.E260A7267@sitemail.everyone.net> Message-ID: <1067492834.8599.7.camel@bushido.localdomain> On Thu, 2003-10-30 at 12:27, Logan Rathbone wrote: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~~~~~~~Logan A. Rathbone~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~~Mississauga, Ontario, Canada~~~~~~~~~~~~~~~ > ~University student - 1st year of studies in Economics~ > ~~~~~~~~~~~~~~~University of Toronto~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Welcome, Logan! It should be really useful to have more non-CS contributors. I have been looking at ArkLinux with interest myself, though admittedly the omission of Gnome turns me away. Could you tell us which packages you plan to contribute? - Michel PS everyone can contribute to Fedora Extra (http://fedora.us), you just need to post a package request to bugzilla.fedora.us and get your package past QA From warren at togami.com Thu Oct 30 05:59:24 2003 From: warren at togami.com (Warren Togami) Date: Wed, 29 Oct 2003 19:59:24 -1000 Subject: Self-Introduction: Logan Rathbone In-Reply-To: <1067492834.8599.7.camel@bushido.localdomain> References: <20031030052745.E260A7267@sitemail.everyone.net> <1067492834.8599.7.camel@bushido.localdomain> Message-ID: <3FA0A8BC.4000707@togami.com> Michel Alexandre Salim wrote: > > PS everyone can contribute to Fedora Extra (http://fedora.us), you just > need to post a package request to bugzilla.fedora.us and get your > package past QA > Oh, and that's simple. =) Warren From salimma1 at yahoo.co.uk Thu Oct 30 06:15:28 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Thu, 30 Oct 2003 13:15:28 +0700 Subject: Self-Introduction: Logan Rathbone In-Reply-To: <3FA0A8BC.4000707@togami.com> References: <20031030052745.E260A7267@sitemail.everyone.net> <1067492834.8599.7.camel@bushido.localdomain> <3FA0A8BC.4000707@togami.com> Message-ID: <1067494528.8599.17.camel@bushido.localdomain> On Thu, 2003-10-30 at 12:59, Warren Togami wrote: > Michel Alexandre Salim wrote: > > > > PS everyone can contribute to Fedora Extra (http://fedora.us), you just > > need to post a package request to bugzilla.fedora.us and get your > > package past QA > > > > Oh, and that's simple. =) > Simpler than Debian's QA? :) On a more serious note, helping to QA other packages help your packages get QA'ed faster. - Michel From P at draigBrady.com Thu Oct 30 09:58:23 2003 From: P at draigBrady.com (P at draigBrady.com) Date: Thu, 30 Oct 2003 09:58:23 +0000 Subject: Run prelink and other stuff not in cron but when screensaver is active. In-Reply-To: <20031029200019.GD2886@ti19.telemetry-investments.com> References: <3FA0147F.8050209@haitsma.org> <20031029200019.GD2886@ti19.telemetry-investments.com> Message-ID: <3FA0E0BF.7080202@draigBrady.com> Bill Rugolsky Jr. wrote: > On Wed, Oct 29, 2003 at 08:26:55PM +0100, Jaap A. Haitsma wrote: > >>I sometime get a bit frustrated that a cron job starts while I'm >>working. Wouldn't it be nicer that this stuff would run when I'm not >>doing any work. I.e. when the screensaver is active. Maybe as a minor >>enhancement when the screensaver is active and there is not a process >>asking for cpu power /disk access. Sometimes I'm running compiling jobs >>which take quite a while. > > > Several things. > > 1. anacron(8) > 2. batch(1) > 3. nice(1) and renice(8) > 4. xscreensaver-command(1) > > With some combination of these, it is not too difficult to roll > a (sub-optimal) solution using nothing more than scripting. true. This reminds me, that it's seriously annoying that xscreensaver runs for vnc sessions. Seems like an easy fix. P?draig. From twaugh at redhat.com Thu Oct 30 10:46:30 2003 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 30 Oct 2003 10:46:30 +0000 Subject: Run prelink and other stuff not in cron but when screensaver is active. In-Reply-To: <3FA0E0BF.7080202@draigBrady.com> References: <3FA0147F.8050209@haitsma.org> <20031029200019.GD2886@ti19.telemetry-investments.com> <3FA0E0BF.7080202@draigBrady.com> Message-ID: <20031030104630.GA1963@redhat.com> On Thu, Oct 30, 2003 at 09:58:23AM +0000, P at draigBrady.com 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. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jakub at redhat.com Thu Oct 30 11:09:32 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 30 Oct 2003 06:09:32 -0500 Subject: Run prelink and other stuff not in cron but when screensaver is active. In-Reply-To: <3FA0E0BF.7080202@draigBrady.com>; from P@draigBrady.com on Thu, Oct 30, 2003 at 09:58:23AM +0000 References: <3FA0147F.8050209@haitsma.org> <20031029200019.GD2886@ti19.telemetry-investments.com> <3FA0E0BF.7080202@draigBrady.com> Message-ID: <20031030060931.G2097@devserv.devel.redhat.com> On Thu, Oct 30, 2003 at 09:58:23AM +0000, P at draigBrady.com wrote: > Bill Rugolsky Jr. wrote: > > On Wed, Oct 29, 2003 at 08:26:55PM +0100, Jaap A. Haitsma wrote: > > > >>I sometime get a bit frustrated that a cron job starts while I'm > >>working. Wouldn't it be nicer that this stuff would run when I'm not > >>doing any work. I.e. when the screensaver is active. Maybe as a minor > >>enhancement when the screensaver is active and there is not a process > >>asking for cpu power /disk access. Sometimes I'm running compiling jobs > >>which take quite a while. > > > > > > Several things. > > > > 1. anacron(8) > > 2. batch(1) > > 3. nice(1) and renice(8) /etc/cron.daily/prelink starts with renice +19 -p $$ >/dev/null 2>&1 I totally agree with Roland, this should be solved in cron. When a new category for run daily when the system is most idle or something like that is added, I'll certainly move prelink to that category. (and slocate.cron should fall in exactly the same category). But, even current prelink cron job, if there are no changes on the system it shouldn't do too many disk accesses nor take much CPU time. Jakub From buildsys at porkchop.devel.redhat.com Thu Oct 30 11:10:07 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Thu, 30 Oct 2003 06:10:07 -0500 Subject: rawhide report: 20031030 changes Message-ID: <200310301110.h9UBA7L24840@porkchop.devel.redhat.com> Updated Packages: abiword-2.0.1-1 --------------- * Tue Oct 28 2003 Jeremy Katz 1:2.0.1-1 - 2.0.1 - really remove duplicate desktop file anaconda-9.2-1 -------------- * Tue Oct 28 2003 Anaconda team - built new version from CVS * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 * Mon Sep 09 2002 Jeremy Katz - can't buildrequire dietlibc and kernel-pcmcia-cs since they don't always exist * Wed Aug 21 2002 Jeremy Katz - added URL * Thu May 23 2002 Jeremy Katz - add require and buildrequire on rhpl * Tue Apr 02 2002 Michael Fulbright - added some more docs * Fri Feb 22 2002 Jeremy Katz - buildrequire kernel-pcmcia-cs as we've sucked the libs the loader needs to there now * Thu Feb 07 2002 Michael Fulbright - goodbye reconfig * Thu Jan 31 2002 Jeremy Katz - update the BuildRequires a bit * Fri Jan 04 2002 Jeremy Katz - ddcprobe is now done from kudzu * Wed Jul 18 2001 Jeremy Katz - own /usr/lib/anaconda and /usr/share/anaconda * Fri Jan 12 2001 Matt Wilson - sync text with specspo * Thu Aug 10 2000 Matt Wilson - build on alpha again now that I've fixed the stubs * Wed Aug 09 2000 Michael Fulbright - new build * Fri Aug 04 2000 Florian La Roche - allow also subvendorid and subdeviceid in trimpcitable * Fri Jul 14 2000 Matt Wilson - moved init script for reconfig mode to /etc/init.d/reconfig - move the initscript back to /etc/rc.d/init.d - Prereq: /etc/init.d * Thu Feb 03 2000 Michael Fulbright - strip files - add lang-table to file list * Wed Jan 05 2000 Michael Fulbright - added requirement for rpm-python * Mon Dec 06 1999 Michael Fulbright - rename to 'anaconda' instead of 'anaconda-reconfig' * Fri Dec 03 1999 Michael Fulbright - remove ddcprobe since we don't do X configuration in reconfig now * Tue Nov 30 1999 Michael Fulbright - first try at packaging reconfiguration tool anaconda-images-9.2-3 --------------------- control-center-2.4.0-3 ---------------------- * Wed Oct 29 2003 Jonathan Blandford 1:2.4.0-3 - require libgail-gnome * Mon Sep 22 2003 Jonathan Blandford 1:2.4.0-2 - get all the schemas desktop-backgrounds-2.0-17 -------------------------- * Wed Oct 29 2003 Havoc Pennington 2.0-17 - redhat-backgrounds-5 fedora-release-1-2 ------------------ indexhtml-1-1 ------------- * Wed Oct 29 2003 Elliot Lee 1-1 - FC1 kernel-2.4.22-1.2115.nptl ------------------------- * Wed Oct 29 2003 Dave Jones - Back out part of the 2.4.23pre ACPI changes as per upstream. - Fix up typo in orlov patch. - Remove orlov patch for the time being. ntp-4.1.2-5 ----------- * Wed Oct 29 2003 Harald Hoyer 4.1.2-5 - reverted to 4.1.2 (4.2.0 is unstable) #108369 * Tue Oct 28 2003 Harald Hoyer 4.2.0-3 - removed libmd5 dependency - removed perl dependency openoffice.org-1.1.0-4 ---------------------- * 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 redhat-config-httpd-1.1.0-5 --------------------------- * Wed Oct 29 2003 Phil Knirsch 1.1.0-5 - Fixed problem with Allow from and Deny from (double from). - Big change in 4Suite requires fix for the Xslt processing. * Fri Oct 03 2003 Jeremy Katz 1.1.0-4 - rebuild rhgb-0.11.2-1 ------------- * Wed Oct 29 2003 Jonathan Blandford 0.11.1-2 - rebuild for fixed german translation rp-pppoe-3.5-8 -------------- * Wed Oct 29 2003 Than Ngo 3.5-8 - fix a bug in connect script rpmdb-fedora-1-0.20031030 ------------------------- up2date-4.1.14-2 ---------------- * Wed Oct 29 2003 Adrian Likins 4.1.14 - fix #108401 - fix for redirect bug from Sopwith * Wed Oct 29 2003 Elliot Lee 4.1.12-2 - Add fedora patch to import extra Fedora keys, and to put yum update URLs in. * Mon Oct 27 2003 Adrian Likins - be more robust when changing on disk metadata formats - fix #108085 - fix yum 0k/s bug (#107048) - dirRepo is close to allowing file tree walks yum-2.0.4-2 ----------- * Wed Oct 29 2003 Elliot Lee 2.0.4-2 - Stick in a new yum.conf for FC1. From matthias at rpmforge.net Thu Oct 30 12:00:24 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Thu, 30 Oct 2003 13:00:24 +0100 Subject: Gnome-common and gnome-autogen.sh In-Reply-To: <20031030020121.GA1190@imp.flyn.org> References: <20031030020121.GA1190@imp.flyn.org> Message-ID: <20031030130024.515e292c.matthias@rpmforge.net> W. Michael Petullo wrote : > Many GNOME CVS trees require a script called gnome-autogen.sh to build > their configure scripts and such. Mandrake and Debian provide > gnome-autogen.sh within their gnome-common package but it seems missing > from Red Hat/Fedora. You could eventually try this one I made for Red Hat Linux 8.0. I doubt anything changed since, as the sources were already very old. http://psyche.freshrpms.net/rpm.html?id=199 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-20.1.2024.2.36.nptl Load : 2.04 2.01 1.99 From tjb at unh.edu Thu Oct 30 14:46:44 2003 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 30 Oct 2003 09:46:44 -0500 Subject: Self-Introduction: Thomas J. Baker Message-ID: <1067525203.12557.31.camel@wintermute.sr.unh.edu> Name: Thomas J. Baker Address: USA, Durham, NH Profession: Systems Programmer Company: University of New Hampshire, Research Computing Center Goals: -- help fedora contain up to date versions of some already included software and some missing software like galeon, seahorse, synergy, gthumb, xmms-shn, glabels -- I'll willing to do QA but it will usually be limited to software I or someone I support or work with needs -- I currently build quite a few rpms on my own which I'd like to see in fedora. I maintain my own apt/yum repository for supported Red Hat releases and my extra packages. I support over 40 linux systems and that number is increasing all the time. I'll probably add a fedora mirror to my mirror list soon. Qualifications: -- I've beta tested every Red Hat release since 6.2. I'm a regular bugzilla contributer for Red Hat, Gnome, Ximian, and GPE, amoung others. I beta test the GPE palmtop environment on iPAQs. -- I know C, C++, Java, Perl, Python, csh, sh, and other 'dead' languages. I do applications, systems, and web programming on a daily basis. GPG KEYID and fingerprint: wintermute> gpg --fingerprint 1CEE63C4 pub 1024D/1CEE63C4 2001-10-08 Thomas J. Baker Key fingerprint = 7AB2 D9FD 1B5A 4CCC 95A9 7E2E A02B 638E 1CEE 63C4 sub 1024g/2DA4F4E2 2001-10-08 neuromancer> gpg --fingerprint 7AFDB8C4 pub 1024D/7AFDB8C4 2001-10-08 Thomas J. Baker Key fingerprint = 18DB A077 00BB 54EB 569B 517E FC87 8868 7AFD B8C4 sub 1024g/230B9388 2001-10-08 tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= -------------- 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 mike at flyn.org Thu Oct 30 15:33:15 2003 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 30 Oct 2003 09:33:15 -0600 Subject: Gnome-common and gnome-autogen.sh In-Reply-To: <1067490039.2058.2.camel@edoras.local.net> References: <20031030020121.GA1190@imp.flyn.org> <1067490039.2058.2.camel@edoras.local.net> Message-ID: <20031030153315.GA3552@imp.flyn.org> >> Many GNOME CVS trees require a script called gnome-autogen.sh to build >> their configure scripts and such. Mandrake and Debian provide >> gnome-autogen.sh within their gnome-common package but it seems missing >> from Red Hat/Fedora. > If you're building GNOME bits from CVS, is it too much to think that you > should expect to build gnome-common from CVS as well? Well, I don't build every library GNOME parts depend on from CVS. Why should I need to build gnome-common from CVS? -- Mike :wq From enrico.scholz at informatik.tu-chemnitz.de Thu Oct 30 17:01:55 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 30 Oct 2003 18:01:55 +0100 Subject: Gnome-common and gnome-autogen.sh In-Reply-To: <20031030020121.GA1190@imp.flyn.org> (W. Michael Petullo's message of "Wed, 29 Oct 2003 20:01:21 -0600") References: <20031030020121.GA1190@imp.flyn.org> Message-ID: <87ptgebqws.fsf@kosh.ultra.csn.tu-chemnitz.de> mike at flyn.org ("W. Michael Petullo") writes: > Many GNOME CVS trees require a script called gnome-autogen.sh to build > their configure scripts and such. 'autoreconf -i -f' should do the same on well-written build-system. Enrico From johnsonm at redhat.com Thu Oct 30 19:29:45 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Thu, 30 Oct 2003 14:29:45 -0500 Subject: Infrastructure job... Message-ID: <20031030142945.E8407@devserv.devel.redhat.com> One of the things that I'd like to have before doing that is a CVS ACL implementation that allows us to put ACLS on branches. The one we use internally allows us to lock down a repository to certain developers, but I'd really like, for example, to allow package developers to lock down CVS HEAD on their packages but still let other developers do work on a branch, and then the main developer(s) for that package merge the work down to CVS HEAD when they think it's appropriate. Anyone interested in working on 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 law at redhat.com Thu Oct 30 20:04:39 2003 From: law at redhat.com (law at redhat.com) Date: Thu, 30 Oct 2003 13:04:39 -0700 Subject: Infrastructure job... In-Reply-To: Your message of "Thu, 30 Oct 2003 14:29:45 EST." <20031030142945.E8407@devserv.devel.redhat.com> Message-ID: <200310302004.h9UK4d8D001571@speedy.slc.redhat.com> In message <20031030142945.E8407 at devserv.devel.redhat.com>, "Michael K. Johnson " writes: >One of the things that I'd like to have before doing that is a >CVS ACL implementation that allows us to put ACLS on branches. >The one we use internally allows us to lock down a repository >to certain developers, but I'd really like, for example, to allow >package developers to lock down CVS HEAD on their packages but >still let other developers do work on a branch, and then the >main developer(s) for that package merge the work down to CVS >HEAD when they think it's appropriate. > >Anyone interested in working on that? There's actually a couple projects which are providing ACLs for CVS. http://cvsacl.sourceforge.net/ http://cvs-nserver.sourceforge.net/ I don't know which is more mature or whether or not either is working with the main CVS folks to ensure integration. But they're probably worth looking into. Jeff > >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 mike at flyn.org Thu Oct 30 18:32:31 2003 From: mike at flyn.org (mike at flyn.org) Date: Thu, 30 Oct 2003 14:32:31 -0400 Subject: gconfd-2 does not exit when a user log out, breaks unmounting home Message-ID: <20031030193231.E28D73156D@neuromancer.voxel.net> I have been having some trouble with gconfd-2 (currently using GConf2-2.4.0 from RawHide PPC) for quite some time. I tried to get some discussion going on Red Hat's Bugzilla quite a while ago but nothing really came of it. I'd be willing to work on a patch, but I'd like to come to consensus on the technique we should use to fix the problem. I thought perhaps I would try this forum. The gconfd-2 daemon is run by many GNOME applications to manage configurations. Gconfd-2 remains running for some time after the application which used it quits. This allows other applications to use gconfd-2 without having to start and stop the daemon too much. This is a good idea. The problem comes when a system tries to unmount a user's home directory when the user logs out. For example, pam_mount unmounts an encrypted home directory then I log out of my system. Other people use NFS or other means to mount home directories. Gconfd-2 continues to run even when a user logs out. This causes the unmounting of the user's home directory to fail because gconfd-2 keeps the following files open: /home/user/.gconfd/saved_state In addition, when using GNOME 2.4, there are four new programs that seem to hang around unwelcome for a second after logging out (at least they are still around when PAM session closing code is run). This is partially documented in bug #106826. The four programs are: bonobo-activation-server (home direcotry remains open as CWD?) gnome-settings-daemon (home direcotry remains open as CWD?) xscreensaver -nosplash (home direcotry remains open as CWD?) mapping-daemon (home direcotry remains open as CWD?) Red Hat Bugzilla bugs #67605, #75895 and #106826 comment more on this problem. -- Mike From ville.skytta at iki.fi Thu Oct 30 20:17:45 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 30 Oct 2003 22:17:45 +0200 Subject: Infrastructure job... In-Reply-To: <200310302004.h9UK4d8D001571@speedy.slc.redhat.com> References: <200310302004.h9UK4d8D001571@speedy.slc.redhat.com> Message-ID: <1067545065.20763.42.camel@bobcat.mine.nu> On Thu, 2003-10-30 at 22:04, law at redhat.com wrote: > In message <20031030142945.E8407 at devserv.devel.redhat.com>, "Michael K. Johnson > " writes: > >One of the things that I'd like to have before doing that is a > >CVS ACL implementation that allows us to put ACLS on branches. [...] > > > >Anyone interested in working on that? > There's actually a couple projects which are providing ACLs for CVS. Don't forget /usr/share/cvs/contrib/cvs_acls. From johnsonm at redhat.com Thu Oct 30 20:22:49 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Thu, 30 Oct 2003 15:22:49 -0500 Subject: Infrastructure job... In-Reply-To: <200310302004.h9UK4d8D001571@speedy.slc.redhat.com>; from law@redhat.com on Thu, Oct 30, 2003 at 01:04:39PM -0700 References: <20031030142945.E8407@devserv.devel.redhat.com> <200310302004.h9UK4d8D001571@speedy.slc.redhat.com> Message-ID: <20031030152247.A19060@devserv.devel.redhat.com> On Thu, Oct 30, 2003 at 01:04:39PM -0700, law at redhat.com wrote: > In message <20031030142945.E8407 at devserv.devel.redhat.com>, "Michael K. Johnson > " writes: > >One of the things that I'd like to have before doing that is a > >CVS ACL implementation that allows us to put ACLS on branches. > >The one we use internally allows us to lock down a repository > >to certain developers, but I'd really like, for example, to allow > >package developers to lock down CVS HEAD on their packages but > >still let other developers do work on a branch, and then the > >main developer(s) for that package merge the work down to CVS > >HEAD when they think it's appropriate. > > > >Anyone interested in working on that? > > There's actually a couple projects which are providing ACLs for CVS. > > http://cvsacl.sourceforge.net/ > http://cvs-nserver.sourceforge.net/ > > I don't know which is more mature or whether or not either is working with > the main CVS folks to ensure integration. But they're probably worth looking > into. Well, at least the one we use now just hooks into the commitinfo hook, so no explicit integration is necessary. I think that adding per-branch acls to the script we have probably wouldn't be too hard for a perl programmer. What we have is 101 lines of perl, including comments. If we want to control reading as well as writing, we'd need more direct integration, such as the two patches above. Dealing with security issues that might be worthwhile, but there are other ways to do 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 johnsonm at redhat.com Thu Oct 30 20:27:59 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Thu, 30 Oct 2003 15:27:59 -0500 Subject: Infrastructure job... In-Reply-To: <1067545065.20763.42.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Thu, Oct 30, 2003 at 10:17:45PM +0200 References: <200310302004.h9UK4d8D001571@speedy.slc.redhat.com> <1067545065.20763.42.camel@bobcat.mine.nu> Message-ID: <20031030152759.B19060@devserv.devel.redhat.com> On Thu, Oct 30, 2003 at 10:17:45PM +0200, Ville Skytt? wrote: > Don't forget /usr/share/cvs/contrib/cvs_acls. That's the version we're using now, internally, FWIW. 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 Thu Oct 30 20:29:22 2003 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Thu, 30 Oct 2003 14:29:22 -0600 (CST) Subject: x86_64 issues, etc. In-Reply-To: <20031030142945.E8407@devserv.devel.redhat.com> Message-ID: As we get closer to Release, and hopefully and x86_64 FC1 release, I would like to offer a few things. First, bugzilla tickets referencing x86_64 arch for fedora packages, if you can assign them to 64bit_Fedora at comcast.net I will look over them and see if I can field them in an effort to reduce load. I have a feeling many of them will be less code issues, and more integration issues which I should be able to easily address, and then forward on if they are code related, or cross arch. This should help reduce the strain of supporting another arch. Second, I am setting up another AMD64 system to use for builds, etc for packages where people do not have the hardware to build or test on. Just let me know where the SRPM is and I will build and QA against AMD64 to ensure the platform is well supported with not just core but extras. If there is anything else I can do to assist, please let me know via email or irc. There has been quite a bit of interest in this platform, and with AMD pushing it as a home user system as well, I think that interest will continue to grow. Thanks, Justin M. Forbes From law at redhat.com Thu Oct 30 20:38:54 2003 From: law at redhat.com (law at redhat.com) Date: Thu, 30 Oct 2003 13:38:54 -0700 Subject: Infrastructure job... In-Reply-To: Your message of "Thu, 30 Oct 2003 15:22:49 EST." <20031030152247.A19060@devserv.devel.redhat.com> Message-ID: <200310302038.h9UKcsBI002087@speedy.slc.redhat.com> In message <20031030152247.A19060 at devserv.devel.redhat.com>, "Michael K. Johnso n" writes: >Well, at least the one we use now just hooks into the commitinfo >hook, so no explicit integration is necessary. I think that adding >per-branch acls to the script we have probably wouldn't be too hard >for a perl programmer. What we have is 101 lines of perl, including >comments. I'm always amazed at what folks manage to do with perl. If we can do it with commitinfo hooks rather than going to a totally different CVS server codebase then I'm all for doing it with commitinfo hooks. My experience with commitinfo hooks was that, yes, you can do almost anything, but that it got rather ugly pretty quick. >If we want to control reading as well as writing, we'd need more >direct integration, such as the two patches above. Dealing with >security issues that might be worthwhile, but there are other >ways to do that. I'm not terribly concerned about shutting down read access to branches, I don't think that's all that interesting of an issue for a public project such as Fedora. What I want to see is the ability to sandbox developers. Hell, whatever we end up using for Fedora may be useful for the GCC project since we're branch-happy these days :-) jeff From ville.skytta at iki.fi Thu Oct 30 20:52:43 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 30 Oct 2003 22:52:43 +0200 Subject: Infrastructure job... In-Reply-To: <20031030152759.B19060@devserv.devel.redhat.com> References: <200310302004.h9UK4d8D001571@speedy.slc.redhat.com> <1067545065.20763.42.camel@bobcat.mine.nu> <20031030152759.B19060@devserv.devel.redhat.com> Message-ID: <1067547163.20763.76.camel@bobcat.mine.nu> On Thu, 2003-10-30 at 22:27, Michael K. Johnson wrote: > On Thu, Oct 30, 2003 at 10:17:45PM +0200, Ville Skytt? wrote: > > Don't forget /usr/share/cvs/contrib/cvs_acls. > > That's the version we're using now, internally, FWIW. But it already supports ACLs on branches, no? From hp at redhat.com Thu Oct 30 20:57:58 2003 From: hp at redhat.com (Havoc Pennington) Date: Thu, 30 Oct 2003 15:57:58 -0500 Subject: gconfd-2 does not exit when a user log out, breaks unmounting home In-Reply-To: <20031030193231.E28D73156D@neuromancer.voxel.net> References: <20031030193231.E28D73156D@neuromancer.voxel.net> Message-ID: <1067547478.5823.25.camel@localhost.localdomain> On Thu, 2003-10-30 at 13:32, mike at flyn.org wrote: > The problem comes when a system tries to unmount a user's home directory when > the user logs out. For example, pam_mount unmounts an encrypted home > directory then I log out of my system. Other people use NFS or other means > to mount home directories. I think the simple solution is to exec "gconftool-2 --shutdown" as the last thing gnome-session does before exiting, or perhaps even in the X scripts in xinitrc. If you wrote and tested a patch along those lines it'd be useful. Another possible solution is to have an X server monitor process for gconfd; basically gconfd would fork/exec a tiny little program that simply connects to the X server and sits there, exiting when it loses the X connection. gconfd would then exit when this program exits. This is conceivably a more robust approach and still pretty easy to implement. Havoc From johnsonm at redhat.com Thu Oct 30 21:13:48 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Thu, 30 Oct 2003 16:13:48 -0500 Subject: Infrastructure job... In-Reply-To: <1067547163.20763.76.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Thu, Oct 30, 2003 at 10:52:43PM +0200 References: <200310302004.h9UK4d8D001571@speedy.slc.redhat.com> <1067545065.20763.42.camel@bobcat.mine.nu> <20031030152759.B19060@devserv.devel.redhat.com> <1067547163.20763.76.camel@bobcat.mine.nu> Message-ID: <20031030161348.C19060@devserv.devel.redhat.com> On Thu, Oct 30, 2003 at 10:52:43PM +0200, Ville Skytt? wrote: > But it already supports ACLs on branches, no? Well, whaddya know? Already done. The version we're using internally is an older version of that script that didn't support ACLs on branches. I just missed that they had been added in that version. That was easy, 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 razvan.vilt at linux360.ro Thu Oct 30 21:24:01 2003 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Thu, 30 Oct 2003 23:24:01 +0200 Subject: Anaconda build problem. (#108643) Message-ID: <1067549041.6230.4.camel@home-04019.b.astral.ro> With the latest version anaconda-runtime-9.0.96-0.20031027175019. I cannot build a distribution tree anymore without changing some of the included files. I've included (hopefully) enough info here to trace the bug. I left a high severity because it makes anaconda not work at all. I don't know any python (it's a problem of variable declaration and use) so that's why I need a confirmation on it. It should be a small change in no more than 2 line. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108643 Regards, Razvan Corneliu VILT From windi at myrealbox.com Thu Oct 30 22:32:58 2003 From: windi at myrealbox.com (Stephan Windischmann) Date: Thu, 30 Oct 2003 23:32:58 +0100 Subject: Self-Introduction: Logan Rathbone In-Reply-To: <1067494528.8599.17.camel@bushido.localdomain> References: <20031030052745.E260A7267@sitemail.everyone.net> <1067492834.8599.7.camel@bushido.localdomain> <3FA0A8BC.4000707@togami.com> <1067494528.8599.17.camel@bushido.localdomain> Message-ID: <1067553178.3079.1.camel@homer.home> On Thu, 2003-10-30 at 07:15, Michel Alexandre Salim wrote: > On Thu, 2003-10-30 at 12:59, Warren Togami wrote: > > Michel Alexandre Salim wrote: > > > > > > PS everyone can contribute to Fedora Extra (http://fedora.us), you just > > > need to post a package request to bugzilla.fedora.us and get your > > > package past QA > > > > > > > Oh, and that's simple. =) > > > Simpler than Debian's QA? :) Well, they don't expect you to meet up with another Debian developer to proof your identity, and there are no Fedora events where public keys are read out loud (I would have loved to watch that). :) -windi (who uses both Debian and Fedora) From fedora at puzzled.xs4all.nl Thu Oct 30 22:36:23 2003 From: fedora at puzzled.xs4all.nl (Patrick) Date: 30 Oct 2003 23:36:23 +0100 Subject: XFree86 & Neomagic: DRI missing? Message-ID: <1067553383.10678.12.camel@guru.puzzled.xs4all.nl> Fully updated Fedora as of Oct 30, 23:15 CET. When I run glxgears it complains: Xlib: extensions "XFree86-DRI" missing on display ":0.0". I thought 3D hardware acceleration was supported on the Neomagic NM2200. Any ideas? TIA, Patrick From mike at flyn.org Fri Oct 31 00:56:27 2003 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 30 Oct 2003 18:56:27 -0600 Subject: gconfd-2 does not exit when a user log out, breaks unmounting home In-Reply-To: <1067547478.5823.25.camel@localhost.localdomain> References: <20031030193231.E28D73156D@neuromancer.voxel.net> <1067547478.5823.25.camel@localhost.localdomain> Message-ID: <20031031005627.GA1536@imp.flyn.org> > > The problem comes when a system tries to unmount a user's home directory when > > the user logs out. For example, pam_mount unmounts an encrypted home > > directory then I log out of my system. Other people use NFS or other means > > to mount home directories. > > I think the simple solution is to exec "gconftool-2 --shutdown" as the > last thing gnome-session does before exiting, or perhaps even in the X > scripts in xinitrc. If you wrote and tested a patch along those lines > it'd be useful. > > Another possible solution is to have an X server monitor process for > gconfd; basically gconfd would fork/exec a tiny little program that > simply connects to the X server and sits there, exiting when it loses > the X connection. gconfd would then exit when this program exits. This > is conceivably a more robust approach and still pretty easy to > implement. Your second solution may be something that could be generalized to be quite useful -- perhaps freedesktop.org material? Other projects, like the venerable esd, have problems similar to gconfd. Esd can lock down a system's audio device for a while after a user logs out. I'll have to spend a little time looking at xscreensaver, gnome-settings-daemon, etc. Your first solution seems simple enough. I included a very unsophisticated patch that performs the task (vs. gnome-session 2.4.0). Comments? ============================================================================== diff --recursive -u gnome-session-2.4.0-vanilla/gnome-session/main.c gnome-session-2.4.0/gnome-session/main.c --- gnome-session-2.4.0-vanilla/gnome-session/main.c 2003-08-13 07:58:52.000000000 -0500 +++ gnome-session-2.4.0/gnome-session/main.c 2003-10-30 17:01:04.000000000 -0600 @@ -481,6 +481,15 @@ #endif } +/* Ensure gconfd-2 is shutdown when a user logs out so the user's $HOME + * may be unmounted if appropriate + */ +static void gconfd_shutdown (void) +{ + char *argv[] = { "gconftool-2", "--shutdown", NULL }; + gnome_execute_async (NULL, 2, argv); +} + int main (int argc, char *argv[]) { @@ -634,6 +643,8 @@ clean_ice (); + gconfd_shutdown (); /* in case home needs to be unmounted on logout */ + /* If a logout command was set, the following will not return */ execute_logout (); ============================================================================== -- Mike :wq From davej at redhat.com Fri Oct 31 02:21:40 2003 From: davej at redhat.com (Dave Jones) Date: Fri, 31 Oct 2003 02:21:40 +0000 Subject: XFree86 & Neomagic: DRI missing? In-Reply-To: <1067553383.10678.12.camel@guru.puzzled.xs4all.nl> References: <1067553383.10678.12.camel@guru.puzzled.xs4all.nl> Message-ID: <20031031022140.GB17002@redhat.com> On Thu, Oct 30, 2003 at 11:36:23PM +0100, Patrick wrote: > Fully updated Fedora as of Oct 30, 23:15 CET. When I run glxgears it > complains: Xlib: extensions "XFree86-DRI" missing on display ":0.0". > > I thought 3D hardware acceleration was supported on the Neomagic NM2200. Nope. Dave From yinyang at eburg.com Fri Oct 31 03:07:18 2003 From: yinyang at eburg.com (Gordon Messmer) Date: Thu, 30 Oct 2003 19:07:18 -0800 Subject: gconfd-2 does not exit when a user log out, breaks unmounting home In-Reply-To: <1067547478.5823.25.camel@localhost.localdomain> References: <20031030193231.E28D73156D@neuromancer.voxel.net> <1067547478.5823.25.camel@localhost.localdomain> Message-ID: <3FA1D1E6.5020402@eburg.com> Havoc Pennington wrote: > > I think the simple solution is to exec "gconftool-2 --shutdown" as the > last thing gnome-session does before exiting, or perhaps even in the X > scripts in xinitrc. If you wrote and tested a patch along those lines > it'd be useful. > > Another possible solution is to have an X server monitor process for > gconfd; basically gconfd would fork/exec a tiny little program that > simply connects to the X server and sits there, exiting when it loses > the X connection. gconfd would then exit when this program exits. This > is conceivably a more robust approach and still pretty easy to > implement. Couldn't you also connect gconfd2 to the session manager? That would be more portable to systems which don't use X11, no? From razvan.vilt at linux360.ro Fri Oct 31 03:07:30 2003 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Fri, 31 Oct 2003 05:07:30 +0200 Subject: Anaconda build problem. (#108643) In-Reply-To: <1067549041.6230.4.camel@home-04019.b.astral.ro> References: <1067549041.6230.4.camel@home-04019.b.astral.ro> Message-ID: <1067569650.12008.6.camel@home-04019.b.astral.ro> On Thu, 2003-10-30 at 23:24, Razvan Corneliu C.R. "d3vi1" VILT wrote: > With the latest version anaconda-runtime-9.0.96-0.20031027175019. > I cannot build a distribution tree anymore without changing some of the > included files. > I've included (hopefully) enough info here to trace the bug. > I left a high severity because it makes anaconda not work at all. > I don't know any python (it's a problem of variable declaration and use) > so that's why I need a confirmation on it. It should be a small change > in no more than 2 line. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108643 > > Regards, > Razvan Corneliu VILT > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list OK guys... this is bad... I have to prove to someone that it is possible... and it doesn't work anymore. I cannot rebuild an installer. With the pkgorder... ok... there were workarounds... but with the buildinstall... I don't know. /usr/lib/anaconda-runtime/buildinstall --pkgorder /mnt/distrib/linux360-1.0test0/pkgorder.txt --comp dist-1 --product "linux360" --version 1.0test0 --release "linux360 1.0test0 (Seraphim)" /mnt/distrib/linux360-1.0test0/i386 the output is just: warning: /mnt/distrib/linux360-1.0test0/i386/Fedora/RPMS/anaconda-runtime-9.0.96-0.20031027175019.i386.rpm: V3 DSA signature: NOKEY, key ID 4f2a6fd2 Running buildinstall... /mnt/distrib/linux360-1.0test0/i386/buildinstall.tree.11971 ~ ~ Going to run buildinstall again Usage: buildinstall [--comp ] [--pkgorder ] [--version ] [--product ] [--release ] [--prodpath ] I thought that it's just the params I passed it... so when I used a RedHat 9 buildinstall command... It gave the same output. Any ideas? From razvan.vilt at linux360.ro Fri Oct 31 03:11:16 2003 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Fri, 31 Oct 2003 05:11:16 +0200 Subject: Anaconda build problem. (#108643) In-Reply-To: <1067569650.12008.6.camel@home-04019.b.astral.ro> References: <1067549041.6230.4.camel@home-04019.b.astral.ro> <1067569650.12008.6.camel@home-04019.b.astral.ro> Message-ID: <1067569876.12008.9.camel@home-04019.b.astral.ro> (...) > > OK guys... this is bad... I have to prove to someone that it is > possible... and it doesn't work anymore. I cannot rebuild an installer. > The problem is that I managed until now. And now it simply crashes. > With the pkgorder... ok... there were workarounds... but with the > buildinstall... I don't know. > From salimma1 at yahoo.co.uk Fri Oct 31 03:19:17 2003 From: salimma1 at yahoo.co.uk (Michel Alexandre Salim) Date: Fri, 31 Oct 2003 10:19:17 +0700 Subject: Splitting gnome-panel Message-ID: <1067570356.11352.11.camel@bushido.localdomain> Hi, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108677 Is there any plan to split gnome-panel, and have the -devel package supplying the proper Requires: dependencies on packages required to compile something that depends on gnome-panel header files? Thanks, Michel From barryn at pobox.com Fri Oct 31 03:21:57 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 30 Oct 2003 19:21:57 -0800 Subject: Anaconda build problem. (#108643) In-Reply-To: <1067569876.12008.9.camel@home-04019.b.astral.ro> References: <1067549041.6230.4.camel@home-04019.b.astral.ro> <1067569650.12008.6.camel@home-04019.b.astral.ro> <1067569876.12008.9.camel@home-04019.b.astral.ro> Message-ID: <20031031032157.GA29089@ip68-4-255-84.oc.oc.cox.net> On Fri, Oct 31, 2003 at 05:11:16AM +0200, Razvan Corneliu C.R. d3vi1 VILT wrote: > The problem is that I managed until now. And now it simply crashes. Did you try the *real* latest (anaconda-runtime-9.2-1, last time I checked)? -Barry K. Nathan From hp at redhat.com Fri Oct 31 04:09:18 2003 From: hp at redhat.com (Havoc Pennington) Date: Thu, 30 Oct 2003 23:09:18 -0500 Subject: gconfd-2 does not exit when a user log out, breaks unmounting home In-Reply-To: <3FA1D1E6.5020402@eburg.com> References: <20031030193231.E28D73156D@neuromancer.voxel.net> <1067547478.5823.25.camel@localhost.localdomain> <3FA1D1E6.5020402@eburg.com> Message-ID: <1067573358.15833.23.camel@localhost.localdomain> On Thu, 2003-10-30 at 22:07, Gordon Messmer wrote: > Couldn't you also connect gconfd2 to the session manager? That would be > more portable to systems which don't use X11, no? Well, basically I don't care about those. ;-) The number of systems using the X Session Management Protocol but not X11 is pretty limited. And what we're talking about here is a short-term hack so why overengineer it. No need to confuse gnome-session any more than it already is (http://mail.gnome.org/archives/desktop-devel-list/2003-April/msg00090.html) Havoc From hp at redhat.com Fri Oct 31 05:20:13 2003 From: hp at redhat.com (Havoc Pennington) Date: Fri, 31 Oct 2003 00:20:13 -0500 Subject: gconfd-2 does not exit when a user log out, breaks unmounting home In-Reply-To: <20031031005627.GA1536@imp.flyn.org> References: <20031030193231.E28D73156D@neuromancer.voxel.net> <1067547478.5823.25.camel@localhost.localdomain> <20031031005627.GA1536@imp.flyn.org> Message-ID: <1067577613.15833.61.camel@localhost.localdomain> On Thu, 2003-10-30 at 19:56, W. Michael Petullo wrote: > Your second solution may be something that could be generalized to be > quite useful -- perhaps freedesktop.org material? Other projects, > like the venerable esd, have problems similar to gconfd. Esd can lock > down a system's audio device for a while after a user logs out. I'll have > to spend a little time looking at xscreensaver, gnome-settings-daemon, > etc. My eventual thought is that dbus could perform this function; the per-session message bus is tied exactly to the lifetime of the user's session, and thus performs the same function as the X server. (Most apps exit on logout because they lose their X server connection.) dbus itself already has a mechanism where it can be tied to the X server lifetime or the login session's pty. > Your first solution seems simple enough. I included a very unsophisticated > patch that performs the task (vs. gnome-session 2.4.0). Comments? It looks sane to me, thanks. I'd file it on bugzilla.gnome.org, and also make a bugzilla.redhat.com bug with a link to the gnome.org bug (or use an existing bug if someone already opened it) to remind us to backport the patch if needed, since we'll probably still be on GNOME 2.4 in the next Fedora Core release. We could also do a bugfix update to Fedora Core 1 once the freeze is over. Havoc From Axel.Thimm at physik.fu-berlin.de Fri Oct 31 06:58:46 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Fri, 31 Oct 2003 07:58:46 +0100 Subject: Distags in rpm sort order (yes, versioning again ;) Message-ID: <20031031065846.GC4184@puariko.nirvana> 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 mharris at redhat.com Fri Oct 31 07:35:39 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 31 Oct 2003 02:35:39 -0500 (EST) Subject: XFree86 & Neomagic: DRI missing? In-Reply-To: <1067553383.10678.12.camel@guru.puzzled.xs4all.nl> References: <1067553383.10678.12.camel@guru.puzzled.xs4all.nl> Message-ID: On Thu, 30 Oct 2003, Patrick wrote: >Fully updated Fedora as of Oct 30, 23:15 CET. When I run glxgears it >complains: Xlib: extensions "XFree86-DRI" missing on display ":0.0". > >I thought 3D hardware acceleration was supported on the Neomagic NM2200. >Any ideas? DRI 3D acceleration has never been supported on any Neomagic video hardware by XFree86 ever. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From warren at togami.com Fri Oct 31 08:53:03 2003 From: warren at togami.com (Warren Togami) Date: Thu, 30 Oct 2003 22:53:03 -1000 Subject: Distags in rpm sort order (yes, versioning again ;) In-Reply-To: <20031031065846.GC4184@puariko.nirvana> References: <20031031065846.GC4184@puariko.nirvana> Message-ID: <3FA222EF.1020008@togami.com> Axel Thimm wrote: > > Certainly many repos will start offering their packages (officially) > after FC1 is (officially) released, so there are only a few days left > ... I could be wrong, but it is already too late to rename packages contained in FC1. Just to be 100% clear I am soon posting my revised package naming counter-proposal for fedora.redhat.com. Warren From linuxnow at newtral.org Fri Oct 31 09:05:49 2003 From: linuxnow at newtral.org (Pau Aliagas) Date: Fri, 31 Oct 2003 10:05:49 +0100 (CET) Subject: Infrastructure job... In-Reply-To: <200310302038.h9UKcsBI002087@speedy.slc.redhat.com> Message-ID: On Thu, 30 Oct 2003 law at redhat.com wrote: > What I want to see is the ability to sandbox developers. Hell, whatever > we end up using for Fedora may be useful for the GCC project since we're > branch-happy these days :-) Have you tried arch? http://savannah.gnu.org/projects/gnu-arch/ It's very difficult to summarize in a few words all it can do, but basically: -you don't deal with patches of every file, you have patchsets that include whole sets of changes -it handles renames -you can have your own repository locally without any special server -you can easyly branch projects and merge back and forth among branches with conflict resolution -branching is cheap, immediate -developement style encourages creating branches for features -development isenouraed because worknig in one's own branch freely, without taboos, conflicts and problems let's you concentrate in what you really want to do. And you know htat getting your work upstreamed will be only a matter of telling the owners of the project to pick up your patchsets (or sending them in patch format that i'ts also possible) -it's written in C and very fast -savannah.gnu.org will offer arch hosting too I don't want to make you lose more time. If you feel like it could fit your needs, that CVS is a bit limited, just try it. Or if you have any questions, just let me know :) Pau From nos at utel.no Fri Oct 31 09:05:44 2003 From: nos at utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Fri, 31 Oct 2003 10:05:44 +0100 Subject: Infrastructure job... In-Reply-To: <7ff8d404050f5f07d3@[192.168.170.10]> References: <7ff8d404050f5f07d3@[192.168.170.10]> Message-ID: <1067591144.1262.29.camel@nos-rh> On Fri, 2003-10-31 at 10:05, Pau Aliagas wrote: > On Thu, 30 Oct 2003 law at redhat.com wrote: > > > What I want to see is the ability to sandbox developers. Hell, whatever > > we end up using for Fedora may be useful for the GCC project since we're > > branch-happy these days :-) > > Have you tried arch? arch is imho a pain to use. If anything else that CSV should be used/considered it ought to be subversion. Though usable now, it doesn't have a stable release yet. And I'm sure there are lots of other suggestions for version control systems also. Better stick with CVS for now.. -- 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 warren at togami.com Fri Oct 31 09:22:27 2003 From: warren at togami.com (Warren Togami) Date: Thu, 30 Oct 2003 23:22:27 -1000 Subject: Warren's Package Naming Proposal - Revision 1 Message-ID: <3FA229D3.4000104@togami.com> http://www.fedora.us/wiki/PackageNamingGuidelines The following is based upon current fedora.us package naming guidelines, quickly edited and dramatically simplified because fedora.redhat.com no longer needs many of fedora.us special considerations. The below proposal is ALMOST EXACTLY THE SAME as fedora.us current scheme except with the leading "0.fdr." removed from all %{release} tags. 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. This proposal is missing considerations for 3rd party repositories. Theoretically 3rd party repositories should no longer have a reason to publish the same %{name} of any packages that exist in FC or FE because changes should be incorporated upstream. There are however some cases like kde-redhat where this is not possible, so we really need to discuss possible solutions to this. Earlier we had discussed the possibility of simply adding a %{reptag} to the far right of %{release}. Fedora Package Naming Guidelines Warren's Proposal for fedora.redhat.com Revision 1 ================================ i. Introduction Goals for package naming guidelines ii. Terminology 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: Minor Number 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. E-V-R Abbreviation for epoch, version, and release. This is often referred to when talking about potential package upgrading problems. 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 judgement, 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. 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 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 usptream 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 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 C-5. Special Case: Kernel modules --------------------------------- This section needs its own discussion due to changed provides within FC1's kernel, and the fact that older distributions are different. 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} C-7. Minor Number ----------------------- Probably no longer needed at fedora.redhat.com. From linuxnow at newtral.org Fri Oct 31 09:37:04 2003 From: linuxnow at newtral.org (Pau Aliagas) Date: Fri, 31 Oct 2003 10:37:04 +0100 (CET) Subject: Infrastructure job... In-Reply-To: <1067591144.1262.29.camel@nos-rh> Message-ID: On Fri, 31 Oct 2003, Nils O. [ISO-8859-1] Sel?sdal wrote: > On Fri, 2003-10-31 at 10:05, Pau Aliagas wrote: > > On Thu, 30 Oct 2003 law at redhat.com wrote: > > > > > What I want to see is the ability to sandbox developers. Hell, whatever > > > we end up using for Fedora may be useful for the GCC project since we're > > > branch-happy these days :-) > > > > Have you tried arch? > > arch is imho a pain to use. I think it's much more difficult to setup a server (be it CVS, SVN, whatever) than arch. Your server is your filesystem. Setting up your repository is two commands: archive-setup + init-tree Upgrading your branch to your ancestor is just one command: replay Branching a project: tag source target It doesn't look a pain to me :) > If anything else that CSV should be used/considered it ought to be > subversion. Though usable now, it doesn't have a stable release yet. I won't comment on that. I only say that promoting development is much easier when you can work as freely as you can with arch, even disconnected. And you are sure tht yourchanges can be easyly upstreamed. > And I'm sure there are lots of other suggestions for version control > systems also. Better stick with CVS for now.. CVS is way too limited to promote distributed developemnt, branches are difficult to get right, no renames, no patchsets... it does the work but painfully. Anyway, I don't want to start an off-topic discussion. Pau From pmatilai at welho.com Fri Oct 31 09:53:20 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 31 Oct 2003 11:53:20 +0200 Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: <3FA229D3.4000104@togami.com> References: <3FA229D3.4000104@togami.com> Message-ID: <1067594000.3fa23110bf6e0@webmail.welho.com> Quoting Warren Togami : Looks good to me. The only thing I don't really like at first sight is separating disttag with underscore rather than something else but then that's probably just a matter of getting used to :) Oh and it's anyway cleaner looking than all the .rh9.0.93.foo type of numberings. > > C-5. Special Case: Kernel modules > --------------------------------- > This section needs its own discussion due to changed provides within > FC1's kernel, and the fact that older distributions are different. Hmm, what's changed? Doesn't look that different to me: Current rawhide kernel: [pmatilai at linox03 RPMS]$ rpm -qp --provides kernel-smp-2.4.22-1.2115.nptl.i686.rpm kernel = 2.4.22 kernel-drm = 4.1.0 kernel-drm = 4.2.0 kernel-drm = 4.3.0 kernel-smp = 2.4.22-1.2115.nptl Latest RHL9 errata kernel: [pmatilai at linox03 i686]$ rpm -qp --provides kernel-smp-2.4.20-20.9.i686.rpm kernel = 2.4.20 kernel-drm = 4.1.0 kernel-drm = 4.2.0 kernel-drm = 4.2.99.3 kernel-drm = 4.3.0 module-info kernel-smp = 2.4.20-20.9 The only change is the dropped module-info provides but that wasn't used by anything AFAIK, certainly not by the fedora.us kernel-module packages anyway. That's not to say this topic doesn't deserve a separate discussion of course :) -- - Panu - From Axel.Thimm at physik.fu-berlin.de Fri Oct 31 11:15:03 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Fri, 31 Oct 2003 12:15:03 +0100 Subject: Distags in rpm sort order (yes, versioning again ;) In-Reply-To: <3FA222EF.1020008@togami.com> References: <20031031065846.GC4184@puariko.nirvana> <3FA222EF.1020008@togami.com> Message-ID: <20031031111503.GB12411@puariko.nirvana> On Thu, Oct 30, 2003 at 10:53:03PM -1000, Warren Togami wrote: > Axel Thimm wrote: > > Certainly many repos will start offering their packages > > (officially) after FC1 is (officially) released, so there are only > > a few days left ... > > I could be wrong, but it is already too late to rename packages > contained in FC1. Just to be 100% clear I am soon posting my > revised package naming counter-proposal for fedora.redhat.com. I am not referring to FC1 itself (it is impossible to turn back time ;), but to the repos that want to offer rpms for it (and for "legacy" RHL distros). Of course, FC >= 1.95 should also consider the versioning scheme, it is possible also less relevant for FC, as it will only seldomly have to issue packages from the same upstream sources (just like RHL's errata do). -- 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 Fri Oct 31 11:20:37 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Fri, 31 Oct 2003 12:20:37 +0100 Subject: Distags in rpm sort order (yes, versioning again ;) In-Reply-To: <3FA229D3.4000104@togami.com> <3FA222EF.1020008@togami.com> <20031031065846.GC4184@puariko.nirvana> References: <3FA229D3.4000104@togami.com> <20031031065846.GC4184@puariko.nirvana> <3FA222EF.1020008@togami.com> <20031031065846.GC4184@puariko.nirvana> Message-ID: <20031031112037.GC12411@puariko.nirvana> On Fri, Oct 31, 2003 at 07:58:46AM +0100, Axel Thimm wrote: > ==================== 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 On Thu, Oct 30, 2003 at 10:53:03PM -1000, Warren Togami wrote: > Just to be 100% clear I am soon posting my revised package naming > counter-proposal for fedora.redhat.com. On Thu, Oct 30, 2003 at 11:22:27PM -1000, Warren Togami wrote: > 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 So this is scheme A, with the variation of dropping the distid. -- 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 mharris at redhat.com Fri Oct 31 10:53:58 2003 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 31 Oct 2003 05:53:58 -0500 (EST) Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: <3FA229D3.4000104@togami.com> References: <3FA229D3.4000104@togami.com> Message-ID: On Thu, 30 Oct 2003, Warren Togami wrote: >http://www.fedora.us/wiki/PackageNamingGuidelines >The following is based upon current fedora.us package naming guidelines, >quickly edited and dramatically simplified because fedora.redhat.com no >longer needs many of fedora.us special considerations. Some feedback below... >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. The "Epoch" tag is already quite confusing to many/most beginner and intermediate packagers, perhaps even some advanced packagers. It's often used when not needed, and with a small amount of forethought when packaging things can be completely avoided in many if not all cases where Epoch ends up being used nowadays by someone. I think your "vepoch" tag potentially adds confusion between what Epoch is and what vepoch is. I unfortunately don't have a better name to offer other than perhaps "versionserial" to indicate a monotonically increasing serial number tied to a version. 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. >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 judgement, and other >developers will help in the final decision. > >Ultimately it is up to QA to decide upon the proper %{name} before >publication. Just to contrast, at Red Hat, package naming is usually determined by the developer who creates a new package from scratch, or who Red Hattifies an existing src.rpm from the wild. I do realize though that when you refer to QA above, you don't mean Red Hat QA, but rather fedora.us QA in sort of a quality control and semi-standardization sense. Sounds like a good idea to me. Also a good idea for people to provide feedback as early on as possible about developer chosen *crappy* package names. I've seen MySQL in rpm format out there named "mysql", "Mysql", "MySQL", and MySql". ICK! >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. 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. Example: This: XFree86-4.3.99.15-0.20031030 is better IMHO, than this: XFree86-20031030-1 The latter one, would require an ugly Epoch bump to upgrade to XFree86 4.4.0 for example. That can be avoided by using the method you describe. (Which is why my CVS rpm packages tend to have insanely long version-release tags ) >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 I find the above quite confusing, and I actually understand what your vepoch is there for and why. ;o) Might want to try rewording that perhaps, although I'm not volunteering.... ;o) >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 usptream 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 For gkrellm is this necessary? rpm considers 2.1.7a newer than 2.1.7 already unless something has changed. Another package of this nature is UW imap. It is generally released with an integer based version number of the year of it's release, possibly followed by a single letter indicating a revision within that year. ie: imap-2000 imap-2000a imap-2000b In rpm's normal operation these packages are naturally treated as the older package on the left, with the newer ones proceeding to the right. My personal preference would be to just let rpm assume that as it should work. I've never gotten bug reports of it not working anyway. Moving things from the version to the release field unnecessarily just complicates packaging when there's no real benefit IMHO. For the pre-release cases above it makes sense as it's being done in order to override rpm's default behaviour, which would be to treat what is a final release as older than a prerelease. I believe treating both pre-release and post-release in the same manner just for consistency with both types of lettered versioned packages is just cosmetic consistency, but doesn't provide any functional or technical benefit. In other words, sticking with the upstream version in the version field is IMHO best unless there is a technical benefit of doing so, such as avoiding having to later use Epoch to override a prerelease build. Are there cases where rpm would consider imap-2000a as older than imap-2000? jbj? >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 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) >C-5. Special Case: Kernel modules >--------------------------------- >This section needs its own discussion due to changed provides within >FC1's kernel, and the fact that older distributions are different. Bah, who needs kernel modules. ;o) >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} I agree, this is a sensible diversion from an upstream package IMHO. >C-7. Minor Number >----------------------- >Probably no longer needed at fedora.redhat.com. Change that to read "MBZ, reserved for future" to cover your bases, and looks good. ;o) Hope my feedback is useful... if not, feel free to kick me in the pants. ;o) Take care, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From Axel.Thimm at physik.fu-berlin.de Fri Oct 31 11:27:53 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Fri, 31 Oct 2003 12:27:53 +0100 Subject: rpm: avoiding evil epochs and split versions In-Reply-To: References: <3FA229D3.4000104@togami.com> Message-ID: <20031031112753.GA21974@puariko.nirvana> On Fri, Oct 31, 2003 at 05:53:58AM -0500, Mike A. Harris wrote: > My personal preference would be to just let rpm assume that as it > should work. I've never gotten bug reports of it not working > anyway. Moving things from the version to the release field > unnecessarily just complicates packaging when there's no real > benefit IMHO. For the pre-release cases above it makes sense as > it's being done in order to override rpm's default behaviour, > which would be to treat what is a final release as older than a > prerelease. > > I believe treating both pre-release and post-release in the same > manner just for consistency with both types of lettered versioned > packages is just cosmetic consistency, but doesn't provide any > functional or technical benefit. In other words, sticking with > the upstream version in the version field is IMHO best unless > there is a technical benefit of doing so, such as avoiding having > to later use Epoch to override a prerelease build. I agree, and rpm (and deb for this matter) should be redesigned long term to have different semantics of a upstream version used for rpm/deb ordering and one used for the package name. So foo-1.2.3beta17.8 could be packaged as foo-1.2.3beta17.8-1.rh9, but be compared as say 1.2.2.99.17.8. This could be done at the cost of introducing a new tag like versionsort that defaults to %{version}. When present it would be used for ordering and interpackage dependencies (Requires, Conflicts, Obsoletes etc.). It would make epochs unnecessary and it would be a local (in time) change of a package (contrasted to epoch's global and eternal presence ...). This was proposed on the rpm-list ages ago, but died a silent death, maybe it could be resurrected here? > Are there cases where rpm would consider imap-2000a as older than > imap-2000? No, not since rpm >= 4.0.3 (#21392). -- 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 buildsys at porkchop.devel.redhat.com Fri Oct 31 12:11:36 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Fri, 31 Oct 2003 07:11:36 -0500 Subject: rawhide report: 20031031 changes Message-ID: <200310311211.h9VCBZX17685@porkchop.devel.redhat.com> Updated Packages: anaconda-9.2-2 -------------- * Thu Oct 30 2003 Anaconda team - built new version from CVS * Tue Oct 08 2002 Jeremy Katz - back to mainstream rpm instead of rpm404 * Mon Sep 09 2002 Jeremy Katz - can't buildrequire dietlibc and kernel-pcmcia-cs since they don't always exist * Wed Aug 21 2002 Jeremy Katz - added URL * Thu May 23 2002 Jeremy Katz - add require and buildrequire on rhpl * Tue Apr 02 2002 Michael Fulbright - added some more docs * Fri Feb 22 2002 Jeremy Katz - buildrequire kernel-pcmcia-cs as we've sucked the libs the loader needs to there now * Thu Feb 07 2002 Michael Fulbright - goodbye reconfig * Thu Jan 31 2002 Jeremy Katz - update the BuildRequires a bit * Fri Jan 04 2002 Jeremy Katz - ddcprobe is now done from kudzu * Wed Jul 18 2001 Jeremy Katz - own /usr/lib/anaconda and /usr/share/anaconda * Fri Jan 12 2001 Matt Wilson - sync text with specspo * Thu Aug 10 2000 Matt Wilson - build on alpha again now that I've fixed the stubs * Wed Aug 09 2000 Michael Fulbright - new build * Fri Aug 04 2000 Florian La Roche - allow also subvendorid and subdeviceid in trimpcitable * Fri Jul 14 2000 Matt Wilson - moved init script for reconfig mode to /etc/init.d/reconfig - move the initscript back to /etc/rc.d/init.d - Prereq: /etc/init.d * Thu Feb 03 2000 Michael Fulbright - strip files - add lang-table to file list * Wed Jan 05 2000 Michael Fulbright - added requirement for rpm-python * Mon Dec 06 1999 Michael Fulbright - rename to 'anaconda' instead of 'anaconda-reconfig' * Fri Dec 03 1999 Michael Fulbright - remove ddcprobe since we don't do X configuration in reconfig now * Tue Nov 30 1999 Michael Fulbright - first try at packaging reconfiguration tool fedora-logos-1.1.20-1 --------------------- * Thu Oct 30 2003 Havoc Pennington 1.1.20-1 - build new stuff from garrett redhat-config-boot-0.1.6-1 -------------------------- * Thu Oct 30 2003 Harald Hoyer 0.1.6-1 - fixed #106796 - added exception handling rpmdb-fedora-1-0.20031031 ------------------------- up2date-4.1.16-1 ---------------- * Thu Oct 30 2003 Adrian Likins 4.1.16 - sources cleanup From Axel.Thimm at physik.fu-berlin.de Fri Oct 31 12:17:35 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Fri, 31 Oct 2003 13:17:35 +0100 Subject: Upgrading redhat-config-httpd and missing pam file Message-ID: <20031031121735.GD21974@puariko.nirvana> In previous packages /etc/pam.d/redhat-config-httpd was a symlink to apacheconf. Upgrading the package resulted in apacheconf's removal, but the symlink was left dangling. Instead a /etc/pam.d/redhat-config-httpd.rpmnew was created. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108704 -- 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 den at tourinfo.ru Fri Oct 31 13:46:22 2003 From: den at tourinfo.ru (Den) Date: Fri, 31 Oct 2003 16:46:22 +0300 Subject: Mozilla 1.4.1 Russian translation Message-ID: <3FA267AE.2080103@tourinfo.ru> Hello! I'm patch mozilla-1.4.1-15.src.rpm to add russian translation. On what address to send changed files? Den, Russia, Moscow. From lhh at redhat.com Fri Oct 31 13:51:25 2003 From: lhh at redhat.com (Lon Hohberger) Date: Fri, 31 Oct 2003 08:51:25 -0500 Subject: Yum-able screen-4.0.1 test-only RPMS Message-ID: <1067608285.4912.141.camel@atlantis.boston.redhat.com> Hi, I put RPMS of screen-4.0.1 on my people.redhat.com account. You can use yum: http://people.redhat.com/lhh/fedora Or, download the packages directly: http://people.redhat.com/lhh/fedora/screen-4.0.1-0.1.i386.rpm http://people.redhat.com/lhh/fedora/screen-4.0.1-0.1.src.rpm The major difference is screen's lack of needing backspace bindings. 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. Additionally, you may have to remove the backspace key binding from /etc/screenrc or ~/.screenrc (If RPM saves your old configuration...) The goal here is to remove all of the workaround we put in to make screen work properly WRT backspace/del. In theory, 4.0.1 no longer needs them. -- 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 black at asplinux.ru Fri Oct 31 13:59:11 2003 From: black at asplinux.ru (Grigory Bakunov) Date: Fri, 31 Oct 2003 16:59:11 +0300 Subject: Mozilla 1.4.1 Russian translation In-Reply-To: <3FA267AE.2080103@tourinfo.ru> References: <3FA267AE.2080103@tourinfo.ru> Message-ID: <3FA26AAF.10900@asplinux.ru> Den wrote: > Hello! > I'm patch mozilla-1.4.1-15.src.rpm to add russian translation. > On what address to send changed files? > > Den, Russia, Moscow. Hello, Dan! Just add RFE to bugzilla and attach your files to it. -- .............................................................. IRC: irc.freenode.net #asplinux Grigory Bakunov ICQ: 51369901 ASPLinux Development Team Life would be so much easier if we could just look at the source code. From fedora at puzzled.xs4all.nl Fri Oct 31 14:30:36 2003 From: fedora at puzzled.xs4all.nl (Patrick) Date: 31 Oct 2003 15:30:36 +0100 Subject: XFree86 & Neomagic: DRI missing? In-Reply-To: References: <1067553383.10678.12.camel@guru.puzzled.xs4all.nl> Message-ID: <1067610636.5537.0.camel@guru.puzzled.xs4all.nl> On Fri, 2003-10-31 at 08:35, Mike A. Harris wrote: > On Thu, 30 Oct 2003, Patrick wrote: > > >Fully updated Fedora as of Oct 30, 23:15 CET. When I run glxgears it > >complains: Xlib: extensions "XFree86-DRI" missing on display ":0.0". > > > >I thought 3D hardware acceleration was supported on the Neomagic NM2200. > >Any ideas? > > DRI 3D acceleration has never been supported on any Neomagic > video hardware by XFree86 ever. > Must have misinterpreted the info on xfree86.org. Sorry for the noise. Thanks, Patrick From warren at togami.com Fri Oct 31 14:31:09 2003 From: warren at togami.com (Warren Togami) Date: Fri, 31 Oct 2003 04:31:09 -1000 Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: References: <3FA229D3.4000104@togami.com> Message-ID: <3FA2722D.6090504@togami.com> Mike A. Harris wrote: > >>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. > > > The "Epoch" tag is already quite confusing to many/most beginner > and intermediate packagers, perhaps even some advanced packagers. > It's often used when not needed, and with a small amount of > forethought when packaging things can be completely avoided in > many if not all cases where Epoch ends up being used nowadays by > someone. > > I think your "vepoch" tag potentially adds confusion between what > Epoch is and what vepoch is. I unfortunately don't have a better > name to offer other than perhaps "versionserial" to indicate a > monotonically increasing serial number tied to a version. > > 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. >>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. > > > 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!" Conspiracy theory: Was he canned because of persecution from aberrant packaging? =) Ok... bad joke. >>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 usptream 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 > > > For gkrellm is this necessary? rpm considers 2.1.7a newer than > 2.1.7 already unless something has changed. Another package of > this nature is UW imap. It is generally released with an integer > based version number of the year of it's release, possibly > followed by a single letter indicating a revision within that > year. ie: imap-2000 imap-2000a imap-2000b > > In rpm's normal operation these packages are naturally treated as > the older package on the left, with the newer ones proceeding to > the right. > > My personal preference would be to just let rpm assume that as it > should work. I've never gotten bug reports of it not working > anyway. Moving things from the version to the release field > unnecessarily just complicates packaging when there's no real > benefit IMHO. For the pre-release cases above it makes sense as > it's being done in order to override rpm's default behaviour, > which would be to treat what is a final release as older than a > prerelease. > > I believe treating both pre-release and post-release in the same > manner just for consistency with both types of lettered versioned > packages is just cosmetic consistency, but doesn't provide any > functional or technical benefit. In other words, sticking with > the upstream version in the version field is IMHO best unless > there is a technical benefit of doing so, such as avoiding having > to later use Epoch to override a prerelease build. > > 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. >>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 > > > 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 "." I personally actually prefer the "." separator, but I really don't care which is chosen. Warren From jkeating at j2solutions.net Fri Oct 31 16:28:06 2003 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 31 Oct 2003 08:28:06 -0800 Subject: x86_64 issues, etc. In-Reply-To: References: Message-ID: <200310310828.07451.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 30 October 2003 12:29, Justin M. Forbes wrote: > If there is anything else I can do to assist, please let me know via > email or irc. > > There has been quite a bit of interest in this platform, and with AMD > pushing it as a home user system as well, I think that interest will > continue to grow. Justin, you totally rock! If you really make a go at it, I'll include amd64 packages through the Legacy system. - -- 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/oo2W4v2HLvE71NURArQVAKCt1E/RmPE/XqBOXpAqxpISrZ9UJwCdGH1D OSU1YbExhhRGdm6kmk/nUcU= =ZtdI -----END PGP SIGNATURE----- From den at tourinfo.ru Fri Oct 31 15:27:15 2003 From: den at tourinfo.ru (Den) Date: Fri, 31 Oct 2003 18:27:15 +0300 Subject: Mozilla 1.4.1 Russian translation In-Reply-To: <3FA26AAF.10900@asplinux.ru> References: <3FA267AE.2080103@tourinfo.ru> <3FA26AAF.10900@asplinux.ru> Message-ID: <3FA27F53.1080804@tourinfo.ru> Grigory Bakunov wrote: > Hello, Dan! > Just add RFE to bugzilla and attach your files to it. > Done. Request with number #108719 added. From Nicolas.Mailhot at laPoste.net Fri Oct 31 15:47:31 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 31 Oct 2003 16:47:31 +0100 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: <1067615251.2792.1.camel@ulysse.olympe.o2t> Le ven 31/10/2003 ? 15:31, Warren Togami a ?crit : > Mike A. Harris wrote: > > 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 "." > > 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:) 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 warren at togami.com Fri Oct 31 15:48:25 2003 From: warren at togami.com (Warren Togami) Date: Fri, 31 Oct 2003 05:48:25 -1000 Subject: x86_64 issues, etc. In-Reply-To: References: Message-ID: <3FA28449.9040204@togami.com> Justin M. Forbes wrote: > > Second, I am setting up another AMD64 system to use for builds, etc for > packages where people do not have the hardware to build or test on. Just > let me know where the SRPM is and I will build and QA against AMD64 to > ensure the platform is well supported with not just core but extras. May I recommend trying to get vserver kernel patch working on the AMD64 kernel, that way you can securely give root access to other developers, and each would have their own independent chroot where they can use yum to add/remove packages... a very necessary part in the process of developing packages. Apache can be running in another vserver instance locally to act as a local yum source. Give the developer vservers a different IP address and use iptables to lockdown network access, so nothing can get out except packets belonging to their incoming SSH connection. (Prevent any chance of abuse.) Warren From pmatilai at welho.com Fri Oct 31 16:02:20 2003 From: pmatilai at welho.com (Panu Matilainen) Date: 31 Oct 2003 18:02:20 +0200 Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: <1067615251.2792.1.camel@ulysse.olympe.o2t> References: <3FA229D3.4000104@togami.com> <3FA2722D.6090504@togami.com> <1067615251.2792.1.camel@ulysse.olympe.o2t> Message-ID: <1067616140.5207.20.camel@chip.ath.cx> On Fri, 2003-10-31 at 17:47, Nicolas Mailhot wrote: > Le ven 31/10/2003 ? 15:31, Warren Togami a ?crit : > > Mike A. Harris wrote: > > > > 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 "." > > > > 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:) Heh, why not make it @ .. it sorta even has a meaning "foo-1.2.3 at (==for) RHL 9": foobar-1.2.3-1 at 0.9.i386.rpm. Looks lovely doesn't it :) - Panu - From rdieter at math.unl.edu Fri Oct 31 16:11:57 2003 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 31 Oct 2003 10:11:57 -0600 Subject: Warren's Package Naming Proposal - Revision 1 In-Reply-To: <20031031091802.29536.71275.Mailman@listman.back-rdu.redhat.com> References: <20031031091802.29536.71275.Mailman@listman.back-rdu.redhat.com> Message-ID: <3FA289CD.1040507@math.unl.edu> Warren wrote: > > C-4. Dist tag OK, here's the good part... (-: > ------------- > 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} ... > Example: > foobar-1.2.3-1_0.7.3.i386.rpm Did you mean %{X}_%{disttag} or %{X}.%{disttag}?? I guess either one works, as long as you're consistent. -- Rex From 64bit_fedora at comcast.net Fri Oct 31 16:54:18 2003 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Fri, 31 Oct 2003 10:54:18 -0600 (CST) Subject: x86_64 issues, etc. In-Reply-To: <3FA28449.9040204@togami.com> Message-ID: I would love to, but would have to work out the logistics... I am an individual, with regular cable net access to this system, so it is DHCP and I only get one address. In the meantime I can take existing SRPMs and do the build for AMD64 on this system without problem. Hopefully at some point I can look at giving others access, etc. Justin On Fri, 31 Oct 2003, Warren Togami wrote: > Justin M. Forbes wrote: > > > > Second, I am setting up another AMD64 system to use for builds, etc for > > packages where people do not have the hardware to build or test on. Just > > let me know where the SRPM is and I will build and QA against AMD64 to > > ensure the platform is well supported with not just core but extras. > > May I recommend trying to get vserver kernel patch working on the AMD64 > kernel, that way you can securely give root access to other developers, > and each would have their own independent chroot where they can use yum > to add/remove packages... a very necessary part in the process of > developing packages. Apache can be running in another vserver instance > locally to act as a local yum source. > > Give the developer vservers a different IP address and use iptables to > lockdown network access, so nothing can get out except packets belonging > to their incoming SSH connection. (Prevent any chance of abuse.) > > Warren > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From tlane at lyrical.net Fri Oct 31 16:56:32 2003 From: tlane at lyrical.net (Tyler Lane) Date: Fri, 31 Oct 2003 09:56:32 -0700 Subject: RHN and Fedora Core Message-ID: <3FA29440.5090406@lyrical.net> I am not sure if this is the correct list to ask this question, but hopefully someone can answer it or send me to the correct place. Will Fedora Core still use RHN? Or will our current subscriptions for RHN only work for RHL9 and earlier? -- Tyler Lane -------------- 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 Fri Oct 31 17:00:06 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 31 Oct 2003 18:00:06 +0100 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: <20031031180006.1b3cad50.ms-nospam-0306@arcor.de> On Fri, 31 Oct 2003 04:31:09 -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. > >> > >>Example (pre-release): > >> mozilla-1.4a.tar.gz from usptream 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 > > > > > > For gkrellm is this necessary? rpm considers 2.1.7a newer than > > 2.1.7 already unless something has changed. Another package of > > this nature is UW imap. It is generally released with an integer > > based version number of the year of it's release, possibly > > followed by a single letter indicating a revision within that > > year. ie: imap-2000 imap-2000a imap-2000b > > > > In rpm's normal operation these packages are naturally treated as > > the older package on the left, with the newer ones proceeding to > > the right. > > > > My personal preference would be to just let rpm assume that as it > > should work. I've never gotten bug reports of it not working > > anyway. Moving things from the version to the release field > > unnecessarily just complicates packaging when there's no real > > benefit IMHO. For the pre-release cases above it makes sense as > > it's being done in order to override rpm's default behaviour, > > which would be to treat what is a final release as older than a > > prerelease. > > > > I believe treating both pre-release and post-release in the same > > manner just for consistency with both types of lettered versioned > > packages is just cosmetic consistency, but doesn't provide any > > functional or technical benefit. In other words, sticking with > > the upstream version in the version field is IMHO best unless > > there is a technical benefit of doing so, such as avoiding having > > to later use Epoch to override a prerelease build. > > > > 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. * 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. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri Oct 31 17:55:53 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 31 Oct 2003 19:55:53 +0200 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: <1067622953.20763.164.camel@bobcat.mine.nu> 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? From mike at flyn.org Fri Oct 31 17:56:56 2003 From: mike at flyn.org (W. Michael Petullo) Date: Fri, 31 Oct 2003 11:56:56 -0600 Subject: gconfd-2 does not exit when a user log out, breaks unmounting home In-Reply-To: <1067577613.15833.61.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> Message-ID: <20031031175656.GA1020@imp.flyn.org> >> Your second solution may be something that could be generalized to be >> quite useful -- perhaps freedesktop.org material? Other projects, >> like the venerable esd, have problems similar to gconfd. Esd can lock >> down a system's audio device for a while after a user logs out. I'll have >> to spend a little time looking at xscreensaver, gnome-settings-daemon, >> etc. > My eventual thought is that dbus could perform this function; the > per-session message bus is tied exactly to the lifetime of the user's > session, and thus performs the same function as the X server. (Most apps > exit on logout because they lose their X server connection.) dbus itself > already has a mechanism where it can be tied to the X server lifetime or > the login session's pty. Very nice. >> Your first solution seems simple enough. I included a very unsophisticated >> patch that performs the task (vs. gnome-session 2.4.0). Comments? > It looks sane to me, thanks. I'd file it on bugzilla.gnome.org, and also > make a bugzilla.redhat.com bug with a link to the gnome.org bug (or use > an existing bug if someone already opened it) to remind us to backport > the patch if needed, since we'll probably still be on GNOME 2.4 in the > next Fedora Core release. We could also do a bugfix update to Fedora > Core 1 once the freeze is over. I attached the patch to GNOME Bugzilla #97361 and mentioned the GNOME report in Red Hat Bugzilla #67605. I'd really like to see a fix in Fedora once it thaws. -- Mike :wq From alan at redhat.com Fri Oct 31 20:32:25 2003 From: alan at redhat.com (Alan Cox) Date: Fri, 31 Oct 2003 15:32:25 -0500 (EST) Subject: Run prelink and other stuff not in cron but when screensaver is active. In-Reply-To: <20031030104630.GA1963@redhat.com> from "Tim Waugh" at Hyd 30, 2003 10:46:30 Message-ID: <200310312032.h9VKWP605083@devserv.devel.redhat.com> > > 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 From johnsonm at redhat.com Fri Oct 31 20:40:56 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 31 Oct 2003 15:40:56 -0500 Subject: Schedule slip Message-ID: <20031031154056.A4480@devserv.devel.redhat.com> We had to respin FC1 today for a non-technical issue (that's all I can say, sorry), which resets the clock for release. We have to start over again with the export process, and I don't think they work weekends, so we have to slip until after we hear back from them and then sync to mirrors. Wednesday the 5th is slightly possible, a day later more likely. We did at least pull in a few technical fixes as well whil we were at it. Sorry about 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 notting at redhat.com Fri Oct 31 21:00:30 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 31 Oct 2003 16:00:30 -0500 Subject: XFree86 & Neomagic: DRI missing? In-Reply-To: <1067553383.10678.12.camel@guru.puzzled.xs4all.nl>; from fedora@puzzled.xs4all.nl on Thu, Oct 30, 2003 at 11:36:23PM +0100 References: <1067553383.10678.12.camel@guru.puzzled.xs4all.nl> Message-ID: <20031031160030.B13212@devserv.devel.redhat.com> Patrick (fedora at puzzled.xs4all.nl) said: > Fully updated Fedora as of Oct 30, 23:15 CET. When I run glxgears it > complains: Xlib: extensions "XFree86-DRI" missing on display ":0.0". > > I thought 3D hardware acceleration was supported on the Neomagic NM2200. The chip supports it, IIRC. But implementing it requires access to docs/specs, and the time and inclination to do it. Bill From keithl at kl-ic.com Fri Oct 31 21:31:43 2003 From: keithl at kl-ic.com (Keith Lofstrom) Date: Fri, 31 Oct 2003 13:31:43 -0800 Subject: Enhanced Logrotate from Suse Message-ID: <20031031213143.GB18168@gate.kl-ic.com> /usr/sbin/logrotate is the program that moves and renames files in /var/log. On Redhat systems, it typically does this by numbering and renumbering - messages becomes messages.1, .1 becomes .2, etc. This makes life difficult for rsync backups, which saves each copy of each renumbered file. Ruediger Oertel at Suse (ro at suse.de) has some patches that enhance the basic Redhat Logrotate with "dateext". This allows a dated extension rather than a numbered one, i.e. messages.29102003 . The old logfiles do not get renamed, just discarded after they get too old. This is a lot easier on rsync, and it also is easier to administer. Ruediger's patches do not change the current logrotate behavior, just adds the new features. His patch to logrotate 3.6.10 can be found at: ftp.suse.com/pub/people/ro/logrotate Suse has been making these patches to RH logrotate for years, and I've been running versions of their code for a few weeks while still using the old logrotate method for testing. It would be nice to fold this into the main line of fedora/redhat and eliminate a needless code fork. Who do I talk to in order to make this happen? Keith BTW, this is the third attempt at sending this, though perhaps the first clueful attempt ... :-) -- 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 mike at flyn.org Fri Oct 31 21:42:56 2003 From: mike at flyn.org (W. Michael Petullo) Date: Fri, 31 Oct 2003 15:42:56 -0600 Subject: More loitering process curiosities In-Reply-To: <20031031175656.GA1020@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> Message-ID: <20031031214256.GA7403@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. -- Mike :wq From aoliva at redhat.com Fri Oct 31 23:53:38 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 31 Oct 2003 21:53:38 -0200 Subject: Enhanced Logrotate from Suse In-Reply-To: <20031031213143.GB18168@gate.kl-ic.com> References: <20031031213143.GB18168@gate.kl-ic.com> Message-ID: On Oct 31, 2003, Keith Lofstrom wrote: > Ruediger Oertel at Suse (ro at suse.de) has some patches that enhance the > basic Redhat Logrotate with "dateext". This allows a dated extension > rather than a numbered one, i.e. messages.29102003 This is nice! Please file an RFE on bugzilla. -- 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